Este guia de estratégia fornece orientações técnicas e práticas recomendadas para conceber e implementar cargas de trabalho de alta disponibilidade (HA) num universo isolado do Google Distributed Cloud (GDC) configurado com várias zonas ou multizona. O guia descreve os principais padrões de arquitetura, configurações de serviços e considerações operacionais necessários para minimizar o tempo de inatividade e fornecer continuidade do negócio para aplicações executadas no GDC.
As estratégias de alta disponibilidade destinam-se a profissionais técnicos envolvidos no design, na implementação e na gestão de aplicações no GDC, que incluem o seguinte:
Arquitetos de nuvem no grupo de administradores da plataforma: conceber arquiteturas de aplicações e infraestruturas resilientes no GDC.
Engenheiros de DevOps e engenheiros de fiabilidade de sites (EFS) no grupo de operadores de aplicações: implementar estratégias de implementação, automatização, monitorização e resposta a incidentes para cargas de trabalho de HA.
Programadores de aplicações no grupo de operadores de aplicações: criar aplicações tolerantes a falhas e que se integram perfeitamente com padrões de infraestrutura de HA.
Para mais informações, consulte a documentação sobre públicos-alvo para GDC com isolamento de ar.
Importância da alta disponibilidade
Nos sistemas distribuídos modernos, o planeamento da alta disponibilidade é fundamental. O tempo de inatividade, quer seja planeado ou não, pode levar a uma interrupção significativa da empresa, perda de receita, danos na reputação e uma má experiência do utilizador. Para cargas de trabalho executadas no limite ou em centros de dados privados através do GDC, a disponibilidade correlaciona-se frequentemente de forma direta com o sucesso operacional principal, especialmente para aplicações sensíveis à latência ou críticas para a missão. Criar a pensar na HA desde o início é essencial para criar serviços resilientes e fiáveis.
Capacidades de hiperescala, fornecidas localmente
O GDC expande a infraestrutura Google Cloud e os serviços até ao limite e aos seus centros de dados. O GDC oferece uma solução de hardware e software totalmente gerida, o que lhe permite executar o Google Kubernetes Engine (GKE) em clusters do GDC e outrosGoogle Cloud serviços mais perto de onde os seus dados são gerados e consumidos.
Este guia foca-se especificamente nos universos da GDC configurados numa topologia de várias zonas. Com várias zonas, um único universo do GDC compreende zonas múltiplas e isoladas fisicamente na mesma localização, como um campus de centro de dados ou uma área metropolitana. Estas zonas têm alimentação, refrigeração e redes independentes, o que oferece proteção contra falhas localizadas na infraestrutura física. A conetividade de rede de baixa latência e elevada largura de banda entre zonas num universo do GDC permite a replicação síncrona e a comutação por falha rápida, formando a base para a criação de aplicações altamente disponíveis.
Escalabilidade e balanceamento de carga
Além da redundância de componentes básica, a gestão eficaz do tráfego e a ativação da escalabilidade perfeita são cruciais para manter a elevada disponibilidade, especialmente com condições de carga variáveis. O GDC oferece vários mecanismos para o equilíbrio de carga e a gestão de tráfego sofisticada.
Balanceador de carga externo para tráfego norte-sul
Para expor as suas aplicações a utilizadores ou sistemas fora de um cluster do GKE no GDC (tráfego norte-sul), usa as capacidades de equilíbrio de carga externo geridas do GDC. O serviço de balanceador de carga externo (ELB) oferece estas capacidades e integra-se perfeitamente com o Kubernetes.
As principais caraterísticas do serviço ELB que oferece HA e escalabilidade são as seguintes:
Serviço gerido: o ELB é gerido pelo GDC e foi concebido para alta disponibilidade e resiliência.
Acesso externo: aprovisiona endereços IP externos estáveis a partir de pools geridos pela GDC, fornecendo um ponto de entrada consistente para clientes externos.
Integração do equilibrador de carga com o Kubernetes: aprovisiona e configura automaticamente o equilibrador de carga quando cria um
Servicedo Kubernetestype: LoadBalancersem anotações internas específicas.Consciência da zona: distribui o tráfego de entrada pelos pods de aplicações saudáveis em execução em todas as zonas disponíveis no universo do GDC. O ELB baseia-se em sondas de disponibilidade de pods para determinar o estado do back-end.
Escalabilidade: processa a distribuição de tráfego externo à medida que a sua aplicação é escalada horizontalmente em nós e zonas.
A utilização de um equilibrador de carga externo é a forma padrão e recomendada de alcançar a HA para a entrada de tráfego externo, pelo que os pedidos de clientes são encaminhados automaticamente para longe de zonas ou instâncias com falhas.
Para mais informações, consulte o artigo Configure equilibradores de carga externos.
Balanceador de carga interno para tráfego leste-oeste
Para a comunicação entre serviços executados no mesmo cluster do GKE no GDC (tráfego leste-oeste), o GDC fornece um balanceador de carga interno (ILB). Isto é fundamental para desassociar os serviços internos e fornecer caminhos de comunicação internos que também sejam altamente disponíveis e escaláveis.
As principais caraterísticas do serviço ILB que oferece HA e escalabilidade são as seguintes:
Acesso interno: aprovisiona um endereço IP interno estável acessível apenas a partir da rede do GDC, como nós de cluster ou outros serviços internos.
Integração do balanceador de carga com o Kubernetes: normalmente, é aprovisionado através da criação de um
Servicedo Kubernetes do tipotype: LoadBalancercom uma anotação específica para indicar que tem de ser interno. Por exemplo,networking.gke.io/load-balancer-type: "Internal".Consciência da zona: distribui o tráfego por agrupamentos de back-end saudáveis, que são identificados com sondagens de prontidão, localizados em todas as zonas disponíveis. Esta distribuição evita falhas de comunicação internas se uma zona tiver problemas.
Deteção de serviços e desvinculação: fornece um endereço IP interno estável e um nome DNS com a integração do kube-dns e do CoreDNS. Os serviços podem descobrir e comunicar entre si, eliminando a necessidade de os clientes conhecerem os endereços IP dos pods individuais.
Escalabilidade: facilita a escalabilidade dos serviços de back-end internos através da distribuição do tráfego por todas as réplicas disponíveis em bom estado.
A utilização de um ILB para a comunicação interna de serviço para serviço torna o fluxo de tráfego interno resiliente a falhas de zona e oferece um dimensionamento eficaz, complementando a HA fornecida pelo ELB externo e a distribuição de computação subjacente. Isto é frequentemente usado para aplicações hierárquicas em que as interfaces têm de comunicar com APIs ou bases de dados de back-end no cluster do Kubernetes.
Para mais informações, consulte o artigo Configure balanceadores de carga internos.
Implementação de apps de HA em várias zonas com armazenamento assíncrono
O GDC permite-lhe executar infraestruturas e aplicações mais perto das suas origens de dados ou utilizadores finais. A obtenção de HA no seu universo do GDC é crucial para cargas de trabalho críticas. Pode implementar aplicações de HA em várias zonas no seu universo do GDC, implementando a replicação de armazenamento assíncrona para persistência de dados e recuperação de desastres.
As zonas representam domínios de falhas distintos num único universo. Ao distribuir componentes da aplicação e replicar dados entre zonas, pode melhorar significativamente a resiliência contra falhas de hardware localizadas ou eventos de manutenção.
O que se segue?
Para implementar um serviço como uma coleção de máquinas virtuais (VMs) distribuídas por zonas através de armazenamento de blocos replicado assíncrono, consulte o artigo Implemente uma app de VM de HA.
Para implementar um serviço como uma aplicação em contentores no Kubernetes em várias zonas com volumes persistentes replicados de forma assíncrona, consulte o artigo Implemente uma app de contentores de HA.