La disponibilidad de la base de datos es uno de los aspectos más importantes de la arquitectura de aplicaciones. Si bien la prevención del tiempo de inactividad del centro de datos es un hecho, eventualmente le sucederá a todos. Incluso los centros de datos mejor administrados dejarán de funcionar por completo de vez en cuando. Por ejemplo, las interrupciones de Amazon AWS del 26/08/13 y el 13/09/13. La pregunta importante que debe hacerse es si esto es aceptable para su aplicación. La mayoría de las aplicaciones pueden tolerar algún tiempo de inactividad de vez en cuando; sin embargo, ciertas aplicaciones requieren un tiempo de actividad cercano al 100 % y la arquitectura de la base de datos de estas aplicaciones requiere un enfoque de diseño más deliberado. Las latencias entre los centros de datos tienden a ser bastante grandes, por lo que se debe pensar cuidadosamente en el diseño de su implementación de alojamiento MongoDB.
Objetivos de tiempo de actividad de MongoDB
- Su base de datos debe estar activa y con capacidad de escritura, incluso si un centro de datos completo se cae.
- La conmutación por error de su base de datos debe ser automática en caso de que falle el servidor o el centro de datos.
- La falla de un solo servidor no debería hacer que el principal cambie a un centro de datos diferente.
Diseño del centro de datos
Para satisfacer nuestros objetivos, se nos ocurrieron tres diseños de centros de datos utilizando un conjunto de réplicas 4+1:
- Centro de datos 1: Primario (Prioridad 10), Secundario 0 (Principal 9)
- Centro de datos 2: Secundario 1 (Prioridad 8), Secundario 2 (Prioridad 7)
- Centro de datos 3: Árbitro
Colocamos dos miembros completos en cada uno de los dos primeros centros de datos y un árbitro en el tercer centro de datos. También configuramos la prioridad de cada servidor para que podamos controlar qué miembro se convierte en principal en caso de falla del servidor.
Hay un par de desventajas en este geo- arquitectura distribuida:
- Si tiene una aplicación de escritura intensa, los secundarios en un centro de datos diferente siempre se retrasarán debido a la mayor latencia. Si algunos datos son cruciales, es posible que desee utilizar una preocupación de escritura de MongoDB de "Mayoría" para asegurarse de que todos los nodos confirmen los datos.
- Las compilaciones de la comunidad MongoDB no tienen habilitado SSL. Es posible que desee realizar una compilación con SSL habilitado o usar MongoDB DBaaS en ScaleGrid para que los datos que fluyen entre regiones estén encriptados.
Disponibilidad de Amazon AWS / EC2
Si está implementando MongoDB en AWS, cada centro de datos en esta imagen corresponde a una región de Amazon y no a una zona de disponibilidad. Amazon no proporciona garantías de disponibilidad en una sola zona de disponibilidad, los SLA son para toda la región. Si realiza implementaciones en zonas de disponibilidad, su SLA es del 99,95 %, lo que sigue siendo un excelente SLA; sin embargo, si una región entera deja de funcionar, su base de datos también lo hará. Además, ciertas regiones de AWS tienen solo dos zonas de disponibilidad, por lo que se debe prestar especial atención a la ubicación del tercer nodo en una región diferente para que el tiempo de inactividad de una sola región no detenga la base de datos completa.
Disponibilidad de menor costo en todas las geografías
Una versión más simple de la misma arquitectura usa solo tres servidores y coloca solo una réplica en cada centro de datos. La desventaja de este enfoque es que una sola falla del servidor hará que el principal se mueva entre los centros de datos. Sin embargo, esta arquitectura cuesta menos que la primera arquitectura. Dependiendo de su escenario, podría funcionar para usted.
Hay muchas formas de lograr un alto tiempo de actividad con MongoDB, y esta es la forma que funciona para nuestras necesidades. Si tiene otras arquitecturas interesantes, envíenos un correo electrónico a [email protected]. ¡Nos encantaría escuchar tu opinión!
