Hinweis:

• Dieses Tutorial erfordert Zugriff auf Oracle Cloud. Informationen zur Registrierung für einen kostenlosen Account finden Sie unter Erste Schritte mit Oracle Cloud Infrastructure Free Tier.
• Es verwendet Beispielwerte für Oracle Cloud Infrastructure-Zugangsdaten, -Mandanten und -Compartments. Ersetzen Sie diese Werte nach Abschluss der Übung durch Werte, die für Ihre Cloud-Umgebung spezifisch sind.

High Availability auf Domain Name System BIND9 in Oracle Cloud Infrastructure implementieren

Einführung

OraStage ist ein führendes Unternehmen im Energiesektor, das sich auf Lösungen für erneuerbare Energien und innovative Energietechnologien spezialisiert hat. Das Unternehmen kündigte eine strategische Entscheidung an, seine Workloads auf Oracle Cloud Infrastructure (OCI) zu migrieren, um Performance, Skalierbarkeit und Sicherheit zu verbessern.

Unter Berücksichtigung der spezifischen Anforderungen und Bedingungen, die OraStage dargelegt hat, benötigt das Unternehmen ein hybrides Domain Name System (DNS). Lösung in der Cloud, und hier durch Hybrid bedeutet, ihr eigenes Berkeley Internet Name Domain Version 9 (BIND9) DNS-System zusätzlich zum OCI DNS-Service zu verwenden, wobei die endgültige Architektur, die sie erstellen möchten, in der folgenden Abbildung dargestellt wird.

OraStage DNS-Anforderungen:

• Das Unternehmen verfügt über mehrere interne Domains und Subdomains. Alle müssen mit ihrem BIND9-DNS in OCI aufgelöst werden. Dabei verwaltet OraStage alle zugehörigen Zonen und Datensätze. Eine dieser Domains ist orastage.com, die wir in diesem Tutorial verwenden werden. Daher muss jede Abfrage an orastage.com an ihre BIND9 weitergeleitet werden.

• In einigen Fällen müssen sie OCI-native Domains (oraclevcn.com, oraclecloud.com usw.) dennoch auflösen. Dazu werden private OCI-DNS-Komponenten verwendet: private Ansichten, Weiterleitung von Endpunkten und Regeln sowie Listening-Endpunkte.

• Alle Abfragen müssen von einer pfSense-Firewallinstanz geprüft werden.

• Um Single Point of Failure zu vermeiden, plant OraStage, einen anderen DNS-Server zu verwenden und den OCI Load Balancer zu nutzen, um Abfragen zwischen primärem und sekundärem DNS zu verteilen.

Diese Tutorial-Serie wird Sie Schritt für Schritt führen, um die oben beschriebenen Anforderungen zu erfüllen und die gesamte Lösung von Grund auf neu zu erstellen. Sie können einfach zu jedem Tutorial aus der folgenden Liste navigieren:

• Tutorial 1: DNS BIND9 in OCI konfigurieren. Erfahren Sie, wie Sie BIND9 auf einer Compute-Instanz installieren und konfigurieren, sodass es zum lokalen DNS-Server für zwei Testumgebungen in OCI wird. Diese Umgebungen bestehen aus "Frontend"- und "Backend"-Servern, die jeweils in einem separaten Spoke-Netzwerk gehostet werden. Der BIND9-Server verarbeitet alle DNS-Abfragen, die an orastage.com weitergeleitet werden.

• Tutorial 2: High Availability für das DNS-Szenario BIND9 in OCI implementieren. Dieses Tutorial konzentriert sich auf das Hinzufügen eines sekundären BIND9-Servers und das Konfigurieren eines Network Load Balancers (NLB), um DNS-Traffic zwischen beiden Servern zu verteilen. DNS-Abfragen an orastage.com werden an die NLB-IP weitergeleitet, mit der die Last zwischen dem primären und dem sekundären BIND9-Server ausgeglichen wird. Wenn ein Server nicht mehr verfügbar ist, wird die DNS-Auflösung ohne Serviceunterbrechung fortgesetzt.

• Tutorial 3: Native Domains mit OCI-DNS auflösen. Konzentrieren Sie sich nur auf einen bestimmten Anwendungsfall, in dem wir native DNS-Komponenten in OCI verwenden, falls native Domains wie oraclevcn.com und oraclecloud.com aufgelöst werden müssen. BIND9 DNS wird in diesem Tutorial nicht verwendet.

• Tutorial 4: Sicherheit mit der pfSense-Firewall zur DNS-Architektur hinzufügen. Konzentrieren Sie sich auf die Installation einer pfSense-Firewall im Hub-VCN in OCI, und führen Sie die erforderliche Netzwerkkonfiguration aus, um den gesamten Ost-West-Traffic einschließlich DNS-Abfragen (in den letzten Tutorials ausgeführt) über die zu prüfende Firewall weiterzuleiten.

