Recuperação de desastres para uma plataforma crítica
Um segundo centro de dados capaz de assumir uma plataforma crítica de um cliente, com replicação da base de dados e failover sujeito a aprovação, para tempo de recuperação e perda de dados próximos de zero.
- Linux
- Docker
- Bash
Arquitetura
- Utilizadores → Plataforma (centro de dados principal): traffic
- Plataforma (centro de dados principal) → Base de dados
- Base de dados → Réplica: replication
- Aprovação → Scripts de failover: go
- Scripts de failover → Plataforma (centro de dados secundário): promote
- Plataforma (centro de dados secundário) → Réplica
- Utilizadores → Plataforma (centro de dados secundário): after failover
- Plataforma (centro de dados principal): Em produção
- Plataforma (centro de dados secundário): Em espera
- Aprovação: Uma pessoa aprova
- centro de dados principal: Plataforma, Base de dados
- centro de dados secundário: Plataforma, Réplica
Contexto
Um cliente tem uma plataforma que tem de estar sempre disponível: uma falha tem impacto operacional imediato. Os detalhes ficam propositadamente gerais.
Problema
O tempo de recuperação e a perda de dados tinham de ser próximos de zero. A plataforma junta várias tecnologias, cada uma com a sua forma de replicação, e mesmo assim têm de fazer failover em conjunto.
Abordagem
O centro de dados secundário replica a produção, com a base de dados sincronizada continuamente entre os dois sites. Cada parte da stack tem a sua estratégia de replicação e de backup, escolhida conforme a forma como essa tecnologia guarda o seu estado.
O failover está automatizado de ponta a ponta, com um único passo manual deliberado: uma pessoa aprova a mudança antes de ela correr. Assim mantém-se a rapidez da automação sem deixar que um falso alarme mude a produção.
Resultado
O objetivo é a plataforma poder passar para o segundo centro de dados quase de imediato, com a base de dados já sincronizada.