リージョンおよび可用性ドメイン
このトピックでは、Oracle Cloud Infrastructureリソースの物理的および論理的な編成について説明します。
リージョンおよび可用性ドメインについて
同じリージョン内の可用性ドメインは、低レイテンシの高帯域幅ネットワークによって相互接続されます。これにより、インターネットおよびオンプレミスへの高可用性接続を提供したり、高可用性とディザスタ・リカバリの両方のためにレプリケートされたシステムを複数の可用性ドメインに構築できるようになります。
オラクルでは、世界中に複数のクラウド・リージョンを追加して、お客様のクラウド・リソースにローカル・アクセスを提供しています。これを迅速に実現するために、新しい地域には1つの可用性ドメインを持つリージョンを立ち上げることを選択しました。
リージョンの拡張が必要になった場合、既存の可用性ドメインへの容量の追加、既存のリージョンへの可用性ドメインの追加、または新しいリージョンの構築という選択肢があります。特定のシナリオでの拡張アプローチは、顧客要件に加え、リージョンの需要パターンとリソースの可用性に関する考慮事項に基づきます。
リージョンは他のリージョンから独立しており、複数の国または大陸をもまたがる広大な空間で分離できます。一般に、近くにあるリソースの使用は遠くにあるリソースの使用よりも高速であるため、アプリケーションは、それが最も頻繁に使用されるリージョンにデプロイします。ただし、次の理由から、様々なリージョンにアプリケーションをデプロイすることもできます:
- 大規模な気象系や地震など、リージョン全体の事象のリスクを軽減するため。
- 法的管轄区域、税領域、その他のビジネス基準または社会基準の様々な要件を満たすため。
リージョンはレルムにグループ化されます。テナンシは、単一のレルムに存在し、そのレルムに属するすべてのリージョンにアクセスできます。自分のレルム内にないリージョンにはアクセスできません。現在、Oracle Cloud Infrastructureには、商用、政府および専用レルムを含む複数のレルムがあります。
次の表に、Oracle Cloud Infrastructureの商用レルムのリージョンを示します:
リージョン名 | リージョン識別子 | リージョンの場所 | リージョン・キー | レルム・キー | 可用性ドメイン |
---|---|---|---|---|---|
オーストラリア東部(シドニー) | ap-sydney-1 | シドニー(オーストラリア) | SYD | OC1 | 1 |
オーストラリア南東部(メルボルン) | ap-melbourne-1 | メルボルン、オーストラリア | MEL | OC1 | 1 |
ブラジル東部(サンパウロ) | sa-saopaulo-1 | サンパウロ(ブラジル) | GRU | OC1 | 1 |
ブラジル南東部(ヴィニェード) | sa-vinhedo-1 | ヴィニェード(ブラジル) | VCP | OC1 | 1 |
カナダ南東部(モントリオール) | ca-montreal-1 | モントリオール、カナダ | YUL | OC1 | 1 |
カナダ南東部(トロント) | ca-toronto-1 | トロント(カナダ) | YYZ | OC1 | 1 |
チリ中央部(サンチアゴ) | sa-santiago-1 | サンチアゴ(チリ) | SCL | OC1 | 1 |
チリ西部(バルパライソ) | sa-valparaiso-1 | バルパライソ、チリ | VAP | OC1 | 1 |
コロンビア中央部(ボゴタ) | サボゴタ-1 | ボゴタ、コロンビア | BOG | OC1 | 1 |
フランス中央部(パリ) | eu-paris-1 | パリ、フランス | CDG | OC1 | 1 |
フランス南部(マルセイユ) | eu-marseille-1 | マルセイユ(フランス) | MRS | OC1 | 1 |
ドイツ中央部(フランクフルト) | eu-frankfurt-1 | フランクフルト(ドイツ) | FRA | OC1 | 3 |
インド南部(ハイデラバード) | ap-hyderabad-1 | ハイデラバード、インド | HYD | OC1 | 1 |
インド西部(ムンバイ) | ap-mumbai-1 | ムンバイ(インド) | BOM | OC1 | 1 |
イスラエル中央部(エルサレム) | il-jerusalem-1 | エルサレム(イスラエル) | MTZ | OC1 | 1 |
イタリア北西部(ミラノ) | eu-milan-1 | ミラノ(イタリア) | LIN | OC1 | 1 |
日本中央部(大阪) | ap-osaka-1 | 大阪、日本 | KIX | OC1 | 1 |
日本東部(東京) | ap-tokyo-1 | 東京(日本) | NRT | OC1 | 1 |
メキシコ中央部(ケレタロ) | mx-queretaro-1 | ケレタロ(メキシコ) | QRO | OC1 | 1 |
メキシコ北東部(モンテレー) | mxモンテレイ-1 | モンテレー、メキシコ | MTY | OC1 | 1 |
オランダ北西部(アムステルダム) | eu-amsterdam-1 | アムステルダム、オランダ | AMS | OC1 | 1 |
サウジアラビア中央部(リヤド) | メリヤド-1 | リヤード、サウジアラビア | RUH | OC1 | 1 |
サウジアラビア西部(ジッダ) | me-jeddah-1 | ジッダ、サウジアラビア | JED | OC1 | 1 |
セルビア中部(ジョバノヴァック) | eu-jovanovac-1 | ジョバノヴァック、セルビア | BEG | OC20 | 1 |
シンガポール(シンガポール) | ap-singapore-1 | シンガポール(シンガポール) | SIN | OC1 | 1 |
シンガポール西部(シンガポール) | ap-singapore-2 | シンガポール(シンガポール) | XSP | OC1 | 1 |
南アフリカ中央部(ヨハネスブルク) | af-johannesburg-1 | ヨハネスバーグ(南アフリカ) | JNB | OC1 | 1 |
大韓民国中部(ソウル) | ap-seoul-1 | ソウル(韓国) | ICN | OC1 | 1 |
韓国北部(春川) | ap-chuncheon-1 | 春川、韓国 | YNY | OC1 | 1 |
スペイン中央部(マドリード) | eu-madrid-1 | マドリード、スペイン | MAD | OC1 | 1 |
スウェーデン中央部(ストックホルム) | eu-stockholm-1 | ストックホルム(スウェーデン) | ARN | OC1 | 1 |
スイス北部(チューリッヒ) | eu-zurich-1 | チューリッヒ(スイス) | ZRH | OC1 | 1 |
アラブ首長国連邦中央部(アブダビ) | me-abudhabi-1 | アブダビ(アラブ首長国連邦) | AUH | OC1 | 1 |
アラブ首長国連邦東部(ドバイ) | me-dubai-1 | ドバイ(アラブ首長国連邦) | DXB | OC1 | 1 |
英国南部(ロンドン) | uk-london-1 | ロンドン、英国 | LHR | OC1 | 3 |
英国西部(ニューポート) | uk-cardiff-1 | ニューポート、英国 | CWL | OC1 | 1 |
米国東部(アッシュバーン) | us-ashburn-1 | アッシュバーン、VA | IAD | OC1 | 3 |
米国中西部(シカゴ) | us-chicago-1 | シカゴ、IL | ORD | OC1 | 3 |
米国西部(フェニックス) | us-phoenix-1 | フェニックス、AZ | PHX | OC1 | 3 |
米国西部(サンノゼ) | us-sanjose-1 | サンノゼ、CA | SJC | OC1 | 1 |
リージョンをサブスクライブするには、リージョンの管理を参照してください。
Oracle Government Cloudレルムのリージョンのリストは、次のトピックを参照してください:
テナンシの可用性ドメイン名
データ・センターの容量のバランスを取るために、Oracle Cloud Infrastructureではテナンシによって可用性ドメインがランダム化されます。たとえば、tenancyAのPHX-AD-1
というラベルの付いた可用性ドメインは、tenancyBのPHX-AD-1
というラベルの付いた可用性ドメインとは異なるデータ・センターの場合があります。
Oracle Cloud Infrastructureでは、各テナンシでどの可用性ドメインがどのデータ・センターに対応するかをトラッキングするために、可用性ドメイン名にテナンシ固有の接頭辞を使用します。接頭辞の例はUocm:
です。この接頭辞を使用すると、可用性ドメイン名はUocm:PHX-AD-1
、Uocm:PHX-AD-2
などになります。
テナンシの可用性ドメインの特定の名前を取得するには、IAM APIで利用できるListAvailabilityDomains操作を使用します。コンソールを使用してインスタンスを作成する際、インスタンスを作成する可用性ドメインを選択するときにも名前を確認できます。
フォルト・ドメイン
フォルト・ドメインとは、可用性ドメイン内のハードウェアおよびインフラストラクチャをグループ化したものです。可用性ドメインごとに3つのフォルト・ドメインが含まれています。フォルト・ドメインではアンチアフィニティが提供されるため、単一の可用性ドメイン内でインスタンスが同じ物理ハードウェア上に存在しないようにインスタンスを分散できます。1つのフォルト・ドメインに影響するハードウェア障害またはコンピュート・ハードウェア・メンテナンス・イベントは、他のフォルト・ドメイン内のインスタンスに影響しません。
コンピュート・インスタンス、ベア・メタルDBシステム・インスタンスまたは仮想マシンDBシステム・インスタンスの配置を制御するために、オプションで、起動時に新規インスタンスまたはインスタンス・プールのフォルト・ドメインを指定できます。フォルト・ドメインを指定しないと、システムによって選択されます。Oracle Cloud Infrastructureは、アベイラビリティ・ドメイン内の空き容量を最適化しながら、様々なフォルト・ドメインにベストエフォート・アンチアフィニティ配置を行います。コンピュート・インスタンスのフォルト・ドメインを変更するには、フォルト・ドメインを編集します。ベア・メタルまたは仮想マシンDBシステムのインスタンスのフォルト・ドメインを変更するには、インスタンスを終了し、優先フォルト・ドメインで新しいインスタンスを起動します。
フォルト・ドメインを使用して、次の処理を実行します:
- 予期しないハードウェア障害から保護します。
- コンピュート・ハードウェアのメンテナンスによる計画済停止から保護します。
詳細情報:
- アプリケーションおよびデータベース・サーバーをプロビジョニングする際にフォルト・ドメインを使用する方法の推奨事項は、コンピュート・インスタンスのベスト・プラクティスのフォルト・ドメインを参照してください。
サブスクライブ済リージョンの制限
トライアル、Free Tierおよびpay-as-you-goのテナンシは、1つのサブスクライブ済リージョンに制限されます。pay-as-you-goテナンシの制限の引上げをリクエストできます。詳細は、サブスクライブ済リージョン制限の引上げをリクエストするにはを参照してください。
ユニバーサル月次クレジット・テナンシは、公開されているすべての商用リージョンにサブスクライブできます。
サブスクライブ済リージョン数に対する制限の引上げのリクエスト
コンソール内からテナンシのサブスクライブ済リージョン数を引き上げるリクエストを送信できます。テナンシの制限を超えてリージョンをサブスクライブしようとすると、制限の引上げリクエストを送信するように求められます。また、サービス制限ページから、または「ヘルプ」メニュー()の下リンクをクリックすることにより、いつでもリクエストを起動できます。
-
「ヘルプ」メニュー()を開き、「サポート」に移動して、「サービス制限の拡大のリクエスト」をクリックします。
-
次を入力します:
- 主な連絡先の詳細: リクエスト元の個人の名前および電子メール・アドレスを入力します。電子メール・アドレスを1つのみ入力します。確認がこの電子メール・アドレスに送信されます。
- サービス・カテゴリ: 「リージョン」を選択します。
- リソース: 「サブスクライブ済リージョン数」を選択します。
- テナンシ制限: 制限数を指定します。
- リクエストの理由: リクエストの理由を入力します。リクエストが緊急であるか通常と異なる場合は、ここで詳細を指定してください。
- リクエストの発行をクリックします。
リクエストを送信してから処理されます。レスポンスは数分から数日かかる場合があります。リクエストが許可されると、主な連絡先の詳細に指定されたアドレスに確認電子メールが送信されます。
リクエストに関する追加情報が必要な場合は、主な連絡先の詳細に指定されたアドレスにフォローアップ電子メールが送信されます。
リージョン間でのサービスの可用性
OCIは、すべてのパブリック・クラウド・リージョンと専用クラウド・リージョンにクラウド・サービスを提供しています。ただし、特定の専門または新興サービスは、特定のリージョンでのみ使用できます。詳細は、サービスの可用性を参照してください。
リソースの可用性
次の各項では、リソース・タイプをその可用性(リージョン間、単一リージョン内、または単一の可用性ドメイン内)に基づいてリストします。
通常、IAMリソースはクロスリージョンです。DBシステム、インスタンスおよびボリュームは、可用性ドメインに固有です。その他すべてはリージョナルです。例外: サブネットは、当初は可用性ドメインに固有として設計されていました。現在は、Oracleが推奨するリージョナル・サブネットを作成できます。
クロスリージョン・リソース
- API署名キー
- コンパートメント
- ディテクタ(クラウド・ガード、レポート・リージョンに対してリージョナル)
- 動的グループ
- フェデレーション・リソース
- グループ
- 管理対象リスト(クラウド・ガード)
- ネットワーク・ソース
- ポリシー(IAMおよびZero Trust Packet Routing)
- レスポンダ(クラウド・ガード、レポート・リージョンに対してリージョナル)
- セキュリティー属性(Zero Trust Packet Routing)
- セキュリティ属性ネームスペース(ゼロ信頼パケット・ルーティング)
- タグ・ネームスペース
- タグ・キー
- ターゲット(クラウド・ガード、レポート・リージョンに対してリージョナル)
- ユーザー
リージョナル・リソース
- アクセス・ポリシー(サービス・メッシュ)
- エージェント(データベース移行)
- アラーム
- apmドメイン(アプリケーション・パフォーマンス・モニタリング)
- アプリケーション (データ・フロー・サービス)
- アプリケーション (ファンクション・サービス)
- アーティファクト・リポジトリ(アーティファクト・レジストリ)
- バックアップ(PostgreSQLを使用したOCIデータベース)
- 要塞
- ブロックチェーン・プラットフォーム(ブロックチェーン・プラットフォーム・サービス)
- バケット: バケットはリージョナル・リソースですが、APIコール用の正しいリージョン固有のオブジェクト・ストレージURLを使用すると、任意の場所からアクセスできます。
- インフラストラクチャ(Compute Cloud@Customerサービス)
- アップグレード・スケジュール(Compute Cloud@Customerサービス)
- クラスタ(ビッグ・データ・サービス)
- クラスタ(Kubernetesエンジン・サービス)
- クラスタ配置グループ(クラスタ配置グループ・サービス)
- cloudevents-rules
- config作業リクエスト(ログ・アナリティクス)
- 構成(PostgreSQLを使用したOCIデータベース)
- 構成ソース・プロバイダ(リソース・マネージャ)
- 接続(データベース移行)
- コネクタ(コネクタ・ハブ)
- コンテンツおよびエクスペリエンス(コンテンツ管理)
- 顧客構内機器(CPE)
- ダッシュボード(コンソール・ダッシュボード)
- ダッシュボード(管理ダッシュボード)
- ダッシュボード・グループ(コンソール・ダッシュボード)
- データ・カタログ
- データベース・インサイト(Opsインサイト)
- データベース(PostgreSQLを使用したOCIデータベース)
- データセット(データ・ラベリング)
- DBシステム(HeatWaveサービス)
- デプロイメント(GoldenGate)
- デスクトッププール(セキュアデスクトップ)
- devopsプロジェクト(DevOps)
- ビルド・パイプライン (DevOps)
- コード・リポジトリ (DevOps)
- デプロイメント・パイプライン(DevOps)
- DHCPオプション・セット
- 検出ジョブ(スタック・モニタリング)
- DrProtectionGroup (フル・スタック・ディザスタ・リカバリ)
- DrPlan (フル・スタック・ディザスタ・リカバリ)
- DrPlanExecution (フル・スタック・ディザスタ・リカバリ)
- 動的ルーティング・ゲートウェイ(DRG)
- 暗号化キー
- エンティティ(ログ・アナリティクス)
- フリート(Java管理)
- フリート(フリート・アプリケーション管理)
- ファンクション
- 汎用アーティファクト(アーティファクト・レジストリ)
- グループ(OS管理ハブ)
- ホスト・スキャン
- イメージ
- イングレス・ゲートウェイ(サービス・メッシュ)
- イングレス・ゲートウェイのルート表(サービス・メッシュ)
- インスタンス(OS管理ハブ)
- ライフサイクル環境(OS管理ハブ)
- ライフサイクル・ステージ(OS管理ハブ)
- インターネット・ゲートウェイ
- ジョブ(データベース管理)
- ジョブ(データベース移行)
- ジョブ(リソース・マネージャ)
- ロード・バランサ
- ローカル・ピアリング・ゲートウェイ(LPG)
- ログ・グループ(ログ・アナリティクス)
- メンテナンス・ウィンドウ(フリート・アプリケーション管理)
- 管理エージェントのインストール・キー
- 管理エージェント
- 管理対象データベース・グループ(データベース管理)
- 管理対象データベース(データベース管理)
- 管理ステーション(OS管理ハブ)
- メッシュ(サービス・メッシュ)
- メトリック
- メディア・ワークフロー(メディア・フロー)
- メディア・ワークフロー構成(メディア・フロー)
- メディア・ワークフロー・ジョブ(メディア・フロー)
- メディア・アセット(メディア・フロー)
- 移行(データベース移行)
- モデル
- モニター(ヘルス・チェック)
- NATゲートウェイ
- ネットワーク・ファイアウォール・ポリシー
- ネットワーク・セキュリティ・グループ
- ノード・プール
- ノートブック・セッション
- オブジェクト収集ルール(ログ・アナリティクス)
- OpenSearchクラスタ(OpenSearchを使用した検索)
- OpenSearchクラスタ・バックアップ(OpenSearchを使用した検索)
- ポート・スキャン
- プライベート・エンドポイント(データベース管理)
- プライベート・エンドポイント(リソース・マネージャ)
- プライベート・エンドポイント作業リクエスト(データベース管理)
- プライベート・テンプレート(リソース・マネージャ)
- プローブ(ヘルス・チェック)
- 問題(クラウド・ガード、レポート・リージョンに対してリージョナル)
- プロファイル(OS管理ハブ)
- プロジェクト
- プロパティ(フリート・アプリケーション管理)
- queryjob作業リクエスト(ログ・アナリティクス)
- キュー
- 登録済データベース(GoldenGate)
- リポジトリ
- 予約済パブリックIP
- リソース(スタック・モニタリング)
- ルート表
- 実行
- runbook (フリート・アプリケーション管理)
- 保存済検索(管理ダッシュボード)
- スキャン・レシピ
- スケジュール(フリート・アプリケーション管理)
- スケジュール済タスク(ログ・アナリティクス)
- スケジュール済ジョブ(OS管理ハブ)
- シークレット
- セキュリティ・リスト
- セキュリティ・ゾーン
- セキュリティ・ゾーン・レシピ
- サービス・ゲートウェイ
- セッション(要塞)
- シャード・データベース(グローバルに分散したAutonomous Database)
- シャード・データベース作業リクエスト(グローバル分散Autonomous Database)
- sharded-database-private-endpoint (グローバルに分散されたAutonomous Database)
- ソフトウェア・ソース(OS管理ハブ)
- スタック(リソース・マネージャ)
- StreamDistributionChannel (メディア・ストリーム)
- StreamPackagingConfig (メディア・ストリーム)
- StreamCdnConfig (メディア・ストリーム)
- storage作業リクエスト(ログ・アナリティクス)
- サブネット: サブネットの作成時に、それがリージョナルであるか、可用性ドメインに固有であるかを選択します。リージョナル・サブネットの使用をお薦めします。
- サブスクリプション
- 表
- ターゲット(脆弱性スキャン)
- チケット(サポート管理サービス)
- 脅威インジケータ
- 脅威のタイプ
- トピック
- ボールト
- 仮想クラウド・ネットワーク(VCN)
- 仮想デプロイメント(サービス・メッシュ)
- 仮想サービス(サービス・メッシュ)
- 仮想サービスのルート表(サービス・メッシュ)
- ボリューム・バックアップ: 格納先と同じリージョン内の任意の可用性ドメインに新規ボリュームとしてリストアできます。
- 脆弱性レポート
- ワークスペース
可用性ドメイン固有のリソース
- コンテナ・インスタンス
- DBシステム(Oracle Databaseサービス)
- エフェメラル・パブリックIP
- インスタンス(コンピュート): 同じ可用性ドメイン内のボリュームにのみアタッチできます。
- ネットワーク・ファイアウォール
- サブネット: サブネットの作成時に、それがリージョナルであるか、可用性ドメインに固有であるかを選択します。リージョナル・サブネットの使用をお薦めします。
- ボリューム: 同じ可用性ドメイン内のインスタンスにのみアタッチできます。