Omnissa Access クラスタのアップグレードが RPMDB の再構築ステージでハングする

RPMDB の再構築ステージで応答を停止するセカンダリ ノードが原因で発生するクラスタのアップグレード停止を解決します。この手順では、クラスタをアップグレードされた単一のノードにスケールダウンし、クローンを作成してクラスタをリストアします。

問題

Omnissa Access クラスタのアップグレード中に、セカンダリ ノードが進行を停止し、successfully rebuilt RPMDB ステージで応答しなくなります。影響を受けるノードへの新しい SSH 接続を確立できません。クラスタ内の他のノードが正常にアップグレードを完了している可能性があります。

原因

RPM データベースの再構築プロセス中にノード固有の環境の問題が発生すると、影響を受けるノードでアップグレードが完了しません。

ソリューション

1. 変更を加える前に、各クラスタ ノードのスナップショットを作成します。

   **注：**デプロイで外部データベースを使用している場合は、続行する前にデータベースをバックアップします。

2. 応答しないノードをパワーオフします。

3. 動作中のノードで、アップグレードが正常に完了したことを確認してから、アップグレードされたノードのスナップショットを作成します。

4. vCenter Server で、パワーオフしたノードごとにアップグレードされたノードのクローンを 1 回作成します。

5. クローン作成された各ノードについて、vCenter Server で仮想マシンの設定を開き、置き換え元のノードの MAC アドレスと一致するようにネットワーク アダプタの MAC アドレスを更新します。

6. クローン作成されたノードをパワーオンし、root としてログインします。

7. このノードの正しい IP アドレスとホスト名を使用して、/etc/hosts ファイルを更新します。

8. sudo ln -sf /run/systemd/resolve/resolv.conf /etc/resolv.conf を実行して、DNS リゾルバ構成をリストアします。

9. /etc/systemd/network/10-eth0.network ファイルを編集し、IP アドレスをこのノードの正しいアドレスに設定します。

10. /etc/hostname ファイルを編集し、既存のエントリをこのノードの正しいホスト名に置き換えます。

11. ノードを再起動します。

12. 再構成されたノードがクラスタに正常に参加し、すべての Omnissa Access サービスが実行されていることを確認します。

    **注：**クローン作成された追加ノードごとに、手順 5 〜 12 を繰り返します。