Omnissa Access Control Plane クラスタ ノードの管理

このトピックでは、Omnissa インフラストラクチャ/プラットフォーム ノードと Access ノードを追加して既存の Control Plane の展開を置き換える方法と、ノードが健全でなくなりクラスタから削除された場合の動作について説明します。

クラスタへの Omnissa Access ノードの追加

Omnissa Access Linux ノードをクラスタに追加することで、既存の Control Plane ノードを置き換えることができます。ブートストラップ ノードから wso cp deploy コマンドを使用すると、新しいノードがオンボーディングされます。

前提条件

• 展開コマンドを実行する前に、適切なホスト グループの cp-cluster.ini に新しいノードの IP アドレスが追加されています。
• ブートストラップ ノードから SSH 経由で新しいノードにアクセスできます。

手順：

1. /opt/wss/<cluster_name>/cp-cluster/cp-cluster.ini ファイルを開き、適切なホスト グループの下に新しいノードの IP アドレスを追加します。例：

   オプション 1 - Omnissa Access ノード： 新しい Omnissa Access ノードを追加する場合は、次のセクションに追加します。

   [general_compute_access_linux]
   10.0.0.x
   10.0.0.x  # New node
   [vault_server_linux]
   10.0.0.x  # New node
   [consul_server_linux]
   10.0.0.x  # New node
   [nomad_server_linux]
   10.0.0.x  # New node
   [general_compute_nginx_http]
   10.0.0.x  # New node
   

   オプション 2 - インフラストラクチャ/プラットフォーム ノード： インフラストラクチャ/プラットフォーム ノードの新しいノードを追加する場合は、次のセクションを除くすべてのセクションに追加します。

   [general_compute_access_linux]
   [general_compute_nginx_http]
   [asset_server_linux]
   
   # If the new node is a candidate for asset-server-linux that will replace existing asset-server, you must add a node IP in asset_server_linux, too.
   

   **重要：**ブートストラップ ノードの IP アドレスをインベントリに追加しないでください。ブートストラップの IP アドレスが検出されると、検証が失敗します。

2. ブートストラップ ノードから、wso cp deploy を実行してノードをオンボーディングします。

   • 1 つ以上の特定のノードをオンボーディングするには、-t (--target-hosts) フラグを使用します。

     # navigate to your cluster working directory
     cd /opt/wss/<cluster_name>
     wso cp deploy -t "10.0.0.x"
     

     複数ノードの場合：

     cd /opt/wss/<cluster_name>
     wso cp deploy -t "10.0.0.x,10.0.0.x"
     

3. 次のコマンドを実行して、クラスタが正常な状態かどうか確認します。

   wso healthcheck
   

4. ワークロード（サービス）を新しいノードに移動します。 デフォルトでは、新しく追加されたノードではワークロードは実行されません。 Nomad トークンを使用して Nomad ユーザー インターフェイスにログインし、次の手順を実行する必要があります。

   1. https://10.0.0.x:4646/ui/jobs で Nomad ユーザー インターフェイスにログインします。
   2. [Clients] をクリックします。
   3. ワークロードを移動するノード ID をクリックします。
   4. [Drain] をクリックして、ワークロードを新しい仮想マシンに移動します。

   **注：**ドレイン操作が完了すると、すべてのワークロードが新しい仮想マシンに移動されます。選択したサービスを新しいノードに移動することはできません。

5. 次のコマンドを実行して、クラスタから既存のノードを削除します。

   # From the bootstrap VM
   source /opt/wss/<cluster_name>/cp-cluster/cp-cluster.env
   server_id = <node_ip> # IP of the node being removed
   
   # API to remove peer
   curl -sk \
   -H "X-Vault-Token: $VAULT_TOKEN" \
   -H "Content-Type: application/json" \
   -X POST \
   -d '{"server_id":"$server_id"}' \
   "$VAULT_ADDRESS/v1/sys/storage/raft/remove-peer"
   

6. クラスタとサービスの健全性を確認します。

   wso healthcheck
   wso access check-service-readiness
   

トラブルシューティング

クラスタからの Omnissa Access ノードの削除

Control Plane クラスタからノードを削除するための、専用の CLI コマンドはありません。ノードが使用できなくなったり、健全でなくなったりすると、クラスタは削除を自動的に処理します。