Überblick

Heute ist eine zuverlässige und effiziente DNS-Infrastruktur entscheidend für einen nahtlosen Netzwerkbetrieb. Im ersten Tutorial: Domainnamensystem BIND9 in Oracle Cloud Infrastructure konfigurieren wurde bereits erläutert, wie BIND9, eine der am häufigsten verwendeten DNS-Software, die robuste Features und Flexibilität zur Verwaltung von DNS-Services bietet, in OCI bereitgestellt und verwendet werden kann. Während ein einzelner BIND9-Server DNS-Anforderungen effektiv verarbeiten kann, bietet das Hinzufügen eines zweiten BIND9-Servers zahlreiche Vorteile, die die allgemeine Performance und Zuverlässigkeit Ihres Netzwerks verbessern.

In diesem Tutorial erfahren Sie, wie Sie einen sekundären BIND9-Server und einen Load Balancer in OCI einrichten. Dabei werden die Vorteile dieser Konfiguration hervorgehoben. Indem Sie dies umsetzen, werden Sie erreichen:

• Redundanz: Gewährleistung der kontinuierlichen Verfügbarkeit von DNS-Services, auch wenn der primäre Server ausfällt.

• Load Balancing: Verteilung der DNS-Abfragelast zwischen Servern, Verbesserung der Antwortzeiten und Reduzierung des Überlastungsrisikos.

• Geografische Verteilung: Bei Bedarf kann das Platzieren von DNS-Servern an verschiedenen Standorten schnellere Reaktionszeiten für globale Benutzer ermöglichen.

• Verbesserte Sicherheit: Risiken mindern, indem DNS-Services auf mehreren Servern getrennt und gesichert werden.

OCI Network Load Balancer

Ein OCI Flexible Network Load Balancer (NLB) ist ein Service, mit dem eingehender Traffic auf mehrere Backend-Ressourcen verteilt werden kann. Dies ist besonders nützlich, um hohe Trafficmengen zu verwalten und sicherzustellen, dass Anwendungen auch dann verfügbar und reaktionsschnell bleiben, wenn ein oder mehrere Server ausfallen.

Der OCI Network Load Balancer wird auf Layer 3 und Layer 4 des Open Systems Interconnection-(OSI-)Modells ausgeführt und verarbeitet Protokolle wie Transmission Control Protocol (TCP), User Datagram Protocol (UDP) und Internet Control Message Protocol (ICMP). Durch eine effiziente Lastverteilung kann die Anwendungsperformance verbessert, High Availability bereitgestellt und die Gesamtskalierbarkeit des Systems verbessert werden. Der Service bietet auch Features wie Health Checks zur Überwachung des Status von Backend-Servern, um sicherzustellen, dass Traffic nur an fehlerfreie und betriebliche Instanzen geleitet wird.

Zusammenfassend spielt ein OCI Network Load Balancer eine wichtige Rolle bei der Aufrechterhaltung der Zuverlässigkeit und Skalierbarkeit von Anwendungen, indem er den Netzwerktraffic intelligent auf mehrere Ressourcen verteilt. Aufgrund aller Vorteile, die wir erwähnt haben, werden wir einen Network Load Balancer zu unserem Setup hinzufügen, um unsere DNS-Lösung zu optimieren.

Ziele

• Stellen Sie OCI Network Load Balancer und einen sekundären BIND9-Server in OCI bereit, der nahtlos in Ihr Netzwerk integriert ist und eine robuste und resiliente DNS-Infrastruktur gewährleistet.

• Das primäre Ziel dieses Tutorials besteht darin, den FE-VM-Client (fe.orastage.com) für die Abfrage von BE-VM (be.orastage.com) und umgekehrt zu aktivieren, wobei DNS-NLB Clientanforderungen zwischen Primary-DNS (primary-dns.orastage.com) und Secondary-DNS (secondary-dns.orastage.com) verteilt, um alle Abfragen zu beantworten.

Abschlussarchitektur

Voraussetzungen

• Zugriff auf einen OCI-Mandanten und Berechtigungen zum Verwalten der erforderlichen Netzwerk- und Compute-Services.

• Grundlegendes Verständnis von OCI-Netzwerkrouting und -sicherheit und ihren Funktionen: Virtuelles Cloud-Netzwerk (VCN), Routentabelle, dynamisches Routinggateway (DRG), Sicherheitsliste, Bastion und OCI Network Load Balancer.

• Grundlegendes Verständnis des OCI Logging-Service.

• Grundlegendes Verständnis von Ubuntu Linux und DNS im Allgemeinen.

