Windows 仮想マシンを一括でチェックおよび修復する方法

01 - システム概要

当社には、社内アプリケーションとテスト システムをホストする小規模なプライベート クラウドがあり、現在 1,000 台を超える仮想マシンを実行しています。採用された技術的ソリューションは、KVM 仮想化 + Sheepdog 分散ブロック ストレージです。

（１）仮想マシンを実行するコンピューティングノードはCentOS 6.5、仮想化技術はKVM、仮想マシン管理はオープンソースのOpenNebulaソリューションです（OpenNebulaは主に歴史的な理由で選択され、日常の管理要件はシンプルで基本的に十分です）

[[245785]]

（２）仮想マシンイメージは、オープンソースのSheepdogアーキテクチャに基づくバックエンドの分散ブロックストレージシステム上で実行されます。

02 - 既存の問題と解決策

2.1 - 問題点

仮想マシン イメージはすべて分散ブロック ストレージ システムでホストされるため、仮想マシンのすべてのストレージ IO は分散ストレージ システムを通過します。この場合、分散ブロックストレージシステムに異常が発生すると（搬送ネットワークの大規模障害、ストレージシステムクラスタ機構の異常など）、仮想マシンを搬送するコンピューティングノードとストレージシステム間のストレージIOがブロックされ、続いて仮想マシンのストレージIOもブロックされ、仮想マシンオペレーティングシステム（特にWindowsオペレーティングシステムの仮想マシン）にWindowsシステムのブルースクリーン、システムセルフチェック、チェックモードに入るなどの異常が発生します。その後、ストレージシステムが正常に戻ったとしても、これらの仮想マシンは異常な状態のままになる可能性があります。

仮想マシンの異常を検出する一般的な方法は、次のように多数あります。

（１）Pingチェックただし、仮想マシンが属するアプリケーション管理者は、ping を禁止したり、セキュリティ グループに制限を課したりする場合があります。

（２）ZabbixやNagiosなどの監視システムのエージェントを導入し、異常監視を行う。ただし、仮想マシンのアプリケーション管理者がエージェントをシャットダウンまたはアンインストールする場合があります。

（3）コンピューティングノード上でいくつかのqemu-kvmツールを使用して、仮想マシンファイルシステムに書き込み可能かどうかを判断します。ただし、この方法では仮想マシンへの「侵入」が伴うため、これは厳しく禁止されている操作です。

上記の方法には 2 つの問題があることがわかります。

（１）仮想マシンが異なるユーザーに属している場合、各ユーザーの運用・保守スタイル、習慣、管理要件（pingの禁止、エージェントクライアントのシャットダウンなど）が異なるため、従来の方法で問題のある仮想マシンを特定すると、漏れが生じる可能性があります。

（２）ブルースクリーン、システムセルフテストなど、仮想マシン（特にWindows仮想マシン）の具体的な異常状態を判断することは不可能である。

したがって、最も安全な方法は、VNC ツールを使用して各仮想マシンに接続し、仮想マシンの画面情報を確認して状態を判断し、状態に応じて 1 つずつ修復することです (VNC は仮想マシンの画面を見ることができますが、仮想マシンにはすべてログイン アカウントとログイン パスワードがあり、検査員はこれらのアカウントとパスワードを持っていないため、仮想マシンに「侵入」することはありません)。しかし、修復プロセスは非常に面倒です。検証と修正の手順は主に次のようになります。

検証操作:

（1）コンピューティングノードにログインし、VNCを使用して仮想マシンに接続し、VNCインターフェースを通じてそのステータス（ブルースクリーン、セルフテストなど）を確認します。仮想マシンの数が大量にある場合、複数人で作業を分担し、表に記録する必要があります。

（２）各検査員の検査結果をまとめた表

修復作業:

（３）表に従って、複数の人がグループに分かれ、それぞれが以下の手順４～６に示すように仮想マシンの一部を修復する責任を負います。

（4）仮想マシンを手動で再起動してみます。

