O Google Distributed Cloud (GDC) com isolamento físico oferece recursos de implantação que proporcionam alta disponibilidade e recuperação de desastres. Nesta página, essa funcionalidade é chamada de multizona.
Com várias zonas, é possível executar cargas de trabalho desconectadas e essenciais no GDC, oferecendo alta disponibilidade (HA) e recuperação de desastres (DR) semelhantes aos provedores de nuvem hiperescala pública. O GDC oferece serviços gerenciados e de infraestrutura que são resilientes a falhas locais. Para alguns serviços, você precisa decidir o nível de resiliência que sua carga de trabalho exige. Exemplos de serviços que oferecem recursos multizona:
Para uma lista completa de serviços que oferecem recursos multizona, consulte Serviços do GDC compatíveis com multizona.
O GDC multizona oferece recursos globais de gerenciamento de recursos para simplificar o gerenciamento em todas as zonas do GDC. É possível conferir todos os recursos e serviços do GDC gerenciados em um universo com visibilidade de alertas, integridade, uso, geração de registros, monitoramento e faturamento.
Os universos multizonais no GDC exigem simetria global de recursos e hardware. Essa simetria significa que o hardware e as organizações precisam ser os mesmos em todas as zonas e não podem ser modificados de forma independente em uma zona específica.
A arquitetura multizonal também oferece blocos de construção para atender às metas de recuperação de desastres e continuidade dos negócios. Há três recursos principais que a arquitetura multizonal oferece:
Continuidade dos serviços do plano de controle. Em caso de desastre zonal, a funcionalidade crítica necessária para recuperar uma organização e os serviços associados a ela já estarão presentes em outra zona.
Recursos multizona. Por exemplo, replicação assíncrona de armazenamento entre zonas do GDC.
Serviços gerenciados de várias zonas. Por exemplo, os balanceadores de carga oferecem variantes multizonais controladas por um serviço gerenciado.
O que é uma zona?
Cada zona pode ser um domínio de desastre independente, dependendo de onde ela está localizada. Por exemplo, duas zonas localizadas a 1 km uma da outra em uma zona de subducção estariam no mesmo domínio de desastre. Cada zona é uma implementação completa do GDC com isolamento físico, uma solução de hardware e software que não exige conectividade com Google Cloud em nenhum momento. Uma zona gerencia infraestrutura, serviços, APIs e ferramentas que usam um plano de controle local.
Uma zona isolada do GDC é composta por quatro camadas:
Hardware: o hardware e o design de rack definidos pelo Google.
Infraestrutura: gerencia o hardware e fornece abstrações que permitem que as camadas de software sejam executadas sem referência a configurações específicas do hardware.
Plataforma de serviços: uma estrutura para criar serviços na Distributed Cloud que oferece consistência entre serviços gerenciados e serviços do marketplace.
Serviços gerenciados e do Marketplace: serviços de nuvem voltados ao cliente executados no GDC.
Um grupo de zonas isoladas conectadas é chamado de universo. Para implantar aplicativos tolerantes a falhas com alta disponibilidade que ajudam a proteger contra falhas inesperadas, implante seus aplicativos em várias zonas em um universo.
O que é uma região?
Uma região é um agrupamento de zonas em um universo dentro dos nossos requisitos de latência definidos. Uma zona sem peers próximos o suficiente é considerada como uma região própria. As zonas em uma região precisam ser separadas por pelo menos 10 km para garantir que sejam domínios de desastre separados em muitos regimes de compliance.
As regiões podem estar a centenas de quilômetros de distância. Por isso, o GDC oferece apenas serviços síncronos em regiões. Os serviços assíncronos estão disponíveis dentro e entre regiões.
Os serviços assíncronos realizam a replicação em segundo plano, oferecendo objetivos de ponto de recuperação (RPO) baixos, mas não nulos. Normalmente, os serviços assíncronos permanecem disponíveis durante as partições de rede.
Exemplos de serviços assíncronos isolados do GDC:
- Armazenamento em blocos
- Armazenamento de objetos
As zonas em uma única região precisam atender aos requisitos de latência que permitem a entrega de serviços fortemente consistentes. Os serviços síncronos realizam a replicação imediatamente, garantindo que cada gravação esteja disponível em pelo menos duas zonas. Essa é a etapa principal necessária para atingir o RPO zero. Normalmente, os serviços síncronos têm latência maior do que os serviços não replicados e podem ficar indisponíveis durante partições de rede.
Exemplos de serviços síncronos com isolamento físico do GDC:
- Compartilhamentos de arquivos NFS
- Armazenamento de objetos
O que é um universo?
Zonas com conectividade de rede direta, independente da distância ou latência, e um plano de controle e gerenciamento compartilhado pertencem a um universo. Um universo pode ter no máximo seis zonas.
Cada universo pode consistir em várias zonas organizadas em regiões interconectadas. Por exemplo, duas regiões no estado da Virgínia, nos EUA, e em Amsterdã, na Holanda, respectivamente, cada uma com três zonas:
Região 1 do GDC (Virgínia)
- Zona 1 (us-virginia1-a)
- Zona 2 (us-virginia1-b)
- Zona 3 (us-virginia1-c)
Região 2 do GDC (Países Baixos)
- Zona 1 (eu-ams1-a)
- Zona 2 (eu-ams1-b)
- Zona 3 (eu-ams1-c)
O diagrama a seguir mostra um exemplo de universo do GDC.
Um universo pode ter de uma a seis zonas e um ou dois centros de operações.
Os universos oferecem as seguintes estratégias de recuperação automatizadas, independente da configuração de região:
- Em universos com duas zonas, a recuperação precisa ser acionada manualmente.
- Para universos com três ou mais zonas, a recuperação pode ser acionada automaticamente.
Entre em contato com a operadora para mais informações.
Recursos zonais
Os recursos por zona funcionam apenas em uma zona. Falhas zonais podem afetar alguns ou todos os recursos da zona. Um exemplo de recurso zonal é uma instância de máquina virtual (VM) que reside em uma zona específica. Para mais informações sobre como os recursos zonais são gerenciados em um universo do GDC, consulte Servidores da API Management.
Recursos globais
Os recursos globais são implantados em todas as zonas de um universo, como organizações. Isso proporciona a eles mais disponibilidade em relação aos recursos de zona. Os recursos globais são implantados e gerenciados no servidor da API de gerenciamento global.
Para cada organização, há servidores de API de gerenciamento globais e zonais.
Domínios de desastres
Um domínio de desastre representa uma coleção de recursos que podem ser afetados ao mesmo tempo devido à proximidade física deles. Portanto, é um constructo relacionado à durabilidade usado para simplificar os requisitos de separação de zonas. Normalmente, um único domínio de desastre corresponde a um único campus.
Na maioria dos universos do GDC, o Google não é proprietário das instalações, mas trabalha com fornecedores de colocation que têm data centers que oferecem acesso a infraestrutura robusta, energia redundante e conectividade de alta velocidade. Essa abordagem oferece performance e tempo de atividade ideais para aplicativos e serviços com base na estratégia e nas práticas recomendadas do Google para HA e DR.
Entre em contato com sua operadora para mais informações sobre as especificações do domínio de desastre para seu universo.
APIs globais e zonais
O GDC air-gapped oferece dois níveis de APIs do plano de gerenciamento para criar e gerenciar recursos globais e zonais: APIs globais e APIs zonais. Consulte a documentação sobre servidores de API de gerenciamento globais e zonais para saber como esses tipos de API são gerenciados em um universo do GDC.
As APIs globais e zonais são APIs declarativas do Kubernetes veiculadas em diferentes endpoints, e os recursos do GDC são representados como recursos personalizados do Kubernetes nos servidores de API. Os servidores globais de API compartilham um único cluster etcd distribuído em várias zonas para oferecer consistência forte com tolerância a falhas, ao custo de maior latência e QPS (consultas por segundo) reduzido em comparação com os servidores de API zonais. Em todas as organizações, um servidor de API de gerenciamento zonal fornece a API zonal para que administradores e desenvolvedores gerenciem recursos zonais, e um servidor de API de gerenciamento global fornece a API global para gerenciar recursos globais.
Para mais informações sobre APIs no GDC, consulte a visão geral das APIs.
CLI gdcloud
A CLI gdcloud oferece maneiras de interagir com a API zonal ou global para gerenciar seus recursos e a implantação deles, incluindo:
- Faça login no URL do console zonal ou global usando a CLI
- Usar uma flag da CLI zonal para ações específicas da zona
O URL global é o que é configurado por padrão ao inicializar a CLI gdcloud. Você pode atualizar sua configuração do gdcloud para definir URLs zonais e fazer login neles para concluir tarefas específicas da zona.
Da mesma forma, a CLI gdcloud oferece uma flag --zone que pode ser definida para
muitas tarefas de gerenciamento de recursos em grupos de comandos. Quando você faz login na
configuração global de URL, suas ações da CLI em recursos globais são aplicadas a
todas as zonas em que estão no escopo.
Para mais informações sobre como usar a CLI gdcloud para serviços zonais e globais, consulte Gerenciar recursos em várias zonas.
Console do GDC
O console do GDC de uma determinada organização pode ser acessado em todas as zonas do mesmo universo. Portanto, é possível usar o console do GDC para gerenciar todos os recursos globais e zonais em uma organização.
Os seguintes recursos multizona estão disponíveis no console do GDC:
Navegar usando um nome de domínio totalmente qualificado (FQDN): é possível usar o FQDN global para resolver automaticamente o endpoint do console zonal mais adequado. Se o FQDN global não for resolvido por algum motivo ou se você quiser se conectar a uma zona específica, use o FQDN zonal para navegar até um endpoint de console específico em uma zona de destino.
Gerenciar a criação de recursos zonais:um seletor de zona está disponível ao criar um recurso zonal, que determina a zona em que um recurso é criado. Por outro lado, o seletor de zona não fica visível quando você cria um recurso global.
Ver recursos em todas as zonas:várias páginas de recursos no console do GDC mostram recursos por zona. Use o seletor de zona para ver os recursos da zona escolhida. Para acessar os recursos de todas as zonas, navegue até os URLs globais e zonais do console do GDC e selecione a zona apropriada no seletor. No entanto, não há uma visualização agregada dos recursos de todas as zonas.
Para mais informações sobre como gerenciar recursos em várias zonas em um universo do GDC com o console do GDC, consulte Gerenciar recursos em várias zonas.
O GDC foi projetado para ser resiliente a falhas. Portanto, se um problema de conectividade zonal for detectado, o console do GDC vai mostrar um banner persistente informando que talvez não seja possível fazer mudanças nos recursos globais.
Contêineres de recursos
Uma organização define um limite de segurança de recursos a serem administrados juntos. Cada organização no GDC air-gapped fornece uma API global e uma API zonal para permitir a criação de recursos globais e zonais dentro da organização. Ao criar uma organização global, o operador é responsável por implantar zonas e configurar definições zonais, como a quantidade de armazenamento e o número de servidores físicos disponíveis para cargas de trabalho do usuário.
Entre em contato com a operadora para mais informações sobre a configuração específica da zona para sua organização.
Um projeto fornece um agrupamento lógico de recursos de serviço em uma organização e um ciclo de vida e um limite de política para gerenciar recursos. Todos os projetos são globais e abrangem as zonas que você configurou no seu universo por padrão.
Embora todos os recursos de serviço precisem ser criados em um projeto, nem todos os serviços são globais. Para serviços que só são compatíveis no nível zonal, é necessário implantá-los e gerenciá-los nas zonas escolhidas. Consulte a documentação apropriada de um tipo de recurso para mais informações.
IAM
Os seguintes serviços do Identity and Access Management (IAM) precisam ser configurados como recursos globais:
- Provedores de identidade (IdP) para autenticação
- Controle de acesso baseado em função (RBAC)
- Identidades de serviço
Cada configuração do IAM abrange todas as zonas em um universo.
Autenticação
É necessário conectar um IdP à sua organização usando o recurso global
IdentityProviderConfig. Esse recurso garante que você use o mesmo IdP para se conectar à sua organização em todas as zonas do universo.
Para mais informações, consulte Conectar-se a um provedor de identidade.
Acesso
Cada usuário ou grupo precisa receber um recurso global
IAMRoleBinding
para ter acesso aos servidores da API de gerenciamento global e zonal,
e aos clusters do Kubernetes de maneira consistente em cada zona da organização.
Acesso ao servidor da API Global Management:
IAMRoleBindingé propagado como umClusterRoleBindingouRoleBindingpara umClusterRolepredefinido no servidor da API global.Acesso ao servidor da API Zonal Management:
IAMRoleBindingé propagado como umClusterRoleBindingouRoleBindingno servidor da API Zonal Management.Acesso ao cluster do Kubernetes:
IAMRoleBindingé propagado como umProjectRoleeProjectRoleBindingpara propagação como umRoleeRoleBindingdo Kubernetes para namespaces do Kubernetes no servidor da API Management e clusters do Kubernetes, correspondentes ao projeto em que oProjectRoleeProjectRoleBindingestão.
Para mais informações, consulte Conceder e revogar acesso.
Identidade do serviço
As contas de serviço são principais de usuários que cargas de trabalho e serviços usam para
consumir recursos e acessar microsserviços de maneira programática e segura. Elas são um tipo especial de identidade usada por um aplicativo ou carga de trabalho, em vez de uma pessoa. Assim como uma conta de usuário, as contas de serviço podem receber permissões
e papéis, mas não podem fazer login como um usuário humano. O recurso de identidade de serviço
está incluído no recurso global
ProjectServiceAccount.
Para mais informações, consulte Autenticar com contas de serviço.
Rede
É possível configurar os seguintes serviços de rede para suas zonas do GDC:
- Serviços de Anycast
- Balanceamento de carga
- Políticas de rede do projeto
- DNS
Configure seus serviços de rede globais e zonais para gerenciar o tráfego de rede entre zonas e dentro de zonas no seu universo do GDC.
Serviços de Anycast
A multizona oferece serviços de rede Anycast para fornecer alta disponibilidade em recursos de várias zonas. Da mesma forma, as opções de interconexão de data center (DCI) são implementadas como uma malha completa para interconectar várias zonas isoladas por ar do GDC. Isso permite que o GDC ofereça proteção contra desastres em várias zonas e locais, atendendo ao requisito de desconexão completa de qualquer infraestrutura do Google.
Os serviços de anycast são representados por prefixos IPv4 /32 exclusivos, que são fornecidos usando o protocolo de gateway de borda (BGP) para as instalações do cliente, garantindo a capacidade de acesso de qualquer rede conectada. Embora cada serviço de Anycast seja acessível de todas as zonas na rede isolada do GDC, o endpoint real para onde o tráfego é direcionado depende de fatores como proximidade e preferência de zona com base na sua política de roteamento personalizada.
A entrega de tráfego é otimizada pelo roteamento para a instância de serviço disponível mais próxima, sempre na mesma zona da conexão do cliente. Isso não apenas reduz a latência, mas também melhora o desempenho geral e a capacidade de resposta do serviço. Por exemplo, se um serviço Anycast for implantado nas zonas 1, 2 e 3, uma solicitação de cliente originada na zona 2 normalmente será encaminhada para a instância de serviço na zona 2, já que é a opção mais próxima e, portanto, mais eficiente.
Embora o intervalo de Anycast seja acessível globalmente, ele só é fornecido a clientes das zonas específicas em que o serviço está implantado ativamente. Essa configuração de acesso significa que um serviço implantado na zona 1 só estaria disponível para clientes conectados à zona 1, e não para aqueles conectados a outras zonas.
Além disso, o GDC implementa um sistema de preferência de zona em que as zonas recebem um valor numérico durante a criação, independente do nome da zona, que define a atração do cliente. Por exemplo, se um serviço Anycast for implantado em zonas com valores numéricos 1, 2 e 3, o tráfego do cliente geralmente será direcionado para a zona com o menor valor definido antes das outras zonas como o local preferido. Esse sistema de preferências oferece um grau de previsibilidade e controle sobre os padrões de tráfego, mas também inclui mecanismos de failover integrados. Em caso de falha ou interrupção que afete a
zona preferida, o sistema muda automaticamente o tráfego para outra zona,
garantindo a disponibilidade ininterrupta do serviço.
Em uma configuração multizona, o acesso a serviços em uma zona específica exige uma interconexão da sua rede com essa zona. Para uma implantação multizonal consistente, as interconexões criadas em cada zona do seu universo precisam ser idênticas em termos de capacidade e configuração. Cada zona que você pretende acessar precisa ter uma interconexão correspondente, e essas interconexões precisam ser idênticas entre si.
Entre em contato com a operadora para mais informações.
Balanceamento de carga
O GDC oferece um balanceador de carga de transmissão direta da camada 4 para cargas de trabalho do Kubernetes e de VM. Esse balanceador de carga oferece as seguintes configurações:
- Protocolo TCP ou UDP.
- Não há proxy entre a carga de trabalho e o cliente.
- Balanceamento de carga dedicado para zonas específicas ou globalmente em todas as zonas do universo.
- Tráfego de rede interna na sua organização ou tráfego de rede externa entre organizações.
O diagrama a seguir ilustra os componentes de um balanceador de carga de passagem externa L4 em um universo do GDC:
O balanceador de carga pode ser ajustado para funcionar em uma única zona ou globalmente para todas as zonas.
Para mais informações sobre o balanceamento de carga no GDC, consulte Gerenciar balanceadores de carga.
Políticas de rede do projeto
As políticas de rede do projeto definem regras de transferência de dados de entrada ou saída para um projeto. Como os projetos são um recurso global, você também precisa definir as políticas de rede de um projeto globalmente para permitir o tráfego de rede entre zonas para os serviços e cargas de trabalho em um projeto.
Para mais informações, consulte Configurar políticas de rede do projeto.
DNS
Os serviços do Sistema de Nomes de Domínio (DNS) são globais e abrangem várias zonas. Se uma instância de serviço DNS ficar inacessível em uma zona, os clientes serão atendidos sem problemas por outra instância de serviço DNS em outra zona.
Cada organização em uma zona contém três servidores DNS globais confiáveis:
Servidor interno da infraestrutura global:o servidor autoritativo que resolve as solicitações de DNS na rede de nuvem privada virtual (VPC) da infraestrutura. Esse servidor gerencia apenas cargas de trabalho de infraestrutura. As cargas de trabalho do usuário não interagem com esse componente. Todas as implantações internas da infraestrutura global de uma organização em todas as zonas podem ser acessadas com um endereço IP Anycast.
Servidor interno global do cliente:o servidor autoritativo que resolve solicitações de DNS na rede de nuvem privada virtual (VPC) do cliente. Esse servidor gerencia apenas cargas de trabalho do usuário, como um pod em um cluster do Kubernetes ou uma máquina virtual (VM), e resolve todas as solicitações de DNS originadas dessas cargas de trabalho do usuário. Todas as implantações internas globais de clientes de uma organização em todas as zonas são acessíveis com um endereço IP anycast. Como as VPCs abrangem várias zonas, uma solicitação de resolução de um nome de domínio totalmente qualificado (FQDN) global de uma zona pode chegar a qualquer uma das zonas íntegras.
Servidor externo global do cliente:o servidor autoritativo que resolve as solicitações de DNS originadas da rede do cliente. Todas as implantações externas globais de clientes de uma organização em todas as zonas são acessíveis com um endereço IP anycast.
É possível se conectar ao GDC com uma rede externa dedicada ou compartilhada. Esses tipos de rede determinam como o GDC resolve suas solicitações de DNS.
Uma rede externa dedicada se conecta diretamente ao servidor DNS externo global do cliente, que resolve a solicitação. Como alternativa, uma rede externa compartilhada se conecta à raiz da sua hierarquia de DNS. Esse servidor raiz fornece o registro do servidor de nomes (NS) da solicitação para a zona DNS adequada ao servidor DNS externo global do cliente. Em seguida, seu resolvedor de DNS resolve recursivamente a solicitação.
O GDC oferece resolução de DNS para tráfego interno e externo, tanto globalmente quanto em uma única zona.
As solicitações originadas da sua rede externa são roteadas do seu resolvedor de DNS. Da mesma forma, as solicitações de DNS internas são originadas das suas cargas de trabalho em um universo do GDC.
As solicitações de DNS têm o seguinte formato de FQDN:
- Solicitações de DNS global:
SERVICE_NAME.ORG_NAME.SUFFIX, comoservice-1.org-1.google.com. - Solicitações de DNS zonal:
SERVICE_NAME.ORG_NAME.ZONE_NAME.SUFFIX, comoservice-1.org-1.zone-1.google.com.
Para mais informações sobre como configurar redes em um universo do GDC, consulte a visão geral de redes.
Armazenamento
Para a versão 1.14.4 e mais recentes, os universos multizona oferecem o uso de recursos de armazenamento replicados, como volumes e buckets no modo assíncrono para cenários de recuperação de desastres. Essas opções de recursos de armazenamento oferecem replicação assíncrona de dados entre duas zonas no mesmo universo. A replicação assíncrona ocorre em segundo plano, fornecendo um RPO baixo, mas não nulo, em caso de desastre. Todos os dados replicados ficam on-line e imediatamente acessíveis, mas podem exigir um procedimento de failover manual para permitir a gravação na zona secundária.
Replicação assíncrona de blocos:fornece volumes (PVs) replicados de forma assíncrona, que mantêm a equivalência de blocos entre os volumes primário e secundário. Devido à natureza assíncrona, o volume secundário vai refletir o estado do primário em algum momento do passado (RPO diferente de zero). O volume secundário não pode ser montado enquanto permanece como destino da replicação, exigindo intervenção manual para encerrar a relação e permitir que as gravações ocorram.
Replicação assíncrona de buckets:os buckets replicados são pareados em zonas, criando uma relação bidirecional de replicação de dados. Os dados de objetos gravados em intervalos de zonas primárias ou secundárias usando esse recurso são copiados para a outra zona. Como os dados são copiados de forma assíncrona, os buckets podem não conter as mesmas versões de objetos a qualquer momento, mas vão se tornar consistentes se nenhuma outra mudança for feita. Ao contrário da replicação de volume, os buckets replicados podem ser gravados durante partições de zona. Cada gravação em um objeto produz uma versão diferente, e a versão mais recente em qualquer zona será o estado final após o restabelecimento da conectividade.
Requisitos de latência
Para garantir que você possa planejar locais de zona do GDC para funcionalidades atuais e futuras, baseamos os requisitos de latência em Google Cloud. Essa abordagem permite escolher com confiança locais isolados do GDC sabendo se essas zonas estarão na mesma região.
A latência máxima aceita é menor que 1 ms de tempo de retorno (RTT) na camada física entre duas zonas em uma região. Como o cálculo da latência na camada física exige equipamentos especializados que não estão disponíveis na maioria das instâncias, é possível aproximar esse valor medindo o comprimento da fibra entre duas zonas.
Um comprimento de fibra para zonas em uma região de 50 km no caminho principal e 100 km no caminho secundário de latência vai oferecer suporte a serviços regionais. Em uma rede em anel, esse requisito significa que cada comprimento de fibra não pode exceder 50 km.
Entre em contato com sua operadora para mais informações sobre os requisitos específicos de latência.
A seguir
- Saiba mais sobre os servidores de API globais e zonais disponíveis em um universo do GDC.
- Confira o guia de alta disponibilidade para garantir que seu aplicativo seja resiliente a falhas na zona local.
- Leia a página sobre hierarquia de recursos para mais informações sobre como os recursos são gerenciados hierarquicamente em uma zona.