VMware Cloud on AWS ～ 嗚呼、アフィニティルールよ。君は何処へ？ 編 ～
いよいよ2020年も終わりですね。
個人的に、2020年はここ数年で、一番キツイ年でした。
仕事の難易度といい、私生活といい、『キツイ』の一言です。
とはいえ、目標としてしていた資格2種は無事取得するなど、一部の『キツさ』が報われたのが唯一の救いです。
来年はもっと穏やかに過ごしたい。。。
さて、今回はVMware Cloud on AWS(以降VMC)のピンポイントな機能として、
『コンピューティングポリシー』について、触れていきたいと思います。
コンピューティングポリシーって？
ざっくりと説明すると、vSphere DRSのアフィニティルールのようなものです。
あるいは、
仮想マシン と ESXiホスト
を紐づけ、仮想マシンの動作環境にルールを設ける機能になります。
アフィニティルールをご存じない方のために、簡単に機能を説明します。
たとえば、『アプリケーション』 と それと連携する『データベース』 が仮想マシンと動いていたとします。
これらは、同一セグメントに存在し、ネットワークを通じてデータのやり取りを行うとします。
① 同一ホスト上で動いていた場合
同じ仮想スイッチにつながっている場合は、仮想スイッチで通信を折り返してくれます。
一方、
② 別ホスト上で動いていた場合
この場合、例え同じセグメント同士の通信であっても、一度ESXiホストの筐体の外に出て通信を行います。
ちょっとした軽度の通信であれば、両者の性能に違いはほとんど出ないでしょう。
ただ、大容量のデータが流れるような通信になると、①と②、どちらの通信経路の方が無駄がなく、ネットワーク機器へ負担が軽度になるのか、一目瞭然ですよね？
じゃあ、①の状態をキープしたいときに、どうすればよいのでしょうか？
日々運用をしていくと、vMotionで仮想マシンを移動したりして、知らない間に②のような状態になっていることは多々あります。
この『①の状態をキープする』を実現してくれるのが、『アフィニティルール』と呼ばれるものです。
そのほか、①とは逆に②の状態をキープしてくれる『アンチアフィニティルール』や、特定の仮想マシンと特定のホストを紐づけて、動作するESXiホストを限定させる『ホストアフィニティ』などがあります。
コンピューティングポリシーは、VMC固有の機能だよ
いつぞや、2度に渡りVMCとオンプレミス環境の違いを記載しました。
さて、上記の記事中に「VMCでは、オンプレミスのvSphereと違って触れない部位が結構あるよ」ということを書きました。
その中には、『vSphere HA』や『vSphere DRS』の設定が変更できないことも記載しています。
はい。
察しの言い方はお分かりかと思いますが、
アフィニティルールも使用できません！
(´・ω・`)ﾅ､ﾅﾝﾔﾃ-
とはいえ、この機能。
vSphere DRSにおいては、主要機能と言っても差し支えないほど重要な機能です。
使用できませんじゃねぇんだよ馬鹿野郎。という方、ご安心ください。
冒頭でも書いた通り、VMCには、「コンピューティングポリシー」があります。
やっとこさ本題。コンピューティングポリシーの機能
VMCで使用できる「コンピューティングポリシー」は、アフィニティルールにとって代われる機能となっています。
ただし、細かな部位がアフィニティルールとは異なっているため、ご紹介したいと思います。
① 遵守性(強制力)
アフィニティルールの一つである、『ホストアフィニティ』には、遵守性があります。
must run on (must not run on)
should run on (should not run on)
や
Strict
Loose
などとも呼ばれますが、どの程度そのルールに強制力を持たせるのか、というものです。
例えば、
ESXiホストと特定の仮想マシンを『ホストアフィニティ』により、紐づけたとします。
この仮想マシンは、ルールにより、特定のESXiホストでしか動けません。
ところが、メンテナンスなどで仮想マシンを別のESXiホストに動かさなくてはいけなくなりました。
さぁ、どうする！
Strict(厳格)の場合、
移動不可です。
vMotionのオペレーション段階で弾かれます。
一方、
Loose(緩い)の場合、
移動可能です。
警告はでますが、移動そのものが可能になっています。
これが、いわゆる遵守性(強制力)と呼ばれるもので、Strictの場合は仮想マシンの移動すら許してくれません。
一方で、Looseの場合は、窘められますが、移動そのものは可能なのです。
VMCのコンピューティングポリシーには、この遵守性(強制力)を決める部位がありません。
自動で、Loose(に近しい)設定になるようです。
VMwareのドキュメントによると、これには以下のような理由があるようです。
ホストまたはクラスタのアップグレードをブロックしないようにするため、仮想マシンとホスト間のアフィニティ ポリシーにはいくつかの制約があります。
・ポリシーを利用して、ホストがメンテナンス モードにならないようにすることはできません。
・HA 向けに設定されているホストによるフェイルオーバーの実行をポリシーが阻止することはできません。障害が発生したホストとアフィニティの関係にある仮想マシンは、クラスタ内の別のホストに移行できます。
・仮想マシンのパワーオンをポリシーが阻止することはできません。ホストのアフィニティ ポリシーの対象となる仮想マシンが、どのホストでも対応できないリソース予約を指定した場合、この仮想マシンは、任意の使用可能なホストでパワーオンされます。これらの制約は、準拠したホストが利用可能になるとすぐに解除されます。
強制力が厳しいと、ホストのメンテナンスや障害時に差支えが出てしまう可能性があるから、ということですね。
② グループ作成の方法
VMCでは、ルール決めをするときのESXiホストや仮想マシンを、『タグ』で識別します。
仮想マシンやESXiホストを、インベントリ名から選択できるわけではありません。
ここは、アフィニティルールに比べてちょっとややこしいですね。
下表のようなタグが付いていた場合は、
ホストタグに、『Host_Tag-01』を指定することで、
ESXiホスト #2・ESXiホスト #3・ESXiホスト #4 が、ルールの対象になるわけです。
というわけで、今回はVMCのコンピューティングポリシーについて、簡単にご紹介いたしました。
それでは、皆さま。
良いお年を～ﾉｼ
