Esta arquitetura de referência é mais adequada para os seguintes exemplos de utilização:
- Precisa de proteção regional, além da proteção zonal, para as suas aplicações essenciais.
Esta arquitetura de referência de disponibilidade incorpora réplicas de leitura na região para AD e em várias regiões para RD. Esta implementação multirregional protege contra interrupções significativas, incluindo falhas de energia generalizadas e desastres naturais de grande escala.
Considerações sobre a arquitetura de referência de disponibilidade
Quando estiver a avaliar esta arquitetura de referência de disponibilidade, tenha em consideração os seguintes fatores:
- Latência e largura de banda da rede na região e entre regiões
- Posicionamento geográfico das bases de dados e dos servidores de aplicações
- Estratégia para transferir cargas de trabalho só de leitura para réplicas
- Implemente a elevada disponibilidade na região de recuperação de desastres remota
O equilíbrio de carga só de leitura pode ser necessário, especialmente se usar servidores de aplicações regionais, para que os pedidos sejam encaminhados para a base de dados mais próxima para obter a resposta mais rápida. Para mais informações, consulte o artigo Encaminhamento de pedidos para um Application Load Balancer clássico de várias regiões.
Pode ser necessária monitorização adicional para a replicação entre regiões para garantir que o atraso de replicação não começa a aumentar devido à carga de transações ou à capacidade da rede.
Para garantir que a recuperação de desastres é bem-sucedida, certifique-se de que realiza testes de recuperação de desastres exaustivos. É importante testar a funcionalidade e o débito da aplicação se existirem ligações de rede com latência elevada entre os servidores de aplicações e a base de dados.
Arquiteturas de AD na região e RD entre regiões
A Figura 1 mostra uma configuração de AD e RD sugerida com três bases de dados de espera de réplica de leitura em três zonas de disponibilidade e duas regiões.
Figura 1. AlloyDB Omni com opções de cópias de segurança e alta disponibilidade entre regiões.
Como ilustra a Figura 1, a replicação de streaming síncrona para réplicas locais (na mesma região) oferece elevada disponibilidade, enquanto a replicação de streaming assíncrona para uma réplica remota geograficamente separada oferece proteção de recuperação de desastres regional. Em toda a configuração, apenas a instância principal pode realizar operações de leitura/escrita, enquanto as outras réplicas podem responder a consultas de leitura.
Configure a replicação da réplica principal para as réplicas na região no modo síncrono, enquanto a replicação para as réplicas entre regiões deve ser configurada no modo assíncrono para evitar que a latência afete o desempenho de gravação principal. Em caso de falha regional, esta configuração pode levar a um RPO diferente de zero. No entanto, esta configuração permite um RTO mais rápido em caso de falha. Isto deve-se ao facto de a base de dados principal não ter de aguardar a confirmação das bases de dados de reserva remotas antes de confirmar as transações.
É possível ter cópias de segurança adicionais em várias regiões que fazem cópias de segurança das bases de dados de réplicas de leitura e, assim, adicionam redundância às cópias de segurança feitas a partir da base de dados principal.
Cópias de segurança de réplicas de leitura
Quando usa implementações do Kubernetes, a implementação secundária na região alternativa é configurada automaticamente com cópias de segurança adicionais.
Considere o seguinte:
- Se a sua cópia de segurança remota puder ser suscetível a falhas na região, tem de iniciar cópias de segurança adicionais nas regiões alternativas.
- Se precisar de redundância de cópias de segurança, tem de fazer cópias de segurança de réplicas de leitura regionais.
Localização da réplica de leitura para suportar a disponibilidade em várias zonas
O operador do Kubernetes do AlloyDB Omni processa automaticamente o posicionamento dos nós nas zonas e em que nós os pods devem ser implementados. Algumas opções de configuração que afetam o posicionamento, como a afinidade e a tolerância de pods, estão disponíveis na configuração da base de dados usada para a implementação com o operador do AlloyDB Omni.
Migração de uma arquitetura apenas de AD para uma arquitetura de AD e RD
Para implementações do Kubernetes, tem de criar uma nova implementação regional do Kubernetes, denominada cluster de base de dados secundário, e ativar a replicação entre centros de dados.
Implementação
Quando escolhe uma arquitetura de referência de disponibilidade, tenha em atenção as seguintes vantagens, limitações e opções.
Vantagens
- Protege contra falhas zonais e de instâncias
- Protege contra falhas regionais
- RTO reduzido quando a base de dados sofre uma falha regional
Limitações
- Pode reduzir o RPO para a recuperação regional com a replicação síncrona, mas esta abordagem causa uma latência adicional no desempenho das transações. Para a recuperação de desastres e a replicação de regiões remotas, recomendamos que use apenas a replicação assíncrona.
- A configuração da transmissão em fluxo WAL do PostgreSQL no modo síncrono oferece zero perda de dados (
RPO=0) durante o funcionamento normal ou as comutações por falha típicas. No entanto, esta abordagem não protege contra a perda de dados em situações específicas de falha dupla, como quando todas as instâncias de espera são perdidas ou ficam inacessíveis a partir da instância principal, e isto é imediatamente seguido de um reinício da instância principal.
Opções de proteção de dados
- A arquitetura de disponibilidade padrão para opções de cópia de segurança e recuperação.
- A arquitetura de disponibilidade melhorada para opções de alta disponibilidade.
O que se segue?
- Vista geral da arquitetura de referência de disponibilidade do AlloyDB Omni.
- AlloyDB Omni Standard Availability.
- Disponibilidade melhorada do AlloyDB Omni.
- Trabalhe com a replicação entre centros de dados.
- Encaminhamento de pedidos para um balanceador de carga de aplicações clássico de várias regiões..