Nota

Questa esercitazione richiede l'accesso a Oracle Cloud. Per iscriverti a un account gratuito, consulta Inizia a utilizzare Oracle Cloud Infrastructure Free Tier.
Utilizza valori di esempio per le credenziali, la tenancy e i compartimenti di Oracle Cloud Infrastructure. Al termine del laboratorio, sostituisci questi valori con quelli specifici del tuo ambiente cloud.

Implementare High Availability su BIND9 Domain Name System in Oracle Cloud Infrastructure

Introduzione

OraStage è un'azienda leader nel settore energetico, specializzata in soluzioni di energia rinnovabile e tecnologie energetiche innovative, l'azienda ha annunciato una decisione strategica per migrare i propri carichi di lavoro su Oracle Cloud Infrastructure (OCI) per migliorare prestazioni, scalabilità e sicurezza.

immagine

Tenendo conto delle specifiche esigenze e condizioni che OraStage ha delineato, l'azienda richiede un sistema di nomi di dominio ibrido (DNS). La soluzione nel cloud e tramite ibrido qui significa utilizzare il proprio sistema DNS Berkeley Internet Name Domain versione 9 (BIND9) oltre al servizio DNS OCI, dove l'architettura finale che si sta cercando di creare è mostrata nella seguente immagine.

immagine

OraStage Requisiti DNS:

L'azienda ha diversi domini interni e sottodomini, tutti devono essere risolti dal proprio DNS BIND9 in OCI, dove OraStage gestirà tutte le zone e i record correlati. Uno di questi domini è orastage.com che useremo in questo tutorial. Pertanto, qualsiasi query a orastage.com deve essere inoltrata al proprio BIND9.
In alcuni casi devono ancora risolvere i domini nativi OCI (oraclevcn.com, oraclecloud.com e così via) e questa operazione verrà eseguita utilizzando i componenti DNS privati OCI: viste private, endpoint e regole di inoltro e endpoint di ascolto.
Tutte le query devono essere ispezionate da un'istanza del firewall pfSense.
Per evitare un singolo punto di errore, OraStage prevede di utilizzare un altro server DNS e sfruttare il load balancer OCI per distribuire le query tra il DNS primario e quello secondario.

Questa serie di esercitazioni ti guiderà passo dopo passo per raggiungere i requisiti descritti sopra, costruendo l'intera soluzione da zero. È possibile accedere facilmente a ciascun tutorial dall'elenco seguente:

Esercitazione 1: Configura BIND9 DNS in OCI. Scopri come installare e configurare BIND9 su un'istanza di computazione, rendendolo il server DNS locale per due ambienti di test in OCI. Questi ambienti saranno costituiti da server "Frontend" e "Backend", ciascuno ospitato in una rete spoke separata. Il server BIND9 gestirà tutte le query DNS dirette a orastage.com.
Esercitazione 2: Implementa High Availability su BIND9 scenario DNS in OCI. Questa esercitazione si concentra sull'aggiunta di un server BIND9 secondario e sulla configurazione di un load balancer di rete (NLB) per distribuire il traffico DNS tra entrambi i server. Le query DNS su orastage.com verranno indirizzate all'IP NLB, che bilancierà il carico tra i server BIND9 primari e secondari. Se un server non è più disponibile, la risoluzione DNS continuerà senza interruzione del servizio.
Esercitazione 3: Utilizza DNS OCI per risolvere i domini nativi. Concentrandosi solo su uno specifico caso d'uso, in cui utilizziamo componenti DNS nativi in OCI, nel caso in cui sia necessario risolvere domini nativi come oraclevcn.com e oraclecloud.com. BIND9 DNS non viene utilizzato in questa esercitazione.
Esercitazione 4: aggiunta della sicurezza all'architettura DNS mediante il firewall pfSense. Concentrarsi sull'installazione di un firewall pfSense nella VCN hub in OCI ed eseguire la configurazione di rete necessaria per instradare tutto il traffico East-West, incluse le query DNS (eseguite nelle esercitazioni precedenti) attraverso il firewall da ispezionare.

Panoramica

