CubeCOSのローリングアップグレード中のVMエバキュエーションの失敗の解決
概要
ローリングアップグレード中、最初のマスター制御ノードが再起動します。 その後、残りのアップグレード手順は自動的に実行されます。 ただし、タイミングの問題や一時的なサービス停止により、仮想マシン(VM)を元のノードから避難させることができない場合があります。 仮想マシンがノードからの移行に失敗した場合、アップグレードプロセスは中止され、問題を解決するために手動での対応が必要となります。
詳細
ローリングアップグレードの過程において、関連コンポーネントの一時的なサービス停止やプラットフォーム上のタイミングの問題により、VMの避難失敗に関連するエラーが発生する可能性があります。 この場合、自動ローリングアップグレードのプロセスを続行するには、仮想マシンを手動で停止させ、ノードを再起動する必要があります。
対象バージョン
CubeCOS 3.1.0 以上。
この記事は、CubeCOS バージョン 3.1.0 以降が動作する環境に適用されます。
決議
VMを手動でシャットダウンし、ノードを再起動して、自動ローリング処理を再開してください
-
端末セッションを開きます。
-
SSHでクラスタのVIPに接続し、
adminユーザーとしてログインします。ssh admin@<your-cluster-vip> -
管理用CLIで、ホストの避難処理の失敗を解決するには、次のコマンドを入力してください:
iaas compute pre_failure_host_evacuation -
障害が発生したホストの避難を求められたら、障害が発生したノードのインデックスを入力してください。
examplecubenode1> iaas compute pre_failure_host_evacuationEvacuate which compute node:1: examplecubenode12: examplecubenode23: examplecubenode3Enter index: 1 -
ノードとVMの詳細を確認し、「YES」と入力して避難を確定してください。
その後、CLIには、避難対象となるホスト上のすべてのVMのステータスおよび関連情報が表示されます。 避難を実行するために「yes」と入力する前に、ホストとVMの情報が正しいことを確認してください。
+------------------+----------------------+--------+--------------------------------+--------------------------+----------------+| ID | Name | Status | Networks | Image | Flavor |+------------------+----------------------+--------+--------------------------------+--------------------------+----------------+| some-id1 | cinder-volumes_nodeID| ACTIVE | \_internal-network=some-ip-info| N/A (booted from volume) | t2.diagnostics |+------------------+----------------------+--------+--------------------------------+--------------------------+----------------+Enter 'YES' to confirm: YES -
自動ローリングアップグレードのプロセスを続行するには、データの移行が完了した後、ノードを再起動してください。
- SSHでクラスタのVIPに接続し、
adminユーザーとしてログインします:ssh admin@\<mgnt-ip-of-errored-node> - CLIに「reboot」と入力して、自動ローリングアップグレードのプロセスを続行し、ノードを再起動してください。
- SSHでクラスタのVIPに接続し、
-
「メンテナンス」>「更新」に移動します。
-
自動ローリングアップグレードがエラーなく継続していること、および障害が発生したノードのステータスが
Succeededに戻っていることを確認してください。