Atualize os seus projetos para usar o DNS zonal

Este documento explica como migrar um projeto existente do DNS global para o DNS zonal. O DNS zonal melhora a fiabilidade ao isolar as indisponibilidades nas zonas, o que impede interrupções nos serviços essenciais, como a criação de instâncias e a autorrecuperação.

Antes de começar

  • Se ainda não o tiver feito, configure a autenticação. A autenticação valida a sua identidade para aceder a Google Cloud serviços e APIs. Para executar código ou exemplos a partir de um ambiente de desenvolvimento local, pode autenticar-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. Instale a CLI Google Cloud. Após a instalação, inicialize a CLI gcloud executando o seguinte comando: 

      gcloud init

      Se estiver a usar um fornecedor de identidade (IdP) externo, primeiro tem de iniciar sessão na CLI gcloud com a sua identidade federada.

    2. Set a default region and zone.

    REST

    Para usar os exemplos da API REST nesta página num ambiente de desenvolvimento local, usa as credenciais que fornece à CLI gcloud.

      Instale a CLI Google Cloud. Após a instalação, inicialize a CLI gcloud executando o seguinte comando: 

      gcloud init

      Se estiver a usar um fornecedor de identidade (IdP) externo, primeiro tem de iniciar sessão na CLI gcloud com a sua identidade federada.

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

Funções necessárias

Para receber as autorizações de que precisa para migrar projetos para usar o DNS zonal, peça ao seu administrador para lhe conceder as seguintes funções de IAM:

Para mais informações sobre a atribuição de funções, consulte o artigo Faça a gestão do acesso a projetos, pastas e organizações.

Estas funções predefinidas contêm as autorizações necessárias para migrar projetos para usar o DNS zonal. Para ver as autorizações exatas que são necessárias, expanda a secção Autorizações necessárias:

Autorizações necessárias

São necessárias as seguintes autorizações para migrar projetos para usar o DNS zonal:

  • Verifique os nomes de DNS globais e os metadados da VM: compute.projects.get
  • Defina metadados numa VM: compute.instances.setMetadata
  • Defina metadados ao nível do projeto: compute.projects.setCommonInstanceMetadata
  • Se as suas VMs usarem contas de serviço: iam.serviceAccounts.actAs

Também pode conseguir estas autorizações com funções personalizadas ou outras funções predefinidas.

Migre o seu projeto para o DNS zonal

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

  1. Verifique se o seu projeto usa o DNS global por predefinição
  2. Determine a prontidão para a migração dos seus projetos através da análise de consultas
  3. Migre projetos compatíveis com o DNS zonal
  4. Corrija consultas incompatíveis
  5. Monitorize os registos de DNS globais para confirmar a prontidão da migração.
  6. Migre os projetos restantes para o DNS zonal
  7. Verifique se uma alteração ao DNS zonal está a afetar o seu projeto

Verifique se o seu projeto usa o DNS global por predefinição

Verifique os seus projetos para ver se têm de migrar da utilização do DNS global para o DNS zonal. Só precisa de migrar projetos configurados para usar o DNS global como predefinição para quaisquer nomes DNS internos criados no projeto.

Consola

  1. Na Google Cloud consola, aceda à página Metadados do Compute Engine.

    Aceda aos metadados

  2. No separador Metadados, veja a definição vmdnssetting, se existir. O valor atribuído indica se o projeto usa o DNS global por predefinição.

    • GlobalDefault: o projeto tem o DNS global ativado.
    • ZonalOnly: o projeto tem o DNS zonal ativado. Não é necessário migrar este projeto.

    Se a definição de metadados vmdnssetting não estiver listada, então verifique se a sua organização usa o DNS global por predefiniçã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 devolvido indica se o projeto usa o DNS global por predefinição.

  • GLOBAL_DEFAULT: o projeto tem o DNS global ativado.
  • ZONAL_ONLY: o projeto tem o DNS zonal ativado. Não é necessário migrar este projeto.

REST

Verifique o valor de vmDnsSetting através do método projects.get. Este exemplo usa um parâmetro de consulta fields para incluir apenas os campos que 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 predefinição.

  • GLOBAL_DEFAULT: o projeto tem o DNS global ativado.
  • ZONAL_ONLY: o projeto tem o DNS zonal ativado. Não é necessário migrar este projeto.