Oggi un'infrastruttura DNS affidabile ed efficiente è fondamentale per garantire operazioni di rete senza interruzioni. Nella prima esercitazione: Configura BIND9 Domain Name System in Oracle Cloud Infrastructure, abbiamo già spiegato come sia possibile distribuire e utilizzare BIND9, uno dei software DNS più utilizzati, che offre funzionalità solide e flessibilità per gestire i servizi DNS in OCI. Mentre un singolo server BIND9 è in grado di gestire le richieste DNS in modo efficace, l'aggiunta di un secondo server BIND9 offre numerosi vantaggi che migliorano le prestazioni complessive e l'affidabilità della rete.

Questa esercitazione descrive il processo di impostazione di un server BIND9 secondario e di un load balancer in OCI, evidenziando i vantaggi di questa configurazione. Implementando questo, si otterrà:

Ridondanza: garantisce la disponibilità continua dei servizi DNS, anche se il server primario non riesce.
Bilanciamento del carico: distribuisci il carico delle query DNS tra i server, migliorando i tempi di risposta e riducendo il rischio di sovraccarico.
Distribuzione geografica: se necessario, posizionare i server DNS in posizioni diverse può fornire tempi di risposta più rapidi per gli utenti globali.
Maggiore sicurezza: ridurre i rischi separando e proteggendo i servizi DNS su più server.

Load balancer di rete OCI

Un load balancer di rete flessibile OCI (NLB, Flexible Network Load Balancer) è un servizio che aiuta a distribuire il traffico in entrata tra più risorse backend. Ciò è particolarmente utile per gestire volumi elevati di traffico e garantire che le applicazioni rimangano disponibili e reattive anche in caso di guasto di uno o più server.

Il load balancer di rete OCI opera ai livelli 3 e 4 del modello OSI (Open Systems Interconnection), gestendo protocolli quali TCP (Transmission Control Protocol), UDP (User Datagram Protocol) e ICMP (Internet Control Message Protocol). Bilanciando il carico in modo efficiente, può migliorare le prestazioni delle applicazioni, fornire alta disponibilità e migliorare la scalabilità complessiva del sistema. Il servizio offre anche funzioni quali i controlli dello stato per monitorare lo stato dei server backend, garantendo che il traffico venga indirizzato solo a istanze integre e operative.

In sintesi, un load balancer di rete OCI svolge un ruolo chiave nel mantenere l'affidabilità e la scalabilità delle applicazioni distribuendo in modo intelligente il traffico di rete su più risorse. A causa di tutti i vantaggi menzionati, aggiungeremo un load balancer di rete alla nostra configurazione per ottimizzare la nostra soluzione DNS.

Obiettivi

Implementa il load balancer di rete OCI e un server BIND9 secondario in OCI perfettamente integrato nella tua rete, garantendo un'infrastruttura DNS solida e resiliente.
L'obiettivo principale di questa esercitazione è consentire al client FE-VM (fe.orastage.com) di eseguire una query su BE-VM (be.orastage.com) e viceversa, con DNS-NLB che distribuisce le richieste del client tra DNS primario (primary-dns.orastage.com) e DNS secondario (secondary-dns.orastage.com) per rispondere a tutte le query.

Architettura finale

immagine

Prerequisiti

Accesso a una tenancy OCI e autorizzazioni per gestire la rete e i servizi di computazione necessari.
Comprensione di base dell'instradamento e della sicurezza della rete OCI e relative funzionalità: rete cloud virtuale (VCN), tabella di instradamento, gateway di instradamento dinamico (DRG), lista di sicurezza, bastion e load balancer di rete OCI.
Comprensione di base del servizio OCI Logging.
Conoscenza di base di Ubuntu Linux e DNS in generale.
Assicurati di completare la prima esercitazione: Configura BIND9 Domain Name System in Oracle Cloud Infrastructure, in cui dovresti aver già creato la seguente architettura.

Task 1: eseguire il provisioning dell'istanza DNS secondaria e configurare BIND9

Fare riferimento alla prima esercitazione: Configura BIND9 Domain Name System in Oracle Cloud Infrastructure, in cui Task 2 e Task 3 mostrano la creazione e la configurazione dell'istanza Primary-DNS, è necessario eseguire gli stessi task per configurare Secondary-DNS, tenere presenti le informazioni riportate di seguito.

