You can deploy VMware Telco Cloud Service Assurance on any size based on the flexible scaling configuration.

For more information on sizing, see VMware Telco Cloud Service Assurance Sizing Sheet.

To deploy VMware Telco Cloud Service Assurance on VMware Tanzu Kubernetes Grid, configure the following parameters in the values-user-overrides.yaml file available in $TCSA_WORK_SPACE/tcx-deployer/product-helm-charts/tcsa.
  • Set Harbor registry URL.
    # Default values for tcsa.
    # This is a YAML-formatted file.
    # Customize your TCSA deployment here by configuring the parameters that are exposed.
    # Uncomment the relevant lines and configure them according to your environment.
    .
    .
    # (string) registryRootUrl is the FQDN of the registry that has the artifacts.
    registryRootUrl: <harbor-registry-fqdn>/<project-name>
  • Set the footprint value.
    # (string) footprint is the number of devices monitored by TCSA.
    footprint: production
    Note:
    • For production deployment, you must provide all the flexibleConfig parameter.
  • For dashboardAccess, set the ip with the IP address of your Kubernetes cluster virtual IP and type as NodePort.
    dashboardAccess:
      # (string) The IP address for accessing the dashboard.
      ip: <Kubernetes cluster virtual IP>
      # Can be either NodePort or LoadBalancer. Defaults to NodePort for TKG and LoadBalancer for Azure. 
      type: NodePort
    Note: Configure dashboardAccess with hostname/FQDN if you want to access the VMware Telco Cloud Service Assurance using hostname/FQDN instead of the IP address.
  • Set edgeServicesAccessIp parameter with the IP address used to access Edge Kafka.
    # (string) Set edgeServicesAccessIp to the IP address to be used to access kafka-edge.
    edgeServicesAccessIp: <Kubernetes cluster virtual IP>
  • Set privateNetwork to false.
    # ----IaaS configuration----
    # (bool) privateNetwork indicates if TCSA is being deployed on a private AKS network
    privateNetwork: false
  • Set cloud provider as tkg for deploying VMware Telco Cloud Service Assurance on TKG.
    # (string) cloud indicates the cloud/K8s provider. Valid values are "tkg", "azure" and "on-prem"
    cloud: tkg
