Upgrade VMware Telco
Cloud Service Assurance CNF
VMware Telco
Cloud Service Assurance
CNFIn this section, you can find information on how to upgrade the
tcsa
CNF.- Launch VMware Telco Cloud Automation and navigate to .
- To upgrade, select the base version of thetcsaCNF and click the vertical ellipsis (⋮) and clickUpgrade.
- In theUpgrade Revisionsection, select the version of thetcsaCNF that you want to upgrade to and clickNext.
- In theInventory Detailsection, select theNamespaceastcsa-systemand select theRepo URLas<oci://<registryRootUrl>>, and clickNext.Use the sameregistryRootUrlas specified during thepush artifacts to registrystep.
- In theInputssection, update the following parameters:The following parameters can be updated by referrening the output of thepopulateTcsaValuesYaml.shscript.
- SetregistryRootUrlto the regsitry URL used while pushing the artifacts.
- SetdashboardAccess.ipto the same IP address as specified during the earlierVMware Telco Cloud Service Assurancedeployment.
- SetdashboardAccess.typeto the same value as specified during the earlierVMware Telco Cloud Service Assurancedeployment.
- Setfootprintproduction.If the base version is 25K or higher, then update the footprint as production.
- SetedgeServicesAccessIpto the same value as specified during the earlierVMware Telco Cloud Service Assurancedeployment.
- All the Backup and Restore values must be same as specified during the earlierVMware Telco Cloud Service Assurancedeployment.
- If AWS S3 is used for backup, then update the following parameters:backupAndRestore.minioDatastoreType backupAndRestore.bucketName backupAndRestore.s3AccessKey backupAndRestore.s3SecretKey
- If VMware vSAN or NFS file service is used for backup, then update the following parameters:backupAndRestore.minioDatastoreType backupAndRestore.nfsProvisionerEnabled backupAndRestore.bucketName backupAndRestore.nfsServer backupAndRestore.nfsPath
- The default value for thehealthMonitoring.s3BucketNamefield isprometheus-metrics. You must change this default value if you are creating multipleVMware Telco Cloud Service Assuranceinstances while you are using NFS or AWS S3 bucket.
- The following configuration parameters must be updated by referring thevalues-user-overrides.yamlfile.
- flexibleConfig.managedDevices
- flexibleConfig.incomingEvents
- flexibleConfig.incomingMetrics
- flexibleConfig.percentMetricsForAnomaly
- flexibleConfig.percentMetricsForAlarms
- flexibleConfig.retentionInterval
- (Optional)The following parameters belong to a flexible scaling parameter for retention interval and are optional.flexibleConfig.retentionIntervalForLongTermData.metricHourlyRollupDataFor example, If the default value for the Flexible Scaling Parameter formetricHourlyRollupDataretention 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.metricDailyRollupDataFor example, If the default value for the Flexible Scaling Parameter formetricDailyRollupDataretention 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.metricWeeklyRollupDataFor example, If the default value for the Flexible Scaling Parameter formetricWeeklyRollupDataretention 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 Flexible Scaling Parameter for Event History data retention (in Days | Example:31d)For example, If the default value for the Flexible Scaling Parameter foreventHistoryretention 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.alertsForOIServerPerSecFor example, If the default value for the Flexible Scaling Parameter foralertsForOIServerPerSecretention 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.noOfTrapsOrSyslogPerSecFor example, If the default value for the Flexible Scaling Parameter fornoOfTrapsOrSyslogPerSecretention 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.The total values ofalertsForOIServerPerSecandnoOfTrapsOrSyslogPerSecmust be less than or equal to 200.
- While upgrading fromVMware Telco Cloud Service Assurance2.1 or 2.2 to 2.3 or 2.3.1 to 2.4, setskipKafkaEdgeRawTopicCreationtotrue. While upgrading from 2.3.0 or 2.3.1 to 2.4.0, setskipKafkaEdgeRawTopicCreationtofalse.
- ClickNext.
- UnderNetwork Function Properties, clickNext.
- In theReviewsection, clickUpgrade.
- After the upgrade is complete, you can see the state as completed as shown in the following screenshot.
Once the upgrade is shown as completed inVMware Telco Cloud AutomationUI, in the background the application continues to deploy.You can manually check theVMware Telco Cloud Service Assurancedeployment status by running the following command from deployment VM.root [ ~/upgrade/tcx-deployer/scripts ]# kubectl get tcxproduct -A OR root [ ~/upgrade/tcx-deployer/scripts ]# kubectl get apps -AFor all the apps, the reconciliation status must be successful.kubectl get tcxproduct -A NAMESPACE NAME STATUS READY MESSAGE AGE tcsa-system tcsa-240-48742-p2fmq updateCompleted True All App CRs reconciled successfully 39m tps-system tcx-platfor-9037e-pdyey-tcx-platform-services updateCompleted True All App CRs reconciled successfully 49mAfter successful deployment, you can launch the VMware Telco Cloud Service Assurance UI. For more information, see Accessing UI topic. Ensure that theAboutpage in VMware Telco Cloud Service Assurance UI reflects the upgraded version of VMware Telco Cloud Service Assurance.If all the apps are not reconciled, the deployment fails. For more information, see VMware Telco Cloud Automation Upgrade topic in theVMware Telco Cloud Service Assurance Troubleshooting Guide. - After the upgrade is successful, you must execute thepostUpgrade.shscript for cleaning the stale entries from the deployer host.$TCSA_WORK_SPACE/tcx-deployer/scripts/postUpgrade.sh <your-kubeconfig-location>
- After theVMware Telco Cloud Service Assuranceupgrade is successful, follow the steps mentioned in the Post Upgrade topic.
After the
VMware Telco
Cloud Service Assurance
upgrade is successful, follow the
steps mentioned in the Post Upgrade topic.After perfoming the steps in the Post Upgrade, you must upgrade all the remote data
collector managers. For more information, see Upgrading Remote Collector Manager.
If you do not have a remote data collector
manager then you can skip this step.
After perfoming the steps in the Upgrading Remote Collector Manager, you must upgrade the domain managers as
mentioned in the Upgrade Domain Manager topic.
If there are any SSL Handshake errors and
the discovery fails in the Domain Managers while discovering VMware Aria Operations,
.
VMware Telco Cloud Automation
, Cisco ACI,
VCD, and VIMS after upgrading the Domain Manager and VMware Telco
Cloud Service Assurance
Core then to regenerate the Kafka Edge
Certificate follow the procedure given in the SSL
Handshake Error Post TCSA and Domain Manager Upgrade topic given in the VMware Telco
Cloud Service Assurance
Troubleshooting Guide