• 約 2 つのハートビートが失われると、ノードは新しいワークロード割り当ての受信を停止します。
• ノード上の既存のワークロードは、健全なノードに再スケジュールされます。
• 手動による削除コマンドは必要ありません。

1. cp-cluster.ini ファイルの関連するすべてのセクションから、古いノードの IP アドレスを削除します。
2. 削除されたノードをパワーオフします。

**注：**クラスタ メンバーシップのクリーンアップは、障害検出とは異なるタイムラインで実行されます。

• Consul は、24 ～ 72 時間の間の任意の時点の非アクティブ ノードをメンバー リストから自動的にパージします。
• Nomad は、次のガベージコレクション サイクル中に古いノードを削除します。
• このため、削除されたノードは、スケジュール設定に使用されなくなっても、トラフィックの受信を停止した後しばらくの間、Nomad または Consul ユーザー インターフェイスに表示されたままになることがあります。

Control Plane クラスタ ノードのパスワード管理

デフォルトでは、configuser と root アカウントのパスワードの有効期限は 60 日です。すべての Control Plane クラスタ ノードのパスワードは、期限切れになる前に変更する必要があります。

root パスワードと configuser パスワードを同じにする必要はありませんが、クラスタ内のすべてのノードで同一である必要があります。たとえば、root パスワードはすべてのノードで同じにする必要があり、configuser パスワードもすべてのノードで同じにする必要があります。

configuser または root パスワードのリセット

単一ノード、root または sudo 経由でログイン：

passwd configuser
passwd root

一度にすべてのノードで。ブートストラップ ノードから実行：

export TARGETS='general_compute_linux:general_compute_access_linux'
wso control-plane ansible -- -b -m shell -a "echo 'configuser:NEW_PASSWORD' | chpasswd" "${TARGETS}"
wso control-plane ansible -- -b -m shell -a "echo 'root:NEW_PASSWORD' | chpasswd" "${TARGETS}"

実行する前に、NEW_PASSWORD は実際のパスワードに置き換えます。${TARGETS} は、Ansible インベントリ グループまたは更新するノードのホスト パターンに置き換えます。保存されたスクリプトやシェル履歴にリテラルなプレースホルダを残さないでください。

重要：configuser パスワードを変更した後、ブートストラップ ノードの cp-cluster.ini で同じパスワードを更新するか、クラスタに対して wso CLI 操作を実行すると認証が失敗します。アクティブな configuser セッションは、リセット後に無効にする必要はありません。

パスワードの有効期限の変更

60 日間の有効期限は、各アカウントのパスワードの有効期間フィールドによって制御されます。

注：configuser として実行する場合は、コマンドの前に sudo を使用します。

現在の設定を確認します。

chage -l configuser
chage -l root

アカウントごとに変更します（単一ノード）。

chage -M <days> configuser
chage -M <days> root

-M は、パスワードが有効な状態を維持する最大日数を設定します。-1 は有効期限を無効にします（通常、root またはサービス アカウントには推奨されません）。

完全に忘れてしまった root パスワードの復元

これには、影響を受ける仮想マシンへのコンソール（ハイパーバイザー）アクセスが必要です。SSH 経由では実行できず、一度に 1 つのノードのみを復元します。

1. 仮想マシンを再起動し、GRUB メニューで割り込みます。

2. 起動エントリをハイライト表示し、e を押して編集します。

3. linux（または linux16）を開始する行を見つけ、その末尾に次のものを追加します。

   rd.break enforcing=0
   

4. Ctrl+X（または F10）を押して、変更されたパラメータを使用して起動すると、Dracut 緊急シェルに移動します。

5. ルート ファイルシステムの read-write と chroot を再マウントします。

   mount -o remount,rw /sysroot
   chroot /sysroot
   

6. 新しいパスワードを設定します。

   passwd root
   

7. SELinux がこのセッションで許可モードであったため、次回の起動時に SELinux の再ラベル付けを行うため、ファイルシステムにフラグを付けます。

   touch /.autorelabel
   

8. chroot を終了して再起動します。

   exit
   reboot
   

   SELinux のラベルが変更されたため、この後の最初の起動は通常よりも時間がかかります。