1. はじめに
VMware仮想環境おける仮想マシンの配置ルール(アフィニティルール)、結構便利なので要件によってはわりとよく利用されているのではないでしょうか。
App VMとDB VMを同じESXiで稼働させたいという要件や、逆にApp VM#1とApp VM#2を別のESXiホストで稼働させたいなどがよくある要件として想定されます。
アフィニティ (Affinity) は「類似性」「親近感」という意味で、特定の仮想マシン同士をくっつけたり離したりする設定、と認識すればイメージしやすいかと思います。
若干挙動は異なるのですが、VMware Cloud on AWSでも同様のアフィニティ設定ができるので設定方法を備忘録として残しておきます。
オンプレミスVMware仮想環境などにおける一般的なアフィニティルールについては次のVMware公式ガイドをご参照ください。
2. VMware Cloud on AWS でアフィニティポリシーを設定してみる
今回はいくつかあるアフィニティの選択肢のうち、仮想マシン間のアフィニティと仮想マシン間の非アフィニティについて設定方法を確認してみます。
VMware Cloud on AWSでは、対象仮想マシン(グループ)をタグで指定して、タグに対してポリシーを適用するのが特徴となります。
また前提として、ユーザーが手動で設定することになるアフィニティポリシーよりもデフォルトで有効となっているHAおよびDRSの構成が優先されるため、ホスト台数やリソース状況によっては、必ずしもアフィニティポリシーどおりの挙動とならない点はご留意ください。
VMware Cloud on AWS におけるアフィニティ設定およびその詳細については、次のVMware公式ガイドを参照します。
事前準備
前提となるVMware Cloud on AWS 環境の確認: 初期2ホスト構成
i3.metal x2ホスト構成で構成しており、ネットワークセグメントもデフォルトのカスタマーセグメント以外は存在していません。
vCenterやNSXなど管理系仮想マシン以外には、AWS Backup Gateway、Cent OS、Windows Server、TinyCore Linuxをそれぞれ複数台稼働させています。特にOS間、アプリケーション間の連携はしておらず、ほぼOS初期インストール状態となっています。
アフィニティ設定もしていないので、それぞれの仮想マシンはまばらな状態で配置されています。
下図はデプロイ完了後から数時間が経過しているので、ホスト毎の消費コンピュートリソース偏りもなく、かなり安定している状態です。
タグの作成
vSphere Clientのメニューからタグとカスタム属性を選択し、仮想マシンに付与するタグおよびタグが属するカテゴリーを作成します。
厳密な条件はなく識別さえできれば良いので、自由に命名します。
仮想マシンへのタグの付与
作成したタグを、対象仮想マシンのタグから割り当てます。
今回の環境において、私は次のようにカテゴリー名とタグを命名し、対象の仮想マシンに割り当てました。
下記以外の仮想マシンについては特にタグなどは付与していません。
| カテゴリー名 | タグ | 対象仮想マシン |
|---|---|---|
| Affinity | Linux - CentOS | CentOS_01, 02, 03, 04, 05, 06 |
| Affinity | Linux - TinyCoreLinux | TinyCoreLinux_01, 02, 03 |
| Anti-Affinity | AWSBackupGW-VMs | awsbackup-gateway-01, 02, 03 |
タグとカスタム属性から遷移すると、該当のタグを割り当てた仮想マシンは次のように確認できます。
アフィニティに関するポリシー設定
それではこれからアフィニティに関するポリシーを作成し、挙動を確認します。
vSphere Clientのメニューからポリシーおよびプロファイルを選択し、コンピューティングポリシーに遷移します。
追加を選択し、新しいコンピューティングポリシーを作成していきます。
仮想マシン間のアフィニティ
仮想マシン間のアフィニティを設定し、特定のタグを付与された複数の仮想マシンを同じESXiホストで稼働させてみます。
VMware公式ガイドの次の章を参照します。
新しいコンピューティングポリシーの作成から、ポリシータイプ仮想マシン間のアフィニティを選択します。
適当なポリシー名を設定し、対象の仮想マシンタグを選択します。
まずはLinux - TinyCoreLinuxのタグを選択しています。
ポリシーの作成当初は、ステータスは更新中と表示されました。
その際に仮想マシンの状況を確認してみると、仮想マシンの移行(vMotion)が実行され、TinyCoreLinuxの仮想マシン3台が同じESXiホストに集まりました。
この時点で再度コンピューティングポリシーをの状況を確認すると、正常(準拠)マークが表示されていました。
別の仮想マシングループに対してポリシー追加
追加で、Linux - CentOSに対しても同じように仮想マシン間のアフィニティ`を設定します。
6台の仮想マシンが対象となるので一時的に非準拠のステータスとなりましたが、並行して仮想マシンの移行(vMotion)も行われています。
しばらく経つと準拠(正常)のステータスとなりました。
CentOSの仮想マシン6台が同じESXiホストに集まりまっているのが確認できます。
仮想マシン間の非アフィニティ
仮想マシン間の非アフィニティを設定し、特定のタグを付与された複数の仮想マシンを異なるESXiホストで稼働させてみます。
VMware公式ガイドの次の章を参照します。
新しいコンピューティングポリシーの作成から、ポリシータイプ仮想マシン間の非アフィニティを選択します。
適当なポリシー名を設定し、対象の仮想マシンタグを選択します。
今回はAWSBackupGW-VMsのタグを選択しています。
初期状態: VMware Cloud on AWS x2ホスト構成
対象の仮想マシンは3台あるのに対して、ESXiは2ホストしか存在していません。
当然ながらこの状態では各対象マシンをそれぞれ別々のESXiホストで稼働させることは不可能なので、いつまで経っても非準拠のステータスから更新されません。
ホスト追加: VMware Cloud on AWS x3ホスト構成
ホスト1台追加し、ESXiが3台となるよう構成にします。
メンテナンスモード、vSAN再構成が実行されます。
ほどなくして3台目のESXiホストが利用可能になります。
しばらく待つと準拠(正常)のステータスとなりました。
念のため各ESXiホストの状況を確認しても、それぞれ対象の仮想マシンは別々のESXiホストに稼働していると確認できました。
おまけ: 仮想マシン間のアフィニティポリシーの削除
作成した仮想マシン間のアフィニティポリシーを削除してみました。
仮想マシン間の非アフィニティのポリシーだけは残しています。
この状態でしばらく放置したあと各ESXiホストの状況をみてみると、今まで同じESXiホストでまとまっていた仮想マシンもそれぞれDRSでリソース状況に応じて分散配置されているのが確認できました。
3. さいごに
今回はVMware Cloud on AWS環境におけるアフィニティ設定時の挙動を確認してみました。比較的シンプルでゆるめのアフィニティ設定だったので、想定通りの挙動でした。
VMware Cloud on AWS環境に限らず、一般的なVMware仮想環境においても複雑で厳格なアフィニティ設定にするとリソースのバランシングが最適化されない可能性もあるので、もしも利用される際にはやはりできる限りリラックスさせた運用とした方が良いかと思われます。
4. 参考資料
(VMware Docs) ポリシーおよびプロファイルの使用