※ 本記事は、Radu Nistorによる”OCI-Azure Interconnect advanced scenarios – part1“を翻訳したものです。
2022年9月14日
OCI-Azure Interconnectに焦点を当てて、2部からなるブログ・エントリへようこそ。第1部ではインターコネクトに関するいくつかの課題といくつかの高度なシナリオについて説明し、第2部では高度なアーキテクチャに関するデモを行います。
OracleとMicrosoftは、インターコネクトと呼ばれる冗長でプライベートな帯域幅を保証する低レイテンシ・リンクを導入することでパートナーになりました。Interconnectは、OCIのFastConnectとAzureのExpressRouteの概念を利用して、接続サービス・プロバイダを必要とせずに2つのクラウドを接続します。
このサービスは非常に効果的ですが、高度なシナリオに入るとき、このブログの焦点となる課題について検討する必要がある課題がいくつかあります。また、ラボ環境を構築し、シリーズの2番目の部分で提案された設計を確認します。
課題1 – すべてのクラウド・リージョンが相互接続をサポートしているわけではありません
インターコネクトはレイテンシを考慮して設計されています。できるだけ短い待機時間を提供するために、インターコネクトは次のような特定のペア・リージョンにのみ構築できます。
- OCI AshurnはAzure US East 1にのみインターコネクトできます
- OCI PhoenixはAzure US West 3にのみインターコネクトできます
注意: インターコネクトされたすべてのリージョンのリストは、OCI-Azure Interconnectリージョンにあります。
これらの地域以外に環境がデプロイされている場合は、インターコネクトを使用できないということでしょうか？絶対違います。2つのクラウドはそれぞれ、独自のバックボーンを使用して、既存のリージョンからインターコネクトを持つ最も近いリージョンにデータを移動する手段を提供します。各クラウドから例を挙げましょう。
OCI
OCIには、OCIバックボーンを使用して2つのOCIリージョンをリンクするリモート・ピアリング接続と呼ばれる構成があります。たとえば、OCIリージョンMontrealにワークロードがある場合、RPCを使用して、次の図のように、インターコネクトが使用可能なリージョンTorontoに接続できます。
重要な点の1つは、RPCがデフォルト設定を使用してFastConnectトラフィックを保持しないことです。RPCがFastConnect BGPに含まれるサブネットを学習できるようにするには、次を実行する必要があります:
- DRGでのカスタム・インポート・ルート配布リストの作成
- 前述のインポート・リストをRPC DRGルート表に割り当てます
カスタム・リストは次のようになります。
Azure
Microsoftではいくつかのオプションが提供されていますが、次のExpressRoute SKUのみに焦点を当てます。
- ローカル: 回線とExpressRouteゲートウェイは同じメトロ領域に存在する必要があります
- Standard: 回線とExpressRouteゲートウェイは同じ地理的領域（例: 北米）に存在する必要があります
- Premium: 回路とExpress Route Gatewayは世界中の任意の2つのリージョンに配置できます。
Standard SKUを利用すると、次に示す例のように、北米のリージョンに構築された回線を北米の他のリージョンのVNET内に構築されたExpressRouteゲートウェイにピアリングできるようになります。
異なるExpressRouteタイプの使用に関連するコストが異なることに注意してください。
課題2 – Multiregionデプロイメント
OCIとAzureの両方に複数のリージョンにリソースがある場合はどうなるか、いくつかのオプションを検討します。
a) 次の図のように、OCIのRPCおよびAzureのExpressRoute SKUを使用して、クラウド間で単一のインターコネクトを使用するオプションがあります。
インターコネクトは2つの冗長物理リンク上に構築されているため、冗長性が組み込まれていますが、地域の災害の影響を受ける可能性がある小さな地理的リージョンのインフラストラクチャを使用します。さらに、リモート・リージョン間のレイテンシ（Phoenix to Azure West3）がアプリケーションにとって問題となる可能性があります。
b) 2つ目の相互接続を構築することで、前述のシナリオを拡張できます。クラウド・クロス・リージョン間の接続（OCI East to Azure WestまたはOCI West to Azure East）は、実装の選択に応じて、OCIのバックボーンまたはAzureのバックボーンによって実行できます。
OCIのバックボーン:
Azureのバックボーン:
このアプローチは問題ありませんが、すべてのリージョン間で可用性の高いネットワーク・パスを提供することはありません。
c) クラウド間の冗長パスを持つフルメッシュ
両方のクラウドのすべてのリージョンが複数のインターコネクト・リンクで相互に通信でき、それらのリンクが冗長パスを提供できるアーキテクチャを構築できますか? はい、できますが、追加のルーティング構成が必要です。
インターコネクトはeBGP上に構築されていますが、いくつかの制限があります。
- どちらの側でもBGPパラメータ（例: path- prepend）を設定することはできません。Azureは「ローカル設定」機能を提供していますが、トラフィックの1つの方向にのみ影響します。
- 各クラウド・リンクは、ローカル・リージョンかリモート・リージョンかにかかわらず、既知の接頭辞を直接接続として通知します。
したがって、2つのインターコネクト・リンクを構築し、すべてのOCIおよびAzureプリフィクスを両方で発表した場合、ルーティングが非対称になる可能性があるため、同じ優先度を持つ2つのクラウド間の複数のパスになります。これを回避するには、OCIのDRGルーティング機能を静的エントリとともに使用します。
アーキテクチャは次のようになります。
このアーキテクチャでは、各インターコネクトが他のインターコネクトの冗長パスを提供します。OCI AshburnへのAzure East US2トラフィックの例を見てみましょう。
– 通常のパス: Azure East US2 -> Azure East US1 -> Interconnect -> OCI Ashburn
– バックアップ・パス: Azure East US2 -> Azure West US3 -> OCI Phoenix -> RPC -> OCI Ashburn
バート2では、この正確なシナリオについてデモを行います。