万が一、災害により NSX Advanced Load Balancer Controller（またはクラスタ全体）が破損した場合、まず flushdb.sh を使用して、コントローラをホストするデバイスまたは仮想マシンを工場出荷時のデフォルト設定にリストアする必要があります。またそうしないと、コントローラが起動しなくなる可能性があります。prev パーティションがある場合は、名前を変更するか、削除します。prev パーティションは、root1 または root2mv root1/root2 prev_back のいずれかになります。

パーティション マッピングを確認する手順は次のとおりです。

  1. sudo cat/proc/cmdline

    出力では、root1 または root2 が現在のパーティションとして表示されます。

    たとえば、以下では root1 が現在のパーティションとして表示されます。

    root=UUID=f4a947e1-7efb-4345-9eac-1ff680fc50e0 subroot=/root1 net.ifnames=0 biosdevname=0 console=tty0 console=ttyS0,115200n8

  2. /host ディレクトリに移動し、次のように prev パーティションの名前を変更します。

    cd /host
ls -lrth <- This is to see if you have root1 and root2 directories.
mv root2 prev_bak ----> as root2 is prev partition

その後、次のスクリプトを使用して、構成のリカバリ プロセスを自動化できます。

/opt/avi/scripts/restore_config.py

注：

prev パーティションは削除する必要があります。

このスクリプトは、バックアップ構成を NSX Advanced Load Balancer Controller にインポートします。Controller クラスタをリストアする場合、このスクリプトは構成をリストアし、他の 2 台のノードもクラスタに再追加します。

  1. 元のクラスタ メンバーと同じ IP アドレスで 3 つの新しいコントローラを作成します（NSX Advanced Load Balancer は現在、静的 IP アドレスのみをサポートしています）。この時点で、IP アドレスがあることを除いて、各コントローラ ノードは工場出荷時のデフォルト状態になっているはずです。

  2. SSH または SCP を使用して NSX Advanced Load Balancer Controller ノードの 1 つにログインします。デフォルトの管理者認証情報を使用します。

  3. リストア コマンドまたはスクリプトを実行します。

    • SCP を使用してバックアップ ファイルをコピーします。

      scp /var/backup/avi_config.json admin@<controller-ip>://tmp/avi_config.json

  4. SSH を使用して、次のリストア コマンドをローカルで実行します。

    /opt/avi/scripts/restore_config.py --config CONFIG --passphrase PASSPHRASE --do_not_form_cluster DO_NOT_FORM_CLUSTER --flushdb --vip VIP --followers FOLLOWER_IP [FOLLOWER_IP ...]

上記のコマンド ラインの詳細：

  • CONFIG は構成ファイルのパスです。

  • PASSPHRASE はエクスポート構成パスフレーズです。

  • DO_NOT_FORM_CLUSTER はクラスタの形成をスキップします。

  • VIP はコントローラの仮想 IP アドレスです。

  • FOLLOWER_IP [FOLLOWER_IP ...] はフォロワーの IP アドレスのリストです。

  • CLUSTER_UUID はリストアする古いクラスタの UUID です。

注：

NSX Advanced Load Balancer 22.1.3 以降、次のオプションはサポートされなくなりました。

  1. --do_not_form_cluster

  2. --vip

  3. --followers

クラスタのセットアップで構成をリストアするには、次の手順を実行します。

  1. いずれかのノードで構成をリストアします。

  2. 2 台の新しいノードをクラスタに招待して、クラスタをリフォームします。

3 ノード クラスタの構成のリストア

3 ノード クラスタの場合は、スクリプトを実行する前に、次の条件が満たされていることを確認します。

  • フォロワー ノードは工場出荷時のデフォルト状態であることが必要です。

  • 2 つの新しいコントローラを生成する必要があります（これらに変更を加えないでください）。

次のコマンドを実行して、ノードを工場出荷時のデフォルト状態にリセットします。

sudo systemctl stop process-supervisor.service
rm /var/lib/avi/etc/flushdb.done
/opt/avi/scripts/flushdb.sh
sudo systemctl start process-supervisor.service

restore_config スクリプトのオプション引数は次のとおりです。

  • vip <Virtual IP of controller>（クラスタの場合はコントローラの仮想 IP アドレス）

  • Followers <follower_IP_1> <follower_IP_2>（フォロワー ノードの IP アドレス）

  • cluster_uuid <cluster_uuid>（古いクラスタの UUID がリストアされます）

3 ノード クラスタをリストアするには、上記のオプション引数を指定して次のコマンドを実行します。

/opt/avi/scripts/restore_config.py --config  --flushdb --passphrase  --followers

上記のコマンドに followers 引数が追加されていない場合は、リストア構成が正常に行った後で、ユーザー インターフェイス、CLI、または API からクラスタを手動で作成できます。他のコントローラがクラスタの構成に受け入れられるには、それらが工場出荷時のデフォルト状態であることが必要です。

リストア構成中に SE パッケージが再署名され、既存の SE パッケージが削除されます。

構成のインポート エラーが原因でリストア構成が失敗した場合、ログは /opt/avi/log/portal-webapp.log にあります。