Use a análise de consultas para determinar a disponibilidade para migração de um projeto

Para avaliar se um projeto pode ser migrado para o DNS zonal sem alterações ao código ou alterar a forma como o DNS global é usado, Google Cloud analisa o seu histórico de consultas DNS. Esta análise fornece as seguintes métricas que indicam a compatibilidade do projeto com o DNS zonal:

  • zonal_dns_ready (Consultas compatíveis): esta métrica representa o número total de consultas num período de 100 dias que podem ser resolvidas com êxito através do DNS zonal.

  • zonal_dns_risky (Consultas incompatíveis): esta métrica representa o número total de consultas que não podem ser resolvidas através do DNS zonal. Normalmente, estas consultas envolvem comunicação entre regiões ou outros cenários em que a resolução zonal falha. É fundamental que, se esta métrica tiver um valor diferente de zero, o seu projeto ainda não está pronto para a migração. Tem de resolver estas consultas incompatíveis antes de mudar para o DNS zonal.

Para ver estas métricas, use o Explorador de métricas na Google Cloud consola.

  1. Na Google Cloud consola, aceda à página  Explorador de métricas:

    Aceda ao Metrics Explorer

    Se usar a barra de pesquisa para encontrar esta página, selecione o resultado cujo subtítulo é Monitorização.

  2. No lado direito da barra de ferramentas que contém o campo Selecionar uma métrica, clique em Editor de código, MQL ou PromQL.

  3. Se o campo de entrada de consulta não tiver o título Consulta PromQL, em Idioma, selecione PromQL.

  4. No campo de introdução de consultas, introduza o seguinte texto exatamente como aparece:

    increase({"compute.googleapis.com/global_dns/request_count", monitored_resource="compute.googleapis.com/Location"}[1d])

  5. Clique no botão Executar consulta.

    A Google Cloud consola apresenta 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 ecrã do gráfico das métricas de utilização de DNS global.

  6. Verifique o valor da métrica zonal_dns_risky.

    • Se o valor for 0, o projeto está pronto para a migração para o DNS zonal. Pode migrar o projeto, conforme descrito no artigo Migre projetos que estão prontos para o DNS zonal.
    • Se o valor for um número diferente de zero, como 0.02k, conforme mostrado na captura de ecrã anterior, existem algumas consultas que podem não funcionar após a migração para o DNS zonal. O projeto não está pronto para migração. Continue com os passos em Corrija consultas incompatíveis.

Migre projetos compatíveis com o DNS zonal

Use qualquer 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 na Google Cloud consola.

    1. Quando visualiza a página Instâncias de VM do seu projeto, se o projeto estiver pronto para a migração (for compatível com consultas DNS zonais), a faixa inclui uma recomendação para usar o DNS zonal. Esta recomendação baseia-se na utilização interna do DNS no projeto, mas está limitada aos últimos 30 dias.

      Uma captura de ecrã da faixa de migração para o DNS zonal na consola.

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

    2. Opcional: veja e consulte os metadados da VM para confirmar a alteração dos metadados.

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

    1. Ative o DNS zonal para as suas instâncias definindo a entrada de metadados para o projeto.vmDnsSetting Depois de definir esta entrada de metadados, só é possível aceder às suas instâncias de computação pelos respetivos nomes DNS zonais (VM_NAME.ZONE.c.PROJECT_ID.internal) quando usar caminhos de pesquisa. As instâncias continuam a reter os caminhos de pesquisa zonais e globais, mas os respetivos nomes de DNS globais, que não incluem o ZONE como parte do nome de DNS interno, deixam de funcionar. Apenas as instâncias na mesma região e no mesmo projeto podem aceder umas às outras através do nome global quando esta definição está em vigor.

      Consola

      1. Para atualizar a definição ao nível do projeto, naGoogle Cloud consola, aceda à página Metadados do Compute Engine.

        Aceda à página Metadados personalizados

      2. Clique em Editar.

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

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

        • No campo Chave, introduza VmDnsSetting.
        • No campo Valor, introduza ZonalOnly.

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

      gcloud

      1. Para atualizar a definiçã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 validar as definiçõ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 consultar.

      REST

      Para atualizar a definição de metadados ao nível do projeto, crie um pedido POST usando o método projects.setCommonInstanceMetadata.

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

        Uma impressão digital é uma string aleatória de carateres gerada pelo Compute Engine. A impressão digital muda após cada pedido e, se fornecer uma impressão digital que não corresponda, o pedido é rejeitado.

        Se não fornecer uma impressão digital, não é feita nenhuma verificação de consistência e o pedido projects.setCommonInstanceMetadata é bem-sucedido. Se usar o método instances.setMetadata, é sempre necessária uma impressão digital.

        Para obter 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 é semelhante ao seguinte:

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

      2. Construa um pedido POST ao 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 seu projeto.

    2. Depois de configurar a entrada de metadados vmDnsSetting para o seu projeto, atualize a alocação de DHCP em cada instância desse projeto. Pode atualizar a concessão reiniciando a instância, aguardando que a concessão expire ou executando um dos seguintes comandos:

      Instâncias do Linux 

      sudo dhclient -v -r

      Instâncias do Windows 

      ipconfig /renew

    3. Verifique se o seu projeto usa DNS zonal.

