Alta disponibilidade para seus apps

Este guia de estratégia fornece orientações técnicas e práticas recomendadas para projetar e implantar cargas de trabalho de alta disponibilidade (HA) em um 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ço e considerações operacionais necessárias para minimizar o tempo de inatividade e garantir a continuidade dos negócios para aplicativos em execução no GDC.

As estratégias de alta disponibilidade são destinadas a profissionais técnicos envolvidos no design, na implantação e no gerenciamento de aplicativos no GDC, incluindo:

  • Arquitetos de nuvem no grupo de administradores da plataforma: projetar infraestrutura resiliente e arquiteturas de aplicativos no GDC.

  • Engenheiros de DevOps e de confiabilidade do site (SREs) no grupo de operadores de aplicativos: implementação de estratégias de implantação, automação, monitoramento e resposta a incidentes para cargas de trabalho de alta disponibilidade.

  • Desenvolvedores de aplicativos no grupo de operadores de aplicativos: criação de aplicativos tolerantes a falhas e que se integram perfeitamente aos padrões de infraestrutura de alta disponibilidade.

Para mais informações, consulte Públicos-alvo para documentação isolada do GDC.

Importância da alta disponibilidade

Em sistemas distribuídos modernos, o planejamento para alta disponibilidade é essencial. A inatividade, planejada ou não, pode causar interrupções significativas nos negócios, perda de receita, danos à reputação e uma experiência do usuário ruim. Para cargas de trabalho executadas na borda ou em data centers particulares usando o GDC, a disponibilidade geralmente se correlaciona diretamente com o sucesso operacional principal, especialmente para aplicativos sensíveis à latência ou essenciais. Projetar para HA desde o início é essencial para criar serviços resilientes e confiáveis.

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 guia se concentra especificamente em universos do GDC configurados em uma topologia multizonal. Com várias zonas, um único universo do GDC compreende várias zonas isoladas fisicamente no mesmo local, como um campus de data center ou uma área metropolitana. 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 zonas em um universo do GDC permite a replicação síncrona 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 maneira 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 sofisticado de tráfego.

Balanceador de carga externo para tráfego norte-sul

Para expor seus aplicativos a usuários ou sistemas fora de um cluster do GKE na GDC (tráfego norte-sul), use os recursos gerenciados de balanceamento de carga externo da GDC. O serviço 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: o ELB é gerenciado pelo GDC e foi projetado para alta disponibilidade e resiliência.

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

Usar um balanceador de carga externo é a maneira padrão e recomendada de alcançar HA para entrada de tráfego externo. Assim, as solicitações do cliente são automaticamente roteadas para fora de zonas ou instâncias com falha.

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 na GDC (tráfego leste-oeste), a GDC fornece um balanceador de carga interno (ILB, na sigla em inglês). Isso é crucial 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 HA e escalonabilidade são as seguintes:

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

  • Integração do balanceador de carga com o Kubernetes: normalmente provisionado pela criação de 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 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 entre todas as réplicas íntegras disponíveis.

Usar um ILB para comunicação interna entre serviços 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. Isso é usado com frequência em aplicativos em camadas em que os front-ends 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 fontes de dados ou usuários finais. Alcançar a alta disponibilidade no seu universo do GDC é crucial para cargas de trabalho críticas. É possível implantar aplicativos de alta disponibilidade em várias zonas no seu universo do GDC, implementando a replicação de armazenamento assíncrono 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 em várias zonas, você pode melhorar significativamente a resiliência contra falhas de hardware localizadas ou eventos de manutenção.

A seguir