1. OCIでのネットワーク導入の詳細
  2. ネットワーク設計について学習

ネットワーク設計について学習

デフォルトのパラメータを使用して適切に計画せずに構築されたOCIネットワーク・インフラストラクチャ・コンポーネント(VCN、サブネット、ゲートウェイなど)は、デプロイメント後に解決が困難な問題を引き起こす可能性があります。適切に計画されたネットワーク設計は、実装を成功させるための設定に役立ち、チームと組織が簡単に使用できます。

ネットワーク設計を早期に実行

導入前にネットワークを完全に設計することで、問題を早期に発見し、導入を成功させるための障壁を取り除くことができます。後でOCIネットワーク設計要素の一部を変更することは可能ですが、多大な労力が必要になり、ビジネス・フローが一時的に中断する可能性があります。

Oracleでは、OCIネットワーク設計に次のことをお薦めします:

  1. 適切な時間を計画し、OCIネットワークを適切に設計するための十分なリソースをプロジェクト計画に割り当てます。
  2. レイアウト、トポロジ、SCNおよびサブネットのサイズ設定、ドメイン・ネーム・サービス(DNS)、およびオンプレミスまたは他のCSPへの外部ネットワーク接続などが最小限含まれます。
  3. Oracleアカウント・チームと協力して、OracleがOCIネットワーキング・スペシャリストを提供できるかどうかを確認することを検討してください。

次に、ネットワーク設計図の例を示します。


vcn-network-design-example.pngの説明が続きます
図vcn-network-design-example.pngの説明

ヒント :

開始点として使用する特定のデプロイメントの関連参照アーキテクチャを検索します。たとえば、Oracleには、Oracle E-Business Suite、Siebel、Oracle Architecture Center上のExaCSなど、一般的なOracle OCIデプロイメント用の多くのリファレンス・アーキテクチャがあります。

ハブ・アンド・スポークVCN設計の検討

ほとんどのOCIデプロイメントに対するOracleのベスト・プラクティスと推奨事項は、接続にDRGを使用するハブアンドスポーク・トポロジで複数のVCN設計を使用することです。

DRGを使用した複数のVCNハブ・アンド・スポーク設計の利点は次のとおりです。

  • 異なる環境を分離してセグメント化します。
  • ログ・サーバー、DNS、ファイル共有など、すべてのスポークVCNが共有できるハブVCN内の共通サービスを提供します。
  • DRGで最大300個のVCNに接続できるため、ネットワーキングを簡単にスケーリングできます。ハブ・アンド・スポーク型のVCN設計ができたら、VCNを簡単に追加できます。
  • ファイアウォールなどのネットワーク・セキュリティ・アプライアンスをハブVCNに配置して、スポークVCNとの間で送受信されるトラフィックを検査します。

次の図は、ハブアンドスポーク・ネットワーク・アーキテクチャの使用例を示しています。


hub-and-spoke-topology.pngの説明が続きます
図hub-and-spoke-topology.pngの説明

Oracleでは、次のことを推奨しています。

  • 異なるネットワーク環境をセグメント化する方法と場所を決定し、それぞれを独自のVCNに配置することを検討してください。次に、環境に個別のSCNを使用するための一般的な顧客の例を示します。
    • 本番環境と非本番環境
    • 内部または外部顧客
  • 概念実証(POC)などの非常にシンプルまたは小規模なOCIデプロイメントがあり、ここで説明するメリットが不要な場合は、単一のVCNを使用することをお薦めします。単一のVCNを使用しても、将来はいつでも環境を別のVCNに配置して、これらの推奨事項を利用できます。

標準OCIネーミング規則の使用

OCIで必要なネットワーク・リソース(VCN、サブネット、セキュリティ・リスト、Dynamic Routing Gateways (DRG)など)をプロビジョニングする場合、リソース名の入力を求められます。OCIリソースに標準ネーミング規則を使用すると、他のOCIユーザーがリソースの目的と場所を理解しやすくなり、リソースが他のユーザーとどのように区別されるかも示されます。

これらのリソース名の一部は後で変更できますが、DNSラベルなどは変更できません。VCN名などの他のものは、コマンドライン・インタフェース(CLI)を使用して変更する必要があります。

Oracleでは、次のことを推奨しています。

  1. リソースの目的を記述するには、名前のどこかに記述的な頭字語を使用します。たとえば次のようにします。
    • VCN名のどこかにあるVCN (VCN名: VCN-prod-ashburn)
    • DRG名の任意の場所にあるDRG (DRG名: DRG-ashburn)
    • sl (セキュリティ・リスト名: web-sn-sl)
  2. OCIネットワークリソース命名規則が、全体的なOCIリソース命名規則の一部であることを確認します。
  3. タグを使用してメタデータ情報をリソースに追加することを検討してください。

OCIプライベートDNSによるハイブリッドDNSの設計

OCIのデフォルトの動作は、デフォルト・ドメインとしてoraclevcn.comを使用してVCNに対して内部DNS解決を実行することに制限されています。他のVCNまたはオンプレミス環境のリソースのDNS名は解決できないため、後で接続の問題が発生する可能性があります。

OCIプライベートDNSサービスは、OCIとオンプレミス・インフラストラクチャ間でDNSをシームレスに解決する機能を提供します。

  • VCN内でカスタムDNSドメインおよびレコードを作成および保守します(oci.customer.comなど)。
  • VCN全体でのDNS解決とオンプレミスDNS、およびCSPや信頼できるパートナDNSなどのその他の環境を統合します。

