IBM Cloud のロケーションとリージョンの理解
IBM Cloud のロケーションとリージョンが、クラスター展開においてどのように構成されているかについて、マルチゾーンリージョンやシングルキャンパス・マルチゾーンリージョンを含めて解説します。
VPC 用のマルチゾーン・リージョン
VPCリソースはリージョン内にプロビジョニングされます。リージョンとは、メトロエリア内のゾーンをまとめた独立したグループのことです。 それらのゾーンは、マルチゾーン・アーキテクチャーで複数のゾーン間にリソースを均等に分散させるために、別々のデータ・センターにマップされます。 API および CLI では、ゾーンはリージョンのゾーン名（us-south-1 ）で指定されますが、コンソールではデータセンターのロケーション（Dallas 1 ）で指定されます。VPC ゾーンおよびロケーションに対応するデータセンターコード（ us-south-1 や DAL10 など）については、 「マルチゾーンリージョン」を 参照してください。
- ムンバイ (
in-mum) VPC MZR制限 - オペレーティングシステム ：ムンバイのバージョン 4.16 以降のクラスタしか作成できず、RHEL 9 または RHCOS ワーカーノードしか使用できません。
- ベアメタルワーカー ムンバイでは Baremetal VPC ワーカーノードは利用できません。
- チェンナイ (
in-che) VPC MZR制限 - オペレーティングシステム: チェンナイではバージョン 4.16 以降でのみクラスターを作成でき、ワーカーノードにはRHEL 9またはRHCOSのみを使用できます。
- ベアメタルワーカー: ベアメタルVPCワーカーノードはチェンナイでは利用できません。
- モントリオール (
ca-mon) VPC MZR 制限事項 - ウェブフック ：クラスタ内サービスにアクセスするウェブフックのみが機能します。 外部の、クラスタ外の、 URL に直接アクセスする Webhook はブロックされます。
- オペレーティングシステム ：モントリオールで作成できるクラスタのバージョンは 4.16 以降で、使用できるワーカーノードは RHEL 9 または RHCOS のみです。
- Portworx Enterprise および Portworx Backupのデフォルトのインストール方法です： Portworx Enterprise および Portworx Backup のデフォルトのインストール方法は、モントリオール地域のプライベート専用クラスタではまだサポートされていません。 モントリオールのプライベート専用クラスタに Portworx Enterprise または Portworx Backup をインストールする必要がある場合は、 Portworx サポートにお問い合わせください。 詳しくは、 Portworx サポートを ご覧ください。
このイメージは芸術的な表現であり、実際の政治的境界や地理的境界を反映していません。
| 地域 | 国 | 大都市圏 | リージョン | ゾーン |
|---|---|---|---|---|
| アジア太平洋 | オーストラリア | シドニー | au-syd | au-syd-1, au-syd-2, au-syd-3 |
| アジア太平洋 | インド | チェンナイ | in-che | in-che-1, in-che-2, in-che-3 |
| アジア太平洋 | インド | ムンバイ | インマム | in-mum-1, in-mum-2, in-mum-3 |
| アジア太平洋 | 日本 | 大阪 | jp-osa | jp-osa-1, jp-osa-2, jp-osa-3 |
| アジア太平洋 | 日本 | 東京 | jp-tok | jp-tok-1, jp-tok-2, jp-tok-3 |
| ヨーロッパ | ドイツ | フランクフルト | eu-de | eu-de-1, eu-de-2, eu-de-3 |
| ヨーロッパ | スペイン | マドリッド | eu-es | eu-es-1, eu-es-2, eu-es-3 |
| ヨーロッパ | 英国 | ロンドン | eu-gb | eu-gb-1, eu-gb-2, eu-gb-3 |
| 北米 | カナダ | モントリオール | ca-mon | ca-mon-1, ca-mon-2, ca-mon-3 |
| 北米 | カナダ | トロント | ca-tor | ca-tor-1, ca-tor-2, ca-tor-3 |
| 北米 | アメリカ合衆国 | ダラス | us-south | us-south-1, us-south-2, us-south-3 |
| 北米 | アメリカ合衆国 | ワシントン DC | us-east | us-east-1, us-east-2, us-east-3 |
| 南米 | ブラジル | サンパウロ | br-sao | br-sao-1, br-sao-2, br-sao-3 |
クラシック地域
この文書で zone という用語は、使用されているインフラの種類によって異なるものを指す。 VPCの場合、zone という用語は、us-south-1 のような MZR内のゾーン名を指す。 クラシック・インフラストラクチャの場合、zone という用語は、dal10 のようなクラシック・データセンターを指す。
複数のデータセンターを持つ古典的なリージョン
複数のデータセンターで構成されるクラシッククラスタを作成すると、高可用性 Kubernetes マスターのレプリカは自動的に各データセンターに分散されます。 ゾーン（データセンター）の障害からアプリケーションを保護するために、ワーカーノードを複数のクラシックゾーンに分散させることも可能です。 CLIからクラシックリージョンに複数のデータセンターがあるかどうかを判断するには、ibmcloud oc locations を実行し、Multizone Metro 列の値を探します。
このイメージは芸術的な表現であり、実際の政治的境界や地理的境界を反映していません。
| 地域 | 国 | 大都市圏 | リージョン | ゾーン |
|---|---|---|---|---|
| アジア太平洋 | オーストラリア | シドニー | au-syd | syd01, syd04, syd05 |
| アジア太平洋 | 日本 | 大阪 | jp-osa | osa21, osa22, osa23 |
| アジア太平洋 | 日本 | 東京 | jp-tok | tok02, tok04, tok05 |
| ヨーロッパ | ドイツ | フランクフルト | デフラ | fra02, fra04, fra05 |
| ヨーロッパ | 英国 | ロンドン | ウコン | lon02, lon04, lon05, lon06 |
| 北米 | アメリカ合衆国 | ダラス | Us-DAL | dal10, dal12, dal13 |
| 北米 | アメリカ合衆国 | ワシントン DC | ダブリューダブリューダブリューシー | wdc04, wdc06, wdc07 |
データセンターが1つのクラシックリージョン
データセンターが1つしかないリージョンにクラシック・クラスタを作成した場合、高可用性マスターには別々のホスト上の3つのレプリカが含まれますが、クラシック・ゾーンにまたがることはありません。
1つのデータセンターを持つクラシックリージョンは、mon01 から us-east、または sao01 から us-south のように、クラシックデータセンターをサポートする最も近いリージョンにあるリージョナルエンドポイントから管理される。
このイメージは芸術的な表現であり、実際の政治的境界や地理的境界を反映していません。
| 地域 | 国 | 大都市圏 | リージョン | ゾーン | 領域から管理 |
|---|---|---|---|---|---|
| アジア太平洋 | インド | チェンナイ | in-che | che01 | 北アジア太平洋地域 (ap-north、jp-tok) |
| アジア太平洋 | シンガポール | シンガポール | スグ・ムトル | sng01 | 北アジア太平洋地域 (ap-north、jp-tok) |
| ヨーロッパ | フランス | パリ | FR-パー | par01 | 中欧 (eu-central、eu-de) |
| ヨーロッパ | オランダ | アムステルダム | NL-AMS | ams03 | 中欧 (eu-central、eu-de) |
| 北米 | カナダ | モントリオール | ca-mon | mon01 | 米国東部 (us-east) |
| 北米 | カナダ | トロント | ca-tor | tor01 | 米国東部 (us-east) |
| 北米 | アメリカ合衆国 | サンノゼ | jp-sjc | sjc03, sjc04 | 米国南部 (us-south) |
| 南米 | ブラジル | サンパウロ | br-sao | sao01 | 米国南部 (us-south) |
Satellite 地域
Satellite クラスターのサポートされる Managed from 地域のリストを表示するには、 サポートされる Satellite の場所 を参照してください。
資源はどこにあるのか？
クラスタのどこにリソースが格納されるかは、クラスタの可用性に依存します。クラスタは単一のゾーンで利用できる場合もあれば、複数のゾーン（マルチゾーン）で利用できる場合もあります。
単一ゾーン・クラスターのリソース
クラスターのリソースは、そのクラスターが展開されているデータセンター内に残りますが、管理操作はリージョンのエンドポイントを経由して行われる場合があります。
クラスターのリソース (マスター・ノードやワーカー・ノードなど) は、クラスターをデプロイした同じゾーンにあります。 ローカル・コンテナーのオーケストレーション・アクション (oc コマンドなど) を実行すると、同じゾーン内のマスター・ノードとワーカー・ノードの間で情報が交換されます。
ストレージ、ネットワーク、コンピューティング、またはポッド内で実行されているアプリケーションなど、その他のクラスタリソースを設定した場合、それらのリソースとそのデータは、クラスタを展開したデータセンター内に残ります。
ibmcloud oc コマンドの実行などといったクラスター管理操作を開始すると、クラスター名、ID、ユーザーなどの基本情報とともに、そのコマンドはリージョナルエンドポイントおよびグローバルエンドポイントを経由して転送されます。
マルチゾーン・クラスタのリソース
マルチゾーン・クラスタでは、クラスタのリソースが複数の場所（VPCの場合はゾーン、Classicの場合はデータセンター）に分散され、より高い可用性を実現します。
ワーカーノードは、複数のVPCゾーンまたは地域のクラシックデータセンターに分散され、クラスタの可用性を高めます。 Kubernetes マスターレプリカは、ゾーンまたは古典的なデータセンターにもまたがっています。 次のようなローカルなコンテナオーケストレーション操作を実行する場合、 oc コマンドなど）を実行すると、その情報はグローバルエンドポイントを介してマスターノードとワーカーノードの間でやり取りされます。
ストレージ、ネットワーク、コンピューティング、またはポッド内で実行されているアプリケーションなど、その他のクラスターリソースは、クラスター内の各ゾーンへのデプロイ方法が異なります。 詳しくは、以下のトピックを参照してください。
- クラスタ内で ファイル ストレージ と ブロック ストレージ をセットアップする、または マルチゾーン永続ストレージ ソリューションを選択する。
- クラスタ内のネットワーク負荷分散（NLB）サービスを使用して、アプリへのパブリックまたはプライベートアクセスを有効にする。
- Ingress を使用したネットワーク・トラフィックの管理
- アプリの可用性の向上
ibmcloud oc コマンドの実行 など、クラスタ管理操作を開始すると、クラスタ名、ID、ユーザーといったクラスタの基本情報は、グローバルエンドポイントを経由して送信されます。