VMware 仮想化インフラストラクチャを本番環境に実装する際に避けるべき 4 つの間違い

[[206711]]

誰もが VMware 仮想化テクノロジをある程度体験したことがあると思いますが、その第一印象は「使いやすい」というものです。しかし、VMware 仮想化インフラストラクチャを実稼働環境に実装する場合、先人たちは貴重な経験と血と涙から学んだ教訓を通じて、次の 4 つの間違いを犯してはならないと警告しています。

1. 当然のこととして受け止め、プロセスに従わない

事例: 操作エラーによる書き込み失敗

問題の説明:

常に書き込みに失敗する DataStore があります。エラー メッセージは非常に単純です: 書き込み失敗。

解決プロセス:

*** 回答: まず、ホストの問題かストレージの問題かを判断します。他のデータストアをテストすると、すべて正常です。次に、問題をデータストアに絞り込みます。マウントまたはフォーマット時に問題が発生した可能性があります。もう一度試しても、結果は同じです。

2 番目の対応は、それを再マウントし、ストレージから Lun を引き出し、それをホストに割り当てることです。まだクマです。

3 番目の対応は、ロック情報が含まれていると思われる VMware の基礎ログを確認することです。

4 番目の反応: 誰がロックを追加したのですか?なぜリリースしないのですか?

5 番目の対応は、実装エンジニアに慎重に問い合わせたところ、ストレージ エンジニアに再割り当てを通知する前に、VMware レベルから DataStore がアンインストールされていなかったことが判明しました。彼はこれを何度もやったが、何の問題もなかったと言った。

6番目の反応は、それについて考える必要はないということです。 Vmare はこのデータストアに SCSI ロックを追加し、このロックは Lun のディスク ヘッダーに追加されます。データストアの異常解放の場合、ストレージは時間内に回収されますが、VMware に再度付与されたときにディスク ヘッダー情報は削除されません。ロックはまだ存在するため、書き込むことはできません。

7 番目の反応は、ストレージがリサイクルされ、再度割り当てられることです。問題は解消されました。

問題の概要:

想像してみてください。当時のエンジニアが通常のプロセスに従い、VMware レイヤーからディスクをアンインストールし、保管してリサイクルしていれば、この問題は発生しなかったでしょう。

999 の成功は 1000 の成功を意味するものではありません。私たちが直面する外部環境は同じまたは類似ではない可能性があるため、すべての操作に対して正しいプロセスに従ってください。

2. 自分の小さな土地に集中する

事例: ファイアウォールによりホストが切断される

環境の紹介:

複数の VMware 仮想化クラスターが VDC を形成し、それらは異なるセキュリティ分離ゾーンに配置されます。 VC は独立したセキュリティ分離ゾーンにあり、各仮想化クラスターには複数のホスト マシンがあります。つまり、ホスト マシンと VC は、異なるセキュリティ分離ゾーンと異なるネットワーク セグメントに属します。

問題の説明:

仮想化インフラストラクチャは完全に導入されており、一貫して正常に動作しています。ある日突然、セキュリティ隔離ゾーンの 1 つにあるホスト マシンの 1 つがオフラインになっていることが判明しました。原因を調査する前に、ホストマシンは正常に戻りました。

解決プロセス:

*** 応答、他に何も言わないでください。これは再現不可能な問題なので、まずはログを確認してください。ホストの 1 つは頻繁に切断され、他のホストも時々切断されることが判明しました。さらに、この現象はセキュリティ隔離エリアの 1 つでのみ発生し、他の隔離エリアでは発生しません。

2 番目の反応は、アプリケーションに何か異常な点がないか確認するように依頼することです。結果はノーです。

3番目の反応は、あまり考えすぎる必要はないということです。オフラインは、ホストマシンと VC 間の通信が切断されたために発生するものであり、通常の業務システムには影響しません。

4 番目の反応は、ログを見て、価値のある手がかりがないと感じることでした。他のクラスターはなぜ大丈夫なのでしょうか?このエリアと他のエリアの違いについて考えてみましょう。同じ VC ですが、異なるセキュリティ分離ゾーンに属しています。ただ、この領域はインターネット ゾーンに属しており、ネットワーク層にはさらにいくつかの分離層があります。

5 番目の対応は、一方ではログを収集し、それをメーカーに送信することです。一方、クロステスト、つまりネットワーク カードをクロス変更することは、依然として良いアイデアです。

