Atualizar seus projetos para usar o DNS zonal

Este documento explica como migrar um projeto do DNS global para o DNS zonal. O DNS zonal aumenta a confiabilidade isolando as falhas nas zonas, evitando interrupções em serviços essenciais, como a criação de instâncias e a autocorreção.

Antes de começar

  • Configure a autenticação, caso ainda não tenha feito isso. A autenticação é o processo de verificação da sua identidade para acesso a serviços e APIs do Google Cloud . Para executar códigos ou amostras de um ambiente de desenvolvimento local, autentique-se no Compute Engine selecionando uma das seguintes opções:

    Select the tab for how you plan to use the samples on this page:

    Console

    When you use the Google Cloud console to access Google Cloud services and APIs, you don't need to set up authentication.

    gcloud

    1. Install the Google Cloud CLI, then initialize it by running the following command: 

      gcloud init
    2. Set a default region and zone.

      3. REST

      Para usar as amostras da API REST nesta página em um ambiente de desenvolvimento local, use as credenciais fornecidas para gcloud CLI.

        Install the Google Cloud CLI, then initialize it by running the following command: 

        gcloud init

      Para mais informações, consulte Autenticar para usar REST na documentação de autenticação do Google Cloud.

Funções exigidas

Para receber as permissões necessárias para migrar projetos para usar o DNS zonal, peça ao administrador para conceder a você os seguintes papéis do IAM:

Para mais informações sobre a concessão de papéis, consulte Gerenciar o acesso a projetos, pastas e organizações.

Esses papéis predefinidos contêm as permissões necessárias para migrar projetos para usar o DNS zonal. Para conferir as permissões exatas necessárias, expanda a seção Permissões necessárias:

Permissões necessárias

As seguintes permissões são necessárias para migrar projetos para usar o DNS zonal:

  • Verifique nomes de DNS globais e metadados de VM: compute.projects.get
  • Defina metadados em uma VM: compute.instances.setMetadata
  • Defina os metadados do projeto: compute.projects.setCommonInstanceMetadata
  • Se as VMs usam contas de serviço: iam.serviceAccounts.actAs

Essas permissões também podem ser concedidas com funções personalizadas ou outros papéis predefinidos.

Migrar seu projeto para o DNS zonal

Para migrar um projeto para usar o DNS zonal, conclua as seguintes tarefas:

  1. Verificar se o projeto usa o DNS global por padrão
  2. Determinar a prontidão para migração dos seus projetos usando a análise de consulta
  3. Migrar projetos compatíveis com o DNS zonal
  4. Corrigir consultas incompatíveis
  5. Monitore os registros de DNS globais para confirmar a prontidão da migração.
  6. Migrar os projetos restantes para o DNS zonal
  7. Verificar se uma mudança no DNS zonal está afetando seu projeto

Verificar se o projeto usa o DNS global por padrão

Verifique seus projetos para ver se eles precisam migrar do uso de DNS global para DNS zonal. Basta migrar os projetos configurados para usar o DNS global como padrão para todos os nomes DNS internos criados no projeto.

Console

  1. No console do Google Cloud, acesse a página Metadados do Compute Engine.

    Acessar a página "Metadados"

  2. Na guia Metadados, confira a configuração vmdnssetting, se ela existir. O valor atribuído indica se o projeto usa o DNS global por padrão.

    • GlobalDefault: o projeto tem o DNS global ativado.
    • ZonalOnly: o projeto tem o DNS zonal ativado. Este projeto não precisa ser migrado.

    Se a configuração de metadados vmdnssetting não estiver listada, verifique se a organização usa o DNS global por padrão.

gcloud

Execute o seguinte comando da CLI gcloud para verificar o valor de vmDnsSetting.

gcloud compute project-info describe --project=PROJECT_ID --flatten="vmDnsSetting"

Substitua PROJECT_ID pelo nome do projeto.

O valor retornado indica se o projeto usa o DNS global por padrão.

  • GLOBAL_DEFAULT: o projeto tem o DNS global ativado.
  • ZONAL_ONLY: o projeto tem o DNS zonal ativado. Este projeto não precisa ser migrado.

REST

Verifique o valor de vmDnsSetting usando o método projects.get. Este exemplo usa um parâmetro de consulta fields para incluir apenas os campos que você quer ver.

GET https://compute.googleapis.com/compute/v1/projects/PROJECT_ID?fields=id,name,vmDnsSetting