• Stellen Sie sicher, dass Sie das erste Tutorial abschließen: Domainnamensystem BIND9 in Oracle Cloud Infrastructure konfigurieren, in dem Sie die folgende Architektur bereits erstellt haben sollten.

  

Aufgabe 1: Sekundär-DNS-Instanz bereitstellen und BIND9 konfigurieren

Im ersten Tutorial finden Sie Folgendes: Domainnamensystem BIND9 in Oracle Cloud Infrastructure konfigurieren. In Aufgabe 2 und Aufgabe 3 wird die Erstellung und Konfiguration der Primary-DNS-Instanz angezeigt. Dieselben Aufgaben müssen ausgeführt werden, um Secondary-DNS zu konfigurieren. Beachten Sie die folgenden Informationen:

• Der Instanzname lautet Sekundär-DNS.

• Er befindet sich im selben Subnetz wie der Primary-DNS, und ihm muss eine IP-Adresse von 10.0.0.20 zugewiesen werden.

• Während des Konfigurationsprozesses muss Primary-DNS 10.0.0.10 bei jeder Erwähnung durch Sekundär-DNS 10.0.0.20 ersetzt werden. Ein Beispiel ist der FQDN für diese Instanz: secondary-dns.orastage.com.

• Verwenden Sie denselben SSH-Schlüssel.

• Mit derselben OCI-Bastion, die für den Zugriff auf Primär-DNS verwendet wird, kann auch auf das Sekundär-DNS zugegriffen werden, jedoch mit einer neuen Session.

• Stellen Sie in der Datei /var/lib/bind/db.orastage.com für primäre und sekundäre Instanzen sicher, dass alle folgenden Datensätze vorhanden sind, damit beide DNS-Server sich zusätzlich zu den FE-VM- und BE-VM-Instanzen gegenseitig auflösen können.

  primary-dns                 IN  A       10.0.0.10
  secondary-dns               IN  A       10.0.0.20
  fe                          IN  A       10.1.0.5
  be                          IN  A       10.2.0.5
  

Am Ende dieser Aufgabe sollte die Architektur wie folgt aussehen:

Aufgabe 2: OCI Network Load Balancer konfigurieren

Aufgabe 2.1: Details hinzufügen

• Klicken Sie in der oberen linken Ecke auf das Hamburger-Menü (≡).

  

  1. Klicken Sie auf Networking.
  2. Klicken Sie auf Network Load Balancer.

  

• Klicken Sie auf Network Load Balancer erstellen.

  

  1. Load-Balancer-Name: Geben Sie einen Namen ein.
  2. Sichtbarkeitstyp auswählen: Wählen Sie Privat aus.
  3. Networking auswählen: Wählen Sie DNS-VCN und das zugehörige private Subnetz aus, in dem der Network Load Balancer abgelegt werden soll.
  4. Klicken Sie anschließend auf Weiter.

  

  

Aufgabe 2.2: Listener konfigurieren

Ein Listener ist eine wesentliche Komponente in einem Load Balancer, die für den Empfang eines bestimmten Traffictyps mit bestimmten Ports (z.B. TCP/Port 80, UDP/Port 21) verantwortlich ist und ihn an Backend-Server weiterleitet. In diesem Tutorial soll der Listener auf Port 53 (TCP) und (UDP) horchen, da beide von DNS verwendet werden.

• Geben Sie folgende Informationen ein.

  1. Listener-Name: Geben Sie einen Namen ein.
  2. Vom Listener verarbeiteten Traffictyp angeben: Wählen Sie UDP/TCP aus.
  3. Port angeben: Geben Sie die Portnummer 53 ein.
  4. Klicken Sie anschließend auf Weiter.

  

Aufgabe 2.3: Backend-Set auswählen

Ein Backend-Set ist eine logische Gruppierung von Backend-Servern, an die der Network Load Balancer Traffic weiterleitet. Unsere Backend-Server sind Primär-DNS und Sekundär-DNS.

• Geben Sie folgende Informationen ein.

  1. Backend-Setname: Geben Sie einen Namen für das Backend-Set ein.
  2. Klicken Sie auf Backends hinzufügen.
  3. Backend-Typ: Wählen Sie Compute-Instanzen aus.
  4. Backend für IPv4-Compute-Instanzen: Wählen Sie beide DNS-Server aus: Primär-DNS und Sekundär-DNS.
  5. Klicken Sie auf Backends hinzufügen.
  6. Sie können sehen, dass die Backend-Server zum Set hinzugefügt wurden.
  7. Health Check Policy angeben: Mit einer Health Check Policy wird die Verfügbarkeit von Backend-Servern geprüft, indem Anforderungen gestellt oder Verbindungen versucht werden. Der Network Load Balancer führt diese Health Checks in angegebenen regelmäßigen Intervallen aus und verwendet diese Policy, um den Status der Backend-Server kontinuierlich zu überwachen.
  8. Klicken Sie anschließend auf Weiter.

  

  

  

  

