IDCF テックブログ

IDCF テックブログ

クラウド・データセンターを提供するIDCフロンティアの公式テックブログ

vSAN ストレージ:容量の考え方について

はじめに

IDCフロンティア エンジニアリング本部の松本です。 プライベートクラウド基盤の設計と開発に携わっています。

今回は、「基盤の設計」とは何か、どのようなことを考えて行うのか、ということの一端をお見せするため、IDCF プライベートクラウド の vSANストレージ、その「容量の考え方」についてお話したいと思います。

【前提】そもそも vSAN って?

ご存知の方には不要かもしれませんが、まずはお話の前提となるvSANについて説明します。

vSANはVMware社の提供するハイパーバイザーOSに統合された仮想化ストレージになります …と言われても、よくわからないですね。少し噛み砕いて表現するなら、vSANは「サーバーのローカルディスクをソフトウェアで束ねて擬似的に1つのストレージ(データストア)を構成する」技術と考えてください。構成されたストレージの容量は、vSANに属するサーバーのローカルストレージを合計したものになります。ストレージの種別としては「オブジェクトストレージ」です。

仮想化環境でストレージを利用する場合、コントローラーのユニットとSSDを格納するディスクアレイで構成される「筐体ストレージ」の利用が一般的だと思います。筐体ストレージは高性能&大容量である一方、技術的、コスト的に導入のハードルが高く、容量の拡張も一朝一夕では難しいです。

対して、vSANは上記の通りサーバーのローカルディスクをソフトウェア(ハイパーバイザーOS)で束ねてストレージを構成します。サーバーのローカルディスクを増やす、あるいはサーバーそのものを増やすことで、ストレージの容量を増やすことができます。そのため、筐体ストレージと比較してより細かくストレージリソースの管理が可能となるのです。

ただ、勿論良いことばかりではありません。vSANがサーバーのハイパーバイザーOSとローカルディスクによって構成される仮想化ストレージだからこそ、筐体ストレージには存在しない制約もあります。

サーバーの故障がそのままストレージ容量の縮退に繋がる、という点が筐体ストレージには存在しない制約のひとつです。この制約についは基盤を設計する上で十分考慮する必要があり、本題の内容にも関係しています。

【本題】vSANストレージ:容量の考え方

前提をお話したところで、いよいよ本題になります。

IDCFでは、vSANストレージの使用を総容量の「50%」推奨としています。vSANを提供しているVMware社の推奨値は「70%」です。

何故そうなるのかを大雑把に表現するのであれば、「vSANはサーバーにストレージの役割も兼ねさせているため、その分のしわ寄せがストレージの使用可能量に跳ね返っている」ということになります。IDCFとVMware社の推奨値の違いの理由も含め、以下ではその「しわ寄せ」の内訳を見ていきましょう。

vSANストレージは、仮想化環境を管理する VMware vCenter Server の「クラスター」という単位毎に「1つ」作成されます。

サーバー1台あたりのローカルディスクが2TBの環境を考えてみると、サーバー6台で構成される「クラスター」のvSANストレージ容量は 2TB × 6 で12TBになるはずです。

f:id:tmatsumoto-idcf:20211115110304p:plain

ただし、vSANの場合この12TB全てをストレージとして使用することはできません。 幾つか理由があります。

重複排除/圧縮のオーバーヘッド

vSANにも配置されたデータを重複排除/圧縮する機能があります。この機能を有効化すると一定のストレージ領域が予約され、「使用済み」の状態となります。確保された領域はメタデータ容量の格納場所になり、ユーザーが使用することはできません。vSANを構成した際、データを配置していないにも関わらず、既に使用済みの領域が存在するのは、大半がこの重複排除/圧縮のためのオーバーヘッド領域です。

下図は実際の vCenter Server上で確認できる vSANストレージ容量の概要です。このストレージには約300GBのディスクしか配置されていない状態ですが、vSANストレージとしては既に8.4TBが使用済みとなっていて、オーバーヘッド領域が確保されていることがわかります。

f:id:tmatsumoto-idcf:20211115111757p:plain

耐障害のために確保される領域

有り体に言ってしまえばRAIDのことなのですが、vSANの場合はディスクではなくサーバー間でRAID(のようなもの)を構成します。理由は簡単で、vSANがサーバーのローカルディスクをソフトウェアで束ねてストレージを構成するためです。

データをvSANのストレージに書き込む際、データのオブジェクトは「コンポーネント」という単位に分割され、「ストレージポリシー」に従って各ホストに配置されます。RAID6を設定している場合、コンポーネントは6ホストに分散して配置される形です。

※「ストレージポリシー」はvSANにとって重要な機能で、vSANのルールを規定するものなのですが、ここでは詳述は控えます。

ホスト間でRAIDを構成する場合でも、ディスクでRAIDを構成する場合と同様実データの他に「パリティ」を作成して配置します。データを配置する場合は「パリティ」分も合わせて消費されます。vSANのストレージ上に100GBのディスクを配置する場合、「パリティ」分を含めて実際には150GBの領域が消費されるということです。

f:id:tmatsumoto-idcf:20211115112120p:plain

ストレージ縮退時の考慮

繰り返しになりますが、vSANはサーバーのローカルディスクをソフトウェアで束ねてストレージを構成します。そのため、サーバーが故障した場合、ストレージの全体容量が縮退してしまいます。vSANにデータを配置する際は、この特性を考慮する必要があります。少し長くなりますがお付き合いください。