For production deployment of VMware Telco Cloud Service Assurance based on the number of Metrics, Events, Devices, Enrichment, Alarm, Anomaly, and Retention Interval, update the values for all the flexible configuration parameters in the values-user-overrides.yaml file.
  • Set the value for incomingMetrics parameter.
    # Configure the flexible configuration for different parameters 
    flexibleConfig:
    # 'incomingMetrics' is to represent the number of Metrics that TCSA should scale to , and it is represented in units of Millions.
      incomingMetrics:
    
    Example
    flexibleConfig:
    # The following example is for 3 million metrics
      incomingMetrics: 3
  • Set the value for incomingEvents and managedDevicesparameters.
    # Configure the flexible configuration for different parameters 
    flexibleConfig:
    # 'incomingEvents' is to represent the number of events that TCSA should scale to , and it is mentioned in units of Thousands.
      incomingEvents:
    # 'managedDevices' is to represent the number of devices that TCSA should scale to, and it is mentioned in units of Thousands.
      managedDevices:
    
    Example   
    flexibleConfig:
    # The following example is for 75k events and 7.5k devices.
      incomingEvents: 75
      managedDevices: 7.5
  • Set the value for percentMetricsForAlarms parameter.
    # Configure the flexible configuration for different parameters 
    flexibleConfig:
    # The parameter ‘% number of metrics for alarms’ it is a one-to-one mapping, which means, the value given for this parameter can be directly taken as the total percentage of the ‘unique metrics’ to calculate Alarm definitions for the resource allocation.
      percentMetricsForAlarms:
    
    Example
    flexibleConfig: 
      percentMetricsForAlarms: 0.25
  • Set the value for percentMetricsForAnomaly parameter.
    # Configure the flexible configuration for different parameters 
    flexibleConfig:
    # The parameter ‘% number of metrics for alarms’ it is a one-to-one mapping, which means, the value given for this parameter can be directly taken as the total percentage of the ‘unique metrics’ to calculate Alarm definitions for the resource allocation.
      percentMetricsForAnomaly:
    
    Example
    flexibleConfig:
      percentMetricsForAnomaly: 0.25
  • (Optional) The following parameters belong to a flexible scaling parameter for retention interval and are optional.
    flexibleConfig:
      retentionIntervalForLongTermData:
        metricHourlyRollupData:

    For example, If the default value for the Flexible Scaling Parameter for metricHourlyRollupData retention is empty. If you do not update this value then by default it is updated to 4w (weeks). If you want to update it then you can update it to 1w or 2w or 3w and so on.

    flexibleConfig:
      retentionIntervalForLongTermData:
        metricDailyRollupData:

    For example, If the default value for the Flexible Scaling Parameter for metricDailyRollupData retention is empty. If you do not update this value then by default it is updated to 1m (month). If you want to update it then you can update it to 1m or 2m or 3m and so on.

    flexibleConfig:
      retentionIntervalForLongTermData:
        metricWeeklyRollupData:

    For example, If the default value for the Flexible Scaling Parameter for metricWeeklyRollupData retention is empty. If you do not update this value then by default it is updated to 1y (year). If you want to update it then you can update it to 1y or 2y or 3y and so on.

    flexibleConfig:
      retentionIntervalForLongTermData:
        eventHistory:

    For example, If the default value for the Flexible Scaling Parameter for eventHistory retention is empty. If you do not update this value then by default it is updated to 31d (days). If you want to update it then you can update it to 1d or 2d or 3d and so on.

  • (Optional) The following parameters belong to a flexible scaling parameter for Alerts for OI Server Per Sec and are optional.
    flexibleConfig:
      alertsForOIServerPerSec:

    For example, If the default value for the Flexible Scaling Parameter for alertsForOIServerPerSec retention is empty. If you do not update this value then by default it is updated to 0. If you want to update it then you can update it to any values between 0 to 200.

  • (Optional) The following parameters belong to a flexible scaling parameter for number of Traps or Syslog Per Sec and are optional.
    flexibleConfig:
      noOfTrapsOrSyslogPerSec:
    For example, If the default value for the Flexible Scaling Parameter for noOfTrapsOrSyslogPerSec retention is empty. If you do not update this value then by default it is updated to 0. If you want to update it then you can update it to any values between 0 to 200.
    Note: The total values of alertsForOIServerPerSec and noOfTrapsOrSyslogPerSec must be less than or equal to 200.
  • Set the value for retentionInterval parameter to the desired retention interval period.
    # Configure the flexible configuration for different parameters 
    flexibleConfig:
      retentionInterval: ''
    Note: By default, the retention interval is 1w. The retention interval values can be 1w, 2w, and so on.
    The following example is for all the optional parameters.
    Example:
    flexibleConfig:
      alertsForOIServerPerSec: #If the value is not given then the default value is taken as 0
      noOfTrapsOrSyslogPerSec: #If the value is not given then the default value is taken as 0
      retentionInterval: ""   # set this to "" or "1w", "2w", "3w"....etc. If set to "" then by default retentionInterval would be 1w
      retentionIntervalForLongTermData:
        metricHourlyRollupData: ""  # set this to "" or "Nw" where N represents the number of weeks eg 1,2,3..., If set to "" then the default value is 4w
        metricDailyRollupData: "" # set this to "" or "Nm" where N represents the number of months eg 1,2,3..., If set to "" then the default value is 1m
        metricWeeklyRollupData: "" # set this to "" or "Ny" where N represents the number of years eg 1,2,3..., If set to "" then the default value is 1y
        eventHistory: "" # set this to "" or "Nd" where N represents the number of weeks eg 1,2,3..., If set to "" then the default value is 31d
    
  • (Optional) Backup and Restore parameters are optional and must be configured only in-case if you are using external AWS S3 or NFS File Service for Backup and Restore operations.
    Note: By default, there is a scheduled backup, which happens everyday and gets stored on the local storage. So its recommended to use AWS S3 or NFS File Service for Backup and Restore operations.
    If AWS S3 is used for backup, then update the following parameters:
    backupAndRestore:
     # (string) minioDatastoreType is the storage backend for minio. Valid options are “s3”, “nas” or “local”
      minioDatastoreType: s3
      # (string) The S3 bucket name. 
      bucketName: <VMbased-TCSA-Backup>
      # The AWS Access key for S3
      s3AccessKey:XXXXXXXXXXXX
      # The AWS Secret key for S3
      s3SecretKey:XXXXXXXXXX
     # (bool) Set to true if the storage backed is on NFS. Set ONLY if datastoreType is local or nas
      nfsProvisionerEnabled: false
    If NFS is used for backup, then update the following parameters:
    backupAndRestore:
    # (string) minioDatastoreType is the storage backend for minio. Valid options are “s3”, “nas” or “local”
      minioDatastoreType: nas
      # (string) the size of the minio storage. Set ONLY if datastoreType is local or nas
      storageSize:
      # (bool) Set to true if the storage backed is on NFS. Set ONLY if datastoreType is local or nas
      nfsProvisionerEnabled: true
      # (string) The IP address/hostname of the NFS server. Set only if minioDatastoreType is set to nas
      nfsServer:xx.xx.xx.xx
      # (string) The NFS server path. Set only if minioDatastoreType is set to nas
      nfsPath:<backup-path>

Note: