ノート:

Oracle Cloud InfrastructureのBIND9ドメイン・ネーム・システムでの高可用性の実装

イントロダクション

OraStageは、再生可能エネルギー・ソリューションと革新的な電力技術を専門とするエネルギー部門のリーディング・カンパニーであり、パフォーマンス、スケーラビリティ、セキュリティを強化するためにワークロードをOracle Cloud Infrastructure(OCI)に移行するという戦略的な決定を発表しました。

イメージ

OraStageが説明した特定のニーズと条件を考慮して、同社はハイブリッド・ドメイン・ネーム・システム(DNS)を必要としています。クラウドでのソリューション、およびハイブリッドでは、OCI DNSサービスに加えて、独自のBerkeley Internet Name Domainバージョン9 (BIND9) DNSシステムを使用することを意味します。ここでは、構築しようとしている最終的なアーキテクチャを次のイメージに示します。

イメージ

OraStage DNSの要件:

このチュートリアルシリーズは、上記の概説された要件を達成するためにステップバイステップをガイドし、最初からソリューション全体を構築します。次のリストから各チュートリアルに簡単にナビゲートできます。

概要

現在、信頼性が高く効率的なDNSインフラストラクチャは、シームレスなネットワーク運用を確保するために重要です。最初のチュートリアル: Oracle Cloud InfrastructureでのBIND9ドメイン・ネーム・システムの構成では、DNSサービスを管理するための堅牢な機能と柔軟性を提供する、最も広く使用されているDNSソフトウェアの1つであるBIND9をOCIでデプロイおよび使用する方法をすでに説明しました。単一のBIND9サーバーはDNSリクエストを効果的に処理できますが、2番目のBIND9サーバーを追加すると、ネットワーク全体のパフォーマンスと信頼性を向上させる多くの利点があります。

このチュートリアルでは、OCIでセカンダリBIND9サーバーとロード・バランサを設定するプロセスを順を追って説明し、この構成の利点について説明します。これを実装すると、次のことが実現します。

OCIネットワーク・ロード・バランサ

OCI Flexible Network Load Balancer (NLB)は、受信トラフィックを複数のバックエンド・リソースに分散するのに役立つサービスです。これは、大量のトラフィックを管理し、1つ以上のサーバーに障害が発生してもアプリケーションが使用可能で応答性を維持するために特に役立ちます。

OCI Network Load Balancerは、オープン・システム相互接続(OSI)モデルのレイヤー3およびレイヤー4で動作し、Transmission Control Protocol (TCP)、ユーザー・データグラム・プロトコル(UDP)、Internet Control Message Protocol (ICMP)などのプロトコルを処理します。負荷を効率的に分散することで、アプリケーションのパフォーマンスを向上させ、高可用性を実現し、システムの全体的なスケーラビリティを向上させることができます。このサービスには、バックエンド・サーバーのステータスを監視するためのヘルス・チェックなどの機能もあり、トラフィックが正常なインスタンスと運用インスタンスにのみ転送されるようにします。

要約すると、OCIネットワーク・ロード・バランサは、ネットワーク・トラフィックを複数のリソースにインテリジェントに分散することで、アプリケーションの信頼性とスケーラビリティを維持する上で重要な役割を果たします。前述のすべての利点により、DNSソリューションを最適化するためのネットワーク・ロード・バランサをセットアップに追加することにしました。

目的

最終的なアーキテクチャ

イメージ

前提条件

タスク1: セカンダリDNSインスタンスのプロビジョニングおよびBIND9の構成

最初のチュートリアル: Oracle Cloud InfrastructureでのBIND9ドメイン・ネーム・システムの構成(タスク2およびタスク3はプライマリ-DNSインスタンスの作成と構成を示します)を参照してください。セカンダリ-DNSを構成するには同じタスクを実行する必要があります。次の情報を考慮してください:

このタスクの最後に、アーキテクチャは次のようになります。

イメージ

タスク2: OCIネットワーク・ロード・バランサの構成

タスク2.1: 詳細の追加

タスク2.2: リスナーの構成

リスナーは、特定のポート(TCP/ポート80、UDP/ポート21など)を使用して特定のタイプのトラフィックを受信し、バックエンド・サーバーに転送するロード・バランサに不可欠なコンポーネントです。このチュートリアルでは、DNSが両方を使用するため、リスナーがポート53 (TCP)および(UDP)でリスニングするようにします。

タスク2.3: バックエンド・セットの選択

バックエンド・セットは、ネットワーク・ロード・バランサがトラフィックをルーティングするバックエンド・サーバーの論理グループです。ここでのバックエンド・サーバーは、プライマリ-DNSおよびセカンダリ-DNSになります。

タスク2.4: 確認と作成

タスク2.5: セキュリティ・ルールの追加

ヘルス・チェックの失敗を回避し、トラフィックを中断することなく円滑な通信を確保するため。

タスク3: OCI DNS転送ルールの構成

タスク3.1: フロントエンドVCN転送ルールの構成

タスク3.2: バックエンドVCN転送ルールの構成

タスク4: テストと検証

前提条件

これで、このサブネットのすべてのイングレスおよびエグレス・トラフィックがログに記録されます。

テスト・シナリオ1: セカンダリDNSが停止している場合、プライマリ-DNSがFE-VM問合せに応答します

セカンダリDNSで障害が発生した場合は、DNS-NLBがトラフィックを転送しているため、プライマリDNSがFE-VMからの問合せに応答することを確認する必要があります。

テスト・シナリオ2: プライマリDNSが停止すると、セカンダリDNSがFE-VM問合せに応答します

プライマリ-DNSで障害が発生した場合は、DNS-NLBがトラフィックを転送しているため、セカンダリ-DNSがFE-VMからの問合せに応答することを確認する必要があります。

テスト・シナリオ3: セカンダリDNSが停止しているときにプライマリ-DNSがBE-VM問合せに応答する

セカンダリDNSで障害が発生した場合は、DNS-NLBがトラフィックを転送しているため、プライマリDNSがBE-VMからの問合せに応答することを確認する必要があります。

テスト・シナリオ4: プライマリDNSが停止すると、セカンダリDNSがBE-VM問合せに応答します

プライマリ-DNSで障害が発生した場合、セカンダリ-DNSがBE-VMからの問合せに応答することを確認する必要があります。これは、DNS-NLBがトラフィックを転送しているためです。

次のステップ

このチュートリアルでは、OCIネットワーク・ロード・バランサとセカンダリDNSサーバーを統合して、OCIで設定された単純なクライアント・サーバーBIND9 DNSを強化し、プライマリ・サーバーに障害が発生した場合の継続的なサービスの可用性を確保します。

これまで、orastage.comドメイン問合せを処理するための高パフォーマンスで信頼性の高いDNSアーキテクチャを開発しました。ただし、OraStage会社には、oraclevcn.comやoraclecloud.comなどのOCIネイティブ・ドメイン名も解決する必要があり、そのために追加のステップが必要です。次のチュートリアルのOCI DNSを使用したネイティブ・ドメインの解決では、この構成を実現する方法を説明します。

承認

その他の学習リソース

docs.oracle.com/learnの他のラボを確認するか、Oracle Learning YouTubeチャネルで無料のラーニング・コンテンツにアクセスしてください。また、education.oracle.com/learning-explorerにアクセスしてOracle Learning Explorerになります。

製品ドキュメントについては、Oracle Help Centerを参照してください。