Substitua PROJECT_ID pelo ID do projeto.

O valor de vmDnsSetting indica se o projeto usa o DNS global por padrão.

  • GLOBAL_DEFAULT: o projeto tem o DNS global ativado.
  • ZONAL_ONLY: o projeto tem o DNS zonal ativado. Este projeto não precisa ser migrado.

Usar a análise de consultas para determinar a prontidão de migração de um projeto

Para avaliar se um projeto pode ser migrado para o DNS zonal sem mudanças no código ou alterar o uso do DNS global, Google Cloud analisou o histórico de consultas DNS. Essa análise fornece as seguintes métricas que indicam a compatibilidade do projeto com o DNS zonal:

  • zonal_dns_ready (Consultas compatíveis): essa métrica representa o número total de consultas em um período de 100 dias que podem ser resolvidas usando o DNS zonal.

  • zonal_dns_risky (Consultas incompatíveis): essa métrica representa o número total de consultas que não podem ser resolvidas usando o DNS zonal. Essas consultas geralmente envolvem comunicação entre regiões ou outros cenários em que a resolução zonal falha. É importante saber que, se essa métrica tiver um valor diferente de zero, o projeto ainda não estará pronto para migração. Você precisa resolver essas consultas incompatíveis antes de mudar para o DNS zonal.

Para conferir essas métricas, use o Metrics Explorer no console do Google Cloud.

  1. No Console do Google Cloud, acesse a página do  Metrics Explorer:

    Acesse o Metrics explorer

    Se você usar a barra de pesquisa para encontrar essa página, selecione o resultado com o subtítulo Monitoramento.

  2. No lado direito da barra de ferramentas que contém o Selecione uma métrica , clique Editor de código e LQM ou PromQL de dois minutos.

  3. Se o campo de entrada da consulta não tiver um título Consulta MQL e, no canto inferior direito do campo de entrada da consulta, Idioma, selecione LQM de dois minutos.

  4. No campo de entrada da consulta, digite o seguinte texto exatamente como aparece:

    fetch compute.googleapis.com/Location
| metric 'compute.googleapis.com/global_dns/request_count'
| every 1d
| within 7d

  5. Clique no botão Run query.

    O console do Google Cloud exibe um gráfico das duas métricas (zonal_dns_ready e zonal_dns_risky) e o número correspondente de consultas feitas durante o período para cada métrica.

    Captura de tela do gráfico de métricas de uso de DNS global.

  6. Verifique o valor da métrica zonal_dns_risky.

    • Se o valor for 0, o projeto estará pronto para migração para o DNS zonal. É possível migrar o projeto, conforme descrito em Migrar projetos prontos para o DNS zonal.
    • Se o valor for um número diferente de zero, como 0.02k, conforme mostrado na captura de tela anterior, há algumas consultas que podem não funcionar depois da migração para o DNS zonal. O projeto não está pronto para migração. Siga as etapas em Corrigir consultas incompatíveis.

Migrar projetos compatíveis com o DNS zonal