Corrija consultas incompatíveis

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

  • Faça uma chamada para uma instância de computação num projeto diferente
  • Fazer uma chamada para uma instância de computação numa região diferente

Se o seu projeto tiver consultas incompatíveis, a seguinte faixa aparece na página Instâncias de VMs da consola Google Cloud :

Faixa que indica que o seu projeto não está pronto para migrar para o DNS zonal.

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

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

  1. Use o Explorador de registos para aceder e consultar a utilização global de DNS para instâncias de computação do seu projeto.

    Aceda ao Explorador de registos

  2. Selecione o projeto.

  3. Aplique os filtros de recursos e de nomes de registos:

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

    4. Na caixa de diálogo Selecionar nomes de registos, selecione gdnsusage e, de seguida, clique em Aplicar.

    Em alternativa, pode introduzir 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 respetivo ID do projeto e o nome da zona.
    • O nome da VM de destino, o respetivo ID do projeto e o nome da zona.

    • Uma mensagem de depuração que fornece informações sobre como atualizar a consulta DNS global que não pode ser resolvida através de nomes DNS zonais. Estas são consideradas consultas que bloqueiam a migração e que deve 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 ecrã seguinte mostra as informações do campo jsonPayload na página da consola do Logs Explorer.

    Captura de ecrã do jsonPayload nos resultados da consulta do registo gdnsusage.

  5. Use as informações no jsonPayload que obteve no passo anterior para determinar que FQDN usar para atualizar manualmente as suas consultas de DNS globais para usar o DNS zonal e preparar o projeto para a migração. Os exemplos de utilização mais comuns para atualizar o FQDN e resolver a compatibilidade são os seguintes:

    • Nomes DNS internos do servidor de metadados: não é necessária nenhuma ação, uma vez que o nome DNS devolvido vai mudar imediatamente para um FQDN zonal após a migração para o DNS zonal. Se o nome de DNS estiver em cache, só tem de fazer mais uma chamada para atualizar o valor da cache.
    • Nomes DNS internos usados para aceder a VMs noutra região: se tiver uma aplicação que use os nomes DNS internos para VMs em diferentes regiões, pode modificar a política de DHCP ou o ficheiro de configuração para incluir a zona na outra região.
    • FQDN global codificado: se tiver uma aplicação que use nomes de FQDN globais codificados para VMs, pode atualizar a chamada na aplicação para usar o nome DNS interno ou o FQDN zonal. Pode fazer esta alteração através de uma alteração de código ou de uma alteração de configuração no Terraform.
    • VMs em projetos de serviço que usam uma rede de VPC partilhada: para resolver nomes DNS de VMs em projetos de serviço que usam uma rede de VPC partilhada, tem de usar 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 Logs Explorer para consultar novamente a utilização global do DNS. Depois de corrigir todas as consultas de DNS globais de bloqueio, não devem ser apresentados registos de depuração nos resultados da consulta.

    2. Volte a verificar a métrica de monitorização para ver se todas as consultas de DNS incompatíveis foram removidas.

Veja os registos de DNS globais no Explorador de registos

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

