Nota:
El acceso a esta página requiere autorización. Puede intentar iniciar sesión o cambiar directorios.
El acceso a esta página requiere autorización. Puede intentar cambiar los directorios.
Azure Managed Instance for Apache Cassandra es un servicio totalmente administrado para clústeres de Apache Cassandra de código abierto puros. El servicio permite invalidar las configuraciones, en función de las necesidades de cada carga de trabajo, lo que permite la máxima flexibilidad y control cuando sea necesario.
Apache Cassandra es una excelente opción para crear aplicaciones altamente resistentes debido a su naturaleza distribuida y a la arquitectura punto a punto. Cualquier nodo de la base de datos puede proporcionar la misma funcionalidad que cualquier otro nodo. Este diseño contribuye a la solidez 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.
Objetivo de punto de recuperación y objetivo de tiempo de recuperación
Siempre que tenga los siguientes elementos, el objetivo de punto de recuperación (RPO) y el objetivo de tiempo de recuperación (RTO) suelen ser bajos, cerca de cero:
- Implementación de varias regiones con replicación entre regiones y un factor de replicación de 3.
- Zonas de disponibilidad habilitadas. Configure esta opción al crear un clúster en Azure Portal o mediante la 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 Azure Traffic Manager o Azure Front Door.
RTO es el tiempo que se está inactivo durante una interrupción. Es bajo porque el clúster es resistente tanto en zonas como en regiones. Además, el propio Apache Cassandra es un sistema altamente tolerante a errores, punto a punto, donde todos los nodos pueden escribir de forma predeterminada.
RPO es la cantidad de datos que puede perder en una interrupción. Es bajo porque los datos se sincronizan entre todos los nodos y centros de datos. La pérdida de datos en una interrupción sería mínima.
Nota:
No es posible lograr RTO=0 y RPO=0 por el teorema CAP. Evalúe el equilibrio entre la coherencia y la disponibilidad o el rendimiento óptimo.
Este equilibrio es diferente para cada aplicación. Por ejemplo, si la aplicación tiene mucha lectura, podría ser mejor hacer frente a una mayor latencia de escrituras entre regiones para evitar la pérdida de datos, lo que favorece la coherencia. Si la aplicación está escribiendo con requisitos de latencia estrictas, el riesgo de perder algunas de las escrituras más recientes en una interrupción regional principal podría ser aceptable, lo que favorece la disponibilidad.
Zonas de disponibilidad
La arquitectura punto a punto de Cassandra aporta tolerancia a errores desde cero. Azure Managed Instance para Apache Cassandra proporciona compatibilidad con zonas de disponibilidad en regiones seleccionadas. Esta compatibilidad mejora la resistencia en el nivel de infraestructura. Para 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. Este enfoque 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 un nivel de tolerancia a errores y resistencia. Tenga en cuenta también el impacto de las interrupciones regionales de las aplicaciones. Para proteger contra interrupciones de nivel de región, se recomienda implementar varios clústeres de regiones. Aunque son poco frecuentes, el posible impacto es grave.
Para la continuidad empresarial, no es suficiente usar una base de datos de varias regiones. Otras partes de la aplicación también deben distribuirse o contar con mecanismos adecuados para conmutar por error. Si los usuarios se distribuyen entre muchas ubicaciones geográficas, una implementación del centro de datos de varias regiones para la base de datos tiene la ventaja adicional de reducir la latencia. Todos los nodos de todos los centros de datos del clúster pueden servir tanto lecturas como escrituras desde la región más cercana a ellos.
Si la aplicación está configurada para que sea activo-activo, considere cómo se aplica el teorema CAP a la coherencia de los datos entre réplicas (nodos) y las ventajas que se requieren para entregar alta disponibilidad.
En términos del teorema CAP, Cassandra es de forma predeterminada un sistema de base de datos tolerante a particiones (AP) disponible, con coherencia altamente ajustable. Para la mayoría de los casos de uso, se recomienda usar LOCAL_QUORUM para lecturas.
En activo-pasivo para las escrituras, hay un equilibrio entre confiabilidad y rendimiento. Para obtener mayor fiabilidad, recomendamos QUORUM_EACH. Sin embargo, para la mayoría de los usuarios, LOCAL_QUORUM o QUORUM es un buen compromiso. Si hay una interrupción regional, es posible que algunas escrituras se pierdan en LOCAL_QUORUM.
Para la mayoría de los casos, si una aplicación se ejecuta en paralelo, se deben preferir las escrituras QUORUM_EACH para garantizar la consistencia entre los dos centros de datos.
Si el objetivo es favorecer la coherencia, o un RPO inferior, en lugar de latencia o disponibilidad, o un RTO inferior, la configuración de coherencia y el factor de replicación deben reflejar este objetivo.
En general, el número de nodos de cuórum necesarios para una lectura más el número de nodos de cuó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.
Nota:
El operador del plano de control para Azure Managed Instance para Apache Cassandra solo se implementa en una sola región. La región es la seleccionada al implementar el primer centro de datos. En el improbable caso de una interrupción total de la región, nos comprometemos a un tiempo de recuperación de 3 horas para conmutar por error el plano de control a otra región.
Dado que los centros de datos deben seguir funcionando, este problema no afecta al Acuerdo de Nivel de Servicio de disponibilidad para el servicio. Durante este período, es posible que no sea posible realizar cambios en la configuración de la base de datos desde Azure Portal o las herramientas del proveedor de recursos.
Replicación
Se recomienda auditar keyspaces y su configuración de replicación de vez en cuando para asegurarse de que se configura la replicación necesaria entre centros de datos. En las primeras fases de desarrollo, se recomienda realizar pruebas sencillas mediante cqlsh. Por ejemplo, inserte un valor mientras está conectado a un centro de datos y léelo desde el otro.
En concreto, cuando configura un segundo centro de datos donde un centro de datos existente ya tiene datos, determine que ha replicado todos los datos y que el sistema está listo. Recomendamos que supervises el progreso de la replicación a través de nuestros comandos DBA con nodetool netstats. Un enfoque alternativo sería contar las filas de cada tabla. Tenga en cuenta que, con tamaños de macrodatos, debido a la naturaleza distribuida de Cassandra, este enfoque solo puede proporcionar una estimación aproximada.
Equilibrio del costo de la recuperación ante desastres
Si la aplicación es activa-pasiva, se recomienda que implemente la misma capacidad en cada región. Este enfoque ayuda a su aplicación a cambiar instantáneamente a un centro de datos en espera activa en una región secundaria. Si se produce una interrupción regional, este enfoque garantiza que no haya degradación del rendimiento. 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, por lo que la conmutación por error debe producirse en el nivel del equilibrador de carga.
Para reducir el costo de aprovisionar un segundo centro de datos, es posible que prefiera implementar una SKU más pequeña y menos nodos en la región secundaria. Cuando se produce una interrupción, escalado vertical y horizontal llave en mano facilita el escalado vertical y horizontal en Azure Managed Instance for Apache Cassandra. Aunque las aplicaciones conmutan por error a la región secundaria, puede escalar horizontalmente y escalar verticalmente de forma manual los nodos del centro de datos secundario. El centro de datos secundario actúa como un modo de espera activo de menor costo. Es necesario equilibrar este enfoque con el tiempo necesario para restaurar el sistema a la capacidad completa si se produce una interrupción. Es importante probar y practicar lo que sucede cuando se pierde una región.
Nota:
El escalado vertical de los nodos es mucho más rápido que el escalado horizontal. Tenga en cuenta este hecho cuando tenga en cuenta el equilibrio entre la escala vertical y horizontal y el número de nodos que se van a implementar en el clúster.
Programaciones de copia de seguridad
Las copias de seguridad son automáticas en Azure Managed Instance para Apache Cassandra. 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. Dependen de la carga de trabajo y de la estrategia de compactación elegida.
Importante
La intención de las copias de seguridad es mitigar la pérdida accidental de datos o daños en los datos. No recomendar copias de seguridad como una estrategia de recuperación ante desastres.
Las copias de seguridad no tienen redundancia geográfica. Incluso si fuera así, puede tardar mucho tiempo en recuperar una base de datos de copias de seguridad. Por lo tanto, se recomienda encarecidamente varias implementaciones de regiones, junto con la habilitación de zonas de disponibilidad siempre que sea posible, para mitigar los escenarios de desastres y para poder recuperarse de ellas de forma eficaz. Este enfoque es especialmente importante en los escenarios poco frecuentes en los que no se puede recuperar la región fallida. Sin la replicación en varias regiones, es posible que se pierdan todos los datos.
