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

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

Esegui la migrazione di una configurazione di forwarding Cloud DNS esistente

La migrazione di una configurazione di forwarding Cloud DNS esistente per l'utilizzo degli endpoint in uscita prevede quattro fasi:

preparazione

Nella fase di preparazione, prima di poter avviare la migrazione, crei le subnet solo proxy, le subnet normali e gli endpoint in uscita. Assicurati inoltre che la tua rete on-premise abbia una route di ritorno per l'intervallo di indirizzi IP della subnet solo proxy regionale e 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, in ogni regione in cui intendi eseguire il deployment di un endpoint in uscita, crea una subnet solo proxy con una dimensione minima di /26 (64 indirizzi).
  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 principale.
  3. Crea endpoint in uscita: crea i tuoi endpoint in uscita e associali alla rete VPC di destinazione, alla regione, alla subnet normale (--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 statico e associa l'endpoint alla subnet solo proxy regionale nella rete VPC.

  4. Aggiorna i firewall e le route on-premise: assicurati che la tua rete on-premise abbia una route di ritorno per l'intervallo di indirizzi IP della subnet solo proxy regionale. Aggiungi regole firewall nei tuoi ambienti on-premise ed esterni per consentire il traffico DNS in entrata (porte UDP e TCP 53) proveniente dall'intervallo di indirizzi IP della subnet solo proxy regionale.

Verifica (facoltativa)

Facoltativamente, 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 per 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 query su un host all'interno della zona di test (ad esempio dig host.test.corp.example.com). Verifica di ricevere una risposta DNS corretta. Verifica nei log del server DNS on-premise o esterno che il server abbia ricevuto la query da un indirizzo IP di origine nella nuova subnet solo proxy a livello di regione. Verifica anche nei log di dns_query che jsonPayload.egressPath sia impostato su OUTBOUND_ENDPOINT.

Migrazione della produzione

Durante la fase di migrazione della produzione, aggiorni le zone di forwarding e le policy dei server per 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 dei server: per ogni zona di forwarding o policy dei server di cui vuoi eseguire la migrazione, modifica la configurazione e cambia il percorso di andata dall'intervallo 35.199.192.0/19 predefinito agli endpoint in uscita.
  2. Monitora la risoluzione e l'integrità: esamina i log delle query DNS di Cloud DNS (controllando jsonPayload.egressPath=OUTBOUND_ENDPOINT, jsonPayload.outboundEndpoint e jsonPayload.egressError) e le metriche di monitoraggio esistenti per le zone migrate 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-warming per volumi elevati:
    • Latenza di scalabilità automatica: esiste una latenza di avvio della scalabilità automatica di circa 10 minuti per l'infrastruttura proxy sottostante gestita da Google.
    • Implementazione 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 query ignorate durante l'incremento della scalabilità automatica.
    • Preriscaldamento dell'assistenza: per migrazioni di grandi dimensioni in una singola zona che superano immediatamente le 10.000 QPS per regione, aumenta gradualmente il traffico (ad esempio, 10%, 25%, 50% e poi 100%) o contatta il tuo team dedicato all'account Google Cloudo l'assistenza prima della migrazione pianificata per richiedere il preriscaldamento dell'infrastruttura durante il periodo di manutenzione programmato. Nella richiesta, specifica:
      • ID progetto
      • Regioni target
      • QPS di picco stimato

Esegui la pulizia

Dopo aver verificato che la migrazione di produzione è andata a buon fine, devi ripulire il meccanismo di inoltro precedente.

  1. Conferma la migrazione completa: verifica che tutte le zone di forwarding e le policy dei server necessarie nel tuo progetto non utilizzino l'intervallo 35.199.192.0/19 predefinito.
    • Esamina i log DNS on-premise e assicurati che non provenga traffico 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 sugli endpoint in uscita, puoi rimuovere in sicurezza la regola firewall on-premise che consentiva il traffico DNS in entrata dall'intervallo 35.199.192.0/19 predefinito. Assicurati che nessun altro servizio Google Cloud utilizzi questa regola prima di rimuoverla o modificarla.

Esegui il rollback

Se devi eseguire il rollback della migrazione, segui questi passaggi:

  1. Ripristina le policy dei server o delle zone di forwarding: modifica la zona o la policy dei server interessata e reimposta il forwarding sull'intervallo 35.199.192.0/19 predefinito.
  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