VMware vSAN＋NVMeネームスペースのマジック：1つのSSDを24のデバイスに分割して優れたストレージパフォーマンスを実現
免責事項：本書に記載されているテクノロジーテストは、現在、VMwareによって裏付けられておらず、今後も裏付けられることはないものとされています。特に、VMwareの対応が必須である製品環境での使用は、推奨されていません。
NVMe™は主流となってきており、業界の大半がこのテクノロジーを、vSAN™のVMwareを含めて、より高いレベルのパフォーマンス標準として適応するよう推進しています。特にSSDに向けて構築されたNVMeプロトコルには、従来のSAS/SATAストレージを上回る数々のパフォーマンス上のメリットがあり、その中でもおそらくレイテンシーの改善が最も重要と思われます。PCIeインターフェイスにおけるNVMeプロトコルは、SAS/SATAプロトコルの上のスタックをほとんど迂回するので、レイテンシーが低く、IOPSが大きく、CPUクロックサイクル、消費電力、熱放出などを低減しつつ高いスループットを実現できます。
ほぼ未知のNVMeネームスペースの紹介
多くの人が把握していないNVMeプロトコルの機能は、ネームスペースです。ネームスペースは、ひとつのSSDを、パーティションのような論理的に個別の小さなドライブに分割することを可能にします。しかしパーティションとは異なり、ネームスペースはそれぞれ固有の提出・完了キューを備えており、高度に並行した操作を可能にします。NVMeドライブはすべてネームスペースを活用していますが、ほとんどのドライブは単一のネームスペースのみに対応し、あらかじめ設置された主要ネームスペースがドライブ能力全部を占めています。Micron® 9300 MAX NVMe SSDを使うと、ご希望のサイズの個別のネームスペースを32個まで設定することができます。
マイクロン9300が提供する最小サイズは3.84TBなので、600GBのみ活用されることを考慮すると、vSANキャッシュデバイスに向けて9300 NVMe SSD全体を使用することは理に適っていないことが判りました。そこで、ネームスペースを使ってSSDをもっと小さな論理ドライブに分割し、それぞれを別個のストレージデバイスとしてVMware ESXi hypervisorに示すという、突飛なアイデアを思いついたのです。
「なぜそうするのか？」 スケーリング！
非常に少ないドライブスロットを備えた最小限のサーバーを活用する、小さなROBOコンフィギュレーションを思い浮かべてください。従来のvSANコンフィギュレーションでは、パフォーマンスをスケールするドライブが複数必要です。vSANは追加のディスクグループそれぞれに別のスレッドを追加するからです。スロット数を限定する場合は、基本的に、単一ディスクグループに制限され1つのスロットをキャッシュドライブ専用にしなければならないので、パフォーマンス（能力も）が制限されます。マイクロン9300 SSDは、単一U.2ドライブに最大15.36TBまで搭載することができ、ネームスペースを用いて非常に高い密度と性能を実現できるのです。もう一つのユースケースとして、最低限のサーバーを使ったエッジコンピューティングが挙げられます。スクラッチディスクをRDMとして複数のVMに送ることができるため、vSAN以外に使用することもできます。
この実現を準備する際に、私は、マイクロン9300を用いてネームスペースを活用し、2つのノードのコンフィギュレーションにHCIBenchを使ったテストを行いました。2機のDell R730サーバーを使用し、そのそれぞれにデュアルIntel Xeon 2690v4プロセッサー、256GM RAM、単一のマイクロン9300 SSD、デュアル 25GbE NICを備えました。vSANパフォーマンスが複数のディスクグループでどのようにスケールするか、1ディスクグループあたりの起動能力、ストレージプロファイルなどを知ることがこのテストの目的でした。公平に比較できるよう、各テストに同じHCIBenchコンフィギュレーションを使用しました。このコンフィギュレーションは、1ノードあたり4VM、1VMあたり8VMDK（各100GB）、1VMDKあたり4スレッドで構成し、128のアウトスタンディングIOにしました。この研究から分かった最大の教訓は、ディスクグループ数が劇的に増加すると、パフォーマンスが向上するということです。3つのディスクグループの読み取りパフォーマンスは、単一ディスクグループの約3倍です。読み取りと書き出しのスケーリングは以下に示しています。これらの数はvSANデフォルトストレージポリシーを用いてレポートされたもので、重複削除と圧縮が不可とされています。
3つのディスクのグループは、単一ディスクのグループのほぼ3倍のパフォーマンス
上記のグラフが示すとおり、読み取り・書き出しパフォーマンスは両方とも、ディスクグループでスケールします。3つ以上のディスクグループに対する結果は無視できる程度であったため、3つのディスクグループを維持しました。パフォーマンススケールは、書き出しより読み取りの方が良いことに気づきました。書き込みテストは、激しいデスケージングを経るのに十分な時間起動させたため、パフォーマンスが低くなっていることを留意してください。キャッシュ階層でデータセットのフィットが100%のテストがあった場合は、数字は実質的に高くなる可能性があります。
1機のデモサーバーで4つのvSANノードを作成する
この研究に伴い、私はVMworld’19での機能性を誇示したかったのですが、私の実演を行うためだけに2機の嵩張るサーバーを配送したくはありませんでした。その代わりに、2U 4-node Supermicro Big Twin（SYS-2029BT-HNC0R）を使用し、実演として4つのノードのvSANフルクラスターを行うことに決めました。4つのノードのそれぞれがIntel Xeon Gold 6142プロセッサーと、384GBのRAMを備えています。それぞれ6つのドライブスロットがあり、うち4つがNVMeに対応しますが、私には1つだけ必要でした。私はそれぞれのノードに15.36TBのマイクロン9300マックスを配置し、最新のESXi 6.7U3イメージ（ビルド14320388）をインストールして、vSphere センターサーバーアプライアンス（6.7U3 ビルド 6.7.0.40000）に接続し、それぞれのドライブを24個の個別のネームスペースに分割し、そのうち3つの600GBのネームスペースがキャッシュドライブ、21の594GBのネームスペースが能力ドライブとして作動しました。コンフィギュレーションは以下のとおりです。
4ノード vSANクラスターを24のネームスペースに分割して設定
幸運にも、これは標準NVMe機能なので、ネームスペースを設定するのに特別なツールは何も必要ありませんでした。ただ、内臓の「esxcli nvme」コマンドを使って作成しただけです。以下のコマンドは、ネームスペースを作成しコントローラに添付する方法を示しています。
作成：
`esxcli nvme device namespace create -A vmhba3 -c 1258291200 -p 0 -f 0 -m 0 -s 1258291200`
添付：
`esxcli nvme device namespace attach -A vmhba3 -c 1 -n 1`
ネームスペースを作成したら、個別のストレージデバイス（パーティションではなく）としてvSphereホストに表示されます。ホストが知る限り、ネームスペースはそれぞれ個別に分かれた物理的なストレージデバイスでした。そのため私は、自分が単体のドライブのみを実際に使用していることが分かっているときに、複数の物理的なドライブを与えられたようにvSANを錯覚させました。
ドライブがボトルネックの場合は、まったく役に立ちませんが、850K IOPSと3.5+GB/秒スループットを実現することが可能なドライブを使用している場合は、小さな論理的ドライブに分割することが、並列コンピューティングを高めてvSAN（あるいは使用しているアプリケーション）のスケールパフォーマンスを助けます。マイクロン9300 高性能SSDのパワーについて、詳しくは製品ページをご覧ください。
実演を作成するという目的のため、私は、HCIBenchより柔軟でコンフィギュレーションしやすいソリューションを使って、読み込みを生成することに決めました。その代わり、独自のVMを作成し、完全に制御できるようにしました。それぞれのホストに、1VMあたり8VMDKの2つのVMを搭載しました。結果的にはこれが、数を最小限にして管理しやすくしつつ、ネームスペース全体に十分なスレッドを拡散させる最適なVM数となりました。私は、OSとしてCentOS 7.6を使用し、それぞれに8vCPUと単一ネットワークインターフェイスを用いた8GMのvRAMを搭載しました。それぞれのVMには通常のハードディスクとして8VMDKをマウントし、テスト結果が示すとおり、どちらを選択してもパフォーマンスに大きな差はありませんでした。私は再度、重複除去と圧縮が不能になっている、vSANデフォルトストレージポリシーを使用しました。
別途VMを作成してWindows Server 2019で起動し、Iometerツールを使用して、ホストに対して読み込みを生成しました。Iometer作業員にそれぞれのVMDKが割り当てられ、それぞれのホストには、4Kランダムおよび128Kシーケンシャルワークロードに対して、個別に16と1のスレッド（アウトスタンディングIO）が割り当てられました。最適なスレッド数は、単純な試行錯誤から判断されました。目標は、4Kランダム読み取りに対するIOPSを最大化して、128Kのシーケンシャル読み取りでのスループットを最大化（GB/秒）しつつ、それぞれに対して合理的なレイテンシーを維持することでした。パフォーマンスはそれ以上上昇しないのに、レイテンシーが上昇するある一定のポイントがあります。そこが、スレッドの追加を止めるポイントです。
そして勝者は…パフォーマンス！
テクニカルな話はこのぐらいにして、パフォーマンスについてお話しましょう。NVMe、ネームスペース、マイクロン9300SSDを知らないうちに、単一ドライブで素晴らしいパフォーマンスが得られると言われたら、おそらくはあり得ないと思うことでしょう。しかし、このソリューションを採用すれば、20以上の物理的なドライブを備えたほとんどのソリューションよりも、単一ドライブからより優れたパフォーマンスを得ることができます。しかも、かなり小さいフォームファクタで、より高い密度で、消費電力を抑えて、発熱が少なく、TCOを抑えて、実現できるのです。
このコンフィギュレーションを用いて、私は750K IOPS（4Kランダム読み取り）と、11.5GB/秒以上（128Kシーケンシャル読み取り）まで記録することができました。スループットは非常に高く、ソリューションに3番目のNICを追加して、vSANが2つの専用NICを備えるようにしなければなりませんでした。1ノードにつき平均21Gbps以上を記録し、一部のノードは25Gbpsに達したときもありました。つまり、vMotion、管理、その他のネットワーク機能の専用を備えていないvSANだとしても、デュアル10GbE NICを用いて可能なパフォーマンスよりも、高いパフォーマンスを実現しているのです。
VMworld’19でのマイクロンNVMeネームスペース実演
実演はVMworldのSolutions Exchangeで起動しましたので（空調設備を備えたラボ環境ではない場所で）、ノイズが問題となっていました。私はパワー設定を、パフォーマンスは若干低下するものの、4日間で550K以上のIOPSを維持できる、「エネルギー効率」に下げました。これはストレートの4Kランダム読み取りテストで、スループットが2GB/秒のみであったのはそのためです。ブロックサイズを128Kに切り替えていたら、スループットが約8GB/秒まで急上昇し、IOPSは約62K IOPSまで低下すると思われます。
それぞれのノードは2つのVMを起動したので、各指標に対して8つの個別の数字がレポートされたことに留意してください。8つの読み込みVMの他、私は、Kibanaを搭載した3つのノードElasticsearchクラスター（各VMの起動にMetricbeatを使用しホスト指標を収集）、vCenterサーバーアプライアンス、そして管理にはWindowsサーバーを使用しました。合計14個のVMをこのクラスターで起動したわけですが、このドライブは少ない労力でこのパフォーマンスを実現しました。
実演では、VMworldの面白さを凝縮したものでした。1日で、このコンフィギュレーションに関するプレゼンテーションをいくつか行い、Virtually Speaking（@virtspeaking）の方とのポッドキャストに参加して、vSAN、オールフラッシュ、ネームスペース、ネットワーキング、耐久性、コスト、TCOなどについての見通しをお話ししました。
この右側がVirtually Speakingで話している私です
私たちはこれをさらにテストして、より多くユースケースを作成するよう計画しています。マイクロンとVMwareは提携しており、近い将来サポート済みのコンフィギュレーションとして登場することを期待しています。オールフラッシュvSANクラスターが注目を集める前の、VMworld 2014にマイクロンのストレージ専門家が参加したことに、人々は不思議に思ったものでした。当時も、私たちはクレイジーだと思われていたのです！😉
Xでマイクロン@MicronTechnologyをフォローし、LinkedInでマイクロンとつながることで、最新情報をチェックできます。