VMware Cloud on AWS ～ ストポリとVMC's SLAの密な関係 編 ～
在宅勤務が続く中、ふとした拍子に事務所へ出社することがあるのですが、出社した翌日、なんと足が筋肉痛になることがあります。
これが噂の…
30代を超えてすぐ疲れる身体を手に入れたが…
これほどまでにッ！
絶不調の陰鬱とした気分はなかったなァ…
フッフッフッフッフッ 在宅勤務のおかげだ
本当によく疲れるッ！
最高に「出勤肉痛」ってやつだアアアアアア
アハハハハハハハハハーッ
ってやつですね。
私はDIO様ではないので、↑のセリフを8～9秒の僅か1秒の間にしゃべることはできませんが、運動不足をまさか出社で感じることになるとは思いもしませんでした。
さて、今回は(だいぶ)以前ご紹介したVMware Cloud on AWS(以降VMC)のSLAと関連して、VMCで使用されているvSANのストレージポリシーと、SLAの関係について、ご紹介しようと思います。
ストレージポリシーって…？
ストレージポリシー、通称ストポリは、vSAN データストアにおいて仮想マシンや仮想ディスクの冗長性や耐障害性を定義したものです。
たとえば、vSANには、Failures To Tolerate、いわゆる『FTT』と呼ばれる考え方があります。訳すると、障害許容台数であるFTTは、その意味の通りESXiホスト何台までの障害に耐えられるようにするか、という考え方です。
こうした定義をVMwareでは、「ストレージポリシー」という形で事前に定義し、仮想マシンや仮想ディスクに対して、このポリシーを適用することができます。
つまり、
仮想マシンや仮想ディスクごとに耐障害性などを決められる、ということですね。
↑こんな感じ。
ちなみに、VMCにおけるFTTと、その設定を行うのに必要なESXiホストの最低台数は、VMwareのドキュメントで公開されています。
ホスト3台などの小規模環境では、RAID-1構成しか選べないので注意です。
さーて、本題のお時間です。
ストポリが何となくイメージがついたところで、タイトルの「ストポリとVMCのSLA」の密な関係についてお話ししようと思います。
いつぞや、↑のような記事を書いたのですが、VMCには、SLAがあり、それが守られなかった場合「クレジットの返還」という形で補償してくれる旨を記載しました。
その条件も少し記載したのですが、
• For non-stretched clusters without VMware Elastic vSAN™ for VMware Cloud™ on AWS(“VMware Elastic vSAN”), you must have a minimum configuration for all VM storage policy Numbers of Failures To Tolerate (FTT) = 1 when the cluster has 2 to 5 hosts, and a minimum configuration of FTT = 2 when the cluster has 6 to 16 hosts.
・VMware Elastic vSAN™ for VMware Cloud™ on AWS（「VMware Elastic vSAN」）を使用していない非ストレッチクラスタの場合、クラスタのホスト数が2～5の時は、すべてのVMストレージポリシーのNumbers of Failures To Tolerate（FTT）=1、クラスタのホスト数が6～16の時は、FTT=2 が最小構成になっている必要があります。
↑この記載です！
そう、VMCのSLAを守るためには、このストポリの設定も重要です。
VMCでは、既定でVMC Workload Storage Policy - Cluster-1 というストレージポリシーが作れています。
このポリシーは、ユーザーが使用できるWorkloadDatastoreの「デフォルトストレージポリシー」に適用されていますので、仮想マシン作成時に変更したりしなければ、既定でこのポリシーが使用されるようになっています。
VMCでは、上記のSLAを守るために、このVMC Workload Storage Policy - Cluster-1 のポリシー設定が、ホスト台数によって自動で変更されるように作られています。
SLAクレジット返還条件にも記載されているように、
クラスタのホスト数が6～16の時は、FTTが自動で2になるのです。
↑ 実際に変わった時のキャプチャです。
逆に、ホストの台数が減っていけば、またFTT=1に戻ります。
このあたりの調整を自動でしてくれるのはとても便利ですね。
えー、じゃぁストポリって変えられないのー？
んなことはありません！
ちゃーんと、オンプレミス同様に、自分で作ったストポリに変えることができます。
普通に考えて、RAID-6とRAID-5では、パリティビット用のディスク本数の関係上、実行容量は、RAID-5の方が大きくなります。
たとえば、ホストが6台を超えたときのことを考えてみましょう。
ホスト6台以上になると、自動でポリシーがRAID-6に変更されてしまいます。
でも、容量のことを考えると、RAID-5を使いたいようなときはどうすればいいのでしょうか？
ずばり、
自分でストポリを作って仮想マシンに適用するしかありません。
よって、ストポリを自分で定義して、仮想マシンに適用するというオペレーションについては、制限されていません。
変更はできる。ただし、注意しようね。
ストポリの変更自体はできますが、2つほど大きく注意しないといけない点があります。
管理コンポーネントのストポリ
過去記事でも何度も記載している通り、vCenterやNSXのコンポーネントに対する操作権限をユーザーは持たないので、これらのコンポーネントのストレージポリシーは、変更できません。
ホスト台数縮小時の妨げになることも
VMCでは、ホスト台数の拡張とは逆に、縮小(最低3台)もできます。
6台→3台に縮小するときのことを考えてみましょう。
ストポリを、VMC Workload Storage Policy - Cluster-1 を使用している場合は、
ポリシーが自動で、ホスト3台で使用できるものへと更新されます。
ストポリを、VMC Workload Storage Policy - Cluster-1 を使用していない場合は、
ポリシーは、自分でホスト3台で使用できるものへ変更する必要があります。
というのも、仮にホスト6台構成でRAID-5を使用していた場合、
ホスト3台構成では、RAID-5構成ができないため、ホストの縮小を妨げてしまう可能性があるのです。
なので、縮小前にストレージポリシーを縮小後の台数で使用できるものへと変更しておく必要があります。
最後に
ホスト台数とvSAN実行容量が比例する傾向にあります。
ただ、ホスト台数の増加はそのままVMCの利用料金として返ってくるので、できればホスト台数を抑えつつ、実行容量を可能な限り大きくしておきたい、というのが心情ですよね。
ただ、今回ご紹介したように、ストポリを変更させることは、VMwareが公表するSLAを守れない構成に、自分で変える、ということに他なりません。
ストレージ ポリシーと SLA 要件
仮想マシン ストレージ ポリシーを使用する場合、それが vSAN クラスタのストレージ容量の利用への影響と、それがVMware Cloud on AWS のサービス レベル アグリーメント (SLA) で定義されている要件を満たしているかを理解することが重要です。
デフォルトの vSAN ストレージ ポリシーは、最初にクラスタ内のホストの数に基づいて設定されます。たとえば、3 台のホストのクラスタのデフォルトは、Raid-1 ミラーリング ポリシーを使用する FTT=1 です。4 台のホストのクラスタでもデフォルトは FTT=1 ですが、より容量効率の高い Raid-5 イレージャ コーディング ポリシーを使用します。1 つの AZ 内に 6 台以上の i3.metal ホストを持つクラスタのデフォルトは、Raid-6 のイレージャ コーディング ポリシーを使用する FTT=2 です。基盤となるデータのニーズとデータの可用性を一致させるカスタム ポリシーを作成することができますが、サービス レベル アグリーメントで設定されている要件を満たさないストレージ ポリシーを持つワークロード仮想マシンは、SLA クレジットに適合しない場合があります。仮想マシン ストレージ ポリシーは、適切なレベルの保護を使用して設定する必要があります。短期のワークロードでは、可用性に関する SLA を結ばずに、キャパシティを節約するためにデータ冗長性を持たないポリシーを使用することがあります。
↑ VMwareのドキュメントでも上記のように記載されています。
SLAクレジット返還条件を満たさない構成であることを覚悟しつつ、ストポリを変更するのか、あるいは実行容量を取るのか。
お客様との会話が必要になってくると思いますので、このあたりの動作をしっかりと理解して、最適な環境をご提供したいですね。
ではでは。
