みなさま、こんにちは、VMware の知久です。
この連載では、VMware のマルチクラウド戦略の中心アーキテクチャである VMware Cloud Foundation がどの様な製品で、どの様な価値をお客様に提供するのかを改めてお伝えしています。
前回の連載では、VMware Cloud Foundation のネットワーク構成の詳細をお伝えしましたが、今回はネットワークに並んでインフラの主要コンポーネントとなるストレージ関連についてお伝えします。
1. VMware Cloud Foundation でサポートされるストレージの種類
VMware Cloud Foundation には、コンピュートの仮想化製品である vSphere、ネットワーク仮想化製品のNSX に並んでストレージ仮想化製品の vSAN も含まれていますが、実はストレージには必ず vSAN を使わなければならないわけではなく、通常のvSphere 同様に 外部ストレージを利用することもサポートされています。
例えばお客様のワークロードの要件には、極めて低遅延で高性能なストレージ要件を要する場合であったり、災害対策やバックアップ要件の中で、ストレージ機器独自のスナップショットやレプリケーションを利用しなければならないケース、更には高価なストレージ機器を購入したばかりで、あと数年はそれを利用しなければならないなど、仮想化基盤に外部ストレージを利用する必要性が比較的多いのも事実かと思います。
そこで VMware Cloud Foundation では、ストレージコンポーネントを vSAN だけでなく外部ストレージも利用できるようなアーキテクチャで構成されていますので、お客様は柔軟なストレージ構成を VMware Cloud Foundation 下でも利用する事ができます。
図1-1： VMware Cloud Foundation で外部ストレージが必要になるケース
2. VMware Cloud Foundation のストレージの考え方(プリンシパルとサプリメンタルストレージ)
VMware Cloud Foundation のストレージの考え方として、プリンシパルストレージとサプリメンタルストレージという定義があります。
プリンシパルストレージ
プリンシパルストレージはワークロードドメインで主のデータストアとして利用されるストレージで、ワークロードドメイン作成時に自動的にクラスタで構成されます。
プリンシパルストレージで利用可能なストレージの種類は限定されおり、マネジメントドメインでは vSAN のみ、ワークロードドメインでは vSAN に加えてNFS / FC / vVOL ストレージの中から選択する事が可能です。
プリンシパルストレージの変更は不可となり、変更する場合にはワークロードドメインの再作成が必要になりますので、最初の選定は非常に重要となります。
サプリメンタルストレージ
サプリメンタルストレージは、位置付けとしてプリンシパルストレージの補助的な要素となり、バックアップやデータアーカイブ向けを想定していますが、仮想マシンを稼働させるデータストアとしても問題なく利用して頂けます。
例えばプリンシパルを vSAN にして、サプリメンタルに NFS データストアを構成して、同一クラスタ内で仮想マシン毎にストレージを使い分ける様なことも可能です。
ちなみにプリンシパルストレージは Bring up もしくはワークロードドメイン作成の際に自動的に構成されますが、サプリメンタルストレージはセットアップが完了した後、通常の vSphere 同様に vCenterからストレージを追加する形になります。
そのため、SDDC Manager ではサプリメンタルストレージに関しては、関与しない形となります。
サプリメンタルストレージでは、プリンシパルでは利用出来ない iSCSI や最先端の NVMe ストレージなど、より多くのストレージを利用可能です。
図2-1： VMware Cloud Foundation プリンシパルストレージとサプリメンタルストレージで利用可能なストレージの種類
3. プリンシパルストレージとして外部ストレージを利用する場合の注意事項
プリンシパルストレージに vSAN を利用する場合には、Bring up や ワークロードドメイン作成 ウィザードにパラメータを入力していくことで自動的にセットアップを実施してくれますが、外部ストレージを利用する場合には、ストレージの種類に応じて事前に準備する内容が異なります。
NFS ストレージ
NFS ストレージをプリンシパルストレージとして利用する場合、SDDC Manager のワークロードドメイン作成ウィザードの中でマウントする NFS ストレージを選択することでワークフローの中で構成する事が可能です。
ただし、前提条件として前回お話しした通り管理用以外の VMKernel ネットワークは IP Pool から IP アドレスの払い出しとなるため、事前に NFS 用の IP Pool を作成し、対象の ESXi をコミッションする際に適切な IP Pool を指定する必要があります。
図3-1： SDDC Manager での NFS VMKernel 用 IP Pool の設定
FC ストレージ
FC ストレージをプリンシパルストレージとして利用する場合には、若干注意事項が必要です。NFS に関してはワークフローの中でマウント処理を実施してくれるのですが、FC ストレージの様なブロックデバイスに関しては、ワークフロー内でマウント処理をしないため、事前に VMware Host Client などを利用して各 ESXi でプリンシパルストレージとなる FC ストレージのブロックデバイスをマウントしてから、ワークロードドメインのワークフローを実施する必要があります。
※ ワークロードドメイン作成前は vCenter が存在せず、対象の ESXi はスタンドアロン状態のため、VMware Host Client からの設定が必要
図3-2： VMware Host Client FC デバイスのデータストアへの追加
vVOL
vVOL を利用する場合には、vVOL に対応しているストレージ機器はもちろんなのですが、vSphere APIs for Storage Awareness (VASA) を使用してストレージベンダーが開発した VASA プロバイダーと SDDC Manager の連携が必要になります。VASA プロバイダーは SDDC Manager から登録することが出来るため、こちらに登録することで、ワークフロー内で SDDC Manager がストレージ機器と連携して、vVOL を構成する事が出来るようになります。
ちなみに余談ですが、現在の VMware Cloud Foundation ではプリンシパルストレージに iSCSI ストレージを利用することはサポートされてないのですが、vVOL のベースストレージとして iSCSI を利用することは可能ですので、もしどうしても iSCSI を利用したい場合には、vVOL にすることで要件を満たすことが可能です。
図3-3： SDDC Manager への VASA Provider 情報の登録
4. VMware Cloud Foundation に vSAN を利用することへの考察
4-1. vSAN を利用する際のメリット
お伝えしたとおり VMware Cloud Foundation では、ストレージ部分に vSAN ではなく、外部ストレージを利用することも可能ですが、vSAN を利用することで以下の様な多くのメリットが存在します。
図4-1： VMware Cloud Foundation で vSAN を利用する際のメリット
End to End の自動ライフサイクル管理
VMware Cloud Foundation で外部ストレージを利用する場合、外部ストレージを SDDC Manager で管理することは不可能なため、ストレージのライフサイクルに関しては切り離され、ストレージ部分は従来の仮想化基盤同様に手動でライフサイクル管理を行う必要があります。
それに対して vSAN では、ソフトウェアに関しては ESXi と同時にバージョンアップされ、さらに vSphere Lifecycle Manager と連携することで、vSAN に必要な RAID コントローラやディスクデバイスなどのファームウェアのアップデートも ESXi のバージョンアップ時に互換性を担保しながら実施出来ます。
そもそも VMware Cloud Foundation は仮想化基盤の運用を出来るだけ簡素化することを目的とした製品になりますので、一部のコンポーネントがライフサイクル管理の枠を外れることで導入に対する費用対効果が低下してしまいますので、vSAN で対応可能な領域は出来るだけ vSAN を活用し、どうしても要件が満たせない部分のみ外部ストレージを導入するのが推奨となります。
性能や容量のリニアな拡張性
vSAN の様なストレージ仮想化製品を活用した Hyper Converged Infrastructure ( HCI )では、サーバー機器の内蔵ディスクを利用してストレージを提供しますので、クラスタ内のサーバー機器を増設するだけで、ストレージの性能や容量を簡単でリニアに拡張することが可能です。
この HCI を VMware Cloud Foundation の下地にすることで、そのメリットを得られるのは、オンプレミスのインフラを効率的に管理する上で、非常に重要な要素になります。
ハイブリッドクラウド構成時のストレージ要件の可搬性
VMware Cloud Foundation のアーキテクチャはオンプレミス以外にパブリッククラウドでも活用されています。
弊社がサービスを提供している VMware Cloud on AWS や、他のハイパースケーラーと呼ばれるクラウドベンダーが提供している VMware ソリューションも同一のアーキテクチャで構成されています。
その様なパブリッククラウド上の VMware Cloud 環境とオンプレミスの VMware Cloud Foundation 環境でハイブリッドクラウドを構成する様なユースケースも多く存在しますが、その際にストレージ部分を vSAN で共通化することで、仮想マシンのストレージ管理をストレージポリシーで一元管理することが可能になります。
例として、オンプレミスからパブリッククラウドに仮想マシンを移動したり、その逆を行った場合でも、同一のストレージポリシーを両環境に準備しておくことによって、可用性などのストレージ要件を大きく変更することなく、高い可搬性を持って運用することが可能になります。
4-2. VMware Cloud Foundation での vSAN 機能の利用可否
最後に VMware Cloud Foundation で vSAN を利用する場合の注意点をお伝えします。
リリースされた当初こそ、最小限のストレージ機能しか実装されていなかった vSAN ですが、バージョンアップのたびに様々なストレージ機能が追加されています。
その中で、vSAN 単体で利用する場合には問題なく使える機能も VMware Cloud Foundation で構成した場合には、サポートされていない機能が一部存在しています。
vSAN 8 から実装された新しいアーキテクチャで高性能ストレージを提供する Express Storage Architecture ( ESA )は、現時点での最新である VMware Cloud Foundation 5.0 では未サポートですし、vSAN クラスタ間で vSAN データストアを相互利用する HCI Mesh の機能に関しては、vSAN クラスタ同士であればサポートされていますが、vSAN クラスタではないクラスタからの構成に関しては、まだサポートされていません。
vSAN の主なストレージ機能の一覧と VMware Cloud Foundation でのサポート状況は以下の表の通りとなっていますので、VMware Cloud Foundation 導入の際の設計にはご注意下さい。
図4-2： VMware Cloud Foundation 5.0 での vSAN サポート機能一覧
まとめ
今回は VMware Cloud Foundation のストレージ部分についてお伝えさせて頂きましたが、いかがでしたでしょうか。
VMware Cloud Foundation では、必ずしもストレージ部分に vSAN を利用しなければならないわけではなく、多種多様な外部ストレージを利用することが出来るため、要件に合わせて柔軟な構成を取ることが可能です。
あとは実際のシステムや運用要件からどのストレージが最適なのかを決めて、ワークロードドメインを構成していくことが、VMware Cloud Foundation のメリットを活かすポイントになると思います。
次回は VMware Cloud Foundation の一番の目玉機能である、自動ライフサイクル管理について詳細をお伝えしようと考えていますので、お楽しみにしていて下さい。
