You can scale VMware Telco Cloud Service Assurance deployment between footprints using VMware Telco Cloud Automation.
VM Sizing for VMware Telco Cloud Service Assurance
|Footprint||VMs||Total vCPU||Total RAM (GBs)|
Scaling on VMware Tanzu Kubernetes Grid using VMware Telco Cloud Automation UI
Depending on the footprint you want to scale up to, increase the replicas of the worker node in your cluster. To increase the number of worker nodes in your cluster, see Edit a Kubernetes Cluster Node Pool in VMware Telco Cloud Automation documentation. For footprint information, see Demo and HA-Based System Requirements.
Steps to Scale VMware Telco Cloud Service Assurance through VMware Telco Cloud Automation UI
ScaleCNFoperation provided in CNF.
- (Optional) Run the installer script to push new artifacts to the registry. For more information, see Push Artifacts to Registry.
To scale VMware Telco Cloud Service Assurance on VMware Tanzu Kubernetes Grid using VMware Telco Cloud Automation, see Scaling on VMware Tanzu Kubernetes Grid using VMware Telco Cloud Automation UI.
- Run the merge-product-yaml-files.sh script as described in Generate a Single Merged YAML File.
Note: Enter the destination footprint value while generating the merged_yamls.yaml file.
- Update the values for the parameters in the merged_yamls.yaml file which is generated in step 2 as shown in the following screenshot. Set them to the same values used during initial deployment.
- Update the statusChecker.enabled parameter. The default value is
true. Set the value as
- Update the retentionInterval value with the same value used during initial deployment.
- If scaling from one footprint to another, update the following parameters in the merged_yamls.yaml file to the required footprint.
Note: Based on the footprint size of deployment, update the value for footprint.
- Update the additionalValuesFile parameter in the merged_yamls.yaml file based on the retention interval value. The following screenshot is an example of a demo footprint.
- In the following screenshot, retention interval is set to 1w as an example.
- If deploying MinIO as a gateway, or if you want to use AWS storage for backup and restore, update the values for
backupbucketnamein the merged_yamls.yaml file which is generated in step 2 as shown in the following screenshot:
If you are deploying MinIO as local PV, then there is no need to update the parameters specified in step 4.Note: If scaling from one footprint to another, update the values for the parameters specified from step 3 through step 4. You must obtain the values for the parameters from the base footprint deployment.
- Click TCSA CNF and select Scale.
- Upload the updated merged_yamls.yaml file which is generated in step 2 in VMware Telco Cloud Automation.
- Click .
tcxproduct) using the kubectl command.
root [ ~/tcx-deployer/scripts ]# kubectl get tcxproduct NAME STATUS READY MESSAGE AGE tcsa-201-abe98-7vckg updateCompleted True All App CRs reconciled successfully 41m root [ ~/tcx-deployer/scripts ]# kubectl get tcxproduct tcsa-201-abe98-7vckg
- The deployment time for VMware Telco Cloud Service Assurance can vary based on scale. So, the
kubectl get tcxproduct <instance-name> -wcommand must run according to scale.
- A successful instantiation shows the following fields:
- STATUS: updateCompleted
- READY: True
- Message: All Apps CRs reconciled successfully