A disponibilidade do banco de dados é um dos aspectos mais importantes da arquitetura do aplicativo. Embora a prevenção do tempo de inatividade do data center seja um dado, isso acontecerá com todos eventualmente. Até mesmo os data centers mais bem executados ficarão completamente inativos de vez em quando. Por exemplo, as interrupções da Amazon AWS de 26/08/13 e 13/09/13. A pergunta importante a fazer é se isso é aceitável para sua aplicação? A maioria dos aplicativos pode tolerar algum tempo de inatividade de vez em quando, no entanto, alguns aplicativos exigem quase 100% de tempo de atividade e a arquitetura de banco de dados desses aplicativos exige uma abordagem de design mais deliberada. As latências entre os data centers tendem a ser bastante grandes, portanto, é preciso pensar cuidadosamente no design da implantação de sua hospedagem MongoDB.
Metas de tempo de atividade do MongoDB
- Seu banco de dados deve estar ativo e gravável, mesmo que um datacenter completo fique inativo.
- O failover do seu banco de dados deve ser automático em caso de falha do servidor/datacenter.
- Uma única falha de servidor não deve fazer com que o primário mude para um datacenter diferente.
Projeto do data center
Para satisfazer nossos objetivos, criamos três designs de data center usando um conjunto de réplicas 4+1:
- Datacenter 1: Primário (prioridade 10), secundário 0 (primário 9)
- Datacenter 2: Secundário 1 (Prioridade 8), Secundário 2 (Prioridade 7)
- Datacenter 3: Árbitro
Colocamos dois membros plenos em cada um dos dois primeiros data centers e um árbitro no terceiro data center. Também configuramos a prioridade para cada servidor para que possamos controlar qual membro se torna primário em caso de falha do servidor.
Existem algumas desvantagens nessa geo- arquitetura distribuída:
- Se você tiver um aplicativo de gravação pesada, os secundários em um data center diferente sempre ficarão para trás devido à latência maior. Se alguns dados forem cruciais, convém usar uma preocupação de gravação do MongoDB de “Majority” para garantir que todos os nós confirmem os dados.
- As compilações da comunidade MongoDB não têm SSL habilitado. Você pode querer fazer uma compilação com SSL habilitado ou usar o MongoDB DBaaS no ScaleGrid para que os dados que fluem entre as regiões sejam criptografados.
Disponibilidade Amazon AWS/EC2
Se você estiver implantando o MongoDB na AWS, cada data center nesta imagem corresponde a uma região da Amazon e não a uma zona de disponibilidade. A Amazon não oferece garantias de disponibilidade em uma única zona de disponibilidade, os SLAs são para toda a região. Se você implantar em zonas de disponibilidade, seu SLA será de 99,95%, o que ainda é um ótimo SLA - no entanto, se uma região inteira ficar inativa, seu banco de dados ficará inativo. Além disso, certas regiões da AWS têm apenas duas zonas de disponibilidade, portanto, atenção especial deve ser dada à colocação do terceiro nó em uma região diferente para que o tempo de inatividade de uma única região não desative todo o banco de dados.
Disponibilidade de custo mais baixo em todas as regiões
Uma versão mais simples da mesma arquitetura usa apenas três servidores e coloca apenas uma réplica em cada data center. A desvantagem dessa abordagem é que uma única falha de servidor fará com que o primário se mova pelos datacenters. No entanto, esta arquitetura custa menos do que a primeira arquitetura. Dependendo do seu cenário, pode funcionar para você.
Existem muitas maneiras de obter um alto tempo de atividade com o MongoDB, e essa é a maneira que funciona para nossas necessidades. Se você tiver outras arquiteturas interessantes, envie um email para [email protected]. Adoraríamos ouvir seus pensamentos!
