VMware Cloud on AWSのSLAとFTTの関係について
こんばんわ
今日はタイトルの通り、VMC on AWSのSLAとvSANのFTTについて紹介したいと思います。
FTTについてのおさらい
これはvSANの用語なので、オンプレミスでも同様ですが、FTTとはFailures To Tolerateの略で、「障害を許容するノード数」のことです。
例えば、FTT=1というのは、1台のノード障害に耐えられる構成、なります。
また、おなじみのRAIDという考え方も同時に存在し、vSANの可用性はRAID + FTTで表現され、ストレージポリシーという名称で呼ばれます。
例えば、RAID1(ミラーリング) + FTT1 だと、データを2重に複製し、1ノードの障害に耐えられる構成、になります。
また、ノード数によって、FTTの数や選べるRAIDレベルは変わります。
RAIDレベルに関しては、1ノード=1ディスクと考えれば、普通のRAIDと同じですね。
さて、ここまではvSANの機能のおさらいでしたが、これがVMware Cloud on AWSのSLAと関わるので紹介しました。
VMware Cloud on AWS の SLA(Service Level Agreement)
VMware Cloud on AWSのSLAは、（ストレッチクラスタなしのシングルAZ環境で）99.9%と定義されています。
👆にSLA定義が記載されていますが、
以下のそれぞれが、VMware Cloud on AWS サービスの SLA 事由とみなされます。
SDDC インフラストラクチャ：
a) 1 つのクラスタで実行中のすべての仮想マシン（以下、「仮想マシン」）が、継続して 4 分間に
わたり接続を確立できない場合。
b) いずれの仮想マシンからも、継続して 4 分間にわたりストレージにアクセスできない場合。
c) いずれの仮想マシンも、継続して 4 分間にわたり起動できない場合。
SDDC 管理：
a) vCenter Server に、継続して 4 分間にわたりアクセスできない場合。
b) NSX Manager に、継続して 4 分間にわたりアクセスできない場合。
と記載されており、4分間業務が停止するような障害が発生した際には、その分のSPPクレジットの受け取りを要求することができます。
ただし、このSLAはVMwareが定めたストレージポリシーで稼働していることが前提条件となります。
（ストレッチクラスタに関しては除外して抜粋）
- すべての仮想マシン ストレージ ポリシーについて、クラスタのホスト数が 2～6台の場合は、最低FTT＝1以上 であり、クラスタのホスト数が 6～16台の場合は、最低FTT＝2以上 であること。
- クラスタのストレージ キャパシティに 25 % のスラック スペースが維持されていること。
- クラスタに、仮想マシンの起動に必要となる十分なキャパシティがあること。
じゃー、そのあたりは注意して設計が必要かーと思いきや、実は、このストレージポリシーはノード数が追加された際に自動で変更されるようになっています！
ただし、、、
変更されるストレージポリシーは、「vSAN Default Policy」というデフォルトで用意されているストレージポリシーのみになります。
VMware Cloud on AWS では、ストレージポリシーは自由に作成することができ、仮想マシンごとに可用性レベルを変更することができます。
「vSAN Default Policy」以外のストレージポリシーを適用した仮想マシンが存在する場合で、EDRSなどでノードが追加された際には、このSLAの対象からは外れてしまう場合があるのでご注意ください。
逆に、DR環境や開発環境で、SLAの担保が必要ない場合には、あらかじめ「vSAN Default Policy」ではないストレージポリシーを作成し、データストアのデフォルトストレージポリシーにするのもアリですね。
FTTは大きいほど、vSANのデータ消費量が多くなるので、ディスク容量を節約したいときにはあえてFTT=1を維持するというパターンです。
このあたりは用途によって使い分けが可能ですが、前提としてSLAとFTTってのが関係しているんだなぁというのを紹介したかった次第です。
ではでは。
