【備忘録】vSAN HCI Mesh Tech Note を読む

Sep 19, 2020 vSphere vSAN
Share on:

Table of contents

はじめに

vSAN 7.0 Update 1 で HCI Mesh なる気になる機能が出てきたようなので、Tech Note を読んで咀嚼して「これポイントかな～」と思ったものを自分用の備忘録としてメモしておく。本記事時点では vSAN 7.0 Update 1 もリリースされていないので検証もしておらず、また、ほとんど落書きに近い内容のため、情報の正確さ等は保証できないことに留意されたし。

VMware vSAN HCI Mesh Tech Note

Why HCI Mesh

従来の vSAN はホストの追加で Computing と Storage の両方を同時にスケールできる。このため、アプリケーションのワークロードの増加に合わせて Computing と Storage が共に自然に増加すれば、長期的なキャパシティプランニングを行いやすい。

その一方で、以下のようなイベントが起きると Computing と Storage のどちらかにリソース要求が偏ったり、キャパシティプランニングが難しくなったりする。このため一方のリソースを使い切る or 無駄なリソースが余るといったように、vSAN として適切なサイジングが難しくなる可能性がある。

  • アプリケーションの改修でログ出力用にストレージが大量に必要になる。
  • 新しい分析サービスの提供にあたって大量のコンピューティングリソースが消費される。
  • 企業の M&A で新部門にストレージが必要になるが事前に見積もれない。
  • NSX などのネットワーク仮想化で既存のレガシーなクラスタを統合／移行したい。

伝統的なストレージでは、複数のストレージアレイを1つにまとめて仮想化するソリューション(多分 EMC ViPR みたいなのを指してる)があるものの、レイテンシや構成の複雑さも追加されるため、管理者がベーシックなオペレーションだったりトラブルシューティングだったりで複数の UI やツールの使用を強いられるケースがある。

vSAN でも同じ実装にすると色々と辛いのでネイティブの通信プロトコルを使ったアプローチを取ったらしい。確かに、もう一段階抽象レイヤーを加えて複数の vSAN データストアを統合、みたいなアプローチだと更に複雑になりそうなので妥当な印象。

また、vSAN では既に iSCSI や NFS としてエクスポート出来るにも関わらず、あえてネイティブな vSAN プロトコルで実装した理由は主に以下のようなもの。

  • ストレージポリシーベース管理(SPBM)を維持できる。
  • vSAN の RDT プロトコルなら compute や I/O のオーバーヘッドが少ない。
  • I/O のモニタリングに vSAN パフォーマンスサービスが使える。
  • iSCSI の LUN や NFS の exports など、個別のストレージ管理も余計な抽象レイヤーも必要ない。
  • ストレージリソースを引き続きクラスタのリソースとして管理＆メンテナンスできる。

見る限り、vSAN のメリットをなるべく損なわずに享受できるようにしたいという意図が見える。

なお、RDT (Reliable Datagram Transport) は vSAN の I/O に使われるプロトコルで、TCP (2233) 上で動く。

Deploy and manage HCI Mesh

Client Cluster と Server Cluster という概念があり、メッシュ関係(?)(Mesh Relationship)は Client Cluster 側から定義される。UI で Client Cluster から [Mount remote datastore] とすると、vSAN データストアをリモートマウントできる。

リモートマウントされた側のクラスタが Server Cluster。

Migrating Storage to HCI Mesh

一度メッシュ関係を構成したら、あとは単純に Storage vMotion でデータストアを移行するだけで仮想マシンがリモートの vSAN データストアに移行される。

移行時にストレージポリシーも変えられる。例えば RAID1-FTT1 のポリシーから RAID5/6-FTT1 のポリシーに変えられる、というのは重要なポイント。

「It is at this time, not supported to split VMDKs of a given VM across multiple datastores.」とあるので、現時点では VMDK ごとにデータストアを分けて配置するのはサポートされないようだ(後で HCI Mesh の制限事項として出てくる)。

Monitor HCI Mesh

HCI Mesh 自体が既定で健全性チェックをいくつか持っている、例えば構成できるかどうかをチェックするなど。Skyline 健全性あたりかな？

