Configuration for Production Footprint

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

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

To deploy VMware Telco Cloud Service Assurance on Azure, configure the following parameters in the values.yaml file available in $TCSA_WORK_SPACE/tcx-deployer/product-helm-charts/tcsa.

Note: Ensure that you obtain the ACR registry details such as URL, user name, and password from the ACR registry section in Azure website.

Set ACR 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: <your-acr-instance>.azurecr.io/tcx

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 static IP address of your cluster and type as LoadBalancer.

dashboardAccess:
  # (string) The IP address for accessing the dashboard. If using a static pre-allocated IP, set this property on Day 0 (fresh deployment). If using a dynamically allocated IP, set this on Day 1 (post deployment)
  ip: <IPAddress1>
  # Can be either NodePort or LoadBalancer. Defaults to NodePort for TKG and LoadBalancer for Azure/AWS. 
  type: LoadBalancer

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. For procedure, refer VMware Telco Cloud Service Assurance UI Access Using FQDN.

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. Leave empty for EKS public networks.
edgeServicesAccessIp: <IPAddress2>

Set resourceGroup to the name of the Azure resource group.

# (map) aks holds AKS specific configuration
aks:
  # (string) resourceGroup is the name of the Azure resource group.
  resourceGroup:

Set privateNetwork to true.

# ----IaaS configuration----
# (bool) privateNetwork indicates if TCSA is being deployed on a private EKS or AKS network
privateNetwork: true

Set cloud provider as azure for deploying VMware Telco Cloud Service Assurance on Azure.
```
# (string) cloud indicates the cloud/K8s provider. Valid values are "tkg", "aws", "azure" and "on-prem"
cloud: azure
```
- For Kubenet network plug-in, IPAddress1 and IPAddress2 must be specified in the values.yaml file.
  IPAddress1 is a public IP and must be created in the same region and resource group where AKS cluster is created. IPAddress1 is the IP address VMware Telco Cloud Service Assurance and IPAddress2 is the IP address of Edge Kafka.
  1. If using Azure CNI plug-in, IPAddress1 and IPAddress2 must be set to empty.
  2. If using Kubenet plug-in, IPAddress1 and IPAddress2 must be set to valid IP address as follows:
    - For the public networks, get Azure public IPs using the az CLI. For more information, see Azure Network Public IP.
    - For the private network, get IP addresses from the subnet used for the AKS cluster private network. You can use the az CLI to list free IP addresses in a subnet. For more information, see Azure Network VNet.
      
      Set privateNetwork to true.

To deploy 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.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 10 million metrics
  incomingMetrics: 10

Set the value for incomingEvents and managedDevices parameters.

# 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   
# The following example is for 250K events and 20k devices.
  incomingEvents: 250
  managedDevices: 20

Note: The number of Events cannot be less than the number of Devices multiplied by 10.

Set the value for percentMetricsForAlarms parameter based on the VMware Telco Cloud Service Assurance sizing sheet.

# 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: 2

Set the value for percentMetricsForAnomaly parameter based on the VMware Telco Cloud Service Assurance sizing sheet.

# Configure the flexible configuration for different parameters 
flexibleConfig
# The parameter ‘% number of metrics for anomalies’ 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 Anomaly definitions for the resource allocation
  percentMetricsForAnomaly:

Example
flexibleConfig
  percentMetricsForAnomaly: 2

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.

(Optional) Backup and Restore parameters are optional and must be configured only in-case if you are using external AWS or vSAN file services for Backup and Restore operations.

Note: By default, there is a scheduled back which happens everyday and gets stored on the local storage. So its recommended to use AWS or vSAN File Service for Backup and Restore operations.

If AWS 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:
  # The AWS Access key for S3
  s3AccessKey:
  # The AWS Secret key for S3
  s3SecretKey:
 # (bool) Set to true if the storage backed is on NFS. Set ONLY if datastoreType is local or nas
  nfsProvisionerEnabled: false

If VMware vSAN file service 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:
  # (string) The NFS server path. Set only if minioDatastoreType is set to nas
  nfsPath:

Note:

For information on configuring VMware vSAN file services, see Enabling VMware vSAN File Services.
For more information, see Customizing Backup and Restore Configurations.