（5）ブルースクリーンやその他の異常が引き続き発生する場合は、Win PEシステムを手動でマウントして修復を試みる必要があります。 Win PE iso ファイルをコンピューティング ノードに手動でコピーし、仮想マシン構成ファイルを手動で変更して Win PE iso ファイルをマウントし、仮想マシンを再起動して Win PE モードに入り、手動で修復する必要があります。

（6）修復が完了したら、システムを再起動します。それでもシステムにログインできず、仮想マシンのユーザーがオペレーティング システムの再インストールを推奨する場合は、仮想マシンをリセットして再インストールする必要があります。

プロセス全体が各仮想マシン上で手動で操作されており、時間がかかり非効率的であることがわかります。

2.2 - 解決策

上記の手動操作手順では、VNC 構成、仮想マシンの概要情報テーブル、仮想マシン構成、および Win PE iso イメージはすべてファイル形式であり、スクリプトを通じてバッチ生成および変更できるため、自動化の基盤が提供されます。

上記の手動操作手順はスクリプト化され、次のバッチ検証および修復スクリプト ツールが形成されます。

（１）検証対象となる仮想マシン情報のExcelスプレッドシートを自動生成する機能

（２）VNCを利用して仮想マシンの画面状態を一括キャプチャし、手動で仮想マシンの画面状態を識別・判断することが可能です。

（3）修復が必要な場合は、Win PEイメージをワンクリックで仮想マシンにマウントし、ブート修復や再インストール操作を実行できます。

03- 仮想マシンの一括チェックと修復の具体的な方法

3.1 - ツール実装フレームワーク

実稼働環境では、構成ツールとして Saltstack を使用しています。 Saltstack のバッチ操作と構成機能に基づいて、統合スクリプト サーバー上に対応するシェル スクリプトと Python スクリプトを作成し、特定の機能を実装し、Linux の Diaglog を使用して簡単な概要表示を行っています。以下のように表示されます。

3.2 - ワンクリックで仮想マシンをエクスポート

クラスターの影響範囲と仮想マシンの数に基づいて、問題が発生する可能性のあるすべての仮想マシンを IP アドレス順に Excel にエクスポートします。エクスポート後はフィルタリングや編集が可能で、複数人の分業検証を素早く行うことができます。

当社の本番環境では、同じネットワークセグメントは同じ業務システムに対応しているため、仮想マシンと業務システム（ネットワークセグメント）の数に応じて作業を分割することが一般的です。

3.3 - 仮想マシンのバッチ VNC スクリーンショットのボタンを確認する

手順 3.2 でフィルタリングされた仮想マシンの IP アドレス情報に基づいて、仮想マシンが配置されている物理マシンと VNC ポート番号を取得し、VNCdotool ツールを使用して仮想マシンの VNC インターフェイスを呼び出してキー テストを実行し、仮想マシン画面のスクリーンショットを撮ります。

仮想マシンの IP アドレス情報を基に、テンプレートが設定されたチェックリスト テーブル (csv 形式) が生成され、以降の手順で手動で判断した情報の記録と要約が容易になります。テーブルの主なフィールドは、IP、ホスト名、仮想マシン ID、ビジネス システムの連絡先、最終チェック結果、ブート修復後のステータス、再インストール後のステータスです。

スクリーンショット情報とテーブルをパッケージ化し、ローカルにダウンロードします。

具体的な手順は次のとおりです。

（1）「8 仮想マシンバッチVNCスクリーンショットキーチェック」を使用して、仮想マシンのホスト名またはIPアドレスを記録したvmlist.txtファイルをアップロードします。

（2）vmlist.txtファイルをアップロードすると、スクリプトはファイル内のホスト名またはIPを読み取り、VNCログインとスクリーンショットを自動的に実行し、日付と時刻を名前にした圧縮ファイルに圧縮します。スクリーンショットの圧縮ファイルはローカルに保存できます。

