Panoramica dell'utilizzo del DNS di zona

Questo documento descrive i vantaggi e l'approccio consigliato per eseguire la migrazione dei workload e dell'organizzazione dal DNS globale al DNS di zona.

Il DNS di zona riduce il rischio di interruzioni tra regioni e migliora l'affidabilità complessiva dei progetti su Compute Engine.

Vantaggi dell'utilizzo di nomi DNS di zona

Trusted Cloud by S3NS offre due tipi di nomi DNS interni: di zona e globali.

DNS di zona

I nomi DNS di zona includono il nome dell'istanza Compute Engine, la zona in cui si trova l'istanza e il progetto a cui appartiene l'istanza. Questi nomi vengono risolti all'interno di una zona specifica. Di conseguenza, my-vm.zone1.google.com è univoco per zone1 e rappresenta un'istanza diversa da my-vm.zone2.google.com. Questo isolamento offre un vantaggio chiave:

  • Maggiore affidabilità: se in una zona si verifica un'interruzione del servizio, questa non influisce sulla risoluzione DNS in altre zone, il che comporta un'affidabilità più alta per le tue applicazioni.

Il DNS di zona è il metodo di risoluzione DNS interno predefinito per le organizzazioni create dopo il 6 settembre 2018.

DNS globale

I nomi DNS globali non includono la zona in cui si trova l'istanza. Ciò significa che ogni istanza deve avere un nome DNS univoco in tutte le zone del progetto. Questo approccio presenta uno svantaggio significativo:

  • Single point of failure: se il servizio DNS globale riscontra dei problemi, gli effetti si possono ripercuotere su tutte le istanze, indipendentemente dalla zona in cui si trovano. Ciò può causare i seguenti problemi:
    • Impossibilità di creare nuove istanze: potresti non essere in grado di creare nuove istanze in nessuna regione in cui si verificano errori nel control plane.
    • Interruzione del servizio: i servizi critici di Compute Engine, come la scalabilità automatica o il ripristino automatico per i gruppi di istanze gestite (MIG), potrebbero non funzionare correttamente.

Le organizzazioni che hanno fatto l'onboarding in Trusted Cloud by S3NS prima del 6 settembre 2018 sono configurate in modo da utilizzare il DNS globale per impostazione predefinita per tutti i nuovi progetti. Google consiglia vivamente di eseguire la migrazione di questi progetti al DNS di zona per migliorare l'affidabilità e prevenire le interruzioni del servizio sopra menzionate. Inoltre, devi aggiornare la policy dell'organizzazione in modo da imporre l'utilizzo del DNS di zona per tutti i nuovi progetti creati all'interno dell'organizzazione.

Approccio consigliato per la migrazione dal DNS globale al DNS di zona

In genere, il processo di migrazione dal DNS globale al DNS di zona prevede due passaggi:

  1. Configura i nuovi progetti in modo che utilizzino il DNS di zona per impostazione predefinita.
  2. Esegui la migrazione dei progetti esistenti dall'utilizzo del DNS globale al DNS di zona, modificando l'impostazione dei metadati DNS interno.

Alcuni progetti potrebbero non essere compatibili con il DNS di zona. Per questi progetti è necessario effettuare l'analisi e la risoluzione dei problemi prima di poter eseguire la migrazione al DNS di zona.

Limitazioni della migrazione

La valutazione dell'idoneità fornita da Compute Engine si basa sulla cronologia delle query DNS interne degli ultimi 30 giorni. Tuttavia, altri fattori potrebbero influire sulla tua capacità di eseguire la migrazione al DNS di zona:

Versione glibc

La migrazione al DNS di zona aggiunge un nuovo dominio al percorso di ricerca. Le istanze Compute che eseguono un sistema operativo Linux o Unix e utilizzano glibc versione 2.25 o precedente hanno un limite di 6 domini di ricerca. Il superamento di questo limite può causare problemi.

  • Istanze interessate: questa limitazione si applica alle VM che utilizzano distribuzioni Linux o Unix precedenti.
  • Istanze non interessate: le istanze che utilizzano i sistemi operativi riportati di seguito non sono interessate.
    • Windows
    • Container-Optimized OS
    • Debian 10 o versioni successive
    • Fedora CoreOS (versione 27 o successive)
    • RHEL 8 o versioni successive
    • Ubuntu 18.04 o versioni successive
    • Immagini personalizzate che utilizzano glibc versione 2.26 o successive

Per controllare la versione di glibc utilizzata dall'istanza, segui questi passaggi:

  1. Connettiti alla VM Linux.
  2. Esegui il comando ldd --version.

Se l'istanza utilizza la versione 2.25 o precedenti di glibc, controlla i domini di ricerca:

  1. Connettiti alla VM Linux.
  2. Esegui il comando cat /etc/resolv.conf.

Versione sistema operativo

Alcuni sistemi operativi, come Windows Server 2003 e versioni precedenti, impongono un limite di 15 caratteri per i nomi delle istanze di computing. Il DNS di zona aggiunge il qualificatore a livello di zona al nome di dominio completo (FQDN) del DNS interno.

La limitazione imposta ai nomi su Windows è dovuta alla convenzione di denominazione NetBIOS utilizzata nelle versioni precedenti del sistema operativo. Le versioni più recenti di Windows non prevedono più questa limitazione e consentono nomi di istanze più lunghi.

Se utilizzi sistemi Windows precedenti, tieni presente la limitazione imposta ai nomi durante la migrazione al DNS di zona, in quanto i nomi DNS di zona più lunghi potrebbero superare la lunghezza massima consentita.

Reti VPC condivise

Per risolvere i nomi DNS delle istanze nei progetti di servizio che utilizzano il VPC condiviso, devi utilizzare il nome di dominio completo (FQDN) di zona, che include quest'ultima.

Passaggi successivi