Omnissa Access クラスタの再起動または計画メンテナンス

ノードの再起動後、ノードは Omnissa Access クラスタに自動的には再参加しません。ブートストラップ ノードから wso cp unseal を実行して、クラスタ メンバーシップをリストアする必要があります。

**注：**この動作は、現在の中間ビルドにのみ適用されます。

メンテナンス シナリオに基づいて、以下の適切な手順オプションを使用します。

オプション 1 - 計画メンテナンス：一度に 1 つのノードを再起動する

クラスタの可用性を維持するために、一度に 1 つのノードを再起動します。再起動中、クラスタはキャパシティが低下した状態で引き続き機能します。

Omnissa Access ノード

1. メンテナンスするノードを停止します。

2. クラスタの健全性とサービス ステータスを監視します。

   クラスタは、各サービスの 1 つのインスタンスが少ないキャパシティで実行されている状態で、健全性を維持している必要があります。

3. メンテナンスを完了し、ノードをオンラインに戻します。

4. ブートストラップ ノードから、次のコマンドを実行します。

   wso cp unseal
   

5. ブートストラップ ノードから、次のコマンドを実行してクラスタの健全性を確認します。

   すべてのサービスがオンラインに戻るように時間をおきます。

   wso healthcheck
   

6. 各サービスの 2 つのインスタンスが実行されていることを確認します。

7. 次のコマンドを実行して、すべてのサービスでトラフィックを処理する準備ができているか確認します。

   wso access check-service-readiness
   

両方の Access ノードが停止した場合（計画外）：

1. 両方のノードがオンラインに戻ったら、ブートストラップ ノードから次のコマンドを実行します。

   wso cp unseal
   

2. ブートストラップ ノードから wso healthcheck を実行し、すべてのサービスがオンラインに戻るように時間をおきます。
3. 各サービスの 2 つのインスタンスが実行されていることを確認します。
4. wso access check-service-readiness を実行して、サービスでトラフィックを処理する準備ができているか確認します。

インフラストラクチャ/プラットフォーム ノード

一度に 1 つのノードを再起動します。インフラストラクチャ サービス（PostgreSQL、Kafka、Redis、OpenSearch）は、再起動中に 2 つのインスタンスで引き続き機能します。

1. メンテナンスするノードを停止します。

2. クラスタの健全性を監視します。

   クラスタは、各インフラストラクチャ サービスの 2 つのインスタンスで引き続き機能している必要があります。

3. メンテナンスを完了し、ノードをオンラインに戻します。

4. ブートストラップ ノードから、次のコマンドを実行します。

   wso cp unseal
   

5. ブートストラップ ノードから、wso healthcheck を実行してクラスタの健全性を確認します。

   すべてのサービスがオンラインに戻るように時間をおきます。

6. 各インフラストラクチャ サービスの 3 つのインスタンスが実行されていることを確認します。

すべてのインフラストラクチャ/プラットフォーム ノードが停止した場合（計画外）：

1. すべてのノードがオンラインに戻ったら、ブートストラップ ノードから次のコマンドを実行します。

   wso cp unseal
   

2. ブートストラップ ノードから wso healthcheck を実行し、サービスがオンラインに戻るように時間をおきます。
3. 各インフラストラクチャ サービスの 3 つのインスタンスが実行されていることを確認します。

ブートストラップ ノードの再起動

ブートストラップ ノードを再起動しても、クラスタ サービスには影響しません。ブートストラップ ノードはクラスタの初期化のみを行い、重要なサービスは実行しません。

オプション 2 - 計画メンテナンス：パフォーマンスが低下しない（バッファ ノード）

サービスを低下させずにメンテナンスを実行するには、開始する前に一時バッファ ノードを追加します。これにより、サービスをメンテナンス中のノードから移行できます。

1. 既存のノードと同じ構成の新しいノードを展開し、クラスタに追加します。

2. ブートストラップ ノードから、新しいノードの IP アドレスで cp-cluster.ini を更新し、次のコマンドを実行します。

   wso cp deploy -t <new-node-ip>
   

3. Nomad ユーザー インターフェイスから、メンテナンスするノードをドレインします（[Clients] > ノードを選択 > [Drain]）。

   このアクションにより、パフォーマンスに影響を与えずに、すべてのサービスがバッファ ノードを含む他のノードに移行されます。

4. 一度に 1 つの既存のノードに対してメンテナンスを実行します。

5. メンテナンスが完了したら、必要に応じて、cp-cluster.ini からエントリを削除してシャットダウンし、バッファ ノードを削除します。

   また、将来のメンテナンスのためにスタンバイ ノードとして保持することもできます。

6. ブートストラップ ノードから、次のコマンドを実行します。

   wso cp unseal
   

7. wso healthcheck を実行して、クラスタの健全性を確認します。

8. 各 Access サービスの 2 つのインスタンスと、各インフラストラクチャ/プラットフォーム サービスの 3 つのインスタンスが実行されていることを確認します。

9. wso access check-service-readiness を実行して、すべてのサービスでトラフィックを処理する準備ができているか確認します。

   **注：**ノードを再起動して wso cp unseal を実行した後、すべてのサービスがオンラインに戻り、健全なクラスタを形成するように時間をおきます。この期間中にクラスタの健全性を監視します。サービスがリカバリに失敗した場合は、Nomad ユーザー インターフェイスでそのログを確認し、サービスをパージして再展開します。

   wso services deploy -s <service-name>