※以下に提示している例はサーバー6台のvSANクラスターにRAID6相当のストレージポリシーを適用している前提です。vSANとしてはサーバー2台までの同時故障に耐えます。

f:id:tmatsumoto-idcf:20211115112349p:plain

RAID を構成していれば、サーバーが故障したことで直ちにデータロストが起こるようなことはありません。故障したサーバーのローカルディスクに格納されていたデータは、パリティから復元されます。

ストレージを90%利用する場合

しかし、ストレージの全体容量が減ってしまうことによる影響はあります。vSANデータストアの90%の容量を使用していた場合、下図のようにサーバー1台が壊れ、2TB分のストレージが使用できなくなるだけで直ちにデータロストが発生することがわかります。

f:id:tmatsumoto-idcf:20211115112810p:plain

更に、サーバーが壊れなかったとしても、vSANの仕様上80%を超えるデータストアの容量を使用している場合、平準化のためにコンポーネントの再配置(サーバー間のデータコピー)という動作を繰り返し、ストレージのネットワークが非常にビジーになる、ということが起ります。環境全体のI/O負荷が上がり、仮想マシンのI/O遅延も懸念される状態です。

ストレージを80%利用する場合

では、80%の容量を使用する場合はどうでしょう。図を見ると特に問題ないように思えますが、これにも実は幾つか問題があります。

f:id:tmatsumoto-idcf:20211115113140p:plain

ひとつは、この状態で2台目のサーバーが壊れることに耐えらないということです。RAID6のポリシーを適用し、せっかく2台のサーバーの同時故障に耐えられるようvSANを設計しているいるのに、実際に2台目のサーバーが壊れるとデータが溢れてロストしてしまいます。

もうひとつは、運用上の懸念です。壊れたサーバーが1台だけだったとしても、パリティからデータを復元する過程(リビルド処理)でストレージの使用率が100%を超えてしまうことが懸念されます。このリビルド処理では、復元対象のディスクは復元が完了するまで重複排除と圧縮のかからない状態になり、一時的にvSANデータストア全体の使用量が増加するためです。

ストレージを70%利用する場合

では、VMware 社の推奨値である70%の容量を使用する場合を見てみましょう。こちらであれば、サーバー1台が壊れてもデータロストは起こらず、リビルド処理の過程でも問題は起りません。

f:id:tmatsumoto-idcf:20211115113322p:plain

サーバー2台が同時に壊れた場合を考えると、やはり70%の使用でも問題が出てしまうことがわかりますが、これはクラスターのサーバー台数にも依存している問題です。

f:id:tmatsumoto-idcf:20211115113335p:plain

図のようにサーバー16台、容量32TBのクラスターでストレージを70%使用する場合を考えてみましょう。ひと目でわかる通り、サーバーが2台故障しても、故障したサーバー分のデータをカバーできるだけの余裕があります。vSANストレージの使用量が70%を超えるとRAID6が必ず機能しないわけではなく、クラスターのサーバー台数によって許容されるかどうかが変わるということです。

f:id:tmatsumoto-idcf:20211115113449p:plain

注意しなければならないのは、vSANでRAID6を構成している場合、クラスターのサーバー台数が増えても同時故障の許容数が2台のままだ、ということです。RAID6を設定したvSANストレージにデータが配置される際は、サーバー6台に分散してデータが配置されるため、同時故障の台数が3を超えると、データの総量が溢れることはありませんが、パリティによる復元が効かないオブジェクトが出てきてしまいデータロストになります。

※VMware社の推奨値70%は、今回の例のような「サーバー6台のクラスターにRAID6の設定で2台のサーバーが同時に壊れても大丈夫」かどうかを基準に設定されているわけではありません。先に述べた「vSANの仕様により、ストレージ使用量が80%を超えるとネットワークのビジーな状態が継続」という事象を避けるために設定された値です。

ストレージを50%利用する場合

長々と語ってしまいましたが、まとめると以上のような諸々を考慮した上で、IDCFではvSANストレージの使用は総容量の「50%」推奨とし、クラスターの最小利用台数をサーバー6台と設定しています。これが「容量の考え方」になります。

  • 最大2台までのサーバーの同時故障に耐える(RAID6)
  • ストレージ縮退時にも復元したデータが納まる
  • サーバー2台が同時故障したストレージ縮退時容量を100%とした場合でもデータの総量が80%を超えない

終わりに

今回、「基盤の設計」とは何か?をお見せするため、できるだけ簡単にわかり易くvSANストレージの「容量の考え方」について説明してみようと試みましたが、正直あまりうまくいった気がしません。書いてみて、改めてHCI製品の特性やVMware vSAN独自の設計が積み重なったことによる前提の多さに気づかされました。複雑になりすぎるため、説明を簡略化した箇所も幾つか(これでも)あります。また、段階を追って説明すると長くなってしまいましたが、設計書に起こす場合、こちらの項目は数百ページのうちの数ページ分の内容です。

要約してしまえば、安全に仮想化基盤をご利用いただくために、見た目よりも大幅に少ない容量(総容量の50%)でのご利用を推奨する設計、ということに尽きるのですが、起こり得る障害や取り得る対策についての説明が一切無いままでは、納得も理解も難しいと思いますのでこのような形になりました。最後まで読んでいただきありがとうございます。

Copyright © IDC Frontier Inc.