Usar DNS zonal para o tipo de DNS interno

O DNS zonal reduz o risco de interrupções entre regiões e melhora a confiabilidade geral dos projetos no Compute Engine. O uso de DNS zonal reduz o impacto de falhas de ponto único que podem ocorrer ao usar o DNS global.

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 da seguinte maneira.
  

  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.

  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 que você precisa migrar para o DNS zonal, peça ao seu administrador para conceder a você os seguintes papéis do IAM:

• Crie ou atualize uma política da organização: Administrador de políticas da organização (roles/orgpolicy.policyAdmin) na pasta ou organização
• Determine se uma pasta está pronta para migrar para o DNS zonal: Navegador (roles/browser) na pasta ou na organização
• Migre um projeto para usar o DNS zonal: Editor do projeto (roles/resourcemanager.projectEditor) no projeto
• Migre VMs para DNS zonal em um projeto: Administrador de instâncias do Compute (v1) (roles/compute.instanceAdmin.v1) no projeto
• Se a VM usa uma conta de serviço: Usuário da conta de serviço (roles/iam.serviceAccountUser) na conta de serviço ou projeto

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 para o DNS zonal. Para conferir as permissões exatas necessárias, expanda a seção Permissões necessárias:

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

Sobre os nomes DNS

Os nomes de DNS por zona incluem o nome da VM, a zona em que ela está localizada e o projeto que a contém. Os nomes de DNS globais não incluem a zona em que a VM está localizada.

Quando você faz uma chamada para uma VM usando um nome DNS global:

• O nome é resolvido em nível global.
• Cada VM precisa ter um nome DNS exclusivo.
• Ao criar uma nova VM, o nome DNS dela precisa ser comparado com todos os outros nomes DNS globais registrados no mesmo projeto para evitar uma colisão de nomes DNS.

Quando você faz uma chamada para uma VM usando um nome DNS zonal:

• O nome é resolvido dentro de uma zona.
• Os nomes de DNS por zona precisam ser exclusivos em uma zona. Por exemplo, my-vm.zone1.google.com precisa ser exclusivo para zone1. Mas, diferentemente dos nomes DNS globais, my-vm.zone2.google.com também é um nome DNS válido ao usar DNS zonal.

O DNS zonal é o método de resolução de DNS interno padrão do Compute Engine para organizações criadas após 6 de setembro de 2018. Os nomes de DNS por zona em uma zona funcionam independentemente de outras zonas, permitindo que você crie mais aplicativos multirregionais tolerantes a falhas com melhores características de disponibilidade. Não há cobrança pelo uso de DNS zonal. O DNS zonal é separado do Cloud DNS.

Os projetos criados antes de 6 de setembro de 2018 foram configurados para usar DNS global por padrão. Esses projetos podem continuar usando o DNS global, mas o Google recomenda que as organizações migrem esses projetos para o DNS zonal para evitar que as interrupções do serviço em outra região afetem os recursos regionais locais. O uso de DNS zonal oferece mais confiabilidade em comparação com o DNS global, isolando as falhas no registro de DNS para zonas individuais. Isso reduz o impacto de falhas de ponto único. Se ocorrer uma interrupção no Google Cloud, ele será isolado em uma única zona, e os recursos e custos não serão afetados significativamente.

Migrar de DNS global para DNS zonal

O DNS zonal substituiu o DNS global como o tipo de DNS interno padrão para todas as novas organizações integradas ao Google Cloud após 6 de setembro de 2018. Se os projetos atuais ainda estiverem usando o DNS global, o Google recomenda que você mude esses projetos para usar nomes DNS zonais internos. Ao não migrar para o DNS zonal, você corre o risco de encontrar os seguintes problemas:

• Não é possível criar novas VMs em nenhuma região com falhas no plano de controle em que você tem ou já teve um projeto.
• Incapacidade de usar alguns serviços do Compute Engine essenciais para suas cargas de trabalho, como escalonamento automático ou recuperação automática para grupos de instâncias gerenciadas (MIGs, na sigla em inglês).

Uma abordagem alternativa para melhorar a confiabilidade das cargas de trabalho que usam o DNS global é migrar para as zonas particulares do Cloud DNS. O uso de zonas particulares do Cloud DNS remove a verificação de exclusividade de nome exigida pelo DNS global e isola falhas para permitir a resolução de nomes DNS. Para mais informações sobre essa opção, consulte a documentação do Cloud DNS ou entre em contato com o Cloud Customer Care ou o representante da equipe de conta. Para informações sobre como o Cloud DNS lida com interrupções zonais e regionais, consulte Como arquitetar a recuperação de desastres para interrupções de infraestrutura em nuvem.