Aufgabe 2.4: Prüfen und erstellen

• Prüfen Sie alle Details, und klicken Sie auf Network Load Balancer erstellen.

  

• DNS-NLB wird erstellt. Notieren Sie sich die private IP-Adresse, wie sie in Aufgabe 3 verwendet wird.

  

Aufgabe 2.5: Sicherheitsregel hinzufügen

Um den Ausfall des Health Checks zu vermeiden und eine reibungslose Kommunikation ohne Verkehrsstörungen sicherzustellen.

• Fügen Sie die folgenden Regeln in die Sicherheitsliste DNS-Private-Subnetz ein. Dadurch wird DNS-Traffic ermöglicht, der vom Network Load Balancer an seine Backends gesendet wird.

  

• Die Architektur sollte wie in der folgenden Abbildung dargestellt aussehen.

  

Aufgabe 3: OCI-DNS-Weiterleitungsregeln konfigurieren

Aufgabe 3.1: Frontend-VCN-Weiterleitungsregel konfigurieren

• Klicken Sie in der oberen linken Ecke auf das Hamburger-Menü (≡).

  

  1. Klicken Sie auf Networking.
  2. Klicken Sie auf Virtual Cloud Networks.

  

• Klicken Sie auf Frontend-VCN.

  

• Klicken Sie auf DNS-Resolver des VCN.

  

• Bildlauf nach unten

  1. Klicken Sie auf Regeln.
  2. Klicken Sie auf Regeln verwalten.
  3. Ändern Sie die Ziel-IP-Adresse von der IP-Adresse Primär-DNS in die IP-Adresse DNS-NLB (10.0.0.110), die in Aufgabe 2 erstellt wurde.
  4. Klicken Sie auf Änderungen speichern.
  5. Ziel-IP-Adresse wurde erfolgreich geändert. Alle Abfragen von FE-VM werden also an die IP-Adresse DNS-NLB weitergeleitet, die sie zwischen primären und sekundären DNS-Servern verteilt.

  

  

  

Aufgabe 3.2: Backend-VCN-Weiterleitungsregel konfigurieren

• Klicken Sie in der oberen linken Ecke auf das Hamburger-Menü (≡).

  

  1. Klicken Sie auf Networking.
  2. Klicken Sie auf Virtual Cloud Networks.

  

• Klicken Sie auf Backend-VCN.

  

• Klicken Sie auf DNS-Resolver des VCN.

  

• Bildlauf nach unten.

  1. Klicken Sie auf Regeln.
  2. Klicken Sie auf Regeln verwalten.
  3. Ändern Sie die Ziel-IP-Adresse von der IP-Adresse Primär-DNS in die IP-Adresse DNS-NLB (10.0.0.110), die in Aufgabe 2 erstellt wurde.
  4. Klicken Sie auf Änderungen speichern.
  5. Ziel-IP-Adresse wurde erfolgreich geändert. Alle Abfragen von BE-VM werden also an die IP-Adresse DNS-NLB weitergeleitet, die sie zwischen primären und sekundären DNS-Servern verteilt.

  

  

  

Aufgabe 4: Testen und validieren

Voraussetzung

• Logs aktivieren: Um den Trafficfluss zu prüfen, aktivieren wir Subnetzflusslogs, mit denen wir den Netzwerkverkehr überwachen und verfolgen können, der in ein bestimmtes Subnetz eintritt oder dieses verlässt. In diesen Logs werden Details zum Netzwerkverkehr erfasst, wie Quell- und Ziel-IP-Adressen, Portnummern und die übertragene Datenmenge. So aktivieren Sie das Log:

  1. Gehen Sie zum privaten Subnetz DNS-VCN, in dem sich Primär-DNS, Sekundär-DNS und DNS-NLB befinden.
  2. Klicken Sie auf Logs.
  3. Wählen Sie Log aktivieren.

  

  Weitere Informationen zu Logs und deren Verwendung in OCI finden Sie unter

  • VCN-Flowlogs.
  • Details zu VCN-Flowlogs - Erfahren Sie, wie Sie den Inhalt des Logs lesen.
  • Folgen Sie den Paketen in einer Hub- und Spoke-VCN-Routingarchitektur in OCI - Ein nützliches Tutorial zum Verfolgen von Netzwerkpaketen in einer OCI-Umgebung mit mehreren Methoden, wie der Erfassung von Firewallpaketen, Subnetzlogs und TCPdump. Führen Sie die Schritte 6 und 13 aus.
    • Aufgabe 6: Logging (alle Logs) im privaten Spoke-Subnetz aktivieren.
    • Aufgabe 13: Prüfen Sie alle Protokollierungspunkte und Paketerfassungen, und folgen Sie dem Pfad - Protokollierungspunkt B.

