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.

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

Para mais informações sobre como conceder papéis, consulte Gerenciar acesso.

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:

Permissões necessárias

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

  • Defina uma restrição de política da organização: orgpolicy.*
  • Determine se uma pasta está pronta para migrar para o DNS zonal:
    • resourcemanager.folders.get
    • resourcemanager.folders.list
    • resourcemanager.organizations.get
    • resourcemanager.projects.get
    • resourcemanager.projects.list
  • 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 papéis personalizados 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.

A imagem mostra um fluxograma das etapas envolvidas na migração para o DNS zonal

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:

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.

Console

  1. Acesse a página IAM e administrador> Identidade e organização no console.

    Acessar "Identidade e organização"

  2. Verifique a data de inscrição da organização.

    Uma captura de tela da página do console "Identidade e organização" mostrando a data de conclusão da inscrição

    • Se a organização foi criada depois de 6 de setembro de 2018, ela usa o DNS zonal por padrão. Nesse caso, nenhuma outra ação é necessária.
    • Se a organização foi criada antes de 6 de setembro de 2018, ela usa o DNS global por padrão e precisa ser migrada para o DNS zonal.

  3. Se a organização usa o DNS global por padrão, verifique se uma restrição da política da organização define o tipo de DNS padrão em todos os projetos recém-criados como DNS zonal.

    1. Acesse a página IAM e administrador>Políticas da organização no console do Google Cloud.
    2. No campo Filtro, digite constraints/compute.setNewProjectDefaultToZonalDNSOnly.
    3. Se a restrição estiver configurada, clique no nome Define a configuração do DNS interno para novos projetos como "Somente DNS zonal".
    4. Na página Detalhes da política, verifique o Status.
      • Se o status for Aplicado, o tipo de DNS interno padrão será DNS zonal para todos os novos projetos criados na organização.
      • Caso contrário, o tipo de DNS padrão para o projeto ainda será determinado pelo horário de criação da organização.
    5. Se a restrição não tiver sido configurada para a organização, o tipo de DNS padrão para o projeto será determinado pelo horário de criação da organização, conforme descrito na primeira etapa.

gcloud

Use os comandos organizations describe e resource-manager org-policies list para determinar o tipo de DNS padrão de uma organização.

  1. Verifique o valor dos metadados creationTime da organização.

    gcloud organizations describe ORGANIZATION_ID

    Substitua ORGANIZATION_ID pelo número do ID ou nome de domínio da organização.

    • Se a organização foi criada depois de 6 de setembro de 2018, ela usa o DNS zonal por padrão. Nesse caso, sua organização já está usando DNS zonal e nenhuma outra ação é necessária.
    • Se a organização foi criada antes de 6 de setembro de 2018, ela usa o DNS global por padrão e precisa ser migrada para o DNS zonal.

  2. Se a organização usa o DNS global por padrão, determine se uma restrição da política da organização está configurada para definir o tipo de DNS padrão em todos os projetos recém-criados como DNS zonal.

    gcloud resource-manager org-policies list --organization=ORGANIZATION_ID \
   --filter="constraints/compute"

    Na saída, procure constraints/compute.setNewProjectDefaultToZonalDNSOnly.

    1. Se a restrição estiver configurada e o Status for Enforced, o tipo de DNS interno padrão será DNS zonal para todos os novos projetos criados na organização.
    2. Se a restrição não tiver sido configurada para a organização ou não for aplicada, o tipo de DNS interno padrão será determinado pelo horário de criação da organização, conforme descrito na primeira etapa.

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 Criar uma nova consulta.

  5. Na área de texto do editor de consultas, insira a seguinte consulta do GoogleSQL e clique em 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 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 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:

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

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

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:

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

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.

    Acessar a página "Metadados"

  2. Na guia Metadados, confira a configuração vmdnssetting. O valor 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.

gcloud

    In the Google Cloud console, activate Cloud Shell.

    Activate Cloud Shell

    At the bottom of the Google Cloud console, a Cloud Shell session starts and displays a command-line prompt. Cloud Shell is a shell environment with the Google Cloud CLI already installed and with values already set for your current project. It can take a few seconds for the session to initialize.

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

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.

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

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

Uma captura de tela do banner "Não está pronto para migração para o DNS zonal" no console

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.

Como alternativa, insira o seguinte no campo de consulta:

   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 painel de navegação do console do Google Cloud, selecione Monitoramento e  Metrics Explorer:

    Acesse o Metrics explorer

  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. 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 podem ser acessadas somente pelos nomes de DNS zonais (VM_NAME.ZONE.c.PROJECT_ID.internal). As VMs ainda mantêm os caminhos de pesquisa global e por zona, mas os nomes DNS globais, que não incluem o ZONE como parte do nome DNS interno, deixam de funcionar. Outras VMs podem lidar com VMs com vmDnsSetting definida para ZonalOnly usando apenas os nomes DNS por zona e não podem abordar 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 simples:

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.

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

  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

  • Para o Debian:

    sudo systemctl restart networking

  • 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