Procedimientos recomendados para alta disponibilidad y recuperación ante desastres

Azure Managed Instance for Apache Cassandra es un servicio totalmente administrado para clústeres de Apache Cassandra de código abierto puros. El servicio también permite invalidar las configuraciones, en función de las necesidades específicas de cada carga de trabajo, lo que permite la máxima flexibilidad y control cuando sea necesario.

Apache Cassandra es una gran elección para construir aplicaciones altamente resistentes debido a su naturaleza distribuida y arquitectura sin maestros - cualquier nodo de la base de datos puede proporcionar exactamente la misma funcionalidad que cualquier otro nodo - contribuyendo a la robustez y resistencia de Cassandra. En este artículo se proporcionan sugerencias sobre cómo optimizar la alta disponibilidad y cómo abordar la recuperación ante desastres.

RTO y RPO

RPO (objetivo de punto de recuperación) y RTO (objetivo de tiempo de recuperación), normalmente serán bajos (cerca de cero) para Apache Cassandra siempre que tenga:

• Una implementación de varias regiones con replicación entre regiones y un factor de replicación de 3.
• Zonas de disponibilidad habilitadas (seleccione la opción al crear un clúster en el portal o a través de CLI de Azure).
• Se ha configurado la conmutación por error de nivel de aplicación mediante la directiva de equilibrio de carga en el controlador de cliente o la conmutación por error de nivel de equilibrio de carga mediante Traffic Manager/Azure Front Door.

El RTO ("tiempo de inactividad en caso de interrupción") será bajo porque el clúster será resistente tanto en zonas como en regiones, y porque Apache Cassandra es un sistema sin maestro (todos los nodos pueden escribir) de alta tolerancia a fallos por defecto. El RPO ("cuántos datos se pueden perder en una interrupción") será bajo porque los datos se sincronizarán entre todos los nodos y centros de datos, por lo que la pérdida de datos en una interrupción sería mínima.

Zonas de disponibilidad

La arquitectura sin maestro de Cassandra aporta tolerancia a errores desde cero y Azure Managed Instance for Apache Cassandra proporciona compatibilidad con zonas de disponibilidad en regiones seleccionadas para mejorar la resistencia en el nivel de infraestructura. Dado un factor de replicación de 3, la compatibilidad con la zona de disponibilidad garantiza que cada réplica se encuentra en una zona de disponibilidad diferente, lo que impide que una interrupción zonal afecte a la base de datos o la aplicación. Se recomienda habilitar zonas de disponibilidad siempre que sea posible.

Redundancia de red de varias regiones

La arquitectura de Cassandra, junto con la compatibilidad con zonas de disponibilidad de Azure, proporciona cierto nivel de tolerancia a errores y resistencia. Sin embargo, es importante tener en cuenta el impacto de las interrupciones regionales de las aplicaciones. Se recomienda implementar clústeres de varias regiones para proteger frente a interrupciones de nivel de región. Aunque son poco frecuentes, el posible impacto es grave.

Para la continuidad empresarial, no basta con hacer que la base de datos sea de varias regiones. Otras partes de la aplicación también deben implementarse de la misma manera, ya sea mediante la distribución o con mecanismos adecuados para conmutar por error. Si sus usuarios están repartidos por varias ubicaciones geográficas, la implantación de un centro de datos multi región para su base de datos tiene la ventaja añadida de reducir la latencia, ya que todos los nodos de todos los centros de datos del clúster pueden servir lecturas y escrituras de la región más cercana. Sin embargo, si la aplicación está configurada para que sea "activa-activa", es importante tener en cuenta cómo teorema CAP se aplica a la coherencia de los datos entre réplicas (nodos) y las ventajas comerciales necesarias para entregar alta disponibilidad.

En términos del teorema CAP, Cassandra es de forma predeterminada un sistema de base de datos AP (tolerante a particiones disponible), con una coherencia altamente ajustable. Para la mayoría de los casos de uso, se recomienda usar local_quorum para lecturas.