Jetzt wird der gesamte Ingress- und Egress-Traffic für dieses Subnetz protokolliert.

Testszenario 1: Primär-DNS antwortet auf FE-VM-Abfragen, wenn Sekundär-DNS heruntergefahren ist

Bei einem Fehler im Sekundär-DNS müssen wir sicherstellen, dass der Primär-DNS auf Abfragen von FE-VM antwortet, da der DNS-NLB Traffic an ihn leitet.

• Die folgende Abbildung veranschaulicht das Testszenario, das wir erreichen wollen.

  

• Derzeit sind alle Instanzen hochgefahren und gestartet. Fahren Sie zunächst die Sekundär-DNS-Instanz herunter. Klicken Sie in der oberen linken Ecke auf das Hamburger-Menü (≡).

  

  1. Klicken Sie auf Berechnen.
  2. Klicken Sie auf Instanzen.

  

  1. Aktivieren Sie das Kontrollkästchen neben der Instanz.
  2. Klicken Sie auf Aktionen.
  3. Klicken Sie auf Stoppen.
  4. Klicken Sie auf Stoppen.
  5. Die Instanz befindet sich jetzt im Status Gestoppt.

  

  

  

• Greifen Sie auf FE-VM zu, und führen Sie einen Test durch, indem Sie eine Abfrage ausführen. Dazu verwenden wir den OCI Bastion-Service. Klicken Sie in der oberen linken Ecke auf das Hamburger-Menü (≡).

  

  1. Klicken Sie auf Identität und Sicherheit.
  2. Klicken Sie auf Bastion.

  

• Klicken Sie auf FEBastion.

  

• Klicken Sie auf Session erstellen.

  

• Geben Sie folgende Informationen ein.

  1. Sessiontyp: Wählen Sie Verwaltete SSH-Session aus.
  2. Sessionname: Geben Sie einen Namen für die Session ein.
  3. Benutzername: Geben Sie den Benutzernamen ein. Bei Oracle Linux-Instanzen ist der Standardbenutzername opc.
  4. Compute-Instanz: Wählen Sie die FE-VM-Instanz aus.
  5. Fügen Sie denselben Public Key ein, der in Tutorial 1 generiert wurde: Aufgabe 2.1: SSH-Schlüsselpaar generieren.
  6. Klicken Sie auf Session erstellen.

  

  

• Nachdem die Session erstellt wurde, klicken Sie auf die drei Punkte und SSH-Befehl kopieren.

  

  Der Befehl sollte wie folgt aussehen:

  ssh -i <privateKey> -o ProxyCommand="ssh -i <privateKey> -W %h:%p -p 22 ocid1.bastionsession.oc1.eu-mi[e-mail]" -p 22 opc@10.1.0.5
  

• Öffnen Sie OCI Cloud Shell.

  1. Navigieren Sie mit dem Befehl cd .ssh in das Verzeichnis .ssh.
  2. Fügen Sie den SSH-Befehl ein. Stellen Sie sicher, dass Sie <privateKey> durch den Private-Key-Dateinamen id_rsa ersetzen.
  3. Geben Sie Ja ein.

  

• Anmeldung erfolgreich durchgeführt. Führen Sie jetzt eine Testabfrage von FE-VM zu be.orastage.com mit dem Befehl host aus. Prüfen Sie, ob die Abfrage erfolgreich war und eine Antwort empfangen wurde.

  

• Wir wissen, dass es nur einen fehlerfreien Backend-Server für die Verarbeitung der Anforderung gibt, nämlich Primary-DNS. Hier werden wir also den Ablauf der DNS-Abfrage prüfen und sehen, welcher Server diese Abfrage mit OCI-Subnetzlogs beantwortet hat.

  1. Klicken Sie auf das Log.
  2. Die Anforderung ging vom Weiterleitungsendpunkt (10.1.0.6), der sich im selben Subnetz wie FE-VM befindet, an die NLB-IP-Adresse (10.0.0.110) im DNS-VCN.
  3. Anschließend wird die Anforderung von der NLB-IP-Adresse (10.0.0.110) an Primary-DNS (10.0.0.10) gesendet.

  

  

  Test erfolgreich. Primary-DNS konnte DNS-Abfragen verarbeiten, falls Secondary-DNS heruntergefahren war.

Testszenario 2: Sekundär-DNS antwortet auf FE-VM-Abfragen, wenn Primär-DNS heruntergefahren ist

Bei einem Fehler im Primary-DNS müssen wir sicherstellen, dass der Secondary-DNS auf Abfragen von FE-VM antwortet, da der DNS-NLB Traffic an ihn leitet.

