Recuperação de desastres e solução multi-ativa
Não importa se você usa o DCS como cache de front-end ou como armazenamento de dados de back-end, o DCS está sempre pronto para garantir a confiabilidade dos dados e a disponibilidade do serviço. A figura a seguir mostra a evolução das arquiteturas DCS DR.
Para atender aos requisitos de confiabilidade de seus dados e serviços, você pode optar por implantar sua instância de DCS em uma única AZ ou entre AZs.
HA Single-AZ dentro de uma região
Implantação Single-AZ significa implantar uma instância dentro de uma sala de equipamentos físicos. O DCS fornece HA de processo/serviço, persistência de dados e políticas de DR em hot em espera para diferentes tipos de instâncias de DCS.
Single-node DCS instance: Quando a DCS detecta uma falha do processo, um processo novo está começado para assegurar o serviço HA.
Principal/Em espera DCS instance: Os dados são persistidos no disco no nó principal e sincronizados incrementalmente e persistidos no nó em em espera, obtendo hot em espera e persistência de dados.
Cluster DCS instance: Semelhante a uma instância principal/em espera, os dados em cada estilhaço (processo de instância) de uma instância de cluster são sincronizados entre os nós principal e em espera e persistem em ambos os nós.
DR Cross-AZ dentro de uma região
Os nós principal e em espera de uma instância de DCS principal/em espera ou cluster podem ser implantados em AZs (em diferentes salas de equipamentos). Fontes de alimentação e redes de diferentes AZs são fisicamente isoladas. Quando ocorre uma falha na AZ em que o nó principal é implantado, o nó em espera se conecta ao cliente e assume as operações de leitura e gravação de dados.
Esse mecanismo se aplica de maneira semelhante a uma instância de DCS de cluster, na qual cada estilhaço (processo) é implantado em AZs.
Ao criar uma instância de DCS principal/em espera, selecione uma AZ em espera que seja diferente da AZ principal, conforme mostrado abaixo.
Você também pode implantar seu aplicativo em AZs para garantir a confiabilidade dos dados e a disponibilidade do serviço em caso de interrupção da fonte de alimentação ou da rede.
Multi-Activo Inter-Regiões
Atualmente, o HUAWEI CLOUD DCS não suporta multiativos entre regiões porque o Redis não tem uma solução madura ativo-ativo. Active-active is different from disaster recovery or principal/em espera HA.
O Redis ativo-ativo em nuvens ou regiões não pode ser alcançado porque os protocolos de serialização do REdis (RESP) personalizados não são unificados. Se ativo-ativo for necessário, ele pode ser implementado por meio de dual-write on the application end.
Nota:
- A solução de gravação dupla cannot ensure cache consistency (devido a problemas de rede). Applications precisam tolerate cache inconsistency (definindo o tempo de vida para alcançar a consistência eventual). Se os aplicativos exigem uma consistência de cache forte, essa solução não é adequada. Atualmente, não há solução na indústria para garantir uma forte consistência de cache entre regiões.
- É aconselhável executar operações no cache L2 entre regiões no modo assíncrono.