Use uma das seguintes opções para migrar projetos que estão prontos para mudar para o DNS zonal:

  • Clique no botão Usar DNS zonal no console do Google Cloud.

    1. Quando você visualizar a página Instâncias de VM do projeto, se ele estiver pronto para migração (compatível com consultas de DNS zonal), o banner vai incluir uma recomendação para Usar DNS zonal. Essa recomendação é baseada no uso de DNS interno no projeto, mas está limitada aos últimos 30 dias.

      Uma captura de tela do banner de DNS zonal pronto para migrar no console.

      Se você clicar no botão Usar DNS zonal, os metadados do projeto serão atualizados para usar o DNS zonal.

    2. Opcional: consulte e faça consultas de metadados da VM para confirmar a mudança.

  • Mude manualmente os metadados do projeto para usar o DNS zonal.

    1. Ative o DNS zonal para suas instâncias definindo a entrada de metadados vmDnsSetting para o projeto. Depois de definir essa entrada de metadados, as instâncias de computação só poderão ser acessadas pelos nomes DNS por zona (VM_NAME.ZONE.c.PROJECT_ID.internal) ao usar caminhos de pesquisa. As instâncias ainda mantêm os caminhos de pesquisa global e por zona, mas os nomes de DNS globais, que não incluem o ZONE como parte do nome DNS interno, deixam de funcionar. Apenas instâncias na mesma região e no mesmo projeto podem acessar uma à outra usando o nome global quando essa configuração está em vigor.

      Console

      1. Para atualizar a configuração no nível do projeto, no console do Google Cloud, acesse a página Metadados do Compute Engine.

        Acessar a página "Metadados personalizados"

      2. Clique em Editar.

      3. Se uma chave com o valor VmDnsSetting existir, mude o valor para ZonalOnly.

      4. Se uma chave com o valor VmDnsSetting não existir, clique em Adicionar item.

        • No campo Chave, digite VmDnsSetting.
        • No campo Valor, insira ZonalOnly.

      5. Para concluir a modificação das entradas de metadados personalizados, clique em Salvar.

      gcloud

      1. Para atualizar a configuração de metadados do projeto atual, use o comando project-info add-metadata.

        gcloud compute project-info add-metadata \
    --metadata vmDnsSetting=ZonalOnly

      2. Opcional: para verificar as configurações de metadados de um projeto, use o seguinte comando:

        gcloud compute project-info describe --project=PROJECT_ID --flatten="vmDnsSetting"

        Substitua PROJECT_ID pelo nome do projeto a ser consultado.

      REST

      Para atualizar a configuração de metadados no nível do projeto, crie uma solicitação POST usando o método projects.setCommonInstanceMetadata.

      1. Opcional: para realizar o bloqueio otimista, você pode fornecer uma impressão digital.

        Uma impressão digital é uma string aleatória de caracteres gerados pelo Compute Engine. A impressão digital muda após cada solicitação. Se você fornecer uma impressão digital incompatível, sua solicitação será rejeitada.

        Se você não fornecer uma impressão digital, nenhuma verificação de consistência será realizada e a solicitação projects.setCommonInstanceMetadata será realizada. Se você usar o método instances.setMetadata, uma impressão digital será sempre necessária.

        Para receber a impressão digital atual de um projeto, chame o método project.get.

        GET https://compute.googleapis.com/compute/v1/projects/PROJECT_ID

        O resultado será assim:

        {
 "name": "myproject",
 "commonInstanceMetadata": {
   "kind": "compute#metadata",
   "fingerprint": "FikclA7UBC0=",
   ...
 }
}

      2. Crie uma solicitação POST para o método projects.setCommonInstanceMetadata para definir o par de chave-valor de metadados:

        POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/setCommonInstanceMetadata

{
"fingerprint": "FikclA7UBC0=",
"items": [
  {
  "key": "vmDnsSetting",
  "value": "ZonalOnly"
  }
]
}

        Substitua PROJECT_ID pelo ID do projeto.

    2. Depois de configurar a entrada de metadados vmDnsSetting para seu projeto, atualize o lease de DHCP em cada instância nesse projeto. Para isso, reinicie a instância, aguarde até que a concessão expire ou execute um dos seguintes comandos:

      Instâncias do Linux 

      sudo dhclient -v -r

      Instâncias do Windows 

      ipconfig /renew

    3. Confira se o projeto usa o DNS zonal.

Corrigir consultas incompatíveis

Um projeto que não está pronto para migrar significa que pelo menos uma consulta DNS incompatível foi feita em um determinado período, como nos últimos 30 dias. As consultas incompatíveis podem ter os seguintes atributos:

  • Fazer uma chamada para uma instância de computação em um projeto diferente
  • Fazer uma chamada para uma instância de computação em uma região diferente

Se o projeto tiver consultas incompatíveis, o banner a seguir vai aparecer na página Instâncias de VM do console do Google Cloud:

Banner indicando que o projeto não está pronto para migrar para o DNS zonal.

Para corrigir todas as consultas incompatíveis, recomendamos que você use o nome de domínio totalmente qualificado (FQDN, na sigla em inglês) zonal da instância de origem na consulta. Essa abordagem garante que a resolução de consultas continue ininterrupta após a migração do projeto para o DNS zonal.

