Alta disponibilidade para seus apps

Este documento fornece orientações técnicas e práticas recomendadas para projetar e implantar cargas de trabalho altamente disponíveis (HA) em várias zonas em um universo isolado do Google Distributed Cloud (GDC). O guia descreve os principais padrões de arquitetura, configurações de serviço e considerações operacionais para minimizar o tempo de inatividade e garantir a continuidade dos negócios.

As estratégias neste documento são destinadas aos seguintes profissionais técnicos:

  • Arquitetos de nuvem que projetam infraestruturas e arquiteturas de aplicativos resilientes.

  • Engenheiros de DevOps e de confiabilidade do site que implementam estratégias de implantação, automação, monitoramento e resposta a incidentes para cargas de trabalho de alta disponibilidade.

  • Desenvolvedores de aplicativos que criam aplicativos com tolerância a falhas e que se integram a padrões de alta disponibilidade.

Para mais informações, consulte Públicos-alvo da documentação do GDC com isolamento físico.

Importância da alta disponibilidade

Em sistemas distribuídos modernos, o planejamento para alta disponibilidade é essencial. O tempo de inatividade pode causar interrupções significativas nos negócios, perda de receita e uma experiência do usuário ruim.

Para cargas de trabalho executadas em data centers particulares usando o GDC, a disponibilidade geralmente está diretamente relacionada ao sucesso operacional principal, especialmente para aplicativos sensíveis à latência ou de missão crítica. Projetar para alta disponibilidade desde o início é essencial para criar serviços resilientes e confiáveis.

O GDC oferece recursos de hiperescala no seu ambiente com isolamento físico com vários data centers ou zonas desconectados. A alta disponibilidade dos seus apps multizonais depende de serviços multizonais, como balanceamento de carga e armazenamento assíncrono. Para mais informações sobre serviços importantes para usar na alta disponibilidade, consulte as seções Escalonabilidade e balanceamento de carga e Implantação de apps de alta disponibilidade em várias zonas com armazenamento assíncrono deste documento.

Recursos de hiperescala entregues localmente

O GDC estende a infraestrutura e os serviços para a borda e os data centers. Google Cloud O GDC oferece uma solução de hardware e software totalmente gerenciada, permitindo que você execute o Google Kubernetes Engine (GKE) em clusters do GDC e outros serviços doGoogle Cloud mais perto de onde seus dados são gerados e consumidos.

Este documento se concentra em universos do GDC configurados em uma topologia de várias zonas. Nessa configuração, um único universo compreende várias zonas fisicamente isoladas no mesmo local.

Essas zonas têm alimentação, resfriamento e rede independentes, oferecendo proteção contra falhas localizadas na infraestrutura física. A conectividade de rede de baixa latência e alta largura de banda entre as zonas permite a replicação de dados e o failover rápido, formando a base para a criação de aplicativos altamente disponíveis.

Escalonabilidade e balanceamento de carga

Além da redundância básica de componentes, gerenciar o tráfego de forma eficaz e permitir o escalonamento contínuo são cruciais para manter a alta disponibilidade, especialmente com condições de carga variáveis. O GDC oferece vários mecanismos para balanceamento de carga e gerenciamento de tráfego sofisticado.

Balanceador de carga externo para tráfego norte-sul

Para expor seus aplicativos a usuários ou sistemas fora de um cluster do GKE no GDC (tráfego norte-sul), use os recursos gerenciados de balanceamento de carga externo do GDC. O serviço de balanceador de carga externo (ELB) oferece essas funcionalidades e se integra perfeitamente ao Kubernetes.

As principais características do serviço ELB que oferece HA e escalonabilidade são as seguintes:

  • Serviço gerenciado: executado como um serviço específico do GDC e projetado para alta disponibilidade e resiliência em um ambiente isolado.

  • Acesso externo: provisiona endereços IP externo estáveis de pools gerenciados pelo GDC, fornecendo um ponto de entrada consistente para clientes externos.

  • Integração do balanceador de carga com o Kubernetes: provisiona e configura automaticamente o balanceador de carga quando você cria um Service do Kubernetes de type: LoadBalancer sem anotações internas específicas.

  • Detecção de zona: distribui o tráfego de entrada entre pods de aplicativos íntegros em execução em todas as zonas disponíveis no universo do GDC. O ELB depende de sondagens de prontidão do pod para determinar a integridade do back-end.

  • Escalonabilidade: lida com a distribuição do tráfego externo à medida que o aplicativo é escalonado horizontalmente em nós e zonas.

Para alcançar a alta disponibilidade do tráfego de entrada externo, de modo que as solicitações do cliente sejam automaticamente roteadas para fora de zonas ou instâncias com falha, recomendamos usar um balanceador de carga externo.

Para mais informações, consulte Configurar balanceadores 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, na sigla em inglês). Um ILB é essencial para desacoplar serviços internos e fornecer caminhos de comunicação interna que também sejam altamente disponíveis e escalonáveis.

As principais características do serviço ILB que oferece alta disponibilidade e escalonabilidade são as seguintes:

  • Acesso interno: provisiona um endereço IP interno estável acessível apenas na rede do GDC, como nós de cluster ou outros serviços internos.

  • Integração do balanceador de carga com o Kubernetes: provisiona o balanceamento de carga criando um Service do Kubernetes de type: LoadBalancer com uma anotação específica para indicar que ele precisa ser interno. Por exemplo, networking.gke.io/load-balancer-type: "Internal".

  • Detecção de zona: distribui o tráfego entre pods de back-end íntegros, que são identificados com sondagens de prontidão, localizados em todas as zonas disponíveis. Essa distribuição evita falhas de comunicação interna se uma zona tiver problemas.

  • Descoberta e desacoplamento de serviços: 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 se descobrir e se comunicar entre si, eliminando a necessidade de os clientes conhecerem os endereços IP individuais dos pods.

  • Escalonabilidade: facilita o escalonamento de serviços de back-end internos ao distribuir o tráfego por todas as réplicas íntegras disponíveis.

Usar um ILB para comunicação interna de serviço para serviço torna o fluxo de tráfego interno resiliente a falhas de zona e oferece escalonamento eficaz, complementando a alta disponibilidade fornecida pelo ELB externo e pela distribuição de computação subjacente. Essa estratégia é usada com frequência em aplicativos em camadas em que as APIs de front-end precisam se comunicar com APIs ou bancos de dados de back-end no cluster do Kubernetes.

Para mais informações, consulte Configurar balanceadores de carga internos.

Implantação de apps de alta disponibilidade em várias zonas com armazenamento assíncrono

Com o GDC, você executa infraestrutura e aplicativos mais perto das suas origens de dados. Para implantar aplicativos de alta disponibilidade com uma fonte de dados resiliente, implemente a replicação assíncrona de armazenamento para persistência de dados e recuperação de desastres.

As zonas representam domínios de falha distintos em um único universo. Ao distribuir componentes de aplicativos e replicar dados entre zonas, você melhora significativamente a resiliência contra falhas de hardware localizadas ou eventos de manutenção.

Para mais informações, consulte Proteção de dados com armazenamento multizona.

A seguir