• Die folgende Abbildung veranschaulicht das Testszenario, das wir erreichen wollen.

  

• Fahren Sie zunächst die Primary-DNS-Instanz herunter. Klicken Sie in der oberen linken Ecke auf das Hamburger-Menü (≡).

  

  1. Klicken Sie auf Berechnen.
  2. Klicken Sie auf Instanzen.

  

  1. Aktivieren Sie das Kontrollkästchen neben der Instanz.
  2. Klicken Sie auf Aktionen.
  3. Klicken Sie auf Stoppen.
  4. Klicken Sie auf Stoppen.
  5. Die Instanz befindet sich jetzt im Status Gestoppt.

  

  

  

• Starten Sie die Sekundär-DNS-Instanz.

  1. Aktivieren Sie das Kontrollkästchen neben der Instanz.
  2. Klicken Sie auf Aktionen.
  3. Klicken Sie auf Start.
  4. Klicken Sie auf Start.
  5. Die Instanz befindet sich jetzt im Status Wird ausgeführt.

  

  

  

• Als Nächstes greifen wir auf FE-VM zu und führen einen Test durch, indem wir eine Abfrage ausführen. Dazu verwenden wir den OCI Bastion-Service. Klicken Sie in der oberen linken Ecke auf das Hamburger-Menü (≡).

  

  1. Klicken Sie auf Identität und Sicherheit.
  2. Klicken Sie auf Bastion.

  

• Klicken Sie auf FEBastion.

  

• Klicken Sie auf Session erstellen.

  

• Geben Sie folgende Informationen ein.

  1. Sessiontyp: Wählen Sie Verwaltete SSH-Session aus.
  2. Sessionname: Geben Sie einen Namen für die Session ein.
  3. Benutzername: Geben Sie den Benutzernamen ein. Bei Oracle Linux-Instanzen ist der Standardbenutzername opc.
  4. Compute-Instanz: Wählen Sie die FE-VM-Instanz aus.
  5. Fügen Sie denselben Public Key ein, der in Tutorial 1 generiert wurde: Aufgabe 2.1: SSH-Schlüsselpaar generieren.
  6. Klicken Sie auf Session erstellen.

  

  

• Nachdem die Session erstellt wurde, klicken Sie auf die drei Punkte und SSH-Befehl kopieren.

  

  Der Befehl sollte wie folgt aussehen:

  ssh -i <privateKey> -o ProxyCommand="ssh -i <privateKey> -W %h:%p -p 22 ocid1.bastionsession.oc1.eu-milan-[e-mail]" -p 22 opc@10.1.0.5
  

• Öffnen Sie OCI Cloud Shell.

  1. Navigieren Sie mit dem Befehl cd .ssh in das Verzeichnis .ssh.
  2. Fügen Sie den SSH-Befehl ein. Stellen Sie sicher, dass Sie <privateKey> durch den Private-Key-Dateinamen id_rsa ersetzen.
  3. Geben Sie Ja ein.

  

• Anmeldung erfolgreich durchgeführt. Führen Sie jetzt eine Testabfrage von FE-VM zu be.orastage.com mit dem Befehl host aus. Prüfen Sie, ob die Abfrage erfolgreich war und eine Antwort empfangen wurde.

  

• Wir wissen, dass es nur einen fehlerfreien Backend-Server für die Verarbeitung der Anforderung gibt, nämlich Sekundär-DNS. Hier werden wir also den Ablauf der DNS-Abfrage prüfen und sehen, welcher Server diese Abfrage mit OCI-Subnetzlogs beantwortet hat.

  1. Klicken Sie auf das Log.
  2. Die Anforderung ging vom Weiterleitungsendpunkt (10.1.0.6), der sich im selben Subnetz wie FE-VM befindet, an die NLB-IP-Adresse (10.0.0.110) im DNS-VCN.
  3. Anschließend wird die Anforderung von der NLB (10.0.0.110) an Sekundär-DNS (10.0.0.20) gesendet.

  

  

  Test erfolgreich. Sekundär-DNS kann DNS-Abfragen verarbeiten, falls das Primär-DNS heruntergefahren ist.

Testszenario 3: Primär-DNS antwortet auf BE-VM-Abfragen, wenn Sekundär-DNS heruntergefahren ist

Bei einem Fehler im Sekundär-DNS müssen wir sicherstellen, dass der Primär-DNS auf Abfragen von BE-VM antwortet, da der DNS-NLB Traffic an ihn leitet.

• Die folgende Abbildung veranschaulicht das Testszenario, das wir erreichen wollen.

  