Visão geral do processo de migração

O processo de migração de DNS zonal tem dois níveis:

• Nível da organização ou pasta: determine a prontidão da pasta ou da organização para migrar para o DNS zonal. Impeça que novos projetos usem o DNS global. Realizada pelo administrador da organização.
• Nível do projeto: migre um único projeto de DNS global para DNS zonal. Geralmente realizado pelo proprietário do projeto.

Geralmente, o processo envolve as seguintes etapas:

1. Verifique se a pasta ou a organização está pronta para migração para o DNS zonal.
2. Se a pasta ou a organização estiver pronta para migrar para o DNS zonal:
   1. O administrador da organização define uma política organizacional para a pasta ou organização para impedir o uso futuro do DNS global.
   2. Os proprietários migram os projetos para usar DNS zonal.
3. Se a pasta ou a organização não estiver pronta para migrar para o DNS zonal:
   1. Os proprietários migram os projetos prontos para o DNS zonal.
   2. Os proprietários de projeto investigam o uso de DNS global em projetos que não estão prontos.
   3. Os proprietários do projeto aplicam melhorias no caminho de pesquisa ou outras alterações para preparar o projeto para migrar para o DNS zonal.
   4. O administrador da organização verifica novamente o status da prontidão da pasta ou da organização para a migração de DNS por zona.

Limitações

• O DNS zonal não é um substituto completo do DNS global. Há alguns tipos de consulta (entre zonas) que podem não ser resolvidos pelo DNS zonal com a pesquisa automática de caminho de pesquisa. Verifique se as pastas e os projetos da organização estão prontos para migração para garantir que sejam compatíveis com o DNS zonal antes da migração.

• O processo de migração de DNS global para DNS zonal apresenta um novo domínio (ZONE.c.PROJECT_ID.internal) no caminho de pesquisa. Se uma VM com Linux ou Unix já tiver seis domínios no caminho de pesquisa, verifique se ela está sendo executada com a versão 2.26 ou mais recente do glibc. Os clientes DHCP com glibc 2.25 e anteriores só oferecem suporte a até seis domínios de pesquisa. Portanto, pode haver o risco de descartar um domínio de pesquisa atual. Esse limite não se aplica a VMs que usam:

  • Imagens do Windows
  • Imagens do Container-Optimized OS
  • Imagens do Debian 10 ou mais recentes
  • Fedora CoreOS (versão 27 ou mais recente)
  • Imagens do RHEL 8 ou mais recentes
  • Imagens do Ubuntu versão 18.04 ou mais recente
  • Outras imagens com a versão 2.26 ou mais recente do glibc

• Ativar a melhoria do caminho de pesquisa adiciona mais alguns domínios de pesquisa, como NEIGHBOR_ZONE.c.PROJECT_ID.internal. Conforme mencionado na limitação anterior, os domínios no caminho de pesquisa poderão ser removidos se o limite de domínios do caminho de pesquisa for excedido ao usar o glibc versão 2.25 ou anterior.

• Para usar as melhorias no caminho de pesquisa com o Google Kubernetes Engine, use o Google Kubernetes Engine versão 1.26 ou posterior.

Verificar a versão do glibc

Para verificar a versão do glibc usada pela sua VM:

1. Conecte-se à VM do Linux.
2. Execute ldd --version para acessar a versão glibc.

Verifique o número de domínios de pesquisa se estiver usando o glibc 2.25 ou anterior

1. Conecte-se à VM do Linux.

2. Verifique se a VM Linux já tem seis domínios no caminho de pesquisa. Você pode executar cat /etc/resolv.conf para visualizar essas informações.

Etapas do administrador da organização

Como administrador da organização, você executa as seguintes tarefas:

• Verifique se sua organização usa o DNS global por padrão.
• Determine quais projetos em uma pasta ou organização usam o DNS global.
• Determine se uma pasta está pronta para migrar para o DNS zonal.
• Configure o DNS zonal como padrão para novos projetos.
• Pastas isentas que não estão prontas para migrar para o DNS zonal da restrição da política da organização.

Verificar se sua organização usa o DNS global por padrão