Também pode usar o Explorador de registos para estas consultas incompatíveis para fazer o seguinte:

  • Crie painéis de controlo: visualize os seus padrões de consulta DNS globais incompatíveis para obter estatísticas sobre o comportamento de comunicação da sua aplicação.
  • Agregue registos: analise os registos de DNS em toda a sua organização para identificar tendências mais amplas e potenciais áreas de melhoria.

Verifique se uma alteração ao DNS zonal está a afetar o seu projeto

Após a migração para o DNS zonal, é fundamental verificar se as suas aplicações e serviços continuam a funcionar corretamente. Uma vez que o DNS zonal altera a forma como os nomes DNS internos são resolvidos, algumas aplicações podem ter problemas se dependerem de nomes DNS globais.

A secção seguinte descreve como verificar potenciais impactos e como os resolver:

  1. Comunicação de instâncias da linha de comandos

    Tarefa: experimente enviar um ping de uma instância para outra usando a CLI gcloud.

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

    Potencial erro: "Não foi possível resolver o anfitrião" – Isto significa que o VM-A não consegue encontrar o endereço IP para VM-B.

    Resolução: atualize o nome do anfitrião que está a usar para VM-B para o respetivo 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 estiver a usar verificações de estado para grupos de instâncias geridos (MIGs) que dependem de nomes DNS internos, verifique se as verificações de estado estão a ser aprovadas.

    Potencial erro: "Verificação de estado falhou" – Isto indica que a verificação de estado não consegue alcançar o respetivo destino devido a problemas de resolução de DNS.

    Resolução: certifique-se de que a verificação de estado está a usar o FQDN da instância de destino, incluindo o nome da zona.

  3. Exemplos de utilização específicos da aplicação

    Muitas aplicações dependem do DNS interno para tarefas como as seguintes:

    • Estabelecer ligação a bases de dados (por exemplo, Cloud SQL)

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

    • Potenciais erros: estes variam consoante a aplicação, mas podem incluir:

      • "Não é possível estabelecer ligação a SERVICE_NAME"
      • "A ligação excedeu o tempo limite"
      • "No such host is known" (Não existe nenhum anfitrião conhecido)

    • Resolução: verifique a configuração da sua aplicação para se certificar de que está a usar o FQDN (incluindo o nome da zona) quando faz referência a serviços.

Reverta para a utilização do DNS global

Pode anular a migração para o DNS zonal alterando o tipo de DNS interno predefinido para DNS global. Pode fazê-lo ao nível da organização, do projeto, da instância ou do contentor.

Reverta para a utilização do DNS global para um projeto

Para reverter um projeto para a utilização de DNS global, conclua os seguintes passos.

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

    Para obter informações sobre como definir valores de metadados do projeto, consulte o artigo Defina e remova 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 verificar.

  3. Atualize a concessão do DHCP em cada instância. Pode atualizar a concessão reiniciando a instância, aguardando que a concessão expire ou executando um dos seguintes comandos no sistema operativo convidado:

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

Reverta para a utilização do DNS global para uma instância

Para reverter uma instância específica para a utilização de DNS global, conclua os seguintes passos.

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

    Para obter informações sobre como definir valores de metadados de instâncias de computação, consulte o artigo Defina e remova metadados personalizados.

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

    • Para o SO otimizado para contentores ou o 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 Debian:

      sudo systemctl restart networking

    • Para sistemas Linux com nmcli:

      sudo nmcli networking off
sudo nmcli networking on

    • Para Windows:

      ipconfig /renew

Reverter para a utilização do DNS global para um contentor

Se executar a sua aplicação ou carga de trabalho em contentores, no Google Kubernetes Engine ou no ambiente flexível do App Engine, a configuração de DNS nas definições do contentor pode não ser atualizada automaticamente até reiniciar os contentores. Para desativar o DNS zonal nestas apps de contentores, conclua os seguintes passos.

  1. Defina a definição de metadados do projeto vmDnsSetting como GlobalDefault nos projetos que detêm os contentores e as VMs.

  2. Reinicie os contentores para que as respetivas definições de DNS revertam para o estado original.

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

Se tiver problemas com o processo de migração, consulte o guia de resolução de problemas.

O que se segue?