Oracleでは、次のことを推奨しています。

  • 初期のネットワーク設計の一部としてDNSを含めて、DNS管理者が関与します。
  • シームレスなDNS名解決(オンプレミス環境、OCI VCN、その他のCSPなど)が必要なすべての環境を検討し、OCIプライベートDNSを使用してハイブリッドDNSソリューションを有効にします。
  • 注意事項を早期に検討し、続行する方向を決定します。デフォルトのoraclevcn.comドメイン名を使用するか、カスタム・ドメイン名を使用するかを決定します。

次の図は、カスタム・ドメイン名を持つローカル内部リソースを解決するためにプライベートDNSリゾルバを使用するカスタム・ドメイン名を含むアーキテクチャの例を示しています:

architecture-deploy-private-dns.pngの説明が続きます
図architecture-deploy-private-dns.pngの説明

ヒント :

カスタムOCIドメイン名を使用する場合、カスタム・ゾーンおよびレコードの管理は手動で行います。デフォルトのoraclevcn.comは自動です。

プロビジョニング前のサブネット・タイプの決定

リソースを編成するには、VCN CIDRを1つ以上のサブネットに分割する必要があります。サブネットは、リージョナル・サブネットまたはアベイラビリティ・ドメイン(AD)固有のサブネットのいずれかであり、パブリック・サブネットまたはプライベート・サブネットでもあります。

リージョナル・サブネットとAD固有のサブネット、およびパブリック・サブネットとプライベート・サブネットに関する決定は、後で変更できません。混乱と複雑さを後から最小限に抑えるために、最初にプロビジョニングするときに正しいことを確認します。

Oracleでは、次のことを推奨しています。

  • パブリック・サブネットまたはプライベート・サブネットを作成する前に必要かどうかを確認します。潜在的なトラフィック・フローと、トラフィックのソースまたは宛先を検討します。
  • パブリック・サブネット内のインバウンド・インターネット接続およびプライベート・サブネット内の他のすべてのリソースに特定の要件があるリソースを配置します。
  • AD固有のサブネットの使用を必要とする特定の要件がないかぎり、リージョナル・サブネットをプロビジョニングします。

ヒント :

後で変更を行うには、サブネットを終了してから再プロビジョニングする必要があります。また、サブネットにデプロイされているリソースを終了してから、新しいサブネットのリソースを再プロビジョニングする必要があります。

サブネットの設計およびサイズ設定

現在および将来の要件を満たすようにサブネットを設計およびサイズ設定します。設計中にSCNおよびサブネットを適切にサイズ設定すると、次の作業に役立ちます。

  • 将来の成長と拡大に備える
  • 連続的で要約可能なIPアドレス空間を使用して、IP割当てを簡素化します。

Oracleでは、次のことを推奨しています。

  • VCNを作成する前に、必要なCIDRブロックの数を決定し、VCNにデプロイする予定のリソースおよびサブネットの数に基づいて各ブロックのサイズを決定します。
  • サブネットとVCN内で、ある程度の将来的な拡張ができるようにしてください。
  • より小さいCIDRを作成する方が望ましいです。
  • VCNに最大5つのCIDRを追加できますが、成長に対応するためにさらに後で追加すると、IPアドレスの割当てに応じて連続しないCIDRになる場合があります。
    • たとえば、ワークロードのテストを開始するために、10.0.0.0/24をVCNに割り当てました。テストに成功した後、ワークロードをさらに多くのVMに拡張する場合は、より多くのIPおよびサブネットが必要です。ただし、次のIPブロック10.0.1.0/24は、別の目的でIPアドレス・ツールに割り当てられました。その結果、連続していないCIDRをVCNに追加することが強制されます。
  • 可能な場合は、標準のRFC 1918プライベートIPアドレス領域内にあるCIDRブロックを使用します。
  • 169.254.0.0/16 IPアドレス空間は使用しないでください。Oracleを含む多くのプロバイダは、ネットワーク内で同じIP領域を使用し、問題が発生する可能性があります。
  • 他のネットワーク(OCI、オンプレミス・データ・センターまたは別のCSP)と重複しない一意のCIDRブロックを選択します。
  • サブネットを設計するときには、トラフィック・フローおよびセキュリティ要件を考慮してください。特定の層またはロール内のすべてのリソースを同じサブネットにアタッチします。

サブネットごとにカスタム・ルート表およびセキュリティ・リストを使用

サブネットをプロビジョニングするときに、各サブネットで使用するVCNルート表およびセキュリティ・リストを選択するように求められます。

OCIには、デフォルト・ルート表とデフォルト・セキュリティ・リストが用意されており、使用すると、それらに関連付けられているすべてのサブネットと共有されます。これらのデフォルト・オプションの使用は、単純なデプロイメントや開始には適していますが、複数のサブネットを含む本番設計の推奨アプローチには適していません。各サブネットに固有のVCNルート表およびセキュリティ・リストを使用すると、これらのリソースを共有するのではなく、個々のサブネットへの詳細なルーティングおよびセキュリティ制御を維持できます。

たとえば次のようにします。

  • プライベート・サブネットにNATゲートウェイへのデフォルト・ルートがあり、パブリック・サブネットに、個別のVCNルート表が必要となるインターネット・ゲートウェイへのデフォルト・ルートがある場合があります。
  • 1つのサブネットに対して特定のトラフィック・フローを許可するが、別のサブネットには許可しない場合があり、個別のセキュリティ・リストが必要になります。

Oracleでは、次のことを推奨しています。

  • サブネットごとに一意のVCNルート表を作成して関連付けます
  • サブネットごとに一意のセキュリティ・リストを作成して関連付けます

ヒント :

これらの一意のVCNルート表およびセキュリティ・リストをプロビジョニングするときに作成および関連付けます。後でデフォルトからの変更はより困難になるためです。