O tipo padrão de nome DNS interno para sua organização é determinado pela data em que a organização foi criada e se a restrição de política da organização constraints/compute.setNewProjectDefaultToZonalDNSOnly foi aplicada.

Determinar quais projetos em uma pasta ou organização usam DNS global

Para determinar quantos projetos estão usando DNS global, recomendamos usar o BigQuery para criar uma tabela que liste os projetos relativos à organização e os metadados deles. Em seguida, use essa tabela para executar uma consulta que exponha a contagem do total de projetos que usam DNS global.

1. crie um conjunto de dados do BigQuery;

2. Exporte os metadados do recurso da sua organização para uma tabela do BigQuery.

   1. Verifique se a API Cloud Asset Inventory está ativada.
   2. Configure as permissões necessárias para usar a API Cloud Asset Inventory.

   3. Use o seguinte comando da CLI gcloud para exportar o recurso compute.googleapis.com/Project:

      gcloud asset export \
         --content-type resource \
         --organization 'ORGANIZATION_ID' \
         --bigquery-table 'projects/PROJECT_ID/datasets/DATASET_ID/tables/TABLE_NAME' \
         --asset-types='compute.googleapis.com/Project' \
         --output-bigquery-force
      

      Substitua:

      • ORGANIZATION_ID: o número do ID da organização
      • PROJECT_ID: o ID do projeto;
      • DATASET_ID: o nome do conjunto de dados do BigQuery.
      • TABLE_NAME: a tabela para a qual você está exportando os metadados. Se a tabela não existir, ela será criada.

3. Vá para a página BigQuery no console do Google Cloud.

4. Selecione add_box Criar uma nova consulta.

5. Na área de texto do editor de consultas, insira a seguinte consulta do GoogleSQL e clique em play_arrow Executar.

   SELECT
     JSON_VALUE(SAFE.PARSE_JSON(resource.data).vmDnsSetting) AS vmDnsSetting,
     count(*) as project_count
   FROM PROJECT_ID.DATASET_ID.TABLE_NAME
   GROUP BY 1
   

   Substitua:

   • PROJECT_ID: o ID do projeto;
   • DATASET_ID: o nome do conjunto de dados do BigQuery.
   • TABLE_NAME: a tabela que contém os metadados exportados, da etapa 2.

   Os projetos com o valor ZONAL_ONLY para vmDnsSetting têm o DNS zonal configurado. Caso contrário, os projetos estarão configurados para usar o DNS global.

6. Opcional: para ter acesso a uma visualização detalhada de vmDnsSetting para cada projeto, insira a seguinte consulta do GoogleSQL e clique em play_arrow Executar.

   SELECT
     SUBSTR(name,35) as project_id,
     JSON_VALUE(SAFE.PARSE_JSON(resource.data).vmDnsSetting) AS vmDnsSetting
   FROM PROJECT_ID.DATASET_ID.TABLE_NAME
   

Determinar se uma pasta está pronta para migrar para o DNS zonal

Esta etapa usa um script bash e a tabela do BigQuery criadas na seção anterior para determinar a prontidão da migração da pasta.

• A pasta estará pronta se nenhum dos projetos tiver feito consultas incompatíveis com o DNS zonal nos últimos 30 dias.
• Se uma pasta não estiver pronta para migração, o script vai responder com os IDs do projeto na pasta que estão fazendo com que ela não esteja pronta para a migração. Os projetos nesta lista de resultados ainda não são compatíveis com DNS zonal e exigem mais ações.

Siga estas etapas:

1. Consiga o ID da pasta. Se você não souber o ID da pasta:
   1. No console do Google Cloud, acesse a página Recursos gerenciados.
   2. Aplique o filtro Name:FOLDER_NAME para conseguir o ID da pasta.

2. Consultar a tabela do BigQuery com os dados compute.Project assets exportados.

   Consulte Determinar quais projetos em uma pasta ou organização usam o DNS global para ver instruções sobre como criar a tabela do BigQuery.

   Digite a seguinte consulta do GoogleSQL e clique em play_arrow Executar:

   SELECT
     SUBSTR(name,35) AS project_id,
   FROM PROJECT_ID.DATASET_ID.TABLE_NAME
   WHERE CONTAINS_SUBSTR(ancestors, 'FOLDER_NUMBER')
   

   Substitua:

   • PROJECT_ID: o ID do projeto;
   • DATASET_ID: o nome do conjunto de dados do BigQuery.
   • TABLE_NAME: a tabela que contém os metadados exportados.
   • FOLDER_NUMBER: o número do ID da pasta.