スイッチを変更すると状況は改善されるように見えますが、同様の問題が依然として発生します。

6 番目の反応は、残りの違いはファイアウォールにあるというものです。このエリアで使用されているファイアウォールは Mo のもので、他のファイアウォールとは異なります。あまり。中国製ではありますが、検査には耐えられます。そこで、ネットワーク運用・保守エンジニアとメーカーに連絡してパケットをキャプチャしてもらいました。数日後、問題は再発しませんでした。待ってください、VMware はついに応答し、VC とホスト間の通信が定期的にブロックされていると言いました。

7 番目の反応は、おそらくファイアウォールの設定に関連しています。探しに行きなさい。 2 つのベンダーのファイアウォール設定を比較した結果、最終的に「Keep Alive」と呼ばれる構成を見つけました。他のファイアウォールと同様にこのスイッチをオフにできるかどうか、ネットワークベンダーに問い合わせました。答えはノーです。くそ、なぜ？答えは、製品のデフォルト設定です。質問：他社の仮想化製品と連携した経験はありますか？回答: はい、あります。そのような問題はありません。では、早速ネットワーク バックエンドをアップグレードしましょう。数日後、ファイアウォール上の UDP では「Keep Alive」をオフにできるが、TCP ではオフにできないという返答がありました。はい、これが私が望んでいるものです。 UDP をオフにして N 日間観察した後、すべてが正常です。

問題の概要:

この場合、仮想化アーキテクチャを他のメーカーの機器と調整するプロセスの問題に重点が置かれます。不注意な設定は深刻な問題を引き起こす可能性があります。

私たちはもっとコミュニケーションをとるべきです。上流と下流でコミュニケーションをとり、仲間とコミュニケーションをとるべきです。私たちは自分の土地の一部を知るだけでなく、他人の土地の一部も知ることになります。これにより、実装にさらなる専門家の価値がもたらされます。

3. 実施後の検査プロセスに注意を払わない

事例: ネットワークカードのバインドエラーによる業務中断

環境の紹介:

ホスト マシンは 4 台あり、それぞれに 2 つのデュアル ポート 10G ネットワーク カードが搭載されています。 2 つのアクセス スイッチ。

ネットワークは管理セグメントとビジネスセグメントに分かれています。各ネットワーク カード上のデュアル ポートは、それぞれ 2 つの異なるスイッチに接続されます。スイッチはポートをトランク モードに設定し、任意のネットワーク セグメントがバインドなしで通過できるようにします。ネットワーク カード側では、4 つのポートをクロスリンク方式で 2 つのグループにバインドする必要があります。1 つはビジネス用、もう 1 つは管理用です。スイッチをバインドする必要はありません。

問題の説明:

すべての仮想化環境が展開されました。業務と組み合わせた切り替えテスト中に、開発者から一部の業務システムにアクセスできないという報告がありました。

解決プロセス:

*** 応答: まず、クライアントからアプリケーション システムへの Ping テストを実行します。 DNS 解決に問題はありませんが、ネットワークに到達できません。

2 番目の反応は、ネットワークに問題がある可能性があるというものです。クライアントからターゲット ネットワーク セグメントへのゲートウェイの到達可能性を確認します。すべてのゲートウェイに到達可能です。

3 番目の反応は、問題はアクセス スイッチとホスト マシン リンクにあるというものでした。二重点障害はありましたか？そこで、運用保守担当者に設備の監視状況について聞いてみました。運用・保守担当者は、すべてが正常であり、異常は発見されなかったと述べた。

4番目の反応: 何が起こっているのですか?監視に関して直感はないのでしょうか？もう一度質問してください。

Q: 特定のキャビネット内の特定のスイッチに問題がありますか?特定のキャビネット内の特定のサーバーにアラームはありますか?

A: 答えは、警報は鳴らなかったが...でも何ですか?スイッチはファームウェアをアップグレードしていましたが、これは通常のシャットダウンであり、異常範囲内ではありませんでした。

Q: 1つだけですか?

A: はい、1つだけです。

5番目の反応は、それは正しくないということです。アーキテクチャの高可用性に影響を与える単一のポイントはありません。 VC はログインして特定のマシンのステータスを確認し、すべてのマシンが実行状態であることを確認しました。アクセス スイッチとホスト間のリンクに問題があることを再度確認してください。そこで、運用保守担当者にコンピュータ室に入ってもらい、ネットワーク カードとスイッチの状態を確認しました。報告書によると、1 台のマシンのネットワーク カードの 1 つで、両方のポートにアップリンク信号がありませんでした。

