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)
25 K 9 16 64
50 K 13 16 64
75 K 16 16 64
100 K 18 16 64
125 K 21 16 64
150 K 24 16 64
175 K 27 16 64
200 K 30 16 64

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

You can scale your VMware Telco Cloud Service Assurance deployment by using the ScaleCNF operation provided in CNF.
  1. (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.

  2. 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.
  3. 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.

    1. ingressHostname.product=<LoadBalancerIP>
    2. ingressHostname.edgeServices
    3. registryRootUrl=<your-registry-url/your-project-name/tcx>
    4. Update the statusChecker.enabled parameter. The default value is true. Set the value as false.
    5. Update the retentionInterval value with the same value used during initial deployment.
    6. If scaling from one footprint to another, update the following parameters in the merged_yamls.yaml file to the required footprint.
      • footprint
      • helmOverride.productInfo.footPrint
        Note: Based on the footprint size of deployment, update the value for footprint.
    7. 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.

    8. In the following screenshot, retention interval is set to 1w as an example.
  4. If deploying MinIO as a gateway, or if you want to use AWS storage for backup and restore, update the values for gateway.enabled=true, accesskey, secretkey, and backupbucketname in 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.
  5. Click TCSA CNF and select Scale.
  6. Upload the updated merged_yamls.yaml file which is generated in step 2 in VMware Telco Cloud Automation.
  7. Click Next > Finish.
Manually check the VMware Telco Cloud Service Assurance CNF scaling status by checking for the corresponding Custom Resource ( 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
Note: After running the kubectl command, wait until the following instantiation message is displayed.
  1. The deployment time for VMware Telco Cloud Service Assurance can vary based on scale. So, the kubectl get tcxproduct <instance-name> -w command must run according to scale.
  2. A successful instantiation shows the following fields:
    • STATUS: updateCompleted
    • READY: True
    • Message: All Apps CRs reconciled successfully