Para resolver consultas incompatíveis, faça o seguinte:

  1. Use o Logs Explorer para acessar e consultar o uso de DNS global das instâncias de computação do seu projeto.

    Acessar o Explorador de registros

  2. Selecione o projeto.

  3. Aplique os filtros de recurso e nome de registro:

    1. Clique em Recurso.
    2. Na caixa de diálogo Selecionar recurso, selecione Instância de VM e clique em Aplicar.
    3. Clique em Nome do registro.

    4. Na caixa de diálogo Selecionar nomes de registro, selecione gdnsusage e clique em Apply.

    Como alternativa, insira o seguinte no campo de consulta:

       resource.type="gce_instance"
   log_name="projects/PROJECT_ID/logs/compute.googleapis.com%2Fgdnsusage"

  4. No painel Resultados da consulta, cada consulta tem um campo jsonPayload. Cada campo jsonPayload contém as seguintes informações:

    • O nome da VM de origem, o ID do projeto e o nome da zona.
    • O nome da VM de destino, o ID do projeto e o nome da zona.

    • Uma mensagem de depuração com informações sobre como atualizar a consulta DNS global que não pode ser resolvida usando nomes DNS zonais. Essas são as consultas de bloqueio de migração que você precisa depurar e corrigir.

      "To use Zonal DNS, update the Global DNS query sent from the source VM
VM_NAME.c.PROJECT_ID.internal to the following zonal
FQDN: VM_NAME.ZONE.c.PROJECT_ID.internal"

    • Uma contagem de consultas que mostra quantas consultas de bloqueio de migração a VM de origem envia para a VM de destino nesse dia.

    A captura de tela a seguir mostra as informações do campo jsonPayload na página do console do Explorador de registros.

    Captura de tela do jsonPayload nos resultados da consulta do registro gdnsusage.

  5. Use as informações no jsonPayload que você recebeu na etapa anterior para determinar qual FQDN usar para atualizar manualmente suas consultas DNS globais para usar o DNS zonal e preparar o projeto para a migração. Os casos de uso mais comuns para atualizar o FQDN e resolver a compatibilidade são os seguintes:

    • Nomes DNS internos do servidor de metadados: nenhuma ação é necessária porque o nome DNS retornado mudará para um FQDN zonal imediatamente após a migração para o DNS zonal. Se o nome DNS estiver armazenado em cache, basta fazer mais uma chamada para atualizar o valor do cache.
    • Nomes de DNS internos usados para acessar VMs em outra região: se você tiver um aplicativo que usa os nomes DNS internos para VMs em diferentes regiões, modifique a política de DHCP ou o arquivo de configuração para incluir a zona na outra região.
    • FQDN global codificado: se você tiver um aplicativo que usa nomes FQDN globais codificados para VMs, atualize a chamada no aplicativo para usar o nome DNS interno ou o FQDN zonal. Essa mudança pode ser feita com uma mudança de código ou de configuração no Terraform.
    • VMs em projetos de serviço que usam uma rede VPC compartilhada: para resolver nomes DNS de VMs em projetos de serviço que usam uma rede VPC compartilhada, use os FQDNs zonais das VMs.

  6. Depois de atualizar as consultas DNS globais para usar o DNS zonal, faça o seguinte:

    1. Use a página da Análise de registros para consultar o uso do DNS global novamente. Depois que você corrigir todas as consultas DNS globais de bloqueio, registros de depuração não serão exibidos nos resultados da consulta.

    2. Verifique novamente a métrica de monitoramento para saber se todas as consultas DNS incompatíveis foram removidas.

Conferir registros de DNS globais no Explorador de registros

O Explorador de registros mostra principalmente registros DNS globais de projetos com consultas que são incompatíveis com o DNS zonal. Esses registros ajudam a identificar e analisar essas consultas problemáticas antes da migração.

Também é possível usar o Explorador de registros para essas consultas incompatíveis para fazer o seguinte:

  • Criar painéis: visualize seus padrões de consulta DNS globais incompatíveis para ter insights sobre o comportamento de comunicação do aplicativo.
  • Registros agregados: analise os registros DNS em toda a organização para identificar tendências mais amplas e possíveis áreas de melhoria.

Verificar se uma mudança no DNS zonal está afetando seu projeto

Depois de migrar para o DNS zonal, é fundamental verificar se os aplicativos e serviços ainda estão funcionando corretamente. Como o DNS zonal muda a forma como os nomes DNS internos são resolvidos, alguns aplicativos podem ter problemas se dependerem de nomes DNS globais.