vSAN パフォーマンスサービスでリモートのクラスタ宛の I/O パスの状況(?)も見られるらしい。この辺り何が見られるかは実機で要確認。

vSAN の容量監視画面ではリモートデータストアへのリンクが tooltip で表示される。クリックでリモートデータストアの [サマリ] タブとかに飛べそう。

HCI Mesh Design Considerations

HCI Mesh 自身の主な制限事項は以下。

  • 1つの Client Cluster あたりのリモート vSAN データストアは5個まで。Server Cluster もデータストアの提供先となる Client Cluster は5個まで。
  • 1つの vSAN データストアに接続されるホストはローカル／リモートの合計で 64 ホストまで。
  • HCI Mesh に参加できるホストやクラスタは、vCenter Server 配下の1つのデータセンターオブジェクト内に制限される(データセンターオブジェクトは跨げないってことね)。
  • 使えるストレージポリシーは、仮想マシンが実際に格納されるデータストアで使用可能なものに制限される。例えば RAID5/6-FTT=2 の VM をリモートデータストアに格納したければ、Server Cluster が6ホスト以上で構成されている必要がある(仕様を考えれば自然)。

また、HCI Mesh がサポートされていないユースケースは以下。

  • vSAN トラフィックの暗号化
  • ストレッチクラスタ
  • 2ノードクラスタ
  • iSCSI, NFS, CNS のリモートへの提供
  • Air-gapped vSAN Network、マルチ vSAN vmkernel ポート [^3]
  • 1 VM 内の複数のオブジェクトが別々の vSAN データストアに跨る。

Air-gapped な vSAN Network は StorageHub の Advanced NIC Teaming を参照。

Networking Design Considerations

I/O は通常の vSAN と同じ RDT プロトコルを使うので、VM 実行中のホストからストレージをバッキングしているホストに対して直接コネクションが張られる。

HCI Mesh で VM の Computing と Storage を担当するホストが別々のクラスタの場合、クラスタ間のリンクが切断される(＝ストレージアクセスが不可になる)と、そのイベントから 60 秒待ってから APD と判断、そこから vSphere HA の設定値だけ待った後に仮想マシンを再起動しようとするらしい。VMCP の APD 応答の動作に凄く似てるけどそれかなぁ・・・とりあえず70U1リリースされたら要検証。

HCI Mesh は仮想マシンの Computing と Storage が別々の vSAN クラスタになるので、ワークロードへの影響が出ないよう＆性能が適切なレベルになるよう、ネットワーク通信要件を考慮する必要がある。vSAN クラスタ間の通信にレイテンシがあると仮想マシンでのレイテンシの影響が顕著に見られる。

ネットワークトポロジは高い availability を保つこと(NIC の冗長化なりクラスタ跨いだスイッチングなり)。ガイドラインは以下の感じ。

  • ボトルネックにならないようなネットワーク。ストレージクラスの NW 機器を使って E2E で 25Gbps の NW 構成が推奨。
  • NW の遅延はミリ秒未満が推奨。遅延が 5ms 以上だと構成チェックでアラートが出る(マウント自体は出来る)。
  • 他のサービスと帯域を共有するなら vDS と NIOC を使って帯域を確保する(これはいつも通り)。
  • L2 と L3 の両方がサポートされる。L3 を使うならルーティングの構成が必要。

ルーティングに関しては、vSAN 7.0 U1 で VMkernel ポートでのデフォルトゲートウェイのオーバーライドがサポートされるようになったので、これを使うと楽とのこと。

「Designing vSAN Networks – 2019 Update」あたりの記事にもあるけど、vSAN 一般として NW 機器のバッファ不足とかで I/O が詰まったらそこに律速しちゃうので、vSAN ネットワークの機器の選定や構成はちゃんと余裕を持った状態にしておきたい。

おわりに

Tech Note をざっと読んだ結果それほど単純に使える機能ではないようなので、ネットワーク設計の段階からしっかりと考慮する必要があるかなと感じた。特に vSphere HA 周りはなかなか面白いことになりそうなので要検証。