6 番目の反応は、ネットワーク カードが間違っているということです。再度確認すると、ネットワーク カードのバインド順序は、同じ種類の他のマシンと同じです。 MAC の対応を確認したところ、このマシンの VMware によって表示されるネットワーク カード名の順序が、他のマシンで認識されるネットワーク カード デバイス名の順序と確かに異なっていることがわかりました。システムを最初に実装したエンジニアは、ネットワーク カードのデバイス ファイル名とサンプル マシンの物理ネットワーク ポート間の対応のみに基づいた標準に従っていました。

問題の概要:

この場合、高可用性設計とネットワーク カード バインディング テクノロジは問題になりません。問題の核心は、エンジニアが、特定のモデルのマシンの IO デバイス ファイル名の認識順序がまったく同じであると当然のこととして考えていることです。実際にはそうではありません。デバイス ファイル名の順序は状況によって異なる場合があります。幸いなことに、この問題はテスト段階で発生しました。

最初のケースでは、物事を当然のことと思わないようにすでに述べましたが、ここでは、実装後の検査プロセスが非常に重要であり、命を救うことができることを強調する必要があります。

4. 事前に計画を立てて問題が起こる前に予防できない

事例：VMware仮想マシンの応答異常のトラブルシューティング事例

問題の説明:

ある日、運用および保守の同僚からのフィードバックによると、VMware 仮想化プラットフォーム上のシステムで深刻な遅延が発生しました。 OS 経由でログインした後は、操作の応答時間が特に長くなり、以前に比べて遅延が顕著になりました。この問題を解決するために、仮想マシンの動作状況を分析しました。

解決プロセス:

最初に思いついたのは、仮想マシンが配置されている Esxi ホストのパフォーマンスを確認することでした。ホストの CPU 使用率は約 20%、メモリ使用率は約 40%、IO 読み取りおよび書き込み遅延は 1 ミリ秒を超えず、Esxi ホスト上の他の仮想マシンは正常に動作していたため、物理ホストの問題は基本的に排除されました。

次に、Vcenter 内の仮想マシンの構成とログを確認することに重点を置きました。 Vcenter 管理コンソールにログインして仮想マシンの構成を確認すると、仮想マシンのディスク ファイルの下に、他の通常の .vmdk ファイルとは異なる -delta.vmdk ファイルが多数存在することがわかりました。問題は当初ここで発見され、VMware エンジニアに送信されました。分析の結果、デルタ ファイルが多すぎることがシステム応答の異常を直接引き起こしていることが確認されました。

では、なぜこれほど多くのデルタ ファイルが生成されるのでしょうか?一般的に、仮想マシンのスナップショットはデルタ ファイルを生成し、VDP バックアップ ソフトウェアもバックアップ前に仮想マシンのスナップショットを取得してデルタ ファイルを生成します。ゲスト オペレーティング システム内でディスク操作が実行されると、ディスク I/O によってディスク ファイル チェーン内の各デルタ ファイルを再解析します。これにより、ホスト ディスクのオーバーヘッドが増加し、パフォーマンスの問題が発生する可能性があります。しかし、仮想マシンのアプリケーションシステムは頻繁に変更されるため、運用保守担当者は変更前にスナップショットを実行する必要があり、スナップショットは長期間削除されません。

問題の概要:

この問題が発生した後は、VMware プラットフォームの今後のメンテナンス中に重複したスナップショットを削除することに特別な注意を払う必要があります。そうしないと、大量のスナップショットが時間の経過とともに仮想マシンのパフォーマンスに影響を与えます。同時に、SSH 経由で ESXi サーバーに定期的にログインし、デルタ ファイルが生成されているかどうかを確認する必要があります。ファイルが多すぎると、より深刻な接続エラーが発生する可能性があり、早急に解決する必要があります。

この例では、話し手は、問題が発見されたら、将来に備えることを検討し、問題を早期に解決し、タイムリーかつ定期的に行動を起こすべきだとしています。

この記事では、実稼働環境での VMware 仮想化インフラストラクチャの実装を分析しますが、実際には、どのプロジェクトの実装でも上記のような間違いは犯されるべきではありません。