A seção a seguir descreve como verificar possíveis impactos e como resolvê-los:

  1. Comunicação de instâncias de linha de comando

    Tarefa: tente fazer ping em uma instância de outra usando a CLI gcloud.

    gcloud compute ssh VM-A --command "ping VM-B"

    Erro potencial: "Não foi possível resolver o host". Isso significa que VM-A não consegue encontrar o endereço IP de VM-B.

    Solução: atualize o nome do host que você está usando para VM-B para o nome de domínio totalmente qualificado (FQDN), que inclui o nome da zona: INSTANCE_NAME.ZONE.c.PROJECT_ID.internal

  2. Comunicação de instâncias nos serviços do Compute Engine

    Tarefa: se você estiver usando verificações de integridade para grupos de instâncias gerenciadas (MIGs, na sigla em inglês) que dependem de nomes de DNS internos, verifique se as verificações de integridade estão sendo aprovadas.

    Possível erro: "A verificação de integridade falhou". Isso indica que a verificação de integridade não pode alcançar o destino devido a problemas de resolução de DNS.

    Solução: verifique se a verificação de integridade está usando o FQDN da instância de destino, incluindo o nome da zona.

  3. Casos de uso específicos do aplicativo

    Muitos aplicativos dependem do DNS interno para tarefas como as seguintes:

    • Conectar-se a bancos de dados (por exemplo, Cloud SQL)

    • Interagir com filas de mensagens (por exemplo, Pub/Sub)

    • Possíveis erros: variam de acordo com o aplicativo, mas podem incluir:

      • "Não foi possível se conectar a SERVICE_NAME"
      • "A conexão expirou"
      • "Nenhum host desse tipo é conhecido"

    • Solução: verifique a configuração do aplicativo para garantir que ele esteja usando o FQDN (incluindo o nome da zona) ao fazer referência a serviços.

Reverter para o uso de DNS global

É possível desfazer a migração para o DNS zonal alterando o tipo de DNS interno padrão de volta para DNS global. É possível fazer isso no nível da organização, do projeto, da instância ou do contêiner.

Reverter para o uso de DNS global em um projeto

Para reverter um projeto a usar o DNS global, conclua as etapas a seguir.

  1. Adicione o seguinte aos metadados do projeto: vmDnsSetting=GlobalDefault.

    Para informações sobre como definir valores de metadados do projeto, consulte Definir e remover metadados personalizados.

  2. Verifique se nenhuma das instâncias no projeto tem o valor de metadados vmDnsSetting definido como ZonalOnly.

    gcloud compute instances describe INSTANCE_NAME --flatten="metadata[]"

    Substitua INSTANCE_NAME pelo nome da instância a ser verificada.

  3. Atualize a concessão de DHCP em cada instância. Para isso, reinicie a instância, aguarde até que a concessão expire ou execute um dos seguintes comandos no sistema operacional convidado:

    • Instâncias do Linux: sudo dhclient -v -r
    • Instância do Windows Server: ipconfig /renew

Reverter para o uso de DNS global em uma instância

Para reverter uma instância específica para o uso do DNS global, conclua as etapas a seguir.

  1. Atualize os metadados da instância para incluir vmDnsSetting=GlobalDefault.

    Para informações sobre como definir valores de metadados de instâncias de computação, consulte Definir e remover metadados personalizados.

  2. Para forçar a mudança na configuração de DNS, reinicie a rede da instância usando um dos seguintes comandos:

    • Para Container-Optimized OS ou Ubuntu:

      sudo systemctl restart systemd-networkd

    • Para CentOS, RedHat EL, Fedora CoreOS ou Rocky Linux:

      sudo systemctl restart network

      ou

      sudo systemctl restart NetworkManager.service

    • Para o Debian:

      sudo systemctl restart networking

    • Para sistemas Linux com nmcli:

      sudo nmcli networking off
sudo nmcli networking on

    • No Windows:

      ipconfig /renew

Reverter para o uso de DNS global para um contêiner

Se o aplicativo é executado em contêineres, no Kubernetes Engine ou no ambiente flexível do App Engine, talvez a configuração do DNS não seja atualizada automaticamente nas configurações dos contêineres. Nesse caso, será necessário reiniciar os contêineres. Para desativar o DNS zonal nesses apps de contêiner, conclua as etapas a seguir.

  1. Defina a configuração de metadados do projeto vmDnsSetting como GlobalDefault nos projetos que têm os contêineres e as VMs.

  2. Reinicie os contêineres para que as configurações de DNS voltem ao estado original.

Resolver problemas do processo de migração do DNS global para o DNS zonal

Se você tiver problemas com o processo de migração, consulte o guia de solução de problemas.

A seguir