Upgrade the Virtual Appliance in Microsoft Azure

Upgrading the Virtual Appliance involves:

  • Backing up and deleting the hard disks of the existing virtual machines.
  • Deploying new virtual machines by using VHD image.
  • Restoring the backup to their hard disks.
  • Attaching the new hard disks to the older virtual machines

Splunk AppDynamics On-Premises Virtual Appliance provides the reference script that helps in upgrading the Virtual Appliance.

Note: This document contains links to Microsoft Azure documentation. Splunk AppDynamics makes no representation as to the accuracy of Microsoft Azure documentation because Microsoft Azure controls its own documentation.

Follow the steps to upgrade the Virtual Appliance in Microsoft Azure.

Back Up the Virtual Appliance Data

Before you begin the upgrade, complete the following steps:

  1. Download the Virtual Appliance upgrade VHD file:
    1. Log in to the Downloads portal using your credentials.
    2. In Downloads, select the Virtual Appliance tab.
    3. Select VHD from the Type list.
    4. Select Download.
    Note: The file available in the downloads portal is used for both installation and upgrade procedures.
  2. Shutdown the Secure Application, Anomaly Detection, and remaining services. Then, shutdown Splunk AppDynamics.
    CODE
    appdcli stop secapp
    appdcli stop aiops
    appdcli stop [services]
    appdcli stop appd
    <<Wait for pods to terminate before deleting operators>>
    appdcli stop operators
    Note:
    • Ensure that there are no pods in the running state before you start the data backup.

    • Sometimes, IOException error occurs in the Controller UI. See Troubleshoot Virtual Appliance Issues
    .
  3. Optional: Create a migration script for custom actions. See Migrate Custom Actions.
  4. Generate a backup file.

Migrate Custom Actions

The custom actions path has changed from the previous release. Create and run the following script to migrate custom actions during the upgrade.

  1. Create a migration script for custom actions (custom-actions-migrate.sh) in /var/appd/config .
  2. Edit custom-actions.migrate.sh.
    CODE
    vi /var/appd/config/custom-actions-migrate.sh
    JSON
    #!/usr/bin/env bash
    
    set -euo pipefail
    
    # Configuration
    OLD=/var/appd/data/custom-actions
    NEW=/var/appd/config/custom-actions
    ARCHIVE=${2:-custom-actions.tgz}
    
    case "${1:-}" in
        backup)
            test -d "$OLD/actions" || { echo "No custom actions found at $OLD/actions"; exit 1; }
            
            sudo tar -C "$OLD" -czf "$ARCHIVE" actions
            echo "Backup created: $ARCHIVE"
            ;;
    
        restore)
            test -f "$ARCHIVE" || { echo "Backup file not found: $ARCHIVE"; exit 1; }
            
            sudo mkdir -p "$NEW"
            sudo tar -C "$NEW" -xzf "$ARCHIVE"
            
            # Set permissions
            sudo chown -R appduser:appduser "$NEW/actions"
            sudo find "$NEW/actions" -type d -exec chmod 755 {} \;
            sudo find "$NEW/actions" -type f -exec chmod 755 {} \;
            
            echo "Restored custom actions to $NEW/actions"
            ;;
    
        *)
            echo "Usage: $0 backup [custom-actions.tgz] | restore <custom-actions.tgz>"
            exit 1
            ;;
    esac
  3. Change permissions of the migration script.
    CODE
    chmod +x /var/appd/config/custom-actions-migrate.sh
  4. Sync custom actions to the running controller.
    CODE
    appdcli controller actions_sync
  5. Create a custom action archive.
    CODE
    ./custom-actions-migrate.sh backup custom-actions.tgz
Generate a Backup File

Generate a Backup File

Follow the steps to generate a backup file and save it outside the cluster:
  1. Run the backup command:
    CODE
    appdcli run backup
    This command generates a <backup_tar> file with all the necessary data.
  2. Copy and paste the <backup_tar> file outside of the cluster. If you have custom certificates, copy them to the same location as the backup file.