Il nome dell'istanza sarà DNS secondario.
Si troverà nella stessa subnet del DNS primario e deve essere assegnato un indirizzo IP di 10.0.0.20.
Attraverso il processo di configurazione, ogni volta che viene menzionato DNS primario 10.0.0.10, deve essere sostituito con DNS secondario 10.0.0.20, un esempio è il nome FQDN per questa istanza deve essere secondary-dns.orastage.com.
Utilizzare la stessa chiave SSH.
Lo stesso bastion OCI utilizzato per accedere al DNS primario può essere utilizzato anche per accedere al DNS secondario, ma utilizzando una nuova sessione.
Nel file /var/lib/bind/db.orastage.com sia per le istanze primarie che per quelle secondarie, assicurarsi che siano presenti tutti i record riportati di seguito, in modo che entrambi i server DNS possano risolversi a vicenda oltre alle istanze FE-VM e BE-VM.
```
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
```

Alla fine di questo compito, l'architettura dovrebbe essere così:

immagine

Task 2: configurare un load balancer di rete OCI

Task 2.1: Aggiungi dettagli

Clicca sul menu hamburger (≡) dall'angolo in alto a sinistra.
1. Fare clic su Networking.
2. Fare clic su load balancer di rete.
Fare clic su Crea load balancer di rete.
1. Nome load balancer: immettere un nome.
2. Scegliere il tipo di visibilità: selezionare Privato.
3. Scegli il networking: selezionare DNS-VCN e la relativa subnet privata in cui verrà posizionato il load balancer di rete.
4. Fare clic su Avanti.

Task 2.2: Configurare un listener

Un listener è un componente essenziale di un load balancer che è responsabile della ricezione di un tipo specifico di traffico con determinate porte (ad esempio, TCP/port 80, UDP/port 21) e lo indirizza ai server backend. In questa esercitazione, vogliamo che il listener ascolti sulle porte 53 (TCP) e (UDP), poiché il DNS li utilizza entrambi.

Immettere le informazioni riportate di seguito.
1. Nome listener: immettere un nome.
2. Specificare il tipo di traffico gestito dal listener: selezionare UDP/TCP.
3. Specificare la porta: immettere il numero di porta 53.
4. Fare clic su Avanti.

Task 2.3: scegliere un set backend

Un set backend è un raggruppamento logico di server backend a cui il load balancer di rete instrada il traffico. I nostri server backend saranno DNS primario e DNS secondario.

Immettere le informazioni riportate di seguito.
1. Nome set backend: immettere un nome per il set backend.
2. Fare clic su Aggiungi backend.
3. Tipo backend: selezionare Istanze di computazione.
4. Istanze di computazione IPv4 backend: scegliere entrambi i server DNS: DNS primario e DNS secondario.
5. Fare clic su Aggiungi backend.
6. È possibile visualizzare i server backend aggiunti al set.
7. Specificare il criterio di controllo dello stato: viene utilizzato un criterio di controllo dello stato per verificare la disponibilità dei server backend effettuando richieste o tentando connessioni. Il load balancer di rete esegue questi controlli dello stato a intervalli regolari specificati, utilizzando questo criterio per monitorare continuamente lo stato dei server backend.
8. Fare clic su Avanti.

Task 2.4: Revisione e creazione

Rivedere tutti i dettagli e fare clic su Crea load balancer di rete.
Viene creato il DNS-NLB, prendere nota dell'indirizzo IP privato, poiché verrà utilizzato nel task 3.

Task 2.5: aggiungere una regola di sicurezza

Per evitare il guasto del controllo dello stato e per garantire una comunicazione fluida senza interruzioni del traffico.

Aggiungere le regole riportate di seguito nella lista di sicurezza DNS-Private-Subnet. Ciò consente il traffico DNS inviato dal load balancer di rete ai relativi backend.
L'aspetto dell'architettura deve essere quello illustrato nella seguente immagine.

Task 3: configurare le regole di inoltro DNS OCI

Task 3.1: Configura regola di inoltro VCN frontend

Clicca sul menu hamburger (≡) dall'angolo in alto a sinistra.
1. Fare clic su Networking.
2. Fare clic su Reti cloud virtuali.
Fare clic su VCN frontend.
Fare clic sul resolver DNS della VCN.
scorrere in Basso
1. Fare clic su Regole.
2. Fare clic su Gestisci regole.
3. Modificare l'indirizzo IP di destinazione da Indirizzo IP DNS primario a Indirizzo IP DNS-NLB (10.0.0.110) creato nel task 2.
4. Fare clic su Salva modifiche.
5. L'indirizzo IP di destinazione è stato modificato. Tutte le query da FE-VM verranno quindi inoltrate all'indirizzo IP DNS-NLB che le distribuirà tra i server DNS primari e secondari.

