[VMware] vSANクラスタに仮想マシンではなくレプリカが表示される

この間、導入した顧客のvSANクラスタに障害が発生しました。

 

4ホスト構成の小規模でしたが運悪く1時間以内で2ホストが停止しまったようです。(FTT=1にもかかわらず一部仮想マシンが”アクセス不可”状態でした。

障害発生後、ホストは復旧されました。vSANクラスタのヘルス状態やオブジェクトのヘルス状態もすべて正常でしたし、すべての仮想マシンにも正常でした。

数時間後顧客から連絡がありました。一部Linux OSの仮想マシンのレスポンスが障害前より遅くなったことと一部コマンドを実行できないということでした。

 

翌日現地で確認してみました。確かに顧客の言うとおりでした。仮想マシンへのSSH接続も’遅い’と感じるほど時間がかかりましたし、やっと接続できてコマンド(例えばsudoやifconfig、rebootなど)を実行すると”バスエラー”が表示されました。あまりLinuxに詳しくないのでググってみたところ、”バスエラー”は一般的に①リソースが足りない②一部ライブラリが破損していると起きるようでした。仮想マシンのリソースは障害発生前と後で変更してませんので、もしかしたらホスト障害によるHA発動でゲストOSに何らかの影響があったのでは?という結論の雰囲気でした。(ただその結論(?)はどうも腑に落ちない…)

 

幸い(?)なことに対象仮想マシンは数日前に新規作成したもので、まだデータはなく最悪の場合テンプレートから作り直せるとのことでしたので、OSブートから少し確認をすることになり、一先ず仮想マシンを強制終了したところ…

仮想マシンがインベントリから消えました。代わりにFTT=1で生成されたレプリカが表示されていました。

ふむ。HA発動のタイミングでレプリカが登録されたんでしょうか?それとも元の仮想マシンの情報が見つからずレプリカの情報が表示されているんでしょうか?詳しい内容は確認できませんでしたが、レプリカが表示されるのは正常ではありませんので、一旦レプリカをインベントリから削除しました。そのあとは元の仮想マシンを再度インベントリに登録したところ、仮想マシンの起動やレスポンスも良くなり、すべてのコマンドが実行できるようになりました。

 

まあ〜結果的にすべて復旧というこのにはなりましたが、原因が特定できず歯がゆい対応でしたね。

(´・ω・`) 推測ですが、HA発動の影響でレプリカを認識するようになった、レプリカは基本’read-only’のはずのため仮想マシンのOS側にも書き込みが正常にできずコマンドが受け付けられなかったのではないかと… 状況をもう少し早く把握してログを採集しサポートチームにエスカレーションしてないのが残念でした。

 

反省…

 

 

広告

[VMware] 既存ストレージからvSANへの移行ガイド

先日、グローバルでvSANを導入した顧客が10,000社と超えたという発表がありました。

 

最近は開発環境や検証環境ではない本番環境として導入する事例が増えてます。しかもSSDの低価格もありハイブリッドよりはAll Flashモードが主流になっていますし、新規環境よりは既存環境のリプレースとしてvSANを採択する企業も増えています。

 

こういう時期に非常に役に立つガイドが公開されました。

 

 

Migrating to vSAN“というタイトルのこのガイドは既存環境からvSANへの移行方法を紹介しています。紹介されている移行シナリオは以下の通りです。

  • VMFSからの移行
  • NFSからの移行
  • non-shared RDMからの移行
  • Shared RDMからの移行
  • 物理サーバの移行

 

ほぼすべての環境をシナリオとして扱っているのでvSANの導入や移行を検討中の管理者必読のガイドかと!!! :)

 

[VMware] !!! vSAN All Flashモードの緊急修正パッチ公開 !!!

10月5日、vSNA All Flashモードの重要なパッチが公開されました。

 

内容は、チェックサムエラーにより、特定な操作やIOパターンが発生した場合、仮想マシンへのアクセス不可、ホスト失敗、再同期失敗などの致命的な状態に陥る可能性があるとのことです。

 

条件はESXi 6.0 Patch 4 (build number 4558694)以上のvSAN、すなわちvSANバージョン6.2, 6.5, 6.6, 6.6.1のAll Flashモードで重複排除が有効化されている場合で、この条件を満たしている場合は、直ちに下記修正パッチを適用することを推奨しています。

 

[VMware] vSAN環境のESXiホストの起動/再起動に時間がかかる

既に運用している方はご存知かと思います。

vSAN環境においえESXiホストを起動または再起動する場合、non-vSAN環境より時間がかかります。理由は下図のような状態がしばらく続くからです。

VSAN: Initializing SSD: xxxxxxxxx-xxxxxx-xxxxxxx-xxxxxxxxx Please wait….

 

この状態がしばらく続くため、起動中フリーズしたかのように見えます。この状態で10分以上なんの変化がないとイライラしてくるかもしれません。:) この場合は軽く「Alt+F12」を押します。すると下図のように実は処理は進んでいることが分かります。

 

それでは”なんでこんなに時間がかかるのか?”ということですが、vSANの場合、ESXiホスト起動時SSD上のログを参照しメタデータテープルを作成するためのようです。このメタデータテープル作成はディスクグループごとに行われるようです。なのでディスクグループ内にデータ量が多いとその分、メタデータテープル作成に時間がかかり、結果的にはESXi起動/再起動全体に時間がかかってしまいます。この現象は所謂、”バイ・デザイン”的な動きのため、イライラせずに処理が終わるまで待ちましょう。なお、“SSD Initialized ~”の状態では強制的に処理中断させたり、再起動を実行するとデータが壊れる可能性があるとのことですので、ご注意を!

 

本現象については先日KB2149115が公開されました。

Initializing vSAN during boot takes a longer time

 

 

[VMware] vExpert 2017 VSANを受賞しました

光栄なことにvExpert 2017 VSANを受賞することになりました。

vExpert 2017 VSAN Announcement

vExpert 2017 VSANは、その年に選ばれたvExpertの中から特定プロダクト普及に貢献したvExpertに授与するサブプログラムです。サブプログラムには今回選ばれましたvSAN以外にNSXとHorizon View(確か…)があります。

 

vExpert 2017 VSANプログラムが開始された2016年にはグローバルで20名ほどだったと思いますが今年は87名まで増えました。うち日本からの受賞者は2名でした。

 

個人的には第1世代のVirtual SAN 5.5から案件に携わっているのでどのプロダクトより愛着(?)があって今回の受賞は非常に光栄で嬉しい限りです。

 

これからもvSANを広めるべく色々と情報を共有して行きますので引き続き、よろしくお願いします。

 

PS>ふむ。確かvExpert Horizon Viewがあったと記憶していますが、調べてみても出てきませんね。なくなったんですかね。。。

[VMware] vSANアップグレードガイド

先日vSphere 6.5 Update 1のリリースと同時にvSANの6.6.1に若干(!)バージョンが上がりました。

vSAN 6.6.1は、まあ〜マイナーバージョンアップ(しかも0.0.1)ですので”バグ修正版”かと思いきや新しいライセンス体系や機能改善がしっかりと含まれていました。

  • vSphere Update Managerとの統合:VUMを利用しvSAN関連パッチを適用できるようなりました。
  • vSANパフォーマンス診断機能改善:バージョン6.6でCEIPを通じてvSANクラスタのヘルス状態や情報をVMware社に転送できるようになりまたが、6.6.1ではその情報を基にディスクのスループットやレイテンシーなどのベンチマーキングが可能になりました。
  • ストレージデバイスのメンテナンス改善:vSANで使用しているディスク以外のストレージデバイスに関してもvCenterよりLEDを点滅させることができます。w
  • 新しいライセンス体系の追加:”vSAN Enterprise for ROBO”エディションでも”暗号化”と”拡張クラスタ”が構成できるようになります。また”Horizon Advanced”や”Horizon Enterprise”に”vSAN Advanced”エディションが含まれるようになりました。

 

で、数日前に今度は”vSANアップグレードガイド”が公開されました。

正確には古いバージョンのvSAN(vSAN 6.6を含む)から6.6.1にアップグレードする際に考慮すべき以下の内容で構成されています。

  • vSANアップグレード時のディスクフォーマットバージョンとバージョンアッププロセス
  • ネットワーキング(6.6以前のマルチキャストからユニキャストへの変更に伴う考慮点)

上記以外にアップグレードには必須であるvCenterのアップグレード方法やvSANアップグレード時のトラブルシューティングの内容も含まれています。

 

1世代のVirtual SAN 5.5のリリースから4年が過ぎました。5.5を含む古いバージョンを導入している方の中ではバージョンアップを検討される方もいるんじゃないでしょうか。アップグレードを検討している方は是非お読みください。

 

[VMware] VCSA vSAN 6.6 easy install

※同僚から質問された内容を基に確認した内容です。

 

オフィシャルにvsanDatastore上へのvCenterインストールはサポートされています。(推奨はvCenterのような管理系仮想マシンはコンピュートクラスタとは別のクラスタ上で稼働させることです)

 

しかし実際にvsanDatastore上にvCenterを構成するのはやや面倒です。vSANを構成するためにはvCenterが必要ですが、vSAN用サーバだと大体インターナルSDカードにESXiをインストールしているはずなので、ローカルデータストアがありません。よってvCenterがインストールできません。要するに”鶏が先か卵が先か”です。そのため1台のESXiのディスクの一部をローカルデータストアとして構成、vCenterをインストールします。vCenterがあればvSANを構成できるのでvSANを構成したあとにvCenterをローカルデータストアからvsanDatastoreにStorage vMotion。vCenterがvsanDatastoreに移ったらローカルデータストアを削除、そのディスクをディスクグループに追加…みたいな方法を使う必要あります。もちろん最初からローカルデータストア用ディスクを用意しておく…というのもありかもですね。:)

 

ただしこういう面倒な方法もvSAN 6.5までです。vSAN 6.6からは面倒な方法を使わなくても簡単にvCenterをインストールすることができます。その名も”Easy Install”!

 

Easy InstallはVCSA 6.5d以降のバージョンで利用できます。VCSAデプロイ時、最初のESXiに一時的なvsanDatastoreを構成し、VCSAをインストールします。上の図のようにデプロイするデータストアを選択する際に”新しいvSANクラスタに含まれるESXiホストにインストール”オプションを選択するだけです。

 

”新しいvSANクラスタに含まれるESXiホストにインストール”オプションを選んだ後はディスクグループとして使用するディスクを指定します。あとは普通のVCSAインストールと同じです。

 

インストール後、動作を確認している中で下の図のようなことを発見しました。

ご覧のとおり、”使用済み-予約超過仮想マシン”のサイズが446GBにもなっていました。”使用済み-予約超過仮想マシン”はストレージポリシーの”オブジェクトスペースの予約”によって予約された容量になります。vSAN構成時、作成されるVirtual SAN Default Storage Policyの”オブジェクトスペースの予約”は0%、即ち”予約はしない”なので予約サイズが446GBにもなってしまったということはストレージポリシーが適用されていないことになります。

 

デプロイしたVCSAを確認しましたところ、ストレージポリシーは適用されてない状態でした。もちろんeasy installでVCSAをインストール後、2台のESXiを追加して必要ノード数を満たしたあとです。

てか… 当たり前のことですよね。そもそも1台で一時的にvSANを構成しているのでVirtual SAN Default Storage Policyの条件をみたしてないし、条件を満たしたとしてもあとから自動的にストレージポリシーが適用されませんので。:)

 

とりあえず、ストレージポリシーを適用しました。結果…

 

”使用済み-予約超過仮想マシン”のサイズは20GBまで減りました。

 

Easy InstallでVCSAをインストールした場合は、vSAN構成後忘れずにVCSAにもストレージポリシーを適用してくださいなー。