Alta disponibilidad y recuperación ante desastres con Azure Managed Redis (versión preliminar)
Al igual que con cualquier sistema en la nube, pueden producirse interrupciones no planeadas que provocan que una instancia de máquinas virtuales (VM), una zona de disponibilidad o una región de Azure completa dejen de funcionar. Se recomienda que los clientes tengan un plan para controlar las interrupciones regionales o de zona.
Este artículo presenta la información para que los clientes creen un plan de continuidad de negocio y recuperación ante desastres para su implementación de Azure Managed Redis (versión preliminar).
Opciones de alta disponibilidad:
| Opción | Descripción | Disponibilidad |
|---|---|---|
| Replicación estándar | Configuración replicada de dos nodos en un único centro de datos con conmutación automática por error | 99,9 % (consulte los detalles) |
| Redundancia de zona | Configuración replicada de varios nodos en zonas de disponibilidad, con conmutación automática por error. | 99.99 % (consulte los detalles) |
| Replicación geográfica | Instancias de caché vinculadas en dos regiones, con conmutación por error controlada por el usuario | Activo (consulte los detalles) |
| Import/Export | Instantánea de un momento dado de los datos en caché. | 99,9 % (consulte los detalles) |
| Persistencia | Almacenamiento periódico de datos en la cuenta de almacenamiento. | 99,9 % (consulte los detalles) |
Replicación estándar para lograr alta disponibilidad
Recomendado para: Alta disponibilidad
Azure Managed Redis tiene una arquitectura de alta disponibilidad que garantiza que su instancia administrada funcione, incluso cuando las interrupciones afecten a las máquinas virtuales (VM) subyacentes. Tanto si se trata de interrupciones planificadas como imprevistas, Azure Managed Redis ofrece porcentajes de disponibilidad superiores a los que se consiguen alojando Redis en una única máquina virtual. Una configuración de Azure Managed Redis se ejecuta en un par de servidores Redis de forma predeterminada. Los dos servidores se hospedan en máquinas virtuales dedicadas.
Con Azure Managed Redis, un servidor es el nodo primario, mientras que el otro es la réplica. Una vez que aprovisiona los nodos de servidor, Azure Managed Redis les asigna funciones primarias y de réplica. Normalmente, el nodo principal es responsable del mantenimiento de las solicitudes de escritura y de lectura de los clientes. En una operación de escritura, confirma una nueva clave y una actualización de claves en su memoria interna y responde inmediatamente al cliente. Además, reenvía la operación al nodo de réplica de forma asincrónica.
Si el nodo principal de una caché no está disponible, el de réplica se promueve para convertirse en el nodo principal automáticamente. Este proceso se denomina conmutación por error. Una conmutación por error es solo dos nodos, principal o réplica, que negocian roles, réplica/principal, con uno de los nodos que posiblemente se desconecta durante unos minutos. En la mayoría de las conmutaciones por error, los nodos principal y de réplica coordinan la entrega para que prácticamente no haya tiempo sin que tenga uno principal en funcionamiento.
El anterior nodo principal se desconecta brevemente para recibir actualizaciones del nuevo principal. Después, el de réplica ahora vuelve a estar en línea y se une de nuevo a la caché totalmente sincronizado. La clave es que cuando un nodo no está disponible, es algo temporal y volverá a estar en línea.
Una secuencia de conmutación por error típica tiene este aspecto, cuando un nodo principal debe dejar de funcionar para someterse a mantenimiento:
- Los nodos principales y de réplica negocian una conmutación por error coordinada y los roles.
- El de réplica (anteriormente el principal) se queda sin conexión para realizar un reinicio.
- Unos segundos o minutos después, el de réplica vuelve a estar en línea.
- El de réplica sincroniza los datos del principal.
Un nodo principal puede retirarse del servicio como parte de una actividad de mantenimiento planeado, como una actualización del sistema operativo o del software de Redis. También puede dejar de funcionar debido a eventos no planeados como errores en el hardware, el software o la red subyacentes. La conmutación por error y la aplicación de parches para Azure Managed Redis ofrece una explicación detallada de los tipos de conmutación por error. Un Azure Redis administrado pasa por muchas conmutaciones por error durante su vida útil. El diseño de la arquitectura de alta disponibilidad realiza estos cambios en una caché de la forma más transparente posible para sus clientes.
Redundancia de zona
Recomendado para: Alta disponibilidad, recuperación ante desastres: dentro de la región
Azure Managed Redis admite la configuración redundante de zonas de forma predeterminada. Una caché redundante de zona coloca automáticamente sus nodos en diferentes Azure Availability Zones de la misma región. Cuando una zona deja de funcionar, los nodos de la caché de otras zonas están disponibles para mantener la caché funcionando como de costumbre. Además, acaba con el problema de que las interrupciones de la zona de disponibilidad o del centro de datos sean el único punto de error, y aumenta la disponibilidad general de la caché.
Experiencia de Zona fuera de servicio
Cuando un nodo de datos deja de estar disponible o se produce una división de red, se realiza una conmutación por error similar a la descrita en Replicación estándar. El clúster utiliza un modelo basado en el cuórum para determinar qué nodos supervivientes participan en un nuevo cuórum. También promueve las particiones de réplica dentro de estos nodos en los elementos principales, según sea necesario.
Disponibilidad regional
Las cachés redundantes por zonas están disponibles en las siguientes regiones:
| América | Europa | Oriente Medio | África | Asia Pacífico |
|---|---|---|---|---|
| Centro de Canadá* | Norte de Europa | Este de Australia | ||
| Centro de EE. UU.* | Sur de Reino Unido 2 | Centro de la India | ||
| Este de EE. UU. | Oeste de Europa | Sudeste Asiático | ||
| Este de EE. UU. 2 | Este de Japón* | |||
| Centro-sur de EE. UU. | Este de Asia* | |||
| Oeste de EE. UU. 2 | ||||
| Oeste de EE. UU. 3 | ||||
| Sur de Brasil |
Persistencia
Recomendado para: Durabilidad de datos
Dado que los datos en caché se almacenan en la memoria, un error poco frecuente y no planeado de varios nodos puede provocar la anulación de todos los datos. Para evitar perder los datos por completo, la Persistencia de Redis permite tomar instantáneas periódicas de los datos en memoria y almacenarlas en un disco administrado conectado directamente a la instancia de caché. En caso de pérdida de datos, los datos de la caché se restauran automáticamente utilizando la instantánea del disco administrado. Para obtener más información, consulte Configurar la persistencia de datos para una instancia de Azure Managed Redis.
Import/Export
Recomendado para: Recuperación ante desastres
Azure Managed Redis admite la opción de importar y exportar archivos de base de datos Redis (RDB) para proporcionar portabilidad de datos. Permite importar datos a Azure Managed Redis o exportarlos desde Azure Managed Redis mediante una instantánea RDB. La instantánea RDB de una caché se exporta a un blob en una cuenta Azure Storage. Puede crear un script para desencadenar la exportación periódicamente a la cuenta de almacenamiento. Para obtener más información, consulte Importar y exportar datos en Azure Managed Redis.
Cuenta de almacenamiento para la exportación
Considere la posibilidad de elegir una cuenta de almacenamiento con redundancia geográfica para garantizar la alta disponibilidad de los datos exportados. Para más información, vea Redundancia de Azure Storage.
Replicación geográfica activa
Recomendado para: Alta disponibilidad, recuperación ante desastres: varias regiones
La replicación geográfica es un mecanismo para vincular instancias de Azure Managed Redis en varias regiones de Azure. Azure Managed Redis admite una forma avanzada de replicación geográfica denominada replicación geográfica activa que ofrece una mayor disponibilidad y recuperación ante desastres en varias regiones. El software Azure Managed Redis utiliza tipos de datos replicados sin conflictos para admitir escrituras en varias instancias de caché, fusiona cambios y resuelve conflictos. Puede unir hasta cinco instancias de caché en diferentes regiones de Azure para formar un grupo de replicación geográfica.
Una aplicación que usa dicha caché puede leer y escribir en cualquiera de las instancias de caché distribuidas geográficamente a través de sus puntos de conexión correspondientes. La aplicación debe usar lo que esté más cerca de cada instancia de la aplicación, lo que ofrece la menor latencia. Para obtener más información, consulte Configuración de la replicación geográfica activa para instancias de Azure Managed Redis.
Si una región de una de las cachés del grupo de replicación deja de funcionar, la aplicación debe cambiar a otra región que esté disponible.
Cuando una caché del grupo de replicación no está disponible, se recomienda supervisar el uso de memoria de otras cachés del mismo grupo de replicación. Mientras una de las cachés está fuera de servicio, todas las demás cachés del grupo de replicación empiezan a guardar metadatos que no pudieron compartir con la caché que está fuera de servicio. Si el uso de memoria de las cachés disponibles empieza a crecer a una velocidad alta después de que una de las cachés deje de funcionar, considere la posibilidad de desvincular la caché que no está disponible del grupo de replicación.
Para obtener más información sobre la desvinculación forzada, consulte Desvinculación forzada si se produce una interrupción de la región.
Eliminación y recreación de una caché
Si experimenta una interrupción regional, considere la posibilidad de volver a crear la caché en otra región y actualizar la aplicación para conectarse a la nueva caché en su lugar. Es importante entender que los datos se pierden durante una interrupción regional, a menos que utilice la replicación geográfica activa. El código de la aplicación debe ser resistente a la pérdida de datos.
Una vez restaurada la región afectada, su Azure Managed Redis no disponible se restaura automáticamente y vuelve a estar disponible para su uso. Para obtener más estrategias para mover su caché a una región diferente, consulte Mover instancias de Azure Managed Redis a diferentes regiones.