Task 3.2: Configura regola di inoltro VCN backend

Clicca sul menu hamburger (≡) dall'angolo in alto a sinistra.
1. Fare clic su Networking.
2. Fare clic su Reti cloud virtuali.
Fare clic su VCN backend.
Fare clic sul resolver DNS della VCN.
scorrere in Basso.
1. Fare clic su Regole.
2. Fare clic su Gestisci regole.
3. Modificare l'indirizzo IP di destinazione da Indirizzo IP DNS primario a Indirizzo IP DNS-NLB (10.0.0.110) creato nel task 2.
4. Fare clic su Salva modifiche.
5. L'indirizzo IP di destinazione è stato modificato. Tutte le query da BE-VM verranno quindi inoltrate all'indirizzo IP DNS-NLB, che le distribuirà tra i server DNS primari e secondari.

Task 4: Esegui test e convalida

Prerequisito

Abilita log: per verificare il flusso del traffico, abiliteremo i log di flusso della subnet che ci consentono di monitorare e tenere traccia del traffico di rete che entra o esce da una subnet specifica. Questi log acquisiscono dettagli sul traffico di rete, ad esempio gli indirizzi IP di origine e destinazione, i numeri di porta e la quantità di dati trasmessi. Per abilitare il log, effettuare le operazioni riportate di seguito.
1. Vai alla subnet privata DNS-VCN, in cui risiedono DNS primario, DNS secondario e DNS-NLB.
2. Fare clic su Log.
3. Selezionare Abilita log.
Per ulteriori informazioni sui log e su come utilizzarli in OCI, vedere
- Log di flusso VCN.
- Dettagli per i log di flusso della VCN: informazioni su come leggere il contenuto del log.
- Segui i pacchetti in un'architettura di instradamento VCN hub e spoke all'interno di OCI: un'utile esercitazione per sapere come tracciare i pacchetti di rete in un ambiente OCI utilizzando più metodi, come l'acquisizione dei pacchetti firewall, i log della subnet e TCPdump. Seguire le attività 6 e 13.
  - Task 6: abilitare la registrazione (tutti i log) nella subnet privata spoke.
  - Task 13: Guarda tutti i punti di registrazione e le acquisizioni di pacchetti e segui il percorso - Punto di registrazione B.

Ora verrà registrato tutto il traffico in entrata e in uscita per questa subnet.

Scenario di test 1: il DNS primario risponde alle query FE-VM quando il DNS secondario è inattivo

In caso di errore nel DNS secondario, è necessario assicurarsi che il DNS primario risponda alle query provenienti da FE-VM, poiché il DNS-NLB sta indirizzando il traffico verso di esso.

La seguente immagine illustra lo scenario di test che intendiamo raggiungere.
Al momento, tutte le istanze sono attive e in esecuzione. Iniziamo chiudendo l'istanza DNS secondario. Clicca sul menu hamburger (≡) dall'angolo in alto a sinistra.
1. Fare clic su Compute.
2. Fare clic su Istanze.
1. Selezionare la casella di controllo accanto all'istanza.
2. Fare clic su Azioni.
3. Fare clic su Arresta.
4. Fare clic su Arresta.
5. L'istanza è ora in stato Interrotto.
Accedere a FE-VM ed eseguire un test eseguendo una query. A tale scopo, utilizzeremo il servizio OCI Bastion. Clicca sul menu hamburger (≡) dall'angolo in alto a sinistra.
1. Fare clic su Identità e sicurezza.
2. Fare clic su Bastion.
Fare clic su FEBastion.
Fare clic su Crea sessione.
Immettere le informazioni riportate di seguito.
1. Tipo di sessione: selezionare Sessione SSH gestita.
2. Nome sessione: immettere un nome per la sessione.
3. Nome utente: immettere il nome utente. Per l'istanza Oracle Linux, il nome utente predefinito è opc.
4. Istanza di computazione: selezionare l'istanza FE-VM.
5. Incollare la stessa chiave pubblica generata nell'esercitazione 1: Task 2.1: Genera coppia di chiavi SSH.
6. Fare clic su Crea sessione.

Dopo aver creato la sessione, fare clic sui tre punti e sul comando Copia SSH.

immagine

Il comando dovrebbe essere simile al seguente:

ssh -i <privateKey> -o ProxyCommand="ssh -i <privateKey> -W %h:%p -p 22 ocid1.bastionsession.oc1.eu-milan-1.amaaaaaaldij5aiaxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxzo2q7dka@host.bastion.eu-milan-1.oci.oraclecloud.com" -p 22 opc@10.1.0.5

Aprire OCI Cloud Shell.
1. Passare alla directory .ssh utilizzando il comando cd .ssh.
2. Incollare il comando SSH. Assicurarsi di sostituire <privateKey> con il nome file della chiave privata id_rsa.
3. Immettere sì.
Login riuscito. A questo punto, eseguire una query di test da FE-VM a be.orastage.com utilizzando il comando host. Verificare che la query sia riuscita e che venga ricevuta una risposta.
Sappiamo che esiste un solo server backend in buono stato per gestire la richiesta, ovvero DNS primario. Quindi, qui verificheremo il flusso della query DNS e vedremo quale server ha risposto a tale query utilizzando i log della subnet OCI.
1. Fare clic sul log.
2. La richiesta è passata dall'endpoint di inoltro (10.1.0.6) posizionato nella stessa subnet di FE-VM all'indirizzo IP NLB (10.0.0.110) nella DNS-VCN.
3. Quindi, dall'indirizzo IP NLB (10.0.0.110), la richiesta viene inviata a DNS primario (10.0.0.10).
Test completato. DNS primario è stato in grado di gestire le query DNS in caso di inattività del DNS secondario.

Scenario di test 2: il DNS secondario risponde alle query FE-VM quando il DNS primario è inattivo

In caso di errore nel DNS primario, è necessario assicurarsi che il DNS secondario risponda alle query provenienti da FE-VM, poiché il DNS-NLB sta indirizzando il traffico verso di esso.

La seguente immagine illustra lo scenario di test che intendiamo raggiungere.
Iniziamo chiudendo l'istanza DNS primario. Clicca sul menu hamburger (≡) dall'angolo in alto a sinistra.
1. Fare clic su Compute.
2. Fare clic su Istanze.
1. Selezionare la casella di controllo accanto all'istanza.
2. Fare clic su Azioni.
3. Fare clic su Arresta.
4. Fare clic su Arresta.
5. L'istanza è ora in stato Interrotto.
Avviare l'istanza DNS secondario.
1. Selezionare la casella di controllo accanto all'istanza.
2. Fare clic su Azioni.
3. Fate clic su Start.
4. Fate clic su Start.
5. L'istanza è ora in stato In esecuzione.
Successivamente, accederemo a FE-VM ed eseguiremo un test eseguendo una query. A tale scopo, utilizzeremo il servizio OCI Bastion. Clicca sul menu hamburger (≡) dall'angolo in alto a sinistra.
1. Fare clic su Identità e sicurezza.
2. Fare clic su Bastion.
Fare clic su FEBastion.
Fare clic su Crea sessione.
Immettere le informazioni riportate di seguito.
1. Tipo di sessione: selezionare Sessione SSH gestita.
2. Nome sessione: immettere un nome per la sessione.
3. Nome utente: immettere il nome utente. Per l'istanza Oracle Linux, il nome utente predefinito è opc.
4. Istanza di computazione: selezionare l'istanza FE-VM.
5. Incollare la stessa chiave pubblica generata nell'esercitazione 1: Task 2.1: Genera coppia di chiavi SSH.
6. Fare clic su Crea sessione.

Dopo aver creato la sessione, fare clic sui tre punti e sul comando Copia SSH.

immagine

Il comando dovrebbe essere simile al seguente:

ssh -i <privateKey> -o ProxyCommand="ssh -i <privateKey> -W %h:%p -p 22 ocid1.bastionsession.oc1.eu-milan-1.amaaaaaaldij5axxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxzo2q7dka@host.bastion.eu-milan-1.oci.oraclecloud.com" -p 22 opc@10.1.0.5

