[VMware] vSAN関連Tipsいくつか

 

※このエントリーは、vExperts Advent Calendar 2017に参加しています。

 

既に10,000社以上で導入されていて、なおその勢いが衰えないvSANですが、お客様と話をしてみると意外とまだまだ知られてないんだぁと感じます。というのはvSANというプロダクトやその特徴は知っていても実際に導入や導入後の運用での注意点についてはあまり認識してないような気がしました。

ということで導入や運用で少し気をつけた方が良い内容を紹介したいと思います。(既に知っているかも内容かもしれませんが…)

● 同じRAID ControllerではVMFSとvSAN FSを構成しない

おそらく初期バージョンのvSAN構成の時に多かったと思います。(ただ最近もちょくちょくと聞きます)
同一RAID Controller上にVMFSとvSAN FSを構成することはサポートされません。どいうことかというと同じRAID ControllerにESXi用RAID 1とvSAN用non-RAIDを構成することはできないということです。
どうしてもESXi用ローカルデータストアを構成したい場合は、ESXi用としてRAID Controllerを用意し、vSAN用RAID Controllerを追加で用意する必要があります。


● ブートデバイスとしてSDカードを使用する場合はスクラッチパーティションを考慮すべき

内蔵USBメモリやSDカードにESXiホストをインストールする場合、ログはRAMディスク上に格納されます。そのためESXiホストを再起動するとログは消え、障害の原因究明が中々できない場合があります。

これを防ぐためには永続的なスクラッチパーティションを構成する必要がありますが、vSANでは①ESXiホストをローカルディスクにインストールするか②NFSのディレクトリを構成するのが用意されているオプションです。ただ①の場合は、前のtipsでも紹介しましたとおりRAID Controllerを追加用意する必要がありますし、②はNFSディレクトリを用意する必要があります。

今までの経験上スクラッチパーティションのため①や②を新たに用意するケースは殆どありませんでした。となると… Remote SyslogとNetwork Dumpを構成する方法が一般的かもしれません。ただ、これもすべてのログが残せるわけではありませんのでvSANを導入する場合は、スクラッチパーティションを用意するか割り切ってsyslogだけにするか考慮する必要があります。個人的にはvRealize Log Insightに転送することをオススメします。 🙂

 


● vsanDatastoreの未使用容量を常に30%確保する

運用開始後、vsanDatastoreの使用容量が全体容量の80%を超えないように気をつけることはよく知られていることです。(SIerによっては70%を利用可能容量の目安として案内する場合もあります)

これと似ている話かもしれませんが、vsanDatastoreの未使用容量は常に30%ほど確保する必要があります。特にFTTが異なる複数のストレージポリシーを利用している場合ですがストレージポリシーを変更すると一時的に変更前と変更後のストレージポリシーは共存するタイミングがあります。

例えば、ある仮想マシンにFTT=1のストレージポリシーが適用されているとします。この仮想マシンのストレージポリシーをイレイジャーコーディングのRAID 5のストレージポリシーに変更する場合、データコンバートが完了するまでこの仮想マシンはRAID 1とRAID 5が共存します。RAID 5のストレージポリシーに変更中、空き容量が足りなくなるとストレージポリシーの変更は失敗します。

そのため、vsanDatastoreの未使用容量を常に30%ほど維持するようにしてください。


● 最初構成は3ホスト、でも4ホストを推奨

はい。分かってます。vSANの最小構成のホスト数は3ホストです。(ROBOや2ホストダイレクト接続構成は除く) サポートも問題なく受けられます。

しかしながら3ホストだと仮想マシンの可用性維持しながら運用することに不安が生じます。特に運用面でのリスクが大きいです。3ホスト構成時は、1ホストのメンテナンスでもFTT=1を満たせなくなり仮想マシンの可用性が担保できなくなるからです。

1ホストメンテナンス中に、他のホストに障害が起きたら?そんなことは殆どないと思っている方々… 起きてしまってからは遅いです。自分だったら嫌ですね。パッチ適用とか1ホストずつローリングで実施する時もハラハラしながらやるのは… :)

対ホスト障害性はもちろんですが、運用開始後のメンテナンスの利便性を考えるとvSANクラスタは最小4ホスト構成をオススメします。

 


● “重複排除と圧縮”有効時はディスク単位での削除はできない

All-FlashのvSANを導入し”重複排除と圧縮”を検討している方は、“重複排除と圧縮”はディスクグループ単位で実装されることにご注意ください。ディスクグループ単位で実装されるため、キャパシティーSSDに障害が発生するとそのSSDのみ削除はできず、ディスクグループ全体を削除し再作成する必要があります。

これは運用開始後しばらく経ってから起きると意外と面倒なことになりますので”重複排除と圧縮”を検討時は運用面での負荷も含め、十分な考慮が必要です。


● vSAN構成ESXiホストのrebootは時間がかかる

過去のエントリーでも紹介したとおり、vSANのホストはブート時、vSANメタデータのテーブルを再作成します。(KBによるとディスクグループあたり最長1時間かかることもあるとのことです)

そのためnon-vSANのESXiホストより起動時間がかかります。待ちましょう。起動に失敗するとエラーが表示されるのでエラーがない限り待ちましょう。

ESXiホスト起動/再起動時は、DCUIやリモートコンソールからブート状態を確認することをオススメします。


● 稼働中のディスク抜きは障害テストとは言えない

vSAN導入直後、障害テストを実施します。ネットワークや電源とかホストとかもやりますね。中にはディスク(キャッシュtierやキャパシティtier)障害を実施する場合は多いかと思います。ただディスクは他のテストとは違ってその状況を作れません。となるとよくやりがちなのが”稼働中のディスクを抜く”… (過去に障害テストとして稼働中のディスクを抜く操作を紹介もしました)

これはAbsent状態になり、きちんとした障害テストではありません。(もちろんこの状態でClomRepairDelayに設定されている時間が過ぎるまで放置しておけばデータの再同期が行われますので結果的には同じかもしれませんが…)

 

じゃあ、どうすれば良いかというと… Failure Testingを利用します。

 

VMwareオフィシャルドキュメントのこのFailure Testingにはホスト障害、ディスク障害について説明するとともに擬似ディスク障害を発生させるコマンドも紹介をしています。

/usr/lib/vmware/vsan/bin/vsanDiskFaultInjection.pyc

 

上記のコマンドを使うと簡単にディスクをPermanent Error状態にできます。是非試してみてください。

 

そもそもHCI系でディスクの障害テスト目的は”ディスク障害でもサービス(仮想マシン)は停止しない”ことのはずです。が、それが変に”仮想マシンの可用性をどのように復旧する”ことを確認することになっているような気がします。 :)


● 隔離アドレス変更後はHAの再有効を忘れずに

これもご存知のとおり、vSANを構成するとハードビートが管理ネットワークからvSANネットワークに変わります。なのでホスト隔離時に利用する隔離アドレスも変更する必要があります。隔離アドレスはvSphere HAの詳細設定から変更しますが、うっかり忘れることが一つあります。

隔離アドレスの変更はvSphere HAを一旦無効にし再有効にしないと反映されません。隔離アドレスの変更後は必ずvSphere HAの無効→有効を実施しましょう。 🙂


VCSAをEasy InstallでインストールしたらvSAN構成後ストレージポリシーの適用を

vSAN 6.6からvSANクラスタ上にVCSAをインストールすることが簡単になりました。VCSAデプロイ時、”新しいvSANクラスタに含まれるESXiホストにインストール”オプションを選択するだけでシングルホストにvsanDatastoreを作り、その上にVCSAをインストールしてくれます。あとは残りのESXiホストをvSANクラスタに追加して上げればvSAN構成は完了です。簡単です。:)

しかし、よく考えてみてください。vsanDatastore上にVCSAをインストールしたことは、自動的にvSAN Default Storage Policyが適用されるということです。vSAN Default Storage PolicyはFTT=1でStripe=1です。ということは最低3ホストが必要ということです。でもVCSAをインストールした時点だと1ホストしかありませんのでVCSAはストレージポリシーに適用されてない状態になります。

 

Easy InstallでVCSAをインストールした場合は、vSANの構成がすべて終わってから忘れずにストレージポリシーを適用しましょう。 🙂

 


vsanDatastoreに大きい仮想マシンを作成したら

vsanDatastoreには最大62TBのvmdkファイルが作成できます。他のストレージと変わりません。ただvSANの場合は最終的キャパシティディスクには”コンポーネント”として書き込まれます。このコンポーネントにも最大サイズがありまして、1つのコンポーネントの最大サイズは255GBです。要は255GBを超えるファイルは自動的に分割され複数のキャパシティディスクに書き込まれます。例えばvmdkファイルサイズが1TBの場合、キャパシティディスクに書き込まれるコンポーネントは4つ以上になります。FTT=1の場合は8つ以上になります。オブジェクトは分割されません。コンポーネントが分割され、その情報はメタデータによって管理されます。

上図のようにある仮想マシンがあり、3つのvmdkを持っています。ストレージポリシーはFTT=1です。ハードディスク1と2は100GB程度のサイズです。ハードディスク3は約400GBのサイズです。ハードディスク1はFTT=1なので2つのコンポーネントがそれぞれ異なるホストに書き込まれています。

 

ハードディスク3は400GBなのでコンポーネントの最大サイズを超えてます。RAID 1の中にそれぞれRAID 0で3つに分割されて書き込まれていることが分かります。(何個に分割されるかはそのファイルのサイズによります)

面白いですよね。 🙂

大きめの仮想マシンを作成する場合は、このコンポーネントの構成や配置も一応考慮した方が良いかもしれません。


 

vSANの導入や運用で少しでもお役に立てればうれしいです。:)

 

 

 

 

広告