Satellite ロケーションのサイズ設定
Satellite ロケーションは独自のデータ・センターおよびインフラストラクチャー・リソースを表しているため、ロケーションのサイズは必要に応じて柔軟に設定できます。 ロケーションに接続するホストの数に制限はありませんが、 Satellite 戦略を計画する際には、以下のサイズ設定に関する考慮事項に留意してください。
最小サイズ要件 : 開始するには、最小要件 を満たすホストを接続し、割り当てる必要があります PoC (概念検証) などのテストが目的であれば、コントロール・プレーンに割り当てるホストは最少 3 台でも可能ですが、実動用の場合は、最少 6 台のホストが必要です。 ロケーションを使用するにつれ、3 の倍数 (ホスト 6 台、9 台、12 台など) で、Satellite ロケーション・コントロール・プレーンのスケーリングが必要になる可能性があります。
- 高可用性
- Satellite ロケーション・コントロール・プレーンにホストを割り当てる場合は、ロケーションの作成時に選択した IBM Cloud マルチゾーン・メトロで 3 つの使用可能なゾーンのそれぞれにホストを均等に割り当てます。 コントロール・プレーンの可用性を高くするには、基礎となるホストが物理インフラストラクチャー環境内の別々のゾーンにあることを確認します。 例えば、クラウド・プロバイダー内の 3 つの別個の可用性ゾーンで実行されるか、または独自のデータ・センター内の 3 つの別個の物理システムで実行されるホストを 2 台ずつ割り当てることができます。 「ゾーン」の特定の要件を満たす必要はありませんが、別々のゾーンでシステム保守操作の可用性を提供する必要があります。 例えば、障害のために 1 つのゾーンが使用不可になったり、更新のために 1 台のホストが使用不可になったりした場合でも、残りの 2 つのゾーンはコントロール・プレーン操作の実行に使用できます。 同じハイパーバイザー上の仮想マシンである 2 台のホストのセットアップでは、可用性が低くなります。これは、マシンの更新などのために基礎となるハードウェアにサービスを提供すると、両方のホストが使用不可になるためです。 詳しくは、IBM Cloud Satellite の高可用性を参照してください。
- コンピュート容量
- Satellite は、ロケーションで使用可能な計算容量をモニターします。 ロケーションが 70% の容量に達すると、ロケーションにさらにホストを接続するように通知する警告状況が表示されます。 ロケーションが容量 80% に達すると、状況が**「重大」**に変わり、ロケーションに追加のホストを接続するように通知する警告が再度表示されます。
少なくとも 3 つの追加ホストが接続され、ロケーションに割り当てられていない状態を維持することを計画します。 追加ホストを用意しておけば、ロケーションが警告容量しきい値に達したり、異常なホストの置換が必要になったりしたときに、IBM がそれらのホストを Satellite ロケーション・コントロール・プレーンに自動的に割り当てることができます。
ロケーションサイジング
以下の表は、 Satellite ロケーション制御プレーンがマスターコンポーネントを実行するために必要とするホスト数のサイズ設定ガイダンスを示しており、さまざまなクラスターとワーカーノードの組み合わせに対応しています。 これらのサイジングは参照のみを目的としています。
| コントロール・プレーンのホストの数 | ロケーション内のクラスターの最大数 | ロケーション内のワーカー・ノードの最大数の例 | クラスターの最大サイズ |
|---|---|---|---|
| 6 台のホスト | 最大 3 クラスター | 3 つのクラスターにわたる 20 のワーカー、または 2 つのクラスターにわたる 80 のワーカー | 1 クラスターあたり 60 のワーカー |
| 9 台のホスト | 最大 5 つのクラスター | 5 つのクラスターにわたる 40 のワーカー、または 3 つのクラスターにわたる 140 のワーカー | 1 クラスターあたり 60 のワーカー |
| 12 台のホスト | 最大 8 つのクラスター | 8 つのクラスターにわたる 60 のワーカー、または 4 つのクラスターにわたる 200 のワーカー | 1 クラスターあたり 60 のワーカー |
| コントロール・プレーンのホストの数 | ロケーション内のクラスターの最大数 | ロケーション内のワーカー・ノードの最大数の例 | クラスターの最大サイズ |
|---|---|---|---|
| 6 台のホスト | 最大 9 クラスター | 9 つのクラスターにわたる 200 のワーカー、または 2 つのクラスターにわたる 550 のワーカー | 1 クラスターあたり 300 のワーカー |
| 9 台のホスト | 最大 16 個のクラスター | 16のクラスターにまたがる400人の労働者、あるいは3つのクラスターにまたがる850人の労働者 | 1 クラスターあたり 300 のワーカー |
| 12 台のホスト | 最大 22 個のクラスター | 22のクラスターにまたがる520人の労働者、あるいは4つのクラスターにまたがる1150人の労働者 | 1 クラスターあたり 300 のワーカー |
テスト用のロケーション・サイズ
以下の表は、 Satellite ロケーション・コントロール・プレーンが Satellite ロケーション・デモンストレーションを実行するために必要とするホスト数のサイジング・ガイダンスを示しています。 この構成は、実動で使用するためのものではありません。
| コントロール・プレーンのホストの数 | ロケーション内のクラスターの最大数 | クラスターの最大サイズ |
|---|---|---|
| 3 ホスト 8x32 | 1 クラスター | 1 クラスターあたり 20 |
ロケーションのサイジングに関する FAQ
ロケーションのサイジングについて詳しくは、以下のよくある質問を参照してください。
クラスターに接続するホストのサイズと数を確認するにはどうすればよいですか?
クラスターに接続するホストのサイズと数を決定するには、そのロケーションで実行するワークロードを考慮します。 以下の考慮事項については、 Red Hat OpenShift on IBM Cloud の資料 を参照してください。
- アプリにはリソースがいくつ必要ですか?
- アプリ以外に、クラスター内のリソースを使用するものは何ですか?
- どのようなタイプの可用性がワークロードに必要ですか?
- ワークロードを処理するには、いくつのワーカー・ノード (ホスト) が必要ですか?
- クラスターのリソース使用量と容量をモニターするにはどうしたらよいですか?
Satellite ロケーション・コントロール・プレーンに容量を接続するタイミングがわかる方法はありますか?
ibmcloud sat location ls コマンドや Satellite コンソールなどでロケーションをリストアップすると、そのロケーションは「 Action required 」というヘルス状態になります。 次の例のような警告メッセージが表示されます。
Hosts in the location control plane are running out of disk space.
Hosts in the location control plane have critical CPU or memory usage issues.
The location control plane is running at max capacity and cannot support any more workloads.
ロケーションのサイズを決定した後、 ロケーション・コントロール・プレーンにホストを追加します。
Satellite ロケーション・コントロール・プレーンを高可用性にスケール・アップするにはどうすればよいですか?
コントロール・プレーン・ワーカーの高可用性セットアップを参照してください。 各ゾーンのコントロール・プレーン・ロケーションに、3 の倍数の数のホストを接続してください。 例えば、IBM Cloud の wdc リージョンから管理されるコントロール・プレーン・ロケーションに 6 台のホストを割り当て、2
台のホストが各ゾーン (us-east-1、us-east-2、us-east-3) をホストするようにします。
コントロール・プレーンをスケールアップする場合は、Satellite ロケーション・コントロール・プレーンのセットアップと同じ手順に従います。
ロケーション・コントロール・プレーンへの容量の接続が必要になる前に、Red Hat OpenShift on IBM Cloud クラスターをいくつ実行できますか?
クラスターの数は、クラスターのサイズと、Satellite ロケーション・コントロール・プレーンに使用するホストのサイズによって決まります。 コントロール・プレーンのホストは、6、9、12 など、3 の倍数でスケール・アップする必要があります。
以下の表は、情報提供のみを目的として、クラスターとワーカー・ノードのさまざまな組み合わせのマスターを実行するためにコントロール・プレーンが必要とするホストの数の例を示しています。
- コントロール・プレーンを実行するホストのサイズ (4 つの vCPU および 16GB の RAM または 16 の vCPU および 64GB の RAM) は、ロケーションで可能なクラスターおよびワーカー・ノードの数に影響します。 実際のパフォーマンス要件は、ロケーションで実行されるアプリケーションによる基礎となる CPU パフォーマンスやコントロール・プレーンの使用量など、多くの要因によって決まることに注意してください。
- 3 つのグループでホストをコントロール・プレーンに割り当てることができます。 この表は、ご使用のホストおよびアプリケーション環境のコントロール・プレーンのサイズを決定する方法を示すために、一般的な構成として最大 12 台のホストの例を示しています。 3 つのグループで 12 台を超えるホストをコントロール・プレーンに追加できることに注意してください。 例えば、18 または 27 台のホストを持つコントロール・プレーンを作成できます。
ロケーションのサイジング要件を増やすことができる変更のタイプは何ですか?
サイズ設定の要件は、クラスター内で実行されているワークロードの量に応じて増加する可能性があります。 以下の例では、ロケーションのサイジング要件が増加する可能性があります。
- すべてのポッド、サービス、またはアプリのメタデータを保持するために必要なストレージの増加など、大量の動的ポッド・ワークロード。
- ConfigMaps や Secrets などの大量の構成情報。これにより、その情報を保持または処理しているコントロール・プレーンのメモリーまたは CPU が増加する可能性があります。
- 集約された
kube-apiserver要求ワークロードと、収集されたデータの応答サイズ。 例えば、クラスターに多数の ConfigMaps が含まれており、アプリケーションがそのデータの完全なリストを照会した場合、その要求により、コントロール・プレーンがより多くのリソースを必要とする可能性があります。