Aprire OCI Cloud Shell.
1. Passare alla directory .ssh utilizzando il comando cd .ssh.
2. Incollare il comando SSH. Assicurarsi di sostituire <privateKey> con il nome file della chiave privata id_rsa.
3. Immettere sì.
Login riuscito. A questo punto, eseguire una query di test da FE-VM a be.orastage.com utilizzando il comando host. Verificare che la query sia riuscita e che venga ricevuta una risposta.
È noto che esiste un solo server backend in buono stato per gestire la richiesta, ovvero DNS secondario. Quindi, qui verificheremo il flusso della query DNS e vedremo quale server ha risposto a tale query utilizzando i log della subnet OCI.
1. Fare clic sul log.
2. La richiesta è passata dall'endpoint di inoltro (10.1.0.6) posizionato nella stessa subnet di FE-VM all'indirizzo IP NLB (10.0.0.110) nella DNS-VCN.
3. Quindi, da NLB (10.0.0.110) la richiesta viene inviata a DNS secondario (10.0.0.20).
Test completato. DNS secondario è in grado di gestire le query DNS nel caso in cui il DNS primario sia inattivo.

Scenario di test 3: il DNS primario risponde alle query BE-VM quando il DNS secondario è inattivo

In caso di errore nel DNS secondario, è necessario assicurarsi che il DNS primario risponda alle query provenienti da VM_BE, poiché il DNS-NLB sta indirizzando il traffico verso di esso.

La seguente immagine illustra lo scenario di test che intendiamo raggiungere.
Al momento, tutte le istanze sono attive e in esecuzione. Iniziamo chiudendo l'istanza DNS secondario. Clicca sul menu hamburger (≡) dall'angolo in alto a sinistra.
1. Fare clic su Compute.
2. Fare clic su Istanze.
1. Selezionare la casella di controllo accanto all'istanza.
2. Fare clic su Azioni.
3. Fare clic su Arresta.
4. Fare clic su Arresta.
5. L'istanza è ora in stato Interrotto.
Successivamente, accederemo a BE-VM ed eseguiremo un test eseguendo una query. A tale scopo, utilizzeremo il servizio OCI Bastion. Clicca sul menu hamburger (≡) dall'angolo in alto a sinistra.
1. Fare clic su Identità e sicurezza.
2. Fare clic su Bastion.
Fare clic su BEBastion.
Fare clic su Crea sessione.
Immettere le informazioni riportate di seguito.
1. Tipo di sessione: selezionare Sessione SSH gestita.
2. Nome sessione: immettere un nome per la sessione.
3. Nome utente: immettere il nome utente. Per l'istanza Oracle Linux, il nome utente predefinito è opc.
4. Istanza di computazione: selezionare l'istanza BE-VM.
5. Incollare la stessa chiave pubblica generata nell'esercitazione 1: Task 2.1: Genera coppia di chiavi SSH.
6. Fare clic su Crea sessione.

Dopo aver creato la sessione, fare clic sui tre punti e sul comando Copia SSH.

immagine

Il comando dovrebbe essere simile al seguente:

ssh -i <privateKey> -o ProxyCommand="ssh -i <privateKey> -W %h:%p -p 22 ocid1.bastionsession.oc1.eu-milan-1.amaaaaaaldij5axxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxuk7pafla@host.bastion.eu-milan-1.oci.oraclecloud.com" -p 22 opc@10.2.0.5

Aprire OCI Cloud Shell.
1. Passare alla directory .ssh utilizzando il comando cd .ssh.
2. Incollare il comando SSH. Assicurarsi di sostituire <privateKey> con il nome file della chiave privata id_rsa.
3. Immettere sì.
Login riuscito. A questo punto, eseguire una query di test da BE-VM a fe.orastage.com utilizzando il comando host. Verificare che la query sia riuscita e che venga ricevuta una risposta.
Sappiamo che esiste un solo server backend in buono stato per gestire la richiesta, ovvero DNS primario. Quindi, qui verificheremo il flusso della query DNS e vedremo quale server ha risposto a tale query utilizzando i log della subnet OCI.
1. Fare clic sul log.
2. La richiesta è passata dall'endpoint di inoltro (10.2.0.6) posizionato nella stessa subnet di VM_BE all'indirizzo IP NLB (10.0.0.110) nella DNS-VCN.
3. Quindi, da NLB (10.0.0.110), la richiesta viene inviata a DNS primario (10.0.0.10).
Test completato. DNS primario è stato in grado di gestire le query DNS in caso di inattività del DNS secondario.

Scenario di test 4: il DNS secondario risponde alle query BE-VM quando il DNS primario è inattivo

In caso di errore nel DNS primario, è necessario assicurarsi che il DNS secondario risponda alle query provenienti da VM_BE, poiché il DNS-NLB sta indirizzando il traffico verso di esso.