Prepare the Microsoft Azure for the Upgrade

To upgrade virtual machines in Azure, you must create a image and snapshot from the new VHD. However, you can use the same Resource Group, Network Security Group, Virtual Network, and Storage Account that you have created at the time of deployment. See Deploy and Configure Virtual Machines in Microsoft Azure.

Note: To use Azure CLI, you require the reference scripts. Download these script from the Splunk AppDynamics GitHub repository. Ensure to update or verify the configuration details in config.cfg such as tags, deployment configuration, and IP addresses. Run these scripts in the given order.

For more information about Azure CLI, see Azure CLI Documentation.

Azure Resources Description Reference Scripts
1 Disk

Upload the VHD image to a storage account. Create a disk by using the URI of the VHD file.

05-azure-create-disk.sh
2 Image Gallery

An image is a copy of the disk. Image gallery is a place where you can store and share the image to create multiple virtual machines.

  1. Create an image gallery.

  2. Update the shared image definition and version.

See

See Store and share images in an Azure Compute Gallery.

06-azure-image-gallery.sh

07-azure-shared-image-def.sh

08-azure-shared-image-version.sh

Upgrade the Virtual Appliance

Note: Download the upgrade script from the Splunk AppDynamics

GitHub repository

. We recommend that you run the scripts in the given order.

Run the upgrade scripts in the given order:

Step Filename
1 Obtain the details of the virtual machine. 01-azure-get-vm-details.sh
2 Shutdown the virtual machine. 02-azure-power-off-vm.sh
3 Associate a NIC to the virtual machine 03-azure-associate-dummy-nic.sh
4

Disassociate the NIC from the virtual machine.

Detach the data disk from the virtual machine.

04-azure-disassociate-nic-and-data-disk.sh
5 Delete the virtual machine. 05-azure-delete-vms.sh
6 Create a virtual machine. 06-azure-create-vms.sh

Verify whether the data directories exist in the following location:

CODE
/var/appd/data

Verify the Deployment Status

Verify the deployment of virtual machines:

  1. Verify whether the deployment of virtual machines are successful:
    CODE
    appdctl show boot
    Note: Ensure the status of the services in each node. If any service appears as Failed, restart that virtual machine. You might have to redeploy the virtual machine if it is still failing.
  2. Create a three-node cluster:
    1. Run the following command in the primary node and specify the IP address of the peer nodes:
      CODE
      appdctl cluster init <Node-2-IP> <Node-3-IP>
    2. Run the following command to verify the node status:
      CODE
      appdctl show cluster
      microk8s status
      Ensure that the output displays the Running status as true for the nodes that are part of the cluster.

      Sample Output

      CODE
      NODE           | ROLE  | RUNNING
      ----------------+-------+---------
      10.0.0.1:19001 | voter | true
      10.0.0.2:19001 | voter | true
      10.0.0.3:19001 | voter | true
      Note: You must re-login to the terminal if the following error appears:
      CODE
      Insufficient Permissions to Access Microk8s

Restore Data in the Virtual Appliance

  1. Copy the <backup_tar> file to one of the cluster nodes that is generated earlier. See Prerequisites.
  2. Run the following command to restore the persistent volumes specifications:
    CODE
    appdcli run restore <backup_tar>
  3. Restore custom actions to a new location.
    CODE
    ./custom-actions-migrate.sh restore custom-actions.tgz
  4. Restore self-signed CA ingress certificates.A prompt is displayed "Do you want to restore self-signed ingress certificates?" Enter 0 for No or 1 for Yes".
    • Choose 0 if you have configured the certificates for DNS.
    • Choose 1 to configure the certificates.
  5. Verify the PVC are in theBound state by running the following command:
    CODE
    kubectl get pvc -A
  6. Start the following services and operators:
    1. Splunk AppDynamics Services.
      CODE
      appdcli start appd [Profile]
    2. Anomaly Detection Service.
      CODE
      appdcli start aiops [Profile]
    3. Secure Application Service.
      CODE
      appdcli start secapp [Profile]
    4. Start the remaining services.
      CODE
      appdcli start [Services] [Profile]
    Note: Sometimes, the MySQL Router pods might fail to start. See MySQL Router Pods Fail to Start.
