AWS での仮想アプライアンスのアップグレード

仮想アプライアンスのアップグレードには以下が含まれます。

  • 既存の仮想マシンのハードディスクのバックアップと削除。
  • AMI イメージを使用した新しい仮想マシンの展開。
  • ハードディスクへのバックアップの復元。
  • 古い仮想マシンへの新しいハードディスクの接続

Splunk AppDynamics オンプレミス仮想アプライアンスは、仮想アプライアンスのアップグレードに役立つリファレンススクリプトを提供します。

注: このページには、AWS のマニュアルへのリンクが含まれています。AWS で自身のマニュアルを管理しているため、Splunk AppDynamics では AWS のマニュアルの精度については一切保証しません。

AWS で仮想アプライアンスをアップグレードするための手順に従ってください。

仮想アプライアンスデータのバックアップ

アップグレードを開始する前に、次の手順を実行します。

  1. ダウンロードポータルから仮想アプライアンスのアップグレード AMI ファイルをダウンロードします。
  2. 仮想アプライアンスをシャットダウンします：
    CODE 
    appdcli stop secapp
appdcli stop aiops
appdcli stop appd
<<Wait for pods to terminate before deleting operators>>
appdcli stop operators
  3. バックアップコマンドを実行します。
    CODE 
    appdcli run backup
    このコマンドは、必要なすべてのデータを含む <backup_tar> ファイルを生成します。
  4. クラスタの外部にバックアップファイルをコピーします。

アップグレードのための AWS 環境の準備

AWS で仮想マシンをアップグレードするには、新しい AMI からイメージとスナップショットを作成する必要があります。ただし、展開時に作成したものと同じ AWS プロファイル、VPC、S3 バケツ、および IAM ロールを使用できます。「AWS での仮想マシンの展開および構成」を参照してください。

注:

AWS CLI を使用するには、参照スクリプトが必要です。Splunk AppDynamics GitHub リポジトリからスクリプトをダウンロードします。config.cfg では、タグ、展開設定、IP アドレスといった設定の詳細を更新または確認するようにしてください。指定された順序でスクリプトを実行してください。AWS CLI の詳細については、「AWS CLI のマニュアル」を参照してください。

AWS で仮想マシンを作成するには、 m5a.4xlarge インスタンスタイプを使用する必要があります。「M5a インスタンス」を参照してください。

AWS リソース 説明 参照スクリプト
1 イメージ

仮想アプライアンスの AMI を生成する S3 バケツに Splunk AppDynamics イメージをアップロードします。「Uploading objects」を参照してください。

 05-aws-upload-image.sh
2 Snapshot

スナップショットは、S3 バケットにアップロードした AMI を使用する際に役立ちます。AMI ID を取得するには、次の手順を完了します。

  1. スナップショットをインポートします。
  2. スナップショットを登録します。
注: AMI ID は、仮想マシンの作成に使用されます。

06-aws-import-snapshot.sh

07-aws-register- snapshot.sh

仮想アプライアンスのアップグレード

注: Splunk AppDynamics GitHub リポジトリからアップグレードスクリプトをダウンロードします。指定された順序でスクリプトを実行することを推奨します。

指定された順序でアップグレードスクリプトを実行します。

ステップ ファイル名
1 仮想マシンの詳細を取得します。 01-aws-get-vm-details.sh
2 仮想マシンのシャットダウン 02-aws-terminate-vms.sh
3 仮想マシンのステータスを確認します。 03-aws-get-vm-status.sh
4 仮想マシンを作成します。 04-aws-create-vms.sh

展開ステータスの確認

仮想マシンの展開を確認します。

  1. 仮想マシンの展開が成功したかどうかを確認します。
    CODE 
    appdctl show boot
    注: 各ノードのサービスのステータスを確認します。[Failed] と表示されているサービスがある場合は、その仮想マシンを再起動します。それでも失敗する場合は、仮想マシンを再展開する必要があります。
  2. 3 ノードクラスタを作成します。
    1. プライマリノードで次のコマンドを実行し、ピアノードの IP アドレスを指定します。
      CODE 
      appdctl cluster init <Node-2-IP> <Node-3-IP>
    2. ノードステータスを確認するには、次のコマンドを実行します。
      CODE 
      appdctl show cluster
microk8s status
      出力に、クラスタの一部であるノードの Running ステータスが true として表示されることを確認します。

      出力例

      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
      注: 次のエラーが表示された場合は、端末に再ログインする必要があります。
      CODE 
      Insufficient Permissions to Access Microk8s

Restore Data in the Virtual Appliance

Verify whether the data directories exist in the following location:

CODE 
/var/appd/data
  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. Verify the PVC are in the Bound state by running the following command:
    CODE 
    kubectl get pvc -A
  4. 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]
    5. Start the operators.
      CODE 
      appdcli start operators
  5. Sometimes, MySQL Router pods might fail to start. In such cases, restart the services using the following commands:
    1. Stop the Splunk AppDynamics services.
      CODE 
      appdcli stop appd

      Wait for the pods to terminate.

    2. Stop the operators:
      CODE 
      appdcli stop operators
    3. Start the Splunk AppDynamics services:
      CODE 
      appdcli start appd <profile>
After the upgrade, the cluster uses the existing data disk and becomes functional.

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_from_globals.yaml.gotmpl>

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
    注:

    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 オンプレミス Classic Controller. To do this, regenerate the hybrid configuration file on the Virtual Appliance and then copy it to your Standalone Controller.