（3）圧縮ファイルを解凍し、ディレクトリに入って仮想マシンの現在の実行状態を表示するVNCスクリーンショットを作成し、仮想マシンのスクリーンショットを手動で確認し、チェックリスト表に検査情報を記録します（ブルースクリーンやセルフテストが発生し、システムに入ることができない仮想マシンを除外することに重点を置きます）。スクリーンショットはマッチングされ、名前も付けられているため、現時点では手動検査の作業量は比較的少ないです。

3.4 - 仮想マシンのワンクリック修復ブート

（１）仮想マシンに異常がある場合は、仮想マシンの修復を試みてください。

（２）ツール実行時に修復が必要なIPまたはホスト名を入力します。スクリプトは、Win PE ファイルをイメージ ライブラリからコンピューティング ノードの対応するディレクトリに自動的に転送し、仮想マシン構成ファイルを変更して Win PE をマウントし (Win PE は自動的に Win PE に入り、NTboot 修復ツールを開くように変更されています)、仮想マシンを再起動して仮想マシン構成を有効にします。

（3）仮想マシンを起動すると、NTbootツールが自動的に呼び出され、ディスクが修復されます。このとき、手動で操作を選択し、修復結果を観察する必要があります。

3.5 ワンクリックで仮想マシンシステムを再インストールする

仮想マシンを再インストールする必要がある場合は、ツールを実行し、再インストールする必要がある IP またはホスト名を入力します。スクリプトは自動的に次の処理を実行します。

（1）コンピューティングノードに入り、仮想マシンをシャットダウンします。

（２）分散ブロックストレージシステムノードに入り、仮想マシンイメージをバックアップし、イメージIDを記録してから、イメージをアンインストールします。

（３）分散ブロックストレージシステムノードでは、ベースイメージ（Windows初期化後の状態）から、元のイメージと同じイメージIDを持つイメージが新しい仮想マシンイメージとして複製される。

（4）再インストールを実行するには、新しい仮想マシンイメージを再マウントします。

04 - 議論して最適化できる問題

上記の Windows 仮想マシンの検査および修復方法は、実際に障害が発生した後の障害対応プロセスに基づいてまとめた操作方法とスクリプトツールです。同様の障害に遭遇することは稀であり、日常的には Linux のメンテナンスを主に行っており、Windows に対する深い理解があるわけではないため、抜け漏れや最適化できる箇所が多数ある可能性があります。ご質問やご意見がございましたら、メッセージを残してディスカッションしてください。

（１）根本的な原因から、分散ブロックストレージシステムとそれに対応するネットワークの安定性を確保することが依然として必要である。これがこの失敗シナリオの根本的な原因です。

（２）私たちが遭遇した障害現象から、分散ブロックストレージシステムに異常がある場合、Windows仮想マシンは異常を起こしやすいが、Linuxでは比較的まれである。ただし、具体的な理由はわかりません (たとえば、Linux では、ディスク IO の読み取りと書き込み、およびファイル システムの小さな読み取りと書き込みの最適化が優れています)。 Windows で特別な最適化が必要な構成はあるのでしょうか?経験のある方はぜひメッセージを残してシェアしてください。

（3）当社の環境では、仮想マシンは他のチームに属しており、pingまたは監視エージェントの実行が禁止されている可能性があります。現時点で仮想マシンが「生きているか死んでいるか」をより適切に判断するにはどうすればよいでしょうか?ご経験のある方は、ぜひメッセージを残して共有してください。

（4）現時点では、仮想マシンの画面を見てブルースクリーンがあるかどうか、セルフテストに入るかどうかを判断するなど、人間の関与と判断が必要なリンクがまだいくつか残っています。この部分は、簡単な画像認識技術と組み合わせて実装することができ、自動化の度合いが高くなります。

（５）このツールは頻繁に使用されていないため（頻繁に使用されていたら、上司は間違いなく私たちを解雇するでしょう）、まだスクリプト段階にあり、運用・保守プラットフォームにはまだ組み込まれていません。今後もさらに最適化・改善してまいります。