3. Copie a lista de IDs de projetos e salve-a em um arquivo.

4. Execute o script bash a seguir. O script faz a iteração dos IDs do projeto no arquivo salvo para determinar se uma pasta está pronta para migração.

#!/bin/bash
inaccessible_projects=()
unready_projects=()

for project in $(cat ~/FILENAME | tr '\n' ' '); do
  echo -e "Checking project $project..."
  ERROR=`curl -s --request POST "https://monitoring.googleapis.com/v3/projects/$project/timeSeries:query"   -H "Authorization: Bearer $(gcloud auth print-access-token)"   -H "Accept: application/json"   -H "Content-Type: application/json"   --data '{"query":"fetch compute.googleapis.com/Location | metric '"'"'compute.googleapis.com/global_dns/request_count'"'"' | filter metric.zonal_dns_readiness = '"'"'zonal_dns_risky'"'"' | every 30d | within 30d"}'   --compressed | jq --raw-output '.error'`
  if ! [[ "$ERROR" -eq "null" ]]; then
    inaccessible_projects+=($project)
    continue
  fi
  QUERY_COUNT=`curl -s --request POST "https://monitoring.googleapis.com/v3/projects/$project/timeSeries:query"   -H "Authorization: Bearer $(gcloud auth print-access-token)"   -H "Accept: application/json"   -H "Content-Type: application/json"   --data '{"query":"fetch compute.googleapis.com/Location | metric '"'"'compute.googleapis.com/global_dns/request_count'"'"' | filter metric.zonal_dns_readiness = '"'"'zonal_dns_risky'"'"' | every 30d | within 30d"}'   --compressed | jq --raw-output '.timeSeriesData[0].pointData[0].values[0].int64Value'`
  if [[ "$QUERY_COUNT" -ne "null" ]] && [[ "$QUERY_COUNT" -ne "0" ]]; then
    unready_projects+=($project)
  fi
done

