ツナカン(TUNA-JP Conference) #11 での、「Tanzu Kubernetes Grid のために自宅ラボの vSAN をあきらめた話、あるいは自宅ラボで vSAN を作っている話。（仮想化基盤の下のストレージのマイブーム）」の発表資料です。
自宅ラボで、仮想マシンを展開する際の問題に対処するときの、物理ホスト側のストレージのマイブームについて紹介します。
- おうちクラウド（自宅ラボ）環境
- vSAN → NFS データストア
- NFS → iSCSI VMFS データストア
- NFS / iSCSI → ローカル SSD の VMFS データストア
- まとめ
- 録画
おうちクラウド（自宅ラボ）環境
まず、私の自宅のラボ環境についての紹介です。
日本にあるので、Aria Operations で表現してみました。
リソース消費が大きめの主な仮想マシンは、ネステッド ESXi や Tanzu Kubernetes Grid ノードです。
自宅ラボの構成方針です。
自宅 vSphere の主要な物理マシンです。CPU 8 スレッド、メモリ 64GB の壁がります。
ネステッド vSphere を利用しています。
ネステッド vSphere を、ネストの内側から見た様子です。
物理マシン側では、基本的に vSAN（OSA）データストアを利用しています。
vSAN のフォルト ドメインは、電源タップ単位で構成しています。
物理 NIC ポートは、1 Gbps x 1ポート（オンボード or USB）のみです。
1Gbps ネットワークのためか、物理マシン（Intel NUC）のためか、このラボでは極端なストレージ遅延が発生しがちです。
vSAN → NFS データストア
vSAN は、メモリ搭載容量が 32GB や 64GB 程度の普通のパソコンで利用するには、メモリのオーバーヘッドが多めです。
そこで、あえて物理マシン側では vSAN の利用を諦めることで、仮想マシン側で多くのリソースを利用できるようになります。
そこで、ネステッド vSphere の ESXi 仮想マシンなどでは、共有データストアに NFS を利用することが多くなりました。物理マシンの vSphere 側に、NFS サーバの仮想マシンを作成して、ESXi 仮想マシンからマウントします。
これで物理マシンの ESXi ではメモリが空くので、ネステッド vSphere 側で vSAN が構成しやすくなります。
ちなみにネステッド vSAN 環境構築には、以前に Nested vSAN Advent Calendar の際に用意した vSAN 自動構築コマンド羅列スクリプトを利用しています。
NFS → iSCSI VMFS データストア
最近は、Tanzu Kubernetes Grid（TKG）による Kubernetes クラスタを作成することが多いのですが、この製品では仮想マシン（テンプレート）のクローンで Kubernetes ノードを用意します。
そんなときに、NFS サーバ仮想マシン / NFS データストアを利用するネステッド vSphere 環境では、仮想マシンのクローンで時間がかかることがあります。
そこで、Linux-IO（LIO）の iSCSI Target が VAAI に対応しているらしいという噂をもとに、Oracle Linux 9 で iSCSI データストアを構築するようになりました。
iSCSI データストアとして ESXi からマウントしてみると、VAAI に対応していそう（ハードウェア アクセラレーション = サポート対象）に見えます。
実際に仮想マシンをクローンしてみると、クローン処理中に iSCSI 接続経路にほとんどネットワーク トラフィクが発生せず、オフロードがされていそうです。
こんな環境で構築した TKG で、最近は Kubeflow を使用しています。
とはいっても、iSCSI よりも NFS のほうが環境構築が楽なので、なんとなく NFS もまだ利用しています。
NFS / iSCSI → ローカル SSD の VMFS データストア
昨年末には、vSphere with Tanzu 8.0 U2 の環境構築をしていました。
vSphere with Tanzu では、スタンドアロンの TKG とは異なり、仮想マシン クローンではなく OVF のデプロイを多用します。
vSphere with Tanzu の、下記のような環境を構築しました。
vSphere with Tanzu での スーパーバイザー → Tanzu Kubernetes Grid Service（TKGS）では、Supervisor Control Plane VM、Avi Service Engine、TKGS ノードの作成が、vCenter コンテンツ ライブラリでの OVF デプロイです
私の自宅の ネステッド vSphere 環境では、OVF デプロイも時間がかかり、タイムアウト → 仮想マシン削除 → 再デプロイ（エンドレス）。になってしまいました。
（NFS 仮想マシンを利用している例ですが）失敗ケースをあらためて見直してみると、けっこう遠回りな OVF デプロイをしてそうです。
別の失敗ケースでも同様・・・
たまに、奇跡的に成功することがあり、その際の OVF デプロイは、ネットワーク トラフィックがホスト内に閉じてそうでした。ということで、このようなケースでは、1台の物理マシンに閉じた構成にして、データストアもローカル SSD のみを利用すると快適になりやすいです。
ちなみに、昨年の vSphere with Tanzu 8.0 U2 自宅ラボ Advent Calendar 2023 では、大容量メモリ搭載マシンが用意できなかったので1台の物理ホストに寄せることができず、気合と奇跡の力で完遂しました。
ということで、OVF デプロイで時間がかかるような検証では、スペックのよい1台のマシンを用意して、ローカル SSD に仮想マシン配置を寄せられると無難かなと思います。
まとめ
自宅での vSphere with Tanzu や VCF 検証のために、メモリ 128GB 搭載のマシンがほしいと思います。
録画
以上、自宅ラボの紹介と、データストア ストレージのマイブームについての話でした。
