新しい会話を開始

Solved!

ソリューションへ移動

5 Practitioner

 • 

886 メッセージ

281

2022年11月27日 17:00

VxRailのノード増設で使用できるリソースについて

いつもお世話になっております。
VxRail E660Fを3ノードで導入しようと考えております。


その後、3ノードから4ノードへ1ノード増設するとき、
増設する1ノードをまるまるHAの予備リソース用として扱うか、
(つまり推奨の4ノード構成にするかわりに、
普段使用できる実行容量やリソースは3ノードの時から増えない)
3ノード構成の時の延長でHA構成をとらずにまるまる増設1ノード分の
リソースも使用できるように構成するか、を選択できるような
イメージでよいでしょうか?


・推奨とされる4ノード構成(予備リソースとして1ノード分確保)に
ついてですが、何らかのHW障害が発生しないと確保している
リソースは使用されないのでしょうか?
例えば3ノード分のリソースでディスクやCPUやメモリといった
リソースの使用率が95%などで業務に影響がでているような状況でも、
HW的に特に障害が発生していなければ確保している
1ノード分のリソースは使えない(解放されない)のでしょうか?


以上、よろしくお願いいたします。

4 Operator

 • 

1.7K メッセージ

2022年11月27日 18:00

その後、3ノードから4ノードへ1ノード増設するとき、
増設する1ノードをまるまるHAの予備リソース用として扱うか、
(つまり推奨の4ノード構成にするかわりに、
普段使用できる実行容量やリソースは3ノードの時から増えない)
3ノード構成の時の延長でHA構成をとらずにまるまる増設1ノード分の
リソースも使用できるように構成するか、を選択できるような
イメージでよいでしょうか?



Compute Resource(CPU & Memory)と Storage Resource (vSAN)を分けて考える必要があります。

※以下の記載は基本概念に基づく概算であり、厳密ではない点にご留意ください

 

Compute Resource に関しては、VxRail / vSAN として1ノード分を予備とする、といった設定はなく、vSphere HA の Admission Control にて制御されるのが一般的と思います。Admission Control自体は現行の3ノード環境でも設定されている場合が多いと思います。また、サイジング時にAdmission Controlを想定したサイジングとするかどうかを選ぶこともできます。
既存でAdmission Controlを利用し、増設後もその設定を維持する場合は、1ノード増設後に利用可能なリソースは増えます
既存でAdmission Controlを利用しておらず、増設後もその設定を維持する場合でも、1ノード増設後に利用可能なリソースは増えます
既存でAdmission Controlを利用しておらず、増設後に1ノード障害分のAdmission Control設定を有効化する場合は、1ノード増設後に利用可能なリソースは増えません

 

Storage Resource に関しても、VxRailとしての設定ははなく、純粋に vSANの仕様と設定に依存します。
vSAN データストアは常にRaw 容量を表示しますので、見かけのサイズは確実に1ノード分増加します。
3ノード構成の場合はFTT1 Mirror しか選択できないため(FTT0やvSAN DPpは除外)、現行3ノード構成においては、1ノード障害時(計画的なメンテナンスモードを含む)にRebuild(Resync)が走らず、障害復旧(&Rebulid完了)するまで冗長性が低下したままとなります。

4ノード構成であれば、1ノード障害時(計画的なメンテナンスモードを含む)に、Rebuild(新規書き込みのキャプチャ含む)を実施することができますので、可用性をより高く保つことができます。
この場合、サイジング的には1ノード分の容量が予備となるため、3ノードのときと比較して実行容量は増加しません。

もちろんサイジング観点でRebuild分の余裕を考慮しないことも不可能ではないですが、vSANは組み込みのヘルスチェックにて、1ノード障害後(Rebuild後)の容量使用率が閾値を超える想定となる場合に警告やエラーとなる仕様となっていますので、データ可用性の観点でもvSAN仕様の観点でもお勧めはできません。

 

 

・推奨とされる4ノード構成(予備リソースとして1ノード分確保)に
ついてですが、何らかのHW障害が発生しないと確保している
リソースは使用されないのでしょうか?
例えば3ノード分のリソースでディスクやCPUやメモリといった
リソースの使用率が95%などで業務に影響がでているような状況でも、
HW的に特に障害が発生していなければ確保している
1ノード分のリソースは使えない(解放されない)のでしょうか?

 

こちらも設定に依存する部分はありますが、必ずしもそうではありません。

Compute Resource に関しては、Admission Control の Failover Host を利用している場合は障害発生まで余剰リソースは利用できませんが、Cluster Resource Percentage を使っている場合は、余剰リソースも利用可能という理解です。(閾値の設定によってはWarninが出る)
参考:
vSphere 6.5 what’s new - HA | Yellow Bricks (yellow-bricks.com)

 

Storage Resource (vSAN)に関しては既にご説明のとおり、警告やエラーは出ますが、余剰まで食い込んでリソースを利用することは可能です。(ただし完全に100%使い切る現実的には困難)
vSAN観点では、Admission Control の Failover Host と等価になるような設定はないですが、Rebuild 容量に食い込んだ場合に新規VM作成やPowerOnを抑止することは可能です。
参考:
調べたこと 試したこと: vSphere・vSAN 7.0 u1 機能強化・アップデート情報 (kwmtlog.blogspot.com)
About Reserved Capacity (vmware.com)