• Derzeit sind alle Instanzen hochgefahren und gestartet. Fahren Sie zunächst die Sekundär-DNS-Instanz herunter. Klicken Sie in der oberen linken Ecke auf das Hamburger-Menü (≡).

  

  1. Klicken Sie auf Berechnen.
  2. Klicken Sie auf Instanzen.

  

  1. Aktivieren Sie das Kontrollkästchen neben der Instanz.
  2. Klicken Sie auf Aktionen.
  3. Klicken Sie auf Stoppen.
  4. Klicken Sie auf Stoppen.
  5. Die Instanz befindet sich jetzt im Status Gestoppt.

  

  

  

• Als Nächstes greifen wir auf BE-VM zu und führen einen Test durch, indem wir eine Abfrage ausführen. Dazu verwenden wir den OCI Bastion-Service. Klicken Sie in der oberen linken Ecke auf das Hamburger-Menü (≡).

  

  1. Klicken Sie auf Identität und Sicherheit.
  2. Klicken Sie auf Bastion.

  

• Klicken Sie auf BEBastion.

  

• Klicken Sie auf Session erstellen.

  

• Geben Sie folgende Informationen ein.

  1. Sessiontyp: Wählen Sie Verwaltete SSH-Session aus.
  2. Sessionname: Geben Sie einen Namen für die Session ein.
  3. Benutzername: Geben Sie den Benutzernamen ein. Bei Oracle Linux-Instanzen ist der Standardbenutzername opc.
  4. Compute-Instanz: Wählen Sie die BE-VM-Instanz aus.
  5. Fügen Sie denselben Public Key ein, der in Tutorial 1 generiert wurde: Aufgabe 2.1: SSH-Schlüsselpaar generieren.
  6. Klicken Sie auf Session erstellen.

  

  

• Nachdem die Session erstellt wurde, klicken Sie auf die drei Punkte und SSH-Befehl kopieren.

  

  Der Befehl sollte wie folgt aussehen:

  ssh -i <privateKey> -o ProxyCommand="ssh -i <privateKey> -W %h:%p -p 22 ocid1.bastionsession.oc1.eu-milan-[e-mail]" -p 22 opc@10.2.0.5
  

• Öffnen Sie OCI Cloud Shell.

  1. Navigieren Sie mit dem Befehl cd .ssh in das Verzeichnis .ssh.
  2. Fügen Sie den SSH-Befehl ein. Stellen Sie sicher, dass Sie <privateKey> durch den Private-Key-Dateinamen id_rsa ersetzen.
  3. Geben Sie Ja ein.

  

• Anmeldung erfolgreich durchgeführt. Führen Sie jetzt eine Testabfrage von BE-VM zu fe.orastage.com mit dem Befehl host aus. Prüfen Sie, ob die Abfrage erfolgreich war und eine Antwort empfangen wurde.

  

• Wir wissen, dass es nur einen fehlerfreien Backend-Server für die Verarbeitung der Anforderung gibt, nämlich Primary-DNS. Hier werden wir also den Ablauf der DNS-Abfrage prüfen und sehen, welcher Server diese Abfrage mit OCI-Subnetzlogs beantwortet hat.

  1. Klicken Sie auf das Log.
  2. Die Anforderung ging vom Weiterleitungsendpunkt (10.2.0.6), der sich im selben Subnetz wie BE-VM befindet, an die NLB-IP-Adresse (10.0.0.110) im DNS-VCN.
  3. Anschließend wird die Anforderung von der NLB (10.0.0.110) an Primary-DNS (10.0.0.10) gesendet.

  

  

  Test erfolgreich. Primary-DNS konnte DNS-Abfragen verarbeiten, falls Secondary-DNS heruntergefahren war.

Testszenario 4: Sekundär-DNS antwortet auf BE-VM-Abfragen, wenn Primär-DNS heruntergefahren ist

Im Falle eines Fehlers im Primär-DNS müssen wir sicherstellen, dass der Sekundär-DNS auf Abfragen von BE-VM antwortet, da der DNS-NLB Traffic an ihn leitet.

• Die folgende Abbildung veranschaulicht das Testszenario, das wir erreichen wollen.

  

• Fahren Sie zunächst die Primary-DNS-Instanz herunter. Klicken Sie in der oberen linken Ecke auf das Hamburger-Menü (≡).

  

  1. Klicken Sie auf Berechnen.
  2. Klicken Sie auf Instanzen.

  

  1. Aktivieren Sie das Kontrollkästchen neben der Instanz.
  2. Klicken Sie auf Aktionen.
  3. Klicken Sie auf Stoppen.
  4. Klicken Sie auf Stoppen.
  5. Die Instanz befindet sich jetzt im Status Gestoppt.

  

  

  

• Starten Sie die Sekundär-DNS-Instanz.

  1. Aktivieren Sie das Kontrollkästchen neben der Instanz.
  2. Klicken Sie auf Aktionen.
  3. Klicken Sie auf Start.
  4. Klicken Sie auf Start.
  5. Die Instanz befindet sich jetzt im Status Wird ausgeführt.

  

  

  