La seguente immagine illustra lo scenario di test che intendiamo raggiungere.
Iniziamo chiudendo l'istanza DNS primario. Clicca sul menu hamburger (≡) dall'angolo in alto a sinistra.
1. Fare clic su Compute.
2. Fare clic su Istanze.
1. Selezionare la casella di controllo accanto all'istanza.
2. Fare clic su Azioni.
3. Fare clic su Arresta.
4. Fare clic su Arresta.
5. L'istanza è ora in stato Interrotto.
Avviare l'istanza DNS secondario.
1. Selezionare la casella di controllo accanto all'istanza.
2. Fare clic su Azioni.
3. Fate clic su Start.
4. Fate clic su Start.
5. L'istanza è ora in stato In esecuzione.
Successivamente, accederemo a BE-VM ed eseguiremo un test eseguendo una query. A tale scopo, utilizzeremo il servizio OCI Bastion. Clicca sul menu hamburger (≡) dall'angolo in alto a sinistra.
1. Fare clic su Identità e sicurezza.
2. Fare clic su Bastion.
Fare clic su BEBastion.
Fare clic su Crea sessione.
Immettere le informazioni riportate di seguito.
1. Tipo di sessione: selezionare Sessione SSH gestita.
2. Nome sessione: immettere un nome per la sessione.
3. Nome utente: immettere il nome utente. Per l'istanza Oracle Linux, il nome utente predefinito è opc.
4. Istanza di computazione: selezionare l'istanza BE-VM.
5. Incollare la stessa chiave pubblica generata nell'esercitazione 1: Task 2.1: Genera coppia di chiavi SSH.
6. Fare clic su Crea sessione.

Dopo aver creato la sessione, fare clic sui tre punti e sul comando Copia SSH.

immagine

Il comando dovrebbe essere simile al seguente:

ssh -i <privateKey> -o ProxyCommand="ssh -i <privateKey> -W %h:%p -p 22 ocid1.bastionsession.oc1.eu-milan-1.amaaaaaaldij5aia73xcxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxa@host.bastion.eu-milan-1.oci.oraclecloud.com" -p 22 opc@10.2.0.5

Aprire OCI Cloud Shell.
1. Passare alla directory .ssh utilizzando il comando cd .ssh.
2. Incollare il comando SSH. Assicurarsi di sostituire <privateKey> con il nome file della chiave privata id_rsa.
3. Immettere sì.
Login riuscito. A questo punto, eseguire una query di test da BE-VM a fe.orastage.com utilizzando il comando host. Verificare che la query sia riuscita e che venga ricevuta una risposta.
È noto che esiste un solo server backend in buono stato per gestire la richiesta, ovvero DNS secondario. Quindi, qui verificheremo il flusso della query DNS e vedremo quale server ha risposto a tale query utilizzando i log della subnet OCI.
1. Fare clic sul log.
2. La richiesta è passata dall'endpoint di inoltro (10.2.0.6) posizionato nella stessa subnet di VM_BE all'indirizzo IP NLB (10.0.0.110) nella DNS-VCN.
3. Quindi, da NLB (10.0.0.110) la richiesta viene inviata a DNS secondario (10.0.0.20).
Test completato. DNS secondario è stato in grado di gestire le query DNS in caso di inattività del DNS primario.

Passi successivi

In questa esercitazione abbiamo migliorato un semplice DNS BIND9 client-server impostato in OCI integrando un load balancer di rete OCI e un server DNS secondario per garantire la disponibilità continua del servizio in caso di errore del server primario.

Finora, abbiamo sviluppato un'architettura DNS ad alte prestazioni e affidabile specificamente per la gestione delle query di dominio orastage.com. Tuttavia, l'azienda OraStage è tenuta a risolvere anche i nomi di dominio nativi OCI, come oraclevcn.com e oraclecloud.com, e per questo sono necessari ulteriori passi. Nella prossima esercitazione, Usa DNS OCI per risolvere i domini nativi, ti mostreremo come ottenere questa configurazione.

Conferme

Autore - Anas abdallah (esperto di cloud networking)

Altre risorse di apprendimento

Esplora altri laboratori su docs.oracle.com/learn o accedi a più contenuti gratuiti sulla formazione su Oracle Learning YouTube channel. Inoltre, visita education.oracle.com/learning-explorer per diventare un Oracle Learning Explorer.

Per la documentazione del prodotto, visita l'Oracle Help Center.

Titolo e informazioni sul copyright

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

G14454-02