error_len=${#inaccessible_projects[@]}
unready_len=${#unready_projects[@]}

echo -e "$error_len projects were inaccessible"
echo -e "$unready_len projects were not ready for migration"

if [ $error_len -ne 0 ]; then
  echo "Unable to access the following projects:"
  for project in "${inaccessible_projects[@]}"; do
    echo "$project"
  done
fi
if [ $unready_len -ne 0 ]; then
  echo "The following projects are not ready for migration:"
  for project in "${unready_projects[@]}"; do
    echo "$project"
  done
fi

if (( $error_len + $unready_len > 0 )); then
  echo "This folder is NOT ready for gDNS -> zDNS migration."
else
  echo "This folder is ready for gDNS -> zDNS migration."
fi

Substitua FILENAME pelo nome do arquivo em que você salvou a lista de IDs do projeto.

Transmita os resultados da análise de prontidão para migração aos proprietários do projeto:

• Para pastas e projetos com segurança para migração, notifique os proprietários do projeto que eles podem começar a migrar projetos prontos.
• No caso de pastas que contenham projetos que não podem ser migrados, instrua os proprietários de projetos a modificar os projetos que não estão prontos para migração.

Aplicar DNS zonal por padrão para novos projetos

Se um novo projeto for criado em uma organização criada antes de 6 de setembro de 2018, por padrão, o tipo de DNS interno usado pelo projeto será o DNS global. Para isolar qualquer falha no registro DNS para zonas individuais, é possível aplicar a política da organização constraints/compute.setNewProjectDefaultToZonalDNSOnly no nível da organização ou da pasta.

Quando você define uma política da organização para substituir o tipo de DNS interno padrão, os projetos recém-criados usam o DNS zonal por padrão. A política da organização não afeta os projetos atuais em que a API Compute Engine já está ativada. Para alternar projetos atuais para que usem DNS por zona, consulte Como alternar projetos atuais para o DNS zonal.

Para aplicar essa alteração de política, é preciso ter acesso no nível da pasta ou da organização com o papel do IAM roles/orgpolicy.policyAdmin.

Siga os seguintes passos para definir a política da organização para uma pasta ou organização:

1. Faça login no console do Google Cloud como superadministrador do Google Workspace ou do Cloud Identity.

2. No console, acesse a página Políticas da organização.

   Acessar as políticas da organização

3. Selecione a pasta ou a organização que contém as políticas da organização que você quer visualizar. O console do Google Cloud exibe uma lista das restrições da política da organização disponíveis. A lista pode abranger várias páginas.

4. Para encontrar a política para aplicar DNS por zona, clique em Filtrar e selecione Nome. Em seguida, defina o nome do filtro como Define a configuração de DNS interno para novos projetos somente para DNS por zona.

5. Clique no nome da política para ver os detalhes dela.

   A página de detalhes da política fornece informações sobre a restrição e como a restrição é aplicada no momento.

   Por padrão, a aplicação é indefinida para uma pasta ou organização. No entanto, se uma pasta pai tiver uma aplicação definida, ela será herdada da pasta mãe mais próxima que tem uma aplicação definida. Para mais informações, consulte Noções básicas sobre a avaliação da hierarquia.

6. Para personalizar a política da organização, clique em Editar.

7. Na página de edição, selecione Personalizar.

8. Em Aplicação, selecione Ativada.

   Isso define o tipo de DNS interno padrão para todos os novos projetos na organização como DNS zonal.

9. Clique em Salvar.

Para validar a alteração da política da organização, crie um novo projeto na pasta ou organização, depois crie e inicie uma instância de VM e verifique se a VM está ativada para DNS por zona.

Se o DNS global interno for necessário para resolver uma consulta de nome DNS integrada à carga de trabalho, é possível reverter essa alteração no nível da organização ou da pasta desativando a aplicação.

As pastas isentas não estão prontas para migrar para o DNS zonal

Se houver apenas algumas pastas em uma organização que não estejam prontas para migrar para o DNS zonal, recomendamos definir uma política da organização no nível da organização, mas conceder uma isenção para as pastas que ainda não foram prontos para a migração.

O exemplo a seguir mostra uma hierarquia da organização em que apenas uma pasta não está pronta para migrar para o DNS zonal.

organização/exemplo.com

• folders/101
  • projects/301 (pronta para a migração)
  • folders/201
    • projects/303 (NÃO está pronto)
    • projects/304 (pronta para a migração)
• folders/102
  • projects/302 (pronta para a migração)

Para isentar uma pasta da política da organização, conclua as etapas a seguir para definir a opção de aplicação da política no nível da pasta como Off.

1. Faça login no console do Google Cloud como superadministrador do Google Workspace ou do Cloud Identity.

2. No console, acesse a página Políticas da organização.

   Acessar as políticas da organização

3. Clique em Selecionar e escolha as pastas que você quer isentar da política da organização.

   O console do Google Cloud exibe uma lista de restrições de políticas da organização para essa pasta em uma ou mais páginas.

4. Para encontrar a restrição da política da organização que aplica o DNS zonal:

   1. Clique em Filtrar.
   2. Selecionar {NOME}
   3. Defina o nome do filtro como Define a configuração do DNS interno para novos projetos como Somente DNS zonal.

5. Clique no nome da restrição da política da organização para abrir a página Detalhes da política.

6. Clique em Editar.

7. Na página Editar, selecione Personalizar.

8. Em Aplicação, selecione Desativada para desativar a aplicação da restrição. Isso significa que o tipo de DNS interno padrão para todos os projetos na pasta é determinado pelo horário de criação da organização.

9. Clique em Salvar.

Para mais informações sobre como personalizar as restrições da política da organização, consulte Como personalizar políticas para restrições booleanas na documentação do Resource Manager.

Etapas do proprietário do projeto

Como proprietário do projeto, você executa as seguintes tarefas durante a migração do DNS global para o DNS zonal:

• Determine o tipo de DNS interno padrão para seu projeto.
• Determine se o projeto está pronto para migrar para o DNS zonal.
• Migre um projeto usando DNS zonal.
• Rastrear o uso do DNS global no projeto.
• Modifique projetos que não estão prontos para migrar para o DNS zonal.
• Verifique se a migração do projeto para o DNS zonal foi concluída

Os proprietários de projetos também podem concluir estas tarefas opcionais:

• Reverta um projeto para usar o DNS global.
• Ocultar o banner de migração de DNS zonal.

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.

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

Determinar se o projeto está pronto para migrar

No console do Google Cloud, na página Instâncias de VM, se o projeto precisar migrar para o DNS zonal, você verá um banner de notificação sobre essa migração.

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

Se o projeto não estiver pronto para migrar para o DNS zonal, um banner diferente será exibido.

Para ver seu uso de DNS global, clique no botão Ver uso de DNS global. Isso vai direcionar você para a página Buscador de registros no console do Google Cloud. Nesta página, é possível conferir os registros de consulta de bloqueio de migração dos últimos 30 dias. Quando você clica no link no banner, a página Buscador de registros é configurada para usar o filtro logName para extrair consultas DNS globais e campos de registro relativos.

Para ver essas informações sem usar o botão no banner, faça o seguinte:

1. No console do Google Cloud, acesse a página do Explorador de registros.

   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.

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

Rastrear o uso de DNS global no projeto

Há duas métricas criadas para rastrear a prontidão do projeto para migrar para DNS zonal:

• zonal_dns_ready: o número agregado de consultas concluídas no intervalo de tempo especificado que podem ser resolvidas usando o DNS zonal em vez do DNS global.
• zonal_dns_risky: o número agregado de consultas concluídas durante o intervalo de tempo especificado que não podem ser resolvidas usando DNS zonal. Para essas consultas, o Compute Engine não conseguiu determinar o endereço IP interno relativo a partir do nome do host atual. Se essa métrica tiver um valor diferente de zero, o projeto não estará pronto para migração.

O intervalo usado por essas métricas é de 100 dias.

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 leaderboard 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.

   

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. Continue com as etapas em Modificar projetos que não estão prontos para migração.

Migrar projetos prontos para o DNS zonal

Em geral, use o seguinte processo de migração:

1. Verifique os aplicativos e atualize-os para solucionar problemas de compatibilidade com as configurações somente por zona:
   • Se você tiver algum aplicativo que use nomes DNS globais codificados, atualize-os para usar nomes DNS zonais.
   • Se algum aplicativo usar nomes de VM para acessar VMs em outra zona, verifique se o nome da zona de destino foi adicionado na consulta, por exemplo: DESTINATION_VM_NAME.DESTINATION_ZONE_NAME.
   • Para resolver nomes DNS de VMs em projetos de serviço que usam uma rede VPC compartilhada, use o nome de domínio totalmente qualificado (FQDN, na sigla em inglês) zonal das VMs.

2. Clique no botão Usar DNS zonal no banner da página Instâncias de VM do Console do Google Cloud. Isso altera os metadados do projeto para usar o DNS zonal.

   Se preferir, modifique manualmente os projetos para usar o DNS zonal por padrão, conforme descrito em Atualizar manualmente projetos e VMs para usar o DNS zonal e Impedir novos projetos. do uso do DNS global por padrão.

Atualizar manualmente projetos e VMs para usar o DNS zonal

Depois de determinar que o projeto está pronto para migrar para o DNS zonal, configure o projeto e as VMs para usar apenas nomes DNS zonais. Basta atualizar os metadados. Ative o DNS zonal para suas VMs definindo a entrada de metadados vmDnsSetting para o projeto ou a VM. Se você definir a entrada de metadados vmDnsSetting para uma VM específica, ela modificará qualquer configuração vmDnsSetting herdada dos metadados do projeto para essa VM.

A variável vmDnsSetting é compatível com as seguintes configurações:

• Recomendado: defina vmDnsSetting=ZonalOnly nos metadados do projeto. Isso significa que as VMs só podem ser acessadas pelos nomes DNS por zona (VM_NAME.ZONE.c.PROJECT_ID.internal) ao usar caminhos de pesquisa. As VMs 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 VMs na mesma zona e mesmo projeto podem acessar um ao outro usando o nome global quando esta configuração está em vigor. Outras VMs podem acessar VMs com vmDnsSetting definida para ZonalOnly usando apenas os nomes DNS por zona e não podem acessar essas VMs usando os nomes DNS globais ou os caminhos de pesquisa. Essa é a opção preferencial e mais confiável, contanto que seus apps possam ser compatíveis.

  A configuração vmDnsSetting=ZonalOnly é a configuração padrão para VMs em projetos independentes e naqueles criados em uma organização que ativou a API Compute Engine depois de 06 de setembro de 2018.

• Defina vmDnsSetting=GlobalDefault para que as VMs registrem nomes DNS globais e por zona, mas use apenas nomes globais como nomes de domínio padrão e entradas de caminho de pesquisa. Essa é a configuração padrão para VMs em projetos independentes e naqueles criados em uma organização que ativou a API Compute Engine antes de 06 de setembro de 2018.

Para informações sobre como definir metadados de projeto ou valores de metadados de VM, consulte Configuração de metadados personalizados.

Depois de configurar a entrada de metadados vmDnsSetting para uma VM, atualize o lease de DHCP na VM. Você pode atualizar o lease reiniciando a VM ou aguarde até que a concessão expire ou execute um dos seguintes comandos:

• VMs do Linux: sudo dhclient -v -r
• VMs do Windows Server: ipconfig /renew

Depois de atualizar o lease de DHCP, verifique se a VM está ativada para DNS por zona.

Modificar projetos que não estão prontos para migração

Um projeto que não está pronto para migrar significa que pelo menos uma consulta DNS arriscada foi feita em um determinado período, como nos últimos 30 ou 100 dias. Uma consulta arriscada é uma chamada para uma VM usando um nome DNS global (VM_NAME.c.PROJECT_ID.internal) que não pode ser resolvido usando um nome DNS zonal (VM_NAME.ZONE.c.PROJECT_ID.internal). Consultas arriscadas podem ter os seguintes atributos:

• Fazer uma chamada para uma VM em um projeto diferente
• Fazer uma chamada para uma VM em uma zona diferente

Para projetos com consultas arriscadas, geralmente é necessário algum trabalho extra para eliminar todas as buscas DNS arriscadas antes da migração.

Para os projetos que não estão prontos para migração, siga estas etapas:

1. Ative a melhoria do caminho de pesquisa para resolver buscas de nome DNS entre zonas. Assim, os projetos podem ser preparados para migração sem afetar os recursos.
2. Se o ajuste de caminho de pesquisa não fizer a transição de todas as consultas entre zonas, atualize manualmente as consultas para usar nomes DNS zonais.

Sobre o recurso de melhoria do caminho de pesquisa

Por padrão, a maioria das distribuições Linux armazena informações de DHCP em resolv.conf. Confira a seguir um resolv.conf file global mínimo:

domain c.PROJECT_ID.internal
search c.PROJECT_ID.internal. google.internal.
nameserver 169.254.169.254

A opção de configuração search é usada para listar os nomes de host a serem usados ao executar a resolução de DNS. O servidor DNS tenta resolver a consulta usando cada um dos nomes de host no caminho de pesquisa, por sua vez, até que uma correspondência de registro DNS seja encontrada. Por exemplo, se uma VM chamar ping my-vm, os domínios no caminho de pesquisa serão anexados à consulta original para receber os nomes de domínio totalmente qualificados (FQDN, na sigla em inglês). Por exemplo, usando my-vm.c.PROJECT_ID.internal. Se houver uma correspondência, o resolvedor de DNS retornará um endereço IP interno na resposta. Caso contrário, ele tentará resolver o nome DNS usando o próximo domínio no caminho de pesquisa.

Adicionar domínios zonais extras ao caminho de pesquisa da VM pode preparar alguns projetos para a migração. Por exemplo, suponha que a VM esteja localizada na zona us-west4-c. Essa VM faz uma chamada para outra VM chamada myapp-vm, localizada na zona us-west4-b.

• Quando você faz uma chamada para a VM como myapp-vm, o Compute Engine tenta resolver o nome DNS usando um FQDN que anexa um dos caminhos de pesquisa ao nome da VM, como myapp-vm.c.PROJECT_ID.internal.
• Se a VM de destino usar DNS zonal, o FQDN da VM de destino será registrado como myapp-vm.us-west4-b.c.PROJECT_ID.internal. Como resultado, o nome DNS não pode ser resolvido.
• Se você adicionar us-west4-b.c.PROJECT_ID.internal à lista de pesquisa, o nome DNS myapp-vm poderá ser resolvido quando us-west4-b.c.PROJECT_ID.internal for anexado ao nome da VM.

O Google oferece um recurso de melhoria do caminho de pesquisa que pesquisa automaticamente o nome DNS zonal de uma VM em todas as zonas da mesma região que a VM. Como resultado, as consultas entre zonas podem ser resolvidas sem exigir uma atualização do arquivo resolv.conf ou da política de DHCP. As melhorias no caminho de pesquisa podem funcionar para resolver consultas entre zonas na região em até 80% do tempo. Esse recurso deve ajudar a maioria dos projetos com consultas arriscadas a ficar pronta para migrar para o DNS zonal.

Ative a melhoria do caminho de pesquisa para resolver pesquisas de nome DNS entre zonas

Siga estas etapas para ativar o recurso de melhoria do caminho de pesquisa.

1. Execute o comando project-info add-metadata da seguinte maneira:

   gcloud compute project-info add-metadata  \
       --metadata=enable-search-path-improvement=true
   

2. Permita que o projeto use essa configuração por alguns dias e, em seguida, verifique a métrica de monitoramento para ver se ainda há consultas DNS globais arriscadas ou entre zonas.

   • Se o valor for 0, o projeto estará pronto para ser migrado.
   • Se o projeto retornar um valor diferente de zero, altere todos os nomes de consultas DNS globais para usar o FQDN zonal, conforme descrito na próxima seção.

Atualizar manualmente as consultas para usar nomes DNS zonais

Se o uso do recurso de melhoria do caminho de pesquisa para adicionar outros domínios zonais ao caminho de pesquisa do nome do DNS não fizer a transição de todas as consultas entre zonas, use a Análise de registros para visualizar o uso do DNS global no projeto.

Para identificar as consultas DNS globais que precisam ser alteradas manualmente para usar nomes de domínio totalmente qualificados (FQDN, na sigla em inglês) por zona, conclua as etapas a seguir:

1. Siga as etapas em Determinar se o projeto está pronto para migrar para ver o uso de DNS global de um projeto. Use-o para acessar e consultar o uso de DNS global das VMs no seu projeto.

2. 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.

   

3. Use as informações no jsonPayload para determinar qual FQDN usar para atualizar manualmente suas consultas DNS globais para usar 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:

   • 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.

Depois de atualizar as consultas DNS globais para usar DNS zonal:

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 arriscadas foram removidas.

Verificar se a migração do projeto para o DNS zonal foi concluída

1. Repita as etapas em Verificar se o projeto usa o DNS global por padrão.

2. Para testar se os metadados do projeto foram atualizados, execute o seguinte comando:

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

   O comando retornará ZONAL_ONLY.

3. Verifique se o nome DNS interno de uma VM usa um nome DNS zonal.

4. Para verificar se a política da organização constraints/compute.setNewProjectDefaultToZonalDNSOnly está sendo aplicada, você pode:

   1. Crie um projeto na pasta ou na organização.
   2. Criar e iniciar uma instância de VM
   3. Verifique se a VM usa um nome DNS zonal.

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 VM ou do contêiner.

Reverter para o uso de DNS global em uma organização ou pasta

Para reverter uma organização ou pasta para usar o DNS global, conclua as etapas a seguir.

1. Desative a política da organização constraints/compute.setNewProjectDefaultToZonalDNSOnly no nível da organização ou da pasta. Para instruções sobre como modificar essa política, consulte Aplicar DNS zonal por padrão para novos projetos.

   Defina a aplicação de Define a configuração do DNS interno para novos projetos como Somente DNS zonal como Desativada.

2. Se você quiser voltar a usar o DNS global para toda a organização, verifique se nenhuma das pastas na organização está aplicando a política da organização constraints/compute.setNewProjectDefaultToZonalDNSOnly.

3. Use as seções a seguir para verificar se o DNS global está configurado para projetos, VMs e contêineres.

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 metadados de projeto ou valores de metadados de VM, consulte Configuração de metadados personalizados.

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

3. Atualize a concessão de DHCP em cada VM. Você pode atualizar a concessão reiniciando a VM, para isso aguarde até que a concessão expire ou execute um dos seguintes comandos:

   • VMs do Linux: sudo dhclient -v -r
   • VMs do Windows Server: ipconfig /renew

Reverter para o uso de DNS global para uma VM

Para reverter uma VM específica para o uso de DNS global, conclua as etapas a seguir.

1. Adicione o seguinte aos metadados da VM: vmDnsSetting=GlobalDefault.

   Para informações sobre como definir valores de metadados da VM, consulte Como definir metadados personalizados.

2. Para forçar a alteração da configuração de DNS, reinicie a rede da VM 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.

Ocultar o banner de migração de DNS zonal no console do Google Cloud

Clique no botão Dispensar no banner de notificação de migração de DNS zonal que aparece na página Instâncias de VM do console do Google Cloud. Isso impede que o banner apareça no projeto indefinidamente.

Se você dispensou o banner, mas quer que ele apareça novamente, entre em contato com o Cloud Customer Care para receber ajuda.

A seguir

• Consulte a hierarquia de recursos do Google Cloud para informações sobre a relação entre organizações, pastas e projetos.
• Saiba mais sobre o DNS interno para o Compute Engine.