Esegui la migrazione di una configurazione di forwarding Cloud DNS esistente agli endpoint in uscita

Questo documento fornisce una panoramica di alto livello di ciò che devi fare per eseguire la migrazione di una configurazione di forwarding di Cloud DNS esistente in modo da utilizzare gli endpoint in uscita.

Eseguire la migrazione di una configurazione di forwarding di Cloud DNS esistente

La migrazione di una configurazione di forwarding di Cloud DNS esistente in modo da utilizzare gli endpoint in uscita prevede quattro fasi:

Preparazione

Nella fase di preparazione, prima di poter avviare la migrazione, devi creare le subnet solo proxy, le subnet regolari e gli endpoint in uscita. Assicurati inoltre che le regole firewall on-premise consentano il traffico DNS in entrata dall'intervallo di indirizzi IP della subnet solo proxy regionale.

  1. Crea subnet solo proxy: se non sono già presenti, crea una subnet solo proxy con una dimensione minima di /26 (64 indirizzi) in ogni regione in cui intendi eseguire il deployment di un endpoint in uscita.
  2. Identifica o crea una subnet regolare: in ogni regione in cui prevedi di eseguire il deployment di un endpoint in uscita, identifica o crea una subnet regolare con un indirizzo IPv4 interno disponibile nel suo intervallo IP primario.
  3. Crea endpoint in uscita: crea gli endpoint in uscita e associali alla rete VPC di destinazione, alla regione, subnet regolare (--subnetwork=REGULAR_SUBNET) e a un indirizzo IPv4 interno disponibile (--endpoint-ip=IP_ADDRESS_STRING). Cloud DNS crea e gestisce automaticamente la risorsa di prenotazione IP statica e associa l'endpoint alla subnet solo proxy regionale nella rete VPC.

  4. Aggiorna i firewall on-premise: aggiungi regole firewall negli ambienti on-premise ed esterni per consentire il traffico DNS in entrata (porta UDP e TCP 53) proveniente dall'intervallo di indirizzi IP della subnet solo proxy regionale.

Verifica (facoltativa)

Se vuoi, puoi utilizzare la fase di verifica per verificare la configurazione dell'endpoint in uscita.

  1. Crea una zona di forwarding di test: crea una nuova zona di forwarding temporanea per un dominio di test (ad esempio, test.corp.example.com).
  2. Configura gli endpoint: configura la zona di test in modo che utilizzi i nuovi endpoint in uscita.
  3. Avvia una VM di test: in una rete VPC pertinente, avvia una VM di test temporanea.
  4. Verifica la risoluzione: dalla VM di test, utilizza dig o nslookup per eseguire una query su un host all'interno della zona di test (ad esempio, dig host.test.corp.example.com). Verifica di ricevere una risposta DNS riuscita nella VM di test e che il server abbia ricevuto la query. Verifica inoltre che il server abbia ricevuto la query da un indirizzo IP di origine nella nuova subnet solo proxy.

Migrazione della produzione

Durante la fase di migrazione della produzione, aggiorna le zone di forwarding e le policy del server in modo da utilizzare gli endpoint in uscita e rivedi i log delle query per assicurarti che le query vengano risolte correttamente.

  1. Aggiorna le zone di forwarding e le policy del server: per ogni zona di forwarding o policy del server di cui vuoi eseguire la migrazione, modifica la configurazione e cambia il percorso di andata dall'intervallo predefinito 35.199.192.0/19 agli endpoint in uscita.
  2. Monitora la risoluzione e l'integrità: esamina i log delle query DNS di Cloud DNS e le metriche di monitoraggio per le zone di cui è stata eseguita la migrazione per verificare che le query vengano risolte correttamente.
    • Utilizza dns.googleapis.com/query/response_count per monitorare il volume delle query e i codici di stato delle risposte.
  3. Strategia di migrazione e pre-riscaldamento a volume elevato:
    • Latenza di scalabilità automatica: per l'infrastruttura proxy sottostante gestita da Google è prevista una latenza di spin-up della scalabilità automatica di circa 10 minuti.
    • Rollout incrementale: esegui la migrazione delle zone in modo incrementale (una zona alla volta) se il volume di query aggregato supera le 10.000 query al secondo (QPS) per regione per evitare che le query vengano eliminate durante l'aumento della scalabilità automatica.
    • Supporta il pre-riscaldamento: per le migrazioni di grandi dimensioni a zona singola che superano immediatamente le 10.000 QPS per regione, aumenta gradualmente il traffico (ad esempio, 10%, 25%, 50% e poi 100%) o contatta il Google Cloudteam dedicato all'account o l'assistenza prima della migrazione pianificata per richiedere il pre-riscaldamento dell'infrastruttura durante il periodo di manutenzione pianificato. Nella richiesta, specifica:
      • ID progetto
      • Regioni di destinazione
      • QPS di picco stimate

Eseguire la pulizia

Dopo aver verificato che la migrazione della produzione è andata a buon fine, devi eseguire la pulizia del meccanismo di forwarding precedente.

  1. Conferma la migrazione completa: verifica che tutte le zone di forwarding e le policy del server necessarie nel tuo progetto non utilizzino l'intervallo predefinito 35.199.192.0/19.
    • Esamina i log DNS on-premise e assicurati che non ci sia traffico proveniente da questo intervallo per un periodo di tempo sicuro (ad esempio, 24 ore).
  2. Rimuovi la regola firewall precedente: dopo aver verificato che tutto il traffico è stato spostato agli endpoint in uscita, puoi rimuovere in sicurezza la regola firewall on-premise che consentiva il traffico DNS in entrata dall'intervallo predefinito 35.199.192.0/19. Prima di rimuovere o modificare questa regola, assicurati che nessun altro Google Cloud servizio la utilizzi.

Esegui il rollback

Se devi eseguire il rollback della migrazione:

  1. Ripristina le zone di forwarding o le policy del server: modifica la zona o la policy del server interessata e riporta il forwarding all'intervallo predefinito 35.199.192.0/19
  2. Ripristina le regole firewall: assicurati che la regola che consente il traffico DNS in entrata da 35.199.192.0/19 sia ancora attiva. Non rimuovere questa regola prima della fase di pulizia di una migrazione riuscita.

Passaggi successivi