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 em várias regiões 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.
Conforme ilustrado na Figura 1, a replicação de streaming síncrona para réplicas locais (na mesma região) oferece alta 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 entre regiões que façam cópias de segurança das bases de dados de réplicas de leitura e, assim, adicionar 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.
- Disponibilidade padrão do AlloyDB Omni.
- 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..