• En activo-pasivo para escrituras hay un compromiso entre fiabilidad y rendimiento: para la fiabilidad recomendamos QUORUM_EACH pero para la mayoría de los usuarios LOCAL_QUORUM o QUORUM es un buen compromiso. Tenga en cuenta, sin embargo, que en el caso de una interrupción regional, es posible que algunas escrituras se pierdan en LOCAL_QUORUM.
• En el caso de que una aplicación se ejecute en paralelo QUORUM_EACH escrituras se prefiere para la mayoría de los casos para garantizar la coherencia entre los dos centros de datos.
• Si el objetivo es favorecer la coherencia (RPO inferior) en lugar de la latencia o la disponibilidad (RTO inferior), esto debe reflejarse en la configuración de coherencia y el factor de replicación. Como regla general, el número de nodos de quórum necesarios para una lectura más el número de nodos de quórum necesarios para una escritura debe ser mayor que el factor de replicación. Por ejemplo, si tiene un factor de replicación de 3 y quorum_one en lecturas (un nodo), debe realizar quorum_all en escrituras (tres nodos), de modo que el total de 4 sea mayor que el factor de replicación de 3.

Replicación

Se recomienda auditar keyspaces y su configuración de replicación de vez en cuando para asegurarse de que se ha configurado la replicación necesaria entre centros de datos. En las primeras fases de desarrollo, se recomienda probar que todo funciona según lo previsto mediante pruebas sencillas mediante cqlsh. Por ejemplo, insertar un valor mientras está conectado a un centro de datos y leerlo desde el otro.

En concreto, al configurar un segundo centro de datos donde un centro de datos existente ya tiene datos, es importante determinar que todos los datos se han replicado y el sistema está listo. Se recomienda supervisar el progreso de la replicación a través de nuestros comandos DBA de con nodetool netstats. Un enfoque alternativo sería contar las filas de cada tabla, pero tenga en cuenta que, con tamaños de macro datos, debido a la naturaleza distribuida de Cassandra, esto solo puede dar una estimación aproximada.

Equilibrio del costo de la recuperación ante desastres

Si la aplicación es "activa-pasiva", se recomienda, por lo general, implementar la misma capacidad en cada región para que la aplicación pueda conmutar por error al instante a un centro de datos "en espera activa" en una región secundaria. Esto garantiza que no se produzca ninguna degradación del rendimiento en el caso de una interrupción regional. La mayoría de los controladores de cliente de Cassandra proporcionan opciones para iniciar la conmutación por error de nivel de aplicación. De forma predeterminada, asumen que la interrupción regional significa que la aplicación también está inactiva, en cuyo caso la conmutación por error debe producirse en el nivel del equilibrador de carga.

Sin embargo, para reducir el costo de aprovisionar un segundo centro de datos, puede que prefiera implementar una SKU más pequeña y menos nodos, en la región secundaria. Cuando se produce una interrupción, el escalado vertical se facilita en Azure Managed Instance for Apache Cassandra mediante escalado vertical y horizontal llave en mano. Aunque las aplicaciones conmutan por error a la región secundaria, puede escalar horizontalmente manualmente y escalar verticalmente los nodos del centro de datos secundario. En este caso, el centro de datos secundario actúa como un modo de espera activo de menor costo. Tomar este enfoque tendría que equilibrarse con el tiempo necesario para restaurar el sistema a toda la capacidad en caso de una interrupción. Es importante probar y practicar lo que sucede cuando se pierde una región.

Programaciones de copia de seguridad

Las copias de seguridad son automáticas en Azure Managed Instance for Apache Cassandra, pero puede elegir su propia programación para las copias de seguridad diarias. Se recomienda elegir horas con menos carga. Aunque las copias de seguridad están configuradas para consumir solo CPU inactiva, pueden desencadenar compactaciones en Cassandra, lo que puede provocar un aumento en el uso de la CPU. Las compactaciones pueden ocurrir en cualquier momento con Cassandra y dependen de la carga de trabajo y la estrategia de compactación elegida.

Pasos siguientes

En este artículo, hemos diseñado algunos procedimientos recomendados para compilar aplicaciones resistentes con Cassandra.