After the upgrade, the cluster uses the existing data disk and becomes functional.

Migrate EUM and Synthetic Services Data to MinIO

If you are running EUM and Synthetic services, you must migrate the existing data in these services to MinIO. To migrate data, you must run the migration script. Complete the following steps to enable data migration:
  1. Log in to the Virtual Appliance node and edit the globals.yaml.gotmpl file.
    CODE
    cd /var/appd/config
    vi globals.yaml.gotmpl
  2. Enable data migration for Minio, set the minio.migration.enable parameter to true.
    CODE
    minio:
      migration:
        enable: true
  3. Sync the changes across all the cluster nodes.
    CODE
    appdcli sync appd <profile>

Generate the Hybrid Configuration File

You require to generate hybrid configuration file only if you are not using custom certificates for Ingress and Kafka clusters.

Ensure that you have the latest CA certificates obtained after installing services. If not, update the CA certificates and regenerate the hybrid configuration file after restarting the service.

  1. Run the script to connect the Kafka node ports with the standalone Controller:
    CODE
    ~/appd-charts/utils$ bash prepare-hybrid.sh

    Sample output:

    CODE
    Writing Kafka CA Cert
    Writing Schema registry CA Cert
    Writing AnomalyDetectionKafkaSSLProducer
    Writing AnomalyDetectionKafkaConsumerSSL
    Writing configure script
    Creating archive of hybrid config
    hybrid-config/
    hybrid-config/kafka-ca.crt
    hybrid-config/AnomalyDetectionKafkaConsumerSSL
    hybrid-config/configure.sh
    hybrid-config/schema-registry-ca.crt
    hybrid-config/AnomalyDetectionKafkaSSLProducer
    Completed

    This script generates the hybrid-config.tar file that includes the required configuration files.

  2. Copy the hybrid-config.tar file to your standalone Controller instance.
  3. Log in to the standalone Controller.
    1. Locate and extract the hybrid-config.tar file contents.
      CODE
      tar -xvf hybrid-config.tar
    2. Run the configure.sh script to provision the Controller with certificates and secrets to connect to the Kubernetes cluster:

      The following script is extracted from the hybrid-config.tar file.

      CODE
      $ ./configure.sh
      Output:
      CODE
      Using controller home as /home/appdynamics/appdynamics and keystore password as changeit
      Do you want to proceed? (y/n): y
      
      Creating Kafka truststore
      Certificate was added to keystore
      
      Creating schema registry truststore
      Certificate was added to keystore
      Certificate was added to keystore
      
      Writing obfuscated producer config
      Writing obfuscated consumer config
      
      Configure MySQL for SSL
      Using controller ip as <IP>
      Is this IP address correct? (y/n): y
      
      DNS name should match the Virtual Appliance cluster hybrid dbHost configuration
      Please enter the DNS name (default: 10.0.0.1.nip.io): <DNS_Name_of_Classic_On_Premises_Controller>
      
      Using controller IP as 10.0.0.1
      Updating certs at /home/appdynamics/appdynamics/platform/controller/db/data using CA key file ca-key.pem and cert file ca.pem
      Certificate request self-signature ok
      subject=CN = mysql
      MySQL certificate generated successfully: server-cert.pem
      Completed
    Note:

    Certificates in the Virtual Appliance expire after 60 days. To maintain connectivity, you must copy the updated certificates from the Virtual Appliance to your Splunk AppDynamics On-Premises Classic Controller. To do this, regenerate the hybrid configuration file on the Virtual Appliance and then copy it to your Standalone Controller.