このドキュメントでは、VMware に Google Distributed Cloud(ソフトウェアのみ)をインストールするための CPU、RAM、ストレージの要件について説明します。 このページは、会社の戦略に従って IT ソリューションとシステム アーキテクチャを定義する管理者とアーキテクトを対象としています。 Google Cloud のコンテンツで使用されている一般的なロールとタスクの例の詳細については、一般的な GKE Enterprise ユーザーロールとタスクをご覧ください。
このドキュメントでは、ユーザー クラスタで Controlplane V2 が有効になっているインストールの要件について説明します。
ここに示されている要件は本番環境に適しています。概念実証のデモに必要な CPU、RAM、ストレージの最小要件については、最小限のインフラストラクチャを設定するをご覧ください。
管理ワークステーションの CPU、RAM、ストレージの要件
管理ワークステーションを作成する前に、管理ワークステーションの構成ファイルを設定します。構成ファイルで、vSphere クラスタ、vSphere リソースプール、vSphere データストアを指定します。
vSphere クラスタは ESXi を実行する一連の物理ホストであり、リソースプールには、それらの ESXi ホストで使用可能なリソースの一部に対する予約があります。
リソースプールには、管理ワークステーションとプールに属するその他の VM の要件をサポートするのに十分な CPU と RAM が必要です。同様に、データストアには、管理ワークステーションやデータストアを使用するその他の VM の要件をサポートするのに十分なストレージが必要です。
管理ワークステーションの要件は次のとおりです。
- 4 個の vCPU(仮想 CPU)
- 8 GiB の RAM
- 100 GiB
Google Distributed Cloud は、CPU マイクロアーキテクチャ レベル v3(x86-64-v3)以降で x86-64 vCPU のみをサポートします。
管理クラスタの CPU、RAM、ストレージの要件
管理クラスタを作成する前に、管理クラスタの構成ファイルに入力します。構成ファイルで、vSphere クラスタ、vSphere リソースプール、vSphere データストアを指定します。
vSphere クラスタは ESXi を実行する一連の物理ホストであり、リソースプールには、それらの ESXi ホストで使用可能なリソースの一部に対する予約があります。
リソースプールには、管理クラスタと、プールに属するその他の VM の要件をサポートするのに十分な CPU と RAM が必要です。同様に、データストアには、管理クラスタとデータストアを使用するその他の VM の要件をサポートするのに十分なストレージが必要です。
管理クラスタには 1 つまたは 3 つのノードがあります。これらは、管理クラスタ用のコントロール プレーンノード(高可用性(HA)管理クラスタの場合は 3 つ、非 HA 管理クラスタの場合は 1 つ)です。
管理クラスタのストレージ要件は次のとおりです。
高度なクラスタが有効になっていない場合:
VM テンプレート用にノードごとに 40 GiB
etcd オブジェクト データの保存用にノードごとに 25 GiB
ネットワーク停止中にログと指標をバッファに保存する Google Cloud Observability 用にノードごとに 240 GiB
高度なクラスタが有効になっている場合:
VM テンプレート用にノードごとに 50 GiB
etcd オブジェクト データの保存用にノードごとに 25 GiB
ネットワーク停止中にログと指標をバッファに保存する Google Cloud Observability 用にノードごとに 20 GiB
次の表に、管理クラスタ内のノードの CPU、RAM、ストレージの要件を示します。要件は、管理クラスタの作成時に高度なクラスタを有効にするかどうかによって異なります。
ノード | 要件 | 目的 |
---|---|---|
管理クラスタのコントロール プレーン |
|
管理クラスタのコントロール プレーンを実行します。 |
高度な管理クラスタのコントロール プレーン |
|
管理クラスタのコントロール プレーンを実行します。 |
* Google Distributed Cloud は、CPU マイクロアーキテクチャ レベル v3(x86-64-v3)以降で x86-64 vCPU のみをサポートします。
ユーザー クラスタの CPU、RAM、ストレージの要件
ユーザー クラスタを作成する前に、ユーザー クラスタ構成ファイルに入力します。構成ファイルで、vSphere クラスタ、vSphere リソースプール、vSphere データストアを指定します。
vSphere クラスタは ESXi を実行する一連の物理ホストであり、リソースプールには、それらの ESXi ホストで使用可能なリソースの一部に対する予約があります。
リソースプールには、ユーザー クラスタと、プールに属するその他の VM の要件をサポートするのに十分な CPU と RAM が必要です。同様に、データストアには、ユーザー クラスタとデータストアを使用するその他の VM の要件をサポートするのに十分なストレージが必要です。
ユーザー クラスタのストレージ要件は次のとおりです。
高度なクラスタが有効になっていない場合:
コントロール プレーン ノードごとに 60 GiB
ワーカーノードごとに 40 GiB
ネットワーク停止中にログと指標をバッファに保存する Google Cloud Observability 用にノードごとに 120 GiB
高度なクラスタが有効になっている場合:
コントロール プレーン ノードごとに 50 GiB
ワーカーノードごとに 40 GiB
ネットワーク停止中にログと指標をバッファに保存する Google Cloud Observability 用にノードごとに 20 GiB
次の表に、ユーザー クラスタの各コントロール プレーン ノードに必要な CPU、RAM、ストレージを示します。要件は、管理クラスタの作成時に高度なクラスタを有効にするかどうかによって異なります。また、ユーザー クラスタ内の各ワーカーノードのデフォルトの CPU、RAM、ストレージ値も示されています。ワークロードのニーズに応じて、ワーカーノードの値を調整することをおすすめします。ワークロードのノードで使用できる CPU と RAM の量を確認するには、ワークロードで使用できるリソースをご覧ください。CPU と RAM の値は、ユーザー クラスタ構成ファイルの nodePools
セクションで指定できます。
ノード | 要件 | 目的 |
---|---|---|
コントロール プレーン ノード |
1 つまたは 3 つの VM。各 VM には次の要件があります。
|
ユーザー クラスタのコントロール プレーンを実行します。 |
高度なコントロール プレーン ノード |
3 つの VM。各 VM には次の要件があります。
|
ユーザー クラスタのコントロール プレーンを実行し、高度なクラスタを有効にします。 |
ワーカーノード | 個々のワーカーノードのデフォルト値は次のとおりです。
|
ユーザー クラスタのワーカーノードは、ワークロードが実行される仮想マシンです。ユーザー クラスタのノードに必要なリソースは、実行するワークロードによって異なります。 |
* Google Distributed Cloud は、CPU マイクロアーキテクチャ レベル v3(x86-64-v3)以降で x86-64 vCPU のみをサポートします。
高度なクラスタが有効になっていない場合の CPU、RAM、ストレージの要件の例
次のような、2 つの vSphere データセンターがあるとします。
データセンター 1 にはクラスタ 1 という名前の vSphere クラスタがあり、クラスタ 1 にはリソースプール 1 という名前のリソースプールがあります。クラスタ 1 には、ESXi を実行する 4 つの物理ホストがあります。
データセンター 2 にはクラスタ 2 という名前の vSphere クラスタがあり、クラスタ 2 にはリソースプール 2 という名前のリソースプールがあります。クラスタ 2 には、ESXi を実行する 8 つの物理ホストがあります。
管理ワークステーションと管理クラスタをリソースプール 1 に配置し、データストア 1 を使用することにしました。
ユーザー クラスタはリソースプール 2 に配置し、データストア 2 を使用することにします。ユーザー クラスタで Prometheus を有効にする予定はありません。
次の 2 つのユーザー クラスタを作成することにします。
各ワーカーノードに 6 個の vCPU、16 GiB の RAM、40 GiB のストレージが必要なユーザー クラスタ。このユーザー クラスタには 20 個のワーカーノードがあります。このユーザー クラスタには HA コントロール プレーンが必要であるため、ユーザー クラスタには 3 つのコントロール プレーン ノードが存在します。
2 番目のユーザー クラスタには、各ワーカーノードに 4 つの vCPU、8 GiB の RAM、40 GiB のストレージが必要です。このユーザー クラスタには 8 つのノードがあります。このユーザー クラスタでは HA コントロール プレーンを必要としないため、ユーザー クラスタ内のコントロール プレーン ノードは 1 つだけです。
リソースプール 1 とデータストア 1 の要件
リソースプール 1 には、クラスタ 1 の 4 つの ESXi ホストにより提供される CPU と RAM の一部が予約されています。リソースプール 1 には、また、管理ワークステーションと管理クラスタの要件を満たす十分な CPU と RAM が必要です。さらに、データストア 1 には、管理ワークステーションと管理クラスタの要件を満たす十分なストレージが必要です。
管理クラスタには 3 つのノードがあり、それぞれがコントロール プレーン ノードです。
前述のように、管理ワークステーションには次のリソース要件があります。
例: 管理ワークステーションの要件 | ||
---|---|---|
vCPU | 4 vCPU | |
RAM | 8 GiB | |
ストレージ | 50 GiB |
管理クラスタのリソース要件は、次のとおりです。
例: 管理クラスタの要件 | ||
---|---|---|
vCPU | 3 つの管理クラスタ コントロール プレーン ノード × 2 つの vCPU/ノード | 6 vCPU |
RAM | 3 つの管理クラスタ コントロール プレーン ノード × 4 GiB/ノード | 12 GiB |
ストレージ |
VM テンプレート用に 40 GiB + etcd オブジェクト データ用に 100 GiB + Google Cloud Observability 用に 240 GiB + 3 つの管理クラスタ コントロール プレーン ノード x 40 GiB/ノード |
500 GiB |
次の表は、管理ワークステーションと管理クラスタの合計の CPU、RAM、ストレージの要件を示したものです。リソースプール 1 とデータストア 1 で、次のリソースを提供できる必要があります。
例: リソースプール 1 とデータストア 1 の合計要件 | ||
---|---|---|
vCPU | 29 vCPU | |
RAM | 73 GiB | |
ストレージ | 790 GiB |
リソースプール 2 とデータストア 2 の要件
リソースプール 2 には、クラスタ 2 の 8 つの ESXi ホストにより提供される CPU と RAM の一部が予約されています。リソースプール 2 には、両方のユーザー クラスタの要件を満たす十分な CPU と RAM が必要です。さらに、データストア 2 には、両方のユーザー クラスタの要件を満たす十分なストレージが必要です。
1 つ目のユーザー クラスタのリソース要件は、次のとおりです。
例: 最初のユーザー クラスタの要件 | ||
---|---|---|
CPU | 3 つのコントロール プレーン ノード x 3 つの vCPU / ノード + 20 個のワーカーノード x 6 つの vCPU / ノード |
129 vCPU |
RAM | 3 つのコントロール プレーン ノード x 5 GiB / ノード + 20 個のワーカーノード x 16 GiB / ノード |
335 GiB |
ストレージ |
Google Cloud Observability 用に 240 GiB + 3 つのコントロール プレーン ノード x 60 GiB / ノード + 20 個のワーカーノード x 40 GiB / ノード |
1,220 GiB |
2 つ目のユーザー クラスタのリソース要件は、次のとおりです。
例: 2 番目のユーザー クラスタの要件 | ||
---|---|---|
CPU | 1 つのコントロール プレーン ノード x 3 つの vCPU / ノード + 8 つのワーカーノード x 4 つの vCPU / ノード |
35 vCPU |
RAM | 1 つのコントロール プレーン ノード x 5 GiB / ノード + 8 つのワーカーノード x 8 GiB / ノード |
69 GiB |
ストレージ |
Google Cloud Observability 用に 240 GiB + 1 つのコントロール プレーン ノード x 60 GiB / ノード + 8 つのワーカーノード x 40 GiB / ノード |
620 GiB |
次の表は、2 つのユーザー クラスタの合計の CPU、RAM、ストレージの要件を示しています。リソースプール 2 とデータストア 2 は、次のリソースを提供できる必要があります。
例: リソースプール 2 とデータストア 2 の合計要件 | |
---|---|
CPU | 164 vCPU |
RAM | 404 GiB |
ストレージ | 1,840 GiB |
リソースのオーバーコミット
vSphere は、メモリのオーバーコミットや CPU のオーバーコミットなどのリソースのオーバーコミットをサポートしています。したがって、クラスタ内のリソースプールによって予約されるリソースの合計量は、クラスタ内の ESXi ホストが提供する物理リソース量を上回る可能性があります。
このドキュメントに示した要件は、予約済みの仮想リソースに関するものです。概念実証のデモに必要とされる物理的なリソースの詳細については、最小限のインフラストラクチャを設定するをご覧ください。
リソース競合をモニタリングする
リソース競合のシグナルをモニタリングして、リソースプールとデータストアが、構成済みの仮想リソースをサポートできることを確認してください。詳細については、VM のヘルス ステータス ダッシュボードを作成するをご覧ください。
ディスクのプロビジョニング
次の表に、さまざまなストレージ ディスクに対する VMware のシンディスクとシックディスクのプロビジョニング ポリシーを示します。
ストレージ ディスク | サイズ | ディスク プロビジョニング ポリシー | |
---|---|---|---|
デフォルト | ユーザー選択 | ||
管理 etcd | 100 GB | シン | × |
ユーザー etcd | 40 GB | シン | × |
ノード OS / ブートディスク | 40 GB - デフォルトと最小 (ユーザーが構成可能) |
シック (遅延ゼロ) |
× |
その他(ログなど) | 240 GB | シン | × |
ユーザー ワークロード | — | シン | ○ |