みなさま、こんにちは、VMware の知久です。
この連載では、VMware のマルチクラウド戦略の中心アーキテクチャである VMware Cloud Foundation がどの様な製品で、どの様な価値をお客様に提供するのかを改めてお伝えしています。
前回の連載では、VMware Cloud Foundation を利用することで、皆様のインフラの導入や運用にどの様な効果をもたらす事が出来るのかをお伝えしましたが、今回から数回に渡って特定のトピック毎にVMware Cloud Foundation の特徴をお伝えしていきます。
今回は、ドメイン管理という観点を記載させて頂きます。
1. VMware Cloud Foundation におけるドメイン単位でのシステム管理
VMware Cloud Foundation ではドメインという単位でシステムやアプリケーションを区分して管理を行います。もちろん、単一のドメイン上で全てのシステムやアプリケーションを実装することも可能ですが、システム毎にハードウェアやネットワーク、セキュリティ要件なども異なるケースは多いかと思いますので、それぞれドメインを分けて構成した方が管理の効率が向上します。
ちなみに、どの様な視点でドメインを分けるのが効果的なのかは、本 Blog の最後の章で解説していますので、そちらを参照して下さい。
VMware Cloud Foundation のドメインは現在のバージョン(4.x)は最大で15個まで構成可能で、ドメイン毎に必ず vCenter が分かれ、全てのドメインのvCenter は拡張リンクモードで接続されます。また NSX Manager もドメイン単位で分けられますが、vCenter の様に必須ではなく、ドメイン毎に占有するか共有するかの選択が可能です。
VMware Cloud Foundation のドメインは以下の2種類に分けられるのですが、それぞれの役割と特徴をお伝えしていきます。
- マネジメントドメイン
- ワークロードドメイン
2. マネジメントドメインの概要
VMware Cloud Foundation のマネジメントドメインは、管理用ワークロードが稼働するためのドメインになり、VMware Cloud Foundation で構成されたvCenter や NSX Manager、VMware Aria の各種管理サーバは必ずこのマネジメントドメイン上に配置され稼働します。
マネジメントドメインは、前回お伝えした VMware Cloud Foundation の初期セットアップである Bring up 時に構成され、VMware Cloud Foundation あたり1個のマネジメントドメインを保持する形になります(複数のマネジメントドメインの構成は不可)。
マネジメントドメインの構成要件としては、最小4台の ESXi ホストが必要で、ストレージには 弊社のストレージ仮想化製品であるvSAN が必須となるため、ESXi ホストには vSAN に準拠しているハードウェア要件も必要になってきます。
なお、このマネジメントドメイン上では、VMware Cloud Foundation で構成された管理サーバ以外の仮想マシンを稼働させることも可能なので、Active Directoryやバックアップサーバなど、全体共通やシステム固有の管理サーバもこちらで統合的に集約することで、より管理効率を向上させることが出来ます。
3. ワークロードドメインの概要
管理系のワークロードを稼働させるマネジメントドメインに対して、ワークロードドメインはユーザーのシステム固有のワークロードを稼働させるドメインで、VMware Cloud Foundation あたり最大で14個まで作成する事が可能です。
最小ホスト数に関しては、マネジメントドメインは4ホストでしたが、ワークロードドメインでは3台、さらにワークロードドメインではストレージに vSAN ではなく、NFSや FC ストレージのような外部ストレージの利用もサポートされており、その場合には2ホストでも構成可能にVMware Cloud Foundation 4.4 から変更になっています。
vCenter や NSX Manager はドメイン毎に構成される点を先述しましたが、これらの管理サーバはワークロードドメイン上には配置されず、全てマネジメントドメイン上に配置され、稼働するため、ワークロードドメインは純粋にユーザー用ワークロードの仮想マシンのみが稼働をする形になります。
ちなみに、各ドメインでは作成時に一つのクラスタが構成されますが、マネジメントドメインでもワークロードドメインでも複数のクラスタを増設する事はサポートされており、最大数も vCenter の構成の上限の範囲で許容されているため、システムやアプリケーションの特性に合わせたクラスタ配置をすることも可能です。
4. ドメインの分け方のポイント
最後に VMware Cloud Foundation においてワークロードドメインをどの様にわけていくかのデザインポイントですが、基本的にはこちらの4つの視点でそれぞれの利用状況によって決めていく形になります。
- アプリケーションユースケース
- ネットワーク
- ストレージ
- ライフサイクルエンジン
アプリケーションユースケースの場合、例えばミッションクリティカルの様なSLAレベルの異なるシステム、VDI環境のようにライセンス体型が違うもの、さらに災害対策環境になると管理するvCenterも異なるものが必要になりますので、このあたりはワークロードドメイン単位で分けていったほうが運用しやすくなります。
ネットワークに関しては NSX インスタンスをワークロードドメイン単位で共有したり占有したりが可能と先述しましたが、システム毎に完全にネットワークトラフィックを分離したいなどの要件がある場合には、ワークロードドメインを分けてNSXも分離するのが効率的です。
また、ワークロードドメインで利用するストレージは、ワークロードドメインの作成時に利用するストレージの種類を vSAN、NFS、FC、vVOL から選択する形になりますので、利用するストレージの種別によってもワークロードドメインを分ける必要性が出てくる場合もあります。
そしてライフサイクルエンジンの部分では、VMware Cloud Foundation の自動ライフサイクル管理を実施する場合、ESXi のアップデートエンジンを従来のvSphere Update Managerベースか、vSphere 7.0 からのvSphere Lifecycle Manager ベースにするのかをワークロードドメイン単位で選択することが出来ます。
vSphere Lifecycle Manager では対応しているメーカー製品であればファームウェアまで含めてライフサイクル管理を実施出来るため、対応するハードウェアを用いたシステムのドメインには vSphere Lifecycle Managerベースのエンジン、対応していないハードウェアを用いたシステムでは、vSphere Update Managerベースのエンジンのワークロードドメインで構成する等の選択が可能になります。
このように、VMware Cloud Foundation では、ドメイン単位でワークロードを分けることで、運用効率を損なうことなく、それぞれのシステムに最適な環境を提供することが実現できます。
次回は引き続きトピックを絞って、VMware Cloud Foundation のネットワークやストレージの構成についてご紹介させて頂く予定です。
