リージョンおよび可用性ドメイン

このトピックでは、Oracle Cloud Infrastructureリソースの物理的および論理的な編成について説明します。

リージョンおよび可用性ドメインについて

Oracle Cloud Infrastructureは、リージョンおよび可用性ドメインにホストされます。リージョンは限られた地理的領域で、可用性ドメインはリージョン内に配置された1つ以上のデータ・センターです。1つのリージョンは、1つ以上の可用性ドメインで構成されます。ほとんどのOracle Cloud Infrastructureリソースは、仮想クラウド・ネットワークのようにリージョン固有であるか、コンピュート・インスタンスのように可用性ドメイン固有です。可用性ドメイン間およびリージョン間のトラフィックは暗号化されます。可用性ドメインは、相互に分離され、フォルト・トレラントであり、同時に失敗することはほとんどありません。可用性ドメインは電源や冷却などのインフラストラクチャや内部可用性ドメイン・ネットワークを共有しないため、リージョン内の1つの可用性ドメインで障害が発生しても、同じリージョン内の他の可用性ドメインの可用性に影響を与える可能性はほとんどありません。

同じリージョン内の可用性ドメインは、低レイテンシの高帯域幅ネットワークによって相互に接続されます。これにより、インターネットおよびオンプレミスへの高可用性の接続を提供したり、高可用性とディザスタ・リカバリの両方のためにレプリケートされたシステムを複数の可用性ドメインに構築できるようになります。

オラクルでは、世界中に複数のクラウド・リージョンを追加して、お客様のクラウド・リソースにローカル・アクセスを提供しています。これを迅速に実現するために、新しい地域には1つの可用性ドメインを持つリージョンを立ち上げることを選択しました。

リージョンの拡張が必要になった場合、既存の可用性ドメインへの容量の追加、既存のリージョンへの可用性ドメインの追加、または新しいリージョンの構築という選択肢があります。特定のシナリオでの拡張アプローチは、顧客要件に加え、リージョンの需要パターンとリソースの可用性に関する考慮事項に基づきます。

1つの可用性ドメインがあるリージョンでは、データ保管場所に関する顧客要件が存在する場合にそれをサポートするディザスタ・リカバリのオプションを有効にするために、同じ国または地政学的領域内の2つ目の可用性ドメインまたはリージョンが1年以内に使用可能になります。

リージョンは他のリージョンから独立しており、複数の国または大陸をもまたがる広大な空間で分離できます。一般に、近くにあるリソースの使用は遠くにあるリソースの使用よりも高速であるため、アプリケーションは、それが最も頻繁に使用されるリージョンにデプロイします。ただし、次の理由から、様々なリージョンにアプリケーションをデプロイすることもできます:

  • 大規模な気象系や地震など、リージョン全体の事象のリスクを軽減するため。
  • 法的管轄区域、税領域、その他のビジネス基準または社会基準の様々な要件を満たすため。

リージョンはレルムにグループ化されます。テナンシは、単一のレルムに存在し、そのレルムに属するすべてのリージョンにアクセスできます。自分のレルム内にないリージョンにはアクセスできません。現在、Oracle Cloud Infrastructureには複数のレルムがあります。商用レルムが1つあります。Government Cloud用のレルムが複数(US Government Cloud FedRAMP認可済およびIL5認可済、およびUnited Kingdom Government Cloud)あります。

次の表に、Oracle Cloud Infrastructureの商用レルムのリージョンを示します:

リージョン名 リージョン識別子 リージョンの場所 リージョン・キー レルム・キー 可用性ドメイン
オーストラリア東部(シドニー) ap-sydney-1 シドニー(オーストラリア) SYD OC1 1
オーストラリア南東部(メルボルン) ap-melbourne-1 メルボルン、オーストラリア MEL OC1 1
ブラジル東部(サンパウロ) sa-saopaulo-1 サンパウロ(ブラジル) GRU OC1 1
カナダ南東部(モントリオール) ca-montreal-1 モントリオール、カナダ YUL OC1 1
カナダ南東部(トロント) ca-toronto-1 トロント(カナダ) YYZ OC1 1
チリ(サンティアゴ) sa -santiago-1 サンティアゴ SCL OC1 1
ドイツ中央部(フランクフルト) eu-frankfurt-1 フランクフルト(ドイツ) FRA OC1 3
インド南部(ハイデラバード) ap-hyderabad-1 ハイデラバード、インド HYD OC1 1
インド西部(ムンバイ) ap-mumbai-1 ムンバイ(インド) BOM OC1 1
日本中央部(大阪) ap-osaka-1 大阪、日本 KIX OC1 1
日本東部(東京) ap-tokyo-1 東京(日本) NRT OC1 1
オランダ北西部(アムステルダム) eu-amsterdam-1 アムステルダム、オランダ AMS OC1 1
サウジアラビア西部(ジッダ) me-jeddah-1 ジッダ、サウジアラビア JED OC1 1
大韓民国中部(ソウル) ap-seoul-1 ソウル(韓国) ICN OC1 1
韓国北部(春川) ap-chuncheon-1 春川、韓国 YNY OC1 1
スイス北部(チューリッヒ) eu-zurich-1 チューリッヒ(スイス) ZRH OC1 1
UAE東部(ドバイ) me -dubai-1 ドバイ,アラバマ州(アメリカ合衆国) DXB OC1 1
英国南部(ロンドン) uk-london-1 ロンドン、英国 LHR OC1 3
UK West (Newport) uk -cardiff-1 ニューポート、英国 CWL OC1 1
米国東部(アッシュバーン) us-ashburn-1 アッシュバーン、VA IAD 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:PHX-AD-1、Uocm:PHX-AD-2などのようになります。

テナンシの可用性ドメインの特定の名前を取得するには、IAM APIで利用できるListAvailabilityDomains操作を使用します。コンソールを使用してインスタンスを起動するときに名前を確認し、インスタンスを起動する可用性ドメインを選択することもできます。

フォルト・ドメイン

フォルト・ドメインとは、可用性ドメイン内のハードウェアおよびインフラストラクチャをグループ化したものです。各可用性ドメインには、3つのフォルト・ドメインが含まれています。フォルト・ドメインではアンチアフィニティが提供されます。これにより、単一の可用性ドメイン内でインスタンスが同じ物理ハードウェア上に存在しないようにインスタンスを分散できます。1つのフォルト・ドメインに影響するハードウェア障害またはコンピュート・ハードウェア・メンテナンス・イベントは、他のフォルト・ドメイン内のインスタンスに影響しません。また、フォルト・ドメイン内の物理ハードウェアには独立した冗長電源装置があるため、1つのフォルト・ドメイン内の電源装置ハードウェアに障害が発生しても他のフォルト・ドメインには影響しません。

コンピュート・インスタンス、ベア・メタルDBシステム・インスタンスまたは仮想マシンDBシステム・インスタンスの配置を制御するために、オプションで、起動時に新規インスタンスまたはインスタンス・プールのフォルト・ドメインを指定できます。フォルト・ドメインを指定しないと、システムによって選択されます。Oracle Cloud Infrastructureは、可用性ドメイン内の使用可能容量を最適化しながら、様々なフォルト・ドメインにベストエフォート・アンチアフィニティ配置を行います。コンピュート・インスタンスのフォルト・ドメインを変更するには、フォルト・ドメインを編集します。ベア・メタルまたは仮想マシンDBシステムのインスタンスのフォルト・ドメインを変更するには、インスタンスを終了し、優先フォルト・ドメインで新しいインスタンスを起動します。

フォルト・ドメインを使用して、次の処理を実行します:

  • 予期しないハードウェア障害や電源装置の障害から保護します。
  • コンピュート・ハードウェアのメンテナンスによる計画済停止から保護します。

詳細情報:

サブスクライブ済リージョンの制限

トライアル、Free Tierおよびpay-as-you-goのテナンシは、1つのサブスクライブ済リージョンに制限されます。pay-as-you-goテナンシの制限の引上げをリクエストできます。詳細は、サブスクライブ済リージョン制限の引上げをリクエストするにはを参照してください。

ユニバーサル月次クレジット・テナンシは、公開されているすべての商用リージョンにサブスクライブできます。

サブスクライブ済リージョン数に対する制限の引上げのリクエスト

コンソール内からテナンシのサブスクライブ済リージョン数を引き上げるリクエストを送信できます。テナンシの制限を超えてリージョンをサブスクライブしようとすると、制限の引上げリクエストを送信するように求められます。また、サービス制限ページから、または「ヘルプ」メニュー(「ヘルプ」メニューのアイコン)でリンクをクリックすることにより、いつでもリクエストを起動できます。

サブスクライブ済リージョン制限の引上げをリクエストするには
  1. 「ヘルプ」メニュー(「ヘルプ」メニューのアイコン)を開き、「サポート」に移動して、「サービス制限の引上げのリクエスト」をクリックします。

  2. 次を入力します:

    • 主な連絡先の詳細: リクエスト元の個人の名前および電子メール・アドレスを入力します。電子メール・アドレスを1つのみ入力します。確認がこの電子メール・アドレスに送信されます。
    • サービス・カテゴリ: 「リージョン」を選択します。
    • リソース: 「サブスクライブ済リージョン数」を選択します。
    • テナンシ制限: 制限数を指定します。
    • リクエストの理由: リクエストの理由を入力します。リクエストが緊急であるか通常と異なる場合は、ここで詳細を指定してください。
  3. 「リクエストの発行」をクリックします。

リクエストを送信してから処理されます。レスポンスは数分から数日かかる場合があります。リクエストが許可されると、主な連絡先の詳細に指定されたアドレスに確認電子メールが送信されます。

リクエストに関する追加情報が必要な場合は、主な連絡先の詳細に指定されたアドレスにフォローアップ電子メールが送信されます。

リージョン間でのサービスの可用性

すべてのOracle Cloud Infrastructureリージョンには、次のようなコア・インフラストラクチャ・サービスがあります:

  • コンピュート: コンピュート(Intelベースのベア・メタルとVM、DenseIOおよび標準)、Container Engine for Kubernetesレジストリ
  • ストレージ: ブロック・ボリュームファイル・ストレージオブジェクト・ストレージアーカイブ・ストレージ
  • ネットワーキング: 仮想クラウド・ネットワーク、ロード・バランシングFastConnect (使用可能および要求された特定のパートナ)
  • データベース: データベース、Exadata Cloud Service、Autonomous Data WarehouseAutonomous Transaction Processing
  • エッジ: DNS
  • プラットフォーム: 監査、Identity and Access Management、モニタリング通知、タグ付け、作業リクエスト
  • セキュリティ: ボールト

一般に、前述のリストに含まれていない使用可能なクラウド・サービスは、リージョンの顧客需要に基づいて使用可能になります。どのサービスも最大3か月以内に使用可能にでき、多くのサービスはより迅速にデプロイできます。新規クラウド・サービスは、リージョンの顧客需要、適用される場合に規制準拠を実現する能力、リソース可用性などの要素を含む様々な考慮事項に基づいて、可能なかぎり迅速にリージョン内で利用可能にされます。Oracle Cloud Infrastructureの低レイテンシ・インターコネクト・バックボーンにより、データ保管場所要件によって阻止されないかぎり、他の地理的リージョンのクラウド・サービスを使用することができ、それらのサービスをホーム・リージョンで使用できない場合に有効な結果をもたらします。オラクルでは、通常はお客様と協力して、必要なサービスへの効果的なアクセスを確保します。

リソースの可用性

次の各項では、リソース・タイプをその可用性(リージョン間、単一リージョン内、または単一の可用性ドメイン内)に基づいてリストします。

ヒント

通常、IAMリソースはクロスリージョンです。DBシステム、インスタンスおよびボリュームは、可用性ドメインに固有です。その他すべてはリージョナルです。例外: サブネットは、当初は可用性ドメインに固有として設計されていました。現在は、Oracleが推奨するリージョナル・サブネットを作成できます。

クロスリージョン・リソース

  • API署名キー
  • コンパートメント
  • ディテクタ(クラウド・ガード、レポート・リージョンに対してリージョナル)
  • 動的グループ
  • フェデレーション・リソース
  • グループ
  • 管理対象リスト(クラウド・ガード)
  • ネットワーク・ソース
  • ポリシー
  • レスポンダ(クラウド・ガード、レポート・リージョンに対してリージョナル)
  • タグ・ネームスペース
  • タグ・キー
  • ターゲット(クラウド・ガード、レポート・リージョンに対してリージョナル)
  • ユーザー

リージョナル・リソース

  • アラーム
  • アプリケーション (データ・フロー・サービス)
  • アプリケーション (ファンクション・サービス)
  • ブロックチェーン・プラットフォーム(ブロックチェーン・プラットフォーム・サービス)
  • バケット: バケットはリージョナル・リソースですが、APIコール用の正しいリージョン固有のオブジェクト・ストレージURLを使用すると、任意の場所からアクセスできます。
  • クラスタ(ビッグ・データ・サービス)
  • クラスタ(Container Engine for Kubernetesサービス)
  • cloudevents-rules
  • config作業リクエスト(ログ・アナリティクス)
  • 構成ソース・プロバイダ(リソース・マネージャ)
  • コンテンツとエクスペリエンス
  • 顧客構内機器(CPE)
  • ダッシュボード(管理ダッシュボード)
  • データ・カタログ
  • データベース・インサイト(オペレーション・インサイト)
  • DBシステム(MySQL Databaseサービス)
  • DHCPオプション・セット
  • 動的ルーティング・ゲートウェイ(DRG)
  • 暗号化キー
  • エンティティ(ログ・アナリティクス)
  • ファンクション
  • イメージ
  • インターネット・ゲートウェイ
  • jobs (データベース管理)
  • jobs (リソース・マネージャ)
  • ロード・バランサ
  • ローカル・ピアリング・ゲートウェイ(LPG)
  • ログ・グループ(ログ・アナリティクス)
  • 管理エージェントのインストール・キー
  • 管理エージェント
  • 管理対象データベース・グループ(Database Management)
  • 管理対象データベース(データベース管理)
  • メトリック
  • モデル
  • NATゲートウェイ
  • ネットワーク・セキュリティ・グループ
  • ノード・プール
  • ノートブック・セッション
  • オブジェクト収集ルール(ログ・アナリティクス)
  • プライベート・テンプレート(リソース・マネージャ)
  • 問題(クラウド・ガード、レポート・リージョンに対してリージョナル)
  • プロジェクト
  • queryjob作業リクエスト(ログ・アナリティクス)
  • リポジトリ
  • 予約済パブリックIP
  • ルート表
  • 実行
  • 保存済検索(管理ダッシュボード)
  • スケジュール済タスク(ログ・アナリティクス)
  • シークレット
  • セキュリティ・リスト
  • サービス・コネクタ
  • サービス・ゲートウェイ
  • stacks (リソース・マネージャ)
  • storage作業リクエスト(ログ・アナリティクス)
  • サブネット: サブネットの作成時に、それがリージョナルであるか、可用性ドメインに固有であるかを選択します。リージョナル・サブネットの使用をお薦めします。
  • サブスクリプション
  • チケット(サポート管理サービス)
  • トピック
  • ボールト
  • 仮想クラウド・ネットワーク(VCN)
  • ボリューム・バックアップ: 格納先と同じリージョン内の任意の可用性ドメインに新規ボリュームとしてリストアできます。
  • ワークスペース

可用性ドメインに固有のリソース

  • DBシステム(Oracle Databaseサービス)
  • エフェメラル・パブリックIP
  • インスタンス: 同じ可用性ドメイン内のボリュームにのみアタッチできます。
  • サブネット: サブネットの作成時に、それがリージョナルであるか、可用性ドメインに固有であるかを選択します。リージョナル・サブネットの使用をお薦めします。
  • ボリューム: 同じ可用性ドメイン内のインスタンスにのみアタッチできます。