4 Operator

 • 

1.7K メッセージ

2022年11月27日 20:00

・記載いただいていることの確認になるかもしれませんが、
VxRail 4ノード構成でも、Rebuild分確保している容量分も
警告はでるにしろ使用することができる、という理解で
正しいでしょうか?
(私の勘違いかと思いますが、4ノード構成の時は
自動的に1ノード分の容量リソースが確保されて
通常時は使用できないと記憶していたため・・・)

はい。ご認識のとおりです。

4ノード構成の場合、だいたい65%くらいのRaw容量使用率になったくらいで警告が出ます。

一般的な外部ストレージアレイと異なり、スペア領域も含めたRaw容量として管理されるため、スペア領域を食いつぶしてしまって、4ノード以上なのにRebuildをするためのスペースがない、ということもあり得ます。

 

 

・上記に関連しまして、VxRail 4ノードで
「ホスト再構築の予約」を有効にしている場合は
Rebuild分確保している容量は使用できない、という
理解で正しかったでしょうか?
(逆にいうとRebuild用の空きも使用するにはホスト再構築の
予約設定をOFFにする必要があるということでしょうか)

参照元のドキュメントにも記載がありますが、完全に使用できないわけではなく新規のVM作成や起動が制限されます。稼働中のVMの追加の書き込みは可能です。

その制限を解除するためにはHost Rebuild Reserve を Off にする必要があります。

 

 

・もし4ノード構成で、1ノードがダウンした場合などで、
残り3ノードにRebuildの空きが無い場合は、
Rebuild自体が実行されない、という理解でよいでしょうか?
その場合、容量の空きを作ったうえで手動でリビルドの実行という
流れになりますでしょうか?

 

vSANのVersionにより挙動が異なります。初期のころのvSANであれば枯渇するまでRebuildをしてしまって、クラスタ全体のIOに影響が出るようなこともあったと思いますが、最近のvSANではそういったことはないため、容量枯渇とならないための調整はされていると思われます。

 

4 Operator

 • 

877 メッセージ

2022年11月27日 23:00

kaneda さんがほぼ回答されておりますので、VMware としての推奨の観点で記します。

まず CPU・Memory などのコンピューティングリソースについては、旧来の運用を踏襲している環境では VM と ESXi を固定で割り当て、HA 用にフェイルオーバーホストを指定することもありました。

kwmt_0-1669619698043.png

 

しかし、フェイルオーバーホストを指定した場合でも vSAN 環境ではデータは当然フェイルオーバーホスト上にも配置されますし、普段そのリソースが利用せずに浮いてしまうのは非常に無駄となるのでやはり DRS を活用し、クラスタ全体のリソースを満遍なく利用するというのが推奨です。

HA リソースの確保というてんでは kaneda さんが記載されたアドミッションコントロールと DRS を組み合わせる、これが鉄板構成です。
※ vSphere Standard のため DRS が利用できない場合も基本はフェイルオーバーホストを確保しておくより全体を均等に使っていただくことを推奨しています。

 

ストレージリソース側も現在は vSAN の自動リバランスで均等に分散配置され仕組みとなり、この辺りの容量の確保や障害発生時の挙動については以前の回答スレッドや VMTN での回答が幾つかあるので参考として以下に貼付します。

5 Practitioner

 • 

886 メッセージ

2022年11月27日 20:00

naoyuki_kanedaさん


詳しくご教示いただきまして大変ありがとうございます。
CPU、メモリ部分の考え方は理解できました。
Storage Resource 部分に関してすみませんが質問させてください。


・記載いただいていることの確認になるかもしれませんが、
VxRail 4ノード構成でも、Rebuild分確保している容量分も
警告はでるにしろ使用することができる、という理解で
正しいでしょうか?
(私の勘違いかと思いますが、4ノード構成の時は
自動的に1ノード分の容量リソースが確保されて
通常時は使用できないと記憶していたため・・・)


・上記に関連しまして、VxRail 4ノードで
「ホスト再構築の予約」を有効にしている場合は
Rebuild分確保している容量は使用できない、という
理解で正しかったでしょうか?
(逆にいうとRebuild用の空きも使用するにはホスト再構築の
予約設定をOFFにする必要があるということでしょうか)


・もし4ノード構成で、1ノードがダウンした場合などで、
残り3ノードにRebuildの空きが無い場合は、
Rebuild自体が実行されない、という理解でよいでしょうか?
その場合、容量の空きを作ったうえで手動でリビルドの実行という
流れになりますでしょうか?


以上、よろしくお願いいたします。

5 Practitioner

 • 

886 メッセージ

2022年11月28日 16:00

naoyuki_kanedaさん
kwmtさん


ご回答ありがとうございます。
Storage Resource 部分やアドミッションコントロール部分に
関しても考え方が理解できました。
詳細に記載いただきまして感謝いたします。

イベントは見つかりませんでした!

Top