• Als Nächstes greifen wir auf BE-VM zu und führen einen Test durch, indem wir eine Abfrage ausführen. Dazu verwenden wir den OCI Bastion-Service. Klicken Sie in der oberen linken Ecke auf das Hamburger-Menü (≡).

  

  1. Klicken Sie auf Identität und Sicherheit.
  2. Klicken Sie auf Bastion.

  

• Klicken Sie auf BEBastion.

  

• Klicken Sie auf Session erstellen.

  

• Geben Sie folgende Informationen ein.

  1. Sessiontyp: Wählen Sie Verwaltete SSH-Session aus.
  2. Sessionname: Geben Sie einen Namen für die Session ein.
  3. Benutzername: Geben Sie den Benutzernamen ein. Bei Oracle Linux-Instanzen ist der Standardbenutzername opc.
  4. Compute-Instanz: Wählen Sie die BE-VM-Instanz aus.
  5. Fügen Sie denselben Public Key ein, der in Tutorial 1 generiert wurde: Aufgabe 2.1: SSH-Schlüsselpaar generieren.
  6. Klicken Sie auf Session erstellen.

  

  

• Nachdem die Session erstellt wurde, klicken Sie auf die drei Punkte und SSH-Befehl kopieren.

  

  Der Befehl sollte wie folgt aussehen:

  ssh -i <privateKey> -o ProxyCommand="ssh -i <privateKey> -W %h:%p -p 22 ocid1.bastionsession.oc1.e[e-mail]" -p 22 opc@10.2.0.5
  

• Öffnen Sie OCI Cloud Shell.

  1. Navigieren Sie mit dem Befehl cd .ssh in das Verzeichnis .ssh.
  2. Fügen Sie den SSH-Befehl ein. Stellen Sie sicher, dass Sie <privateKey> durch den Private-Key-Dateinamen id_rsa ersetzen.
  3. Geben Sie Ja ein.

  

• Anmeldung erfolgreich durchgeführt. Führen Sie jetzt eine Testabfrage von BE-VM zu fe.orastage.com mit dem Befehl host aus. Prüfen Sie, ob die Abfrage erfolgreich war und eine Antwort empfangen wurde.

  

• Wir wissen, dass es nur einen fehlerfreien Backend-Server für die Verarbeitung der Anforderung gibt, nämlich Sekundär-DNS. Hier werden wir also den Ablauf der DNS-Abfrage prüfen und sehen, welcher Server diese Abfrage mit OCI-Subnetzlogs beantwortet hat.

  1. Klicken Sie auf das Log.
  2. Die Anforderung ging vom Weiterleitungsendpunkt (10.2.0.6), der sich im selben Subnetz wie BE-VM befindet, an die NLB-IP-Adresse (10.0.0.110) im DNS-VCN.
  3. Anschließend wird die Anforderung von der NLB (10.0.0.110) an Sekundär-DNS (10.0.0.20) gesendet.

  

  

  Test erfolgreich. Sekundär-DNS konnte DNS-Abfragen verarbeiten, falls Primär-DNS heruntergefahren war.

Nächste Schritte

In diesem Tutorial haben wir ein einfaches DNS-Setup für den Client-Server BIND9 in OCI verbessert, indem wir einen OCI Network Load Balancer und einen sekundären DNS-Server integriert haben, um bei einem Ausfall des primären Servers eine kontinuierliche Serviceverfügbarkeit sicherzustellen.

Bisher haben wir eine leistungsstarke und zuverlässige DNS-Architektur speziell für die Bearbeitung von orastage.com-Domainabfragen entwickelt. Das Unternehmen OraStage muss jedoch auch OCI-native Domainnamen wie oraclevcn.com und oraclecloud.com auflösen. Dazu sind zusätzliche Schritte erforderlich. Im nächsten Tutorial Native Domains mit OCI DNS auflösen wird gezeigt, wie Sie diese Konfiguration erreichen.

Danksagungen

• Autor - Anas abdallah (Cloud Networking Specialist)

Weitere Lernressourcen

Sehen Sie sich andere Übungen zu docs.oracle.com/learn an, oder greifen Sie im Oracle Learning YouTube-Channel auf weitere kostenlose Lerninhalte zu. Besuchen Sie außerdem education.oracle.com/learning-explorer, um Oracle Learning Explorer zu werden.

Die Produktdokumentation finden Sie im Oracle Help Center.

---

Titel und Copyright-Informationen

<

Implement High Availability on BIND9 Domain Name System in Oracle Cloud Infrastructure

G14451-02

Copyright ©2025, Oracle and/or its affiliates.