せっかくNestedでvSphere7環境を構築したので
vSphere7がリリースされてそれなりに経過していますが、当時自身の環境ではvSphere7の構成を組むにはこちらのハードウェアが古すぎる・・・ということで自分の所の環境ではなかなかvSphere7の機能評価とかが出来ずに居ました。
が、Twitterの知人から「NestedならvSphere7の環境が組めるよ？」とのアドバイスを頂いて実際やってみると、割とすんなりvSphere7が組み上がりまして。VMなんかも立ててみたり、分散スイッチ組んでみたりvMotionのパフォーマンスを見てみたり色々やったのですが、今回VSANを組んでみようということでこれを試してみることにしました。
この記事では、vSANの組み方そのものは論じません。どちらかというとvSAN構成時にはまったポイントや運用上役に立ちそうな機能などを主に取り扱いたいと思います。(構成手順に関する情報は割とたくさんありますので）
VSAN Datastoreを組む自体は簡単だった
今回構成したvSphere7及びVSAN構成は以下の通りです。
後述するんですが、事情あってクラスタノードは4台構成となっています。本当は最小3台で行けると言うことでそれを狙ったんですが、構成制約で4台になったという感じです（何故そうなったのかは分からない）。
分散データストアを組む手順は割と簡単でして、以下の点に気をつければ基本的にそれほど難しくなく「vsandatastore」という名のついたデータストアができあがります。この記事では手順を割愛しています。
参考としては、上記資料をベースにすると良いかなと思います。以下のように、いずれかのネットワークでも良いので、VMKernelには必ず「VSAN」の役割を与えるようにしましょう。加えて、ライセンスの適用を忘れずに・・
大変なのはストレージポリシーの定義
データストアが「データストアが出来たぞー、わーい」と喜んだのもつかの間、じゃぁNAS上に配置していたVMをこの分散データストアに置くかと思ったらこっからが大変だったのです。
フォルトドメインは細かく分かれる方が正みたい
最初、フォルトドメインの意味が正しく理解できておらず、1つのフォルトドメインに全てのESXiホストを突っ込んでいました。が、実はこれが間違いだったことを知ります。
フォルト ドメインは、データセンターでの物理的な場所に基づいてグループ化された 1 台以上の vSAN ホストで構成されます。フォルト ドメインが構成されている場合、vSAN では、物理ラック全体の障害とともに、単独のホスト、キャパシティ デバイス、ネットワーク リンク、またはフォルト ドメイン専用のネットワーク スイッチの障害を許容できます。
https://docs.vmware.com/jp/VMware-vSphere/6.7/com.vmware.vsphere.virtualsan.doc/GUID-8491C4B0-6F94-4023-8C7A-FD7B40D0368D.html
要は、フォルトドメインというのは「設備が同一のものを1つにまとめる機能」であり、例えばラック、例えば電源、例えばシャーシと言った設備的な近接位置を定義するものでした。今回のように小規模なクラスタ構成にした場合、1つにまとめることは、全ての可用性を捨てることに等しい行為なんですね。
そのために、許容されるフォルトドメイン数が0となり、可用性としては全くない状態となってしまい、全てのストレージポリシーが互換性を失っていました。小規模クラスタを構成する場合は、スタンドアロンフォルトドメインのまんまで構成するか、ノード単位でフォルトドメインを個別構成することが正しいようです。。
3ノードだとRAID1ポリシーが動かない
当初実は3ノード構成で組んでいました。で、ストレージポリシーは「vSAN Default Storage Policy」だったのですが、これが何故か通らずにやっぱりVMを配置することが出来ないという。見てみるとノードの数が足りないと仰る。そこで、ギリギリリソースに余裕のあったDL160G8にもう1ノードESXiサーバを構成し、それをVSANに加えてVSAN Default Storage Policyを適用したところ無事に適用できた模様で・・・
分散単位上の問題があるってことなのかな？とか、色々不明なところはあると思うんですが、取り敢えず本当の意味での最小単位（2ノードVSANを除く）って4ノードのようです。
RAID5/6はAll Flashでしか使用できない
RAID5/6と言うのは名称上のアヤであり、実際には「イレイジャーコーディング」という仕組みを用いて可用性を担保します。で、個人的にはvSANってRAID5的な想定で組むものだと考えていたので、特に何も考えずに当初はRAID5想定のストレージポリシーを組んでいました。
が、これも互換性が担保できないようで、VMが配置できない。メッセージを見てみると「HDDが入ってんじゃ組めねーよ」とのこと。どうやらハイブリッドでは組めないようです。VMware社のブログを見てみると仰るとおりそのことが書かれていました。
おうふ・・・知らなかった。というわけで、ハイブリッド（SSD＋HDD)構成である限り原則RAID1になりそうです。
容量管理に対する考え方
実は、vSANデータストアを組んだ時点でのその総容量はvSANクラスタにおけるCapacity階層の総量になります。よって、今回構成した場合のデータストア容量は2,000GBとなります。でもそれだと普通考えてみればJBODみたいなもんで、それをそのまま消費するのは可用性もクソもないという話になります。
実体としては、VMDKなりファイルを配置する際に、そのストレージポリシーによって書き込み動作が変わることで「使用量が変化する」と言うことになります。
例えば100GBのVMDKがあるとして、これをRAID1ベースのストレージポリシーが構成されている場合、そのオブジェクトは2つのノードに並列して書き込みが行われます。読み出しは2ノードからストライピングする形で処理されます。書き込みは2倍のIOが、読み込みはノード単位0.5倍のIOがかかることになります。
キャパシティは本来100GB VMDKを配置するはずが、実質200GB配置することになります。RAID5/6となると、パリティ生成と分散処理が発生するのでこれがより細かく高速化することになり、IO負荷が上昇します。RAID5/6がオールフラッシュじゃないと出来ないよと言うのはここから来てるんだろうなーと思います。
こうしたストレージポリシーはデフォルトを定めれば原則その設定に従いますし、VM単位あるいはハードディスク単位でカスタマイズすることが可能になります。つまりは、同じクラスタ内であってもVM事に可用性を変更させることが可能になる・・・ということでもあります。
これはこれで便利ですが、やっぱりキャパシティ管理が複雑になりがちなので、上図のように容量管理のためのインタフェースが備わっていたりします。RAID5/6のようにオールフラッシュを必要としますが、圧縮/重複排除を行ったときの状況も確認は出来るので、こうした容量管理の方法に慣れていくと言うこともある程度は出来るのかなーと言う気がします。
今後どうしようか
今のところVMUG AdvantageでNSX-Tがダウンロードできることが分かりましたので、やっぱり・・・Tanzuを触ってみたいなーとは思います。まずもって仮想アプライアンスのデプロイメントで性能不足による処理遅延ががっつり発生して死にそうではあるんですが、何とか雰囲気だけでもつかめたら良いな-なんて考えながら、可能な限りで調べてみようと思います。
using WordPress and
Comments are closed