プライベートエンドポイントADBとクロスリージョンAutonomous Data Guard向けVCNピアリング (2021/09/01)

プライベートエンドポイントADBとクロスリージョンAutonomous Data Guard向けVCNピアリング (2021/09/01)

https://blogs.oracle.com/datawarehousing/post/vcn-peering-for-adbs-with-private-endpoints-and-cross-region-autonomous-data-guard

投稿者: Nilay Panchal | Principal Product Manager


Cross-Region Autonomous Data Guard (X-ADG) を紹介した記事に続き、X-ADG を有効にしたデータベースがプライベートエンドポイント (PE) の背後にある場合に必要なネットワーク設定について、さらに詳しく説明したいと思います。これはより高度で管理的なトピックですが、プライベートエンドポイントを使用することは、Autonomous Database (ADB) にとって最も安全なセットアップであるため、賞賛に値するものです。


ここでは、クライアントアプリケーションとは異なるリージョンにあるリモートプライベートデータベースに接続する際に必要な Virtual Cloud Network (VCN) ピアリング構成を簡略化して説明します(たとえば、中層アプリケーションがプライマリリージョンにある間に、データベースをリモートリージョンのスタンバイフェイルオーバー/スイッチオーバーする場合などです)。リモートデータベースのホスト名は、リモートリージョン VCN のプライベート IP アドレスを参照するため、プライベートデータベースのホスト名(ADB ウォレットにマッピングされている)はリージョンをまたいで解決することはできません。これを実現するためには


  1.     ダイナミックルーティングゲートウェイ(DRG)内のリモートピアリング接続(RPC)を使用して、2つのリージョンのVCN間でプライベートトラフィックを送信できるように、リモートVCNピアリングを確立する。
  2.     VCNのDNSリゾルバを更新して、一方のリージョンのADBホスト名を他方のリージョンに転送し、リモートリージョンのリスナーがホスト名をリモートADBのプライベートIPアドレスに変換するようにします。


 


注:スタック全体(中間層、アプリケーションなど)を常に同じリモートリージョンにスイッチオーバー/フェイルオーバーすることを想定している場合、ADBインスタンスをスイッチオーバーする際に、VCNをピアリングする必要はないでしょう。


また、以下の設定は、2つのリージョンのVCNをピアリングし、Oracle Cloudで動作するアプリケーションからAutonomous Database(ADB)への接続を想定しています。オンプレミスのアプリケーションからADBインスタンスの1つに接続するには、トランジットルーティングを設定する必要があります。



以下では、このようなピアリングネットワークのセットアップを作成する手順を説明します。リモートスタンバイが有効なAutonomous Databaseインスタンスと、データベースインスタンスへの接続に使用するパブリックコンピュートインスタンス(VM)またはアプリケーションを持っていると仮定しています。2 つの VCN をピアリングする前に、Autonomous Databaseのプライベートエンドポイントを有効にするために必要な仮想クラウドネットワーク(VCN)、サブネット、セキュリティリスト、ネットワークセキュリティグループ(NSG)を作成および構成する手順の例を紹介します。プライマリーリージョンとリモートリージョンの両方で、ほとんどの手順を実行します。すでにデータベースにプライベートエンドポイントを設定している場合は、最初の手順の一部を省略できますが、要件(重複しない CIDR ブロックなど)を見逃していないことを確認するために、これらの手順に目を通すことを強くお勧めします。


以下、私が使用するリージョンの例です。


リージョン1 (プライマリ/ソースリージョン): Mumbai

リージョン2(リモート/スタンバイ・リージョン):Hyderabad


1.  送信元と送信先の2つのVCNを、CIDRブロックが重ならないように作成します。


  1.     MumbaiでCIDRブロック10.0.0.0/16を使用
  2.     Hyderabadの10.2.0.0/16

    注:DNSホストネームを使用する設定は、デフォルトのままにしてください。これをオフにすると、ユーザーは解決可能なホスト名ではなく、データベースウォレットのIPアドレスを手動で置き換える必要があります。



 

2.   各VCNにプライベートサブネットを作成します。プライマリおよびスタンバイADBインスタンスのプライベートエンドポイントは、ここに配置されます。ルートテーブル、DHCP、セキュリティリストについては、デフォルトのオプションのままでかまいません。


  1.     Mumbaiで全CIDRブロック10.0.2.0/24のサブセットを使用しました(ブロック10.0.1.0/24の一部を残して、インターネット向けのVMまたはアプリケーションを含むパブリックサブネットに使用できます)。
  2.     HyderabadのCIDRブロック10.2.0.0/16をフルに使用しました。必要に応じて、ここでもパブリックサブネット用にCIDRブロックの一部を残すことができます。


  3.     2つのVCNそれぞれで、デフォルトのセキュリティリストを更新してください。


プライマリーリージョン(Mumbai)のVCNセキュリティリストに、以下のようなものを作成します。


  - ソースタイプ CIDR のイングレスルールを作成し、その IP 範囲からの接続を許可します。


        - パブリックサブネットで動作するVMやアプリケーションに接続するために、CIDR 0.0.0.0/0 のIPアドレスからVCNへの安全なSSHプロトコルトラフィックのデフォルトルールを維持しています。

        - リモート(HYD)VCNからのTCP接続は、CIDRブロック10.2.0.0/16、宛先ポート1522(PE付きADB-Sのポート)で許可しています。

        - リモート(HYD)VCNからの着信UDP接続は、CIDRブロック10.2.0.0/16、宛先ポート53、これはOCI DNSリゾルバーが使うポートです(これについてはステップ10で詳しく説明します)を許可しています。


  - ソースタイプCIDRのegressルールで、リストアップされたIP範囲への接続を許可します。この例では、ムンバイのVCNで、CIDR 0.0.0.0/0のすべてのトラフィックのデフォルト・ルールを維持します。



遠隔地(Hyderabad)のVCNセキュリティリストには、.NET Framework 2.0を作成します。


  - イングレスルールにソースタイプCIDRを指定し、そのIPレンジからの接続を許可します。

        - 私は、パブリックサブネットで動作するVMまたはアプリケーションに接続するために、CIDR 0.0.0.0/0 の任意のIPアドレスからVCNへの安全なSSHプロトコルトラフィックのデフォルトルールを保持しています。

        - プライマリ (Mumbai) VCN からの TCP 接続は、CIDR ブロック 10.0.0.0/16 で、宛先ポート 1522 (PE による ADB-S 用ポート) を許可しています。

        - プライマリ(Mumbai)の VCN からの着信 UDP 接続を、CIDR ブロック 10.0.0.0/16 で、宛先ポート 53 で許可しました。


  - ソースタイプCIDRのegressルールで、リストアップされたIP範囲への接続を許可します。この例では、Mumbai VCNで、CIDR 0.0.0.0/0を持つすべてのトラフィックのデフォルトルールを維持しています。 

VCNを特定のIPアドレスのみに公開したり、TCPポート443を開放してORDS/HTTPSアクセスを許可するなど、業務に応じてルールを追加することができます。





4.  2つのリージョンのVCNのそれぞれで、ネットワークセキュリティグループ(NSG)を作成します。これは、プライベートエンドポイントを持つADBインスタンスに必要なファイアウォールのルールです。前のステップと同様に、プライベート・データベース用のイングレス・セキュリティ・ルールおよびイグレス・セキュリティ・ルールを追加することができます。この例では、ADB-Sのトラフィックをブロックするための特定のルールは必要ありません。




 


5.  2つのリージョンのそれぞれに、Dynamic Routing Gateway (DRG) (つまり、あなたの仮想ルータ)を作成します。それぞれのリージョンのDRGから、それぞれのリージョンのVCNにVCNアタッチメントを作成する。(注意: このアタッチメントを VCN 内から作成した場合、代わりに "DRG attachment" という名前になります)


このVCNアタッチメントを作成する際、「詳細設定」で、このアタッチメントがデフォルトでDRGルートテーブルに適切にルートを追加することに気づかれるでしょう。


前述のように、オンプレミス・アプリケーションへのトランジット・ルーティングの場合は、VCNのルート・テーブルに必要なルートを追加する必要もあります。



6.  作成した2つのリージョンのDRGのそれぞれで、Remote Peering Connections Attachmentsをクリックし、2つのVCNをピアリングするために使用するRPC(Remote Peering Connection)を作成します。RPC を作成すると、DRG への RPC アタッチメントと、RPC アタッチメント用の DRG ルートテーブ ルも自動的に作成されます。


 

 

7.  このステップは、どちらかのリージョンで実行する必要があるだけです。プライマリーリージョンの RPC から "Establish Connection" をクリックします。ここで、あなたのプライマリ・リージョンの VCN をリモート・リージョンの VCN にリモート・ピアリングすることになります。ドロップダウンからリモートリージョンを選択し、リモートリージョンの RPC の OCID  をダイアログに入力します(リモート RPC のコンソールからコピーすることができます)。


成功すると、あなたの2つのVCNがピアリングされます! リモートリージョンの RPC を覗いてみると、そこでも接続が確立されているのがわかるはずです。





8.  RPCアタッチメントを作成すると、RPCへの適切なルートを持つ自動生成DRGルーティングテーブルエントリもDRGに自動的に作成されるはずです。RPCアタッチメントのためにDRGルーティングテーブルが適切に更新されたかどうかを確認するには、DRG → DRGルートテーブル → RPC、VC、IPSecアタッチメント用の自動生成DRGルートテーブル → 「すべてのルートを取得」をクリックします。


適切に設定されていれば、現在のリージョンの CIDR ブロックのネクストホップがローカル VCN として、またリモートリージョンのサブネットの CIDR ブロックのネクストホップが RPC として表示されます(下のスクリーンショットのように)。これは DRG に、その特定の CIDR ブロックに意図されたトラフィックをどこにルーティングするかを伝えます。


このルールが設定にない場合、これらのルールを生成する必要があります。DRGのコンソールで、"Autogenerated Import Route Distribution for VCN Routes "をクリックします。利用可能なステートメントを選択し、"Manage Statements "をクリックします。ここでは、既存のステートメントに「別のステートメント」を追加し、ルート生成オプションを選択して、アタッチメントタイプ「リモートピアリング接続」からルートを生成するようにしたいと思います。保存をクリックすると、ルートルールが自動的に更新され、リモートリージョンのRPCへの適切なホップが含まれるようになるはずです。上の段落の手順に従って、これを確認することができます。


注意:このRPCルートテーブルは、各リージョンで同じようにセットアップする必要があります。リモートリージョンでも、これと同じ手順に従ってください。



9.  リモートピアリングを設定した後、まだ設定していない場合は、プライマリADBインスタンスとリモートスタンバイインスタンスの両方でプライベートエンドポイントを有効にします。各リージョンで、上記で作成したNSG付きのプライベートサブネットを選択します(データベースがパブリックインターネットに一切公開されないようにします)。




 

10.  2つのデータベース(プライマリとリモート)のそれぞれのドメインホスト名をメモして、データベースコンソールのプライベートエンドポイントURLとして表示します。


私の例では、MumbaiのプライベートADBのホスト名は以下の通りです。

                                     x2ic8wriy.adb.ap-mumbai-1.oraclecloud.com です。

で、Hyderabad(リモート)のプライベートADBのホスト名は 

                                     x2ic8wqa.adb.ap-hyderabad-1.oraclecloud.com となります。



11.  2つのリージョンのVCNコンソールで、それぞれDNSリゾルバに移動します。各VCNのプライベートサブネットに、リスニングエンドポイントとフォワーディングエンドポイントの両方を作成します。デフォルトのままにしておけば、未使用のIPアドレスが選ばれます。






12.  2つのリージョンのDNSリゾルバ内で、もう一方のリージョンのエンドポイントへのドメイン転送ルールを作成します。これは、それぞれのリージョンのドメインホスト名を、そのリージョンのプライベートIPアドレスに解決するのに役立つものである。

 


  1.     プライマリーリージョンで、次のルールを作成します。
    1.         リモートリージョンのホスト名を「ドメイン」として使用(例:x2ic8wnr.adb.ap-hyderabad-1.oraclecloud.com)
    2.         プライマリーリージョンのForwarderのエンドポイントを使用
    3.         宛先IPはリモートリージョンのリスナーのIPアドレスを入力        (例:10.2.2.152)
  2.     リモートリージョンで、ルールを作成する
    1.         プライマリーリージョンのホスト名を "ドメイン "として使用        (例: x2ic8wriy.adb.ap-mumbai-1.oraclecloud.com)
    2.         リモートリージョンのForwarderのエンドポイントを使用
    3.         プライマリーリージョンのリスナーとして宛先IPを入力        (例:10.0.2.79)





13.      上記では、リモートリージョン向けのプライベート CIDR トラフィックをどこにルーティングするか、つまり RPC に伝えるよう DRG に指示しました。VCN のデフォルト・ルート・テーブルが、リモートリージョンのプライベート・サブネットを対象としたトラフィックを DRG にルーティングしていることを確認しましょう。プライマリーリージョンのVCNコンソール→「デフォルトルートテーブル」にアクセスし、リモートリージョンのプライベートサブネットのCIDRブロックトラフィックがDRGにルーティングされ、相手側に送られているかどうかを確認します。そうでない場合は、必要なルートルールを追加します。

    他のリージョンでも同じようにすることを確認してください。



     




これで完了です! これで、プライマリーリージョンからリモートリージョンのプライベートデータベースに接続するためのトンネルができました。プライマリリージョンのパブリック VM やアプリケーションにアクセスし、ADB ウォレットをダウンロードします。


すべてがうまくいけば、VCN はピアリングされ、ホスト名は VCN 間で適切に転送され、このダウンロードしたウォレットを使って、プライマリリージョンと、スイッチオーバーフェイルオーバーを行った後のリモートリージョンの両方でデータベースインスタンスに接続できるようになるはずです。リモートリージョンのホスト名はリモートデータベースのプライベートIPアドレスに解決され、プライマリリージョンからリモートプライベートデータベースに接続できるようになります。






コメント

このブログの人気の投稿

Oracle RACによるメンテナンスのためのドレインとアプリケーション・コンティニュイティの仕組み (2023/11/01)

Oracle Cloud Infrastructure Secure Desktopsを発表: デスクトップ仮想化のためのOracleのクラウドネイティブ・サービス (2023/06/28)

新しいOracle Container Engine for Kubernetesの機能強化により、大規模なKubernetesがさらに簡単になりました (2023/03/20)