Alta disponibilidad y recuperación ante desastres
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.
En este artículo se presenta la información para que los clientes creen un plan de continuidad empresarial y recuperación ante desastres para su implementación de Azure Cache for Redis Enterprise o Azure Cache for Redis.
Hay varias opciones de alta disponibilidad disponibles en los niveles Estándar, Premium y Enterprise:
| Opción | Descripción | Disponibilidad | Estándar | Premium | Enterprise |
|---|---|---|---|---|---|
| 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) | Sí | Sí | Sí |
| Redundancia de zona | Configuración replicada de varios nodos en zonas de disponibilidad, con conmutación automática por error. | El 99,9 % en Premium; el 99,99 % en Enterprise (consulte los detalles) | Sí | Sí | Sí |
| Replicación geográfica | Instancias de caché vinculadas en dos regiones, con conmutación por error controlada por el usuario | Premium; Enterprise (consulte los detalles) | No | Pasivo | Activo |
| Import/Export | Instantánea de un momento dado de los datos en caché. | 99,9 % (consulte los detalles) | No | Sí | Sí |
| Persistencia | Almacenamiento periódico de datos en la cuenta de almacenamiento. | 99,9 % (consulte los detalles) | No | Sí | Vista previa |
Replicación estándar para lograr alta disponibilidad
Niveles aplicables: Estándar, Premium, Enterprise, Enterprise Flash
Recomendado para: Alta disponibilidad
Azure Cache for Redis tiene una arquitectura de alta disponibilidad que garantiza el funcionamiento de la instancia administrada, incluso cuando las interrupciones afectan a las máquinas virtuales (VM) subyacentes. Tanto si se trata de interrupciones planeadas como no planeadas, Azure Cache for Redis ofrece porcentajes de disponibilidad superiores a los que se consiguen hospedando Redis en una única máquina virtual.
De manera predeterminada, una instancia de Azure Cache for Redis en los niveles aplicables se ejecuta en un par de servidores de Redis. Los dos servidores se hospedan en máquinas virtuales dedicadas. Redis de código abierto solo permite que un servidor controle las solicitudes de escritura de datos.
Con Azure Cache for Redis, un servidor es el nodo principal, mientras que el otro es la réplica. Después de aprovisionar los nodos de servidor, Azure Cache for Redis les asigna roles principales 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.
Nota:
Normalmente, una aplicación cliente de Azure Cache for Redis se comunica con el nodo principal en una caché para todas las solicitudes de lectura y escritura. Algunos clientes se pueden configurar para que lleven a cabo operaciones de lectura desde el nodo de réplica.
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. En el artículo Conmutación por error y aplicación de revisiones para Azure Cache for Redis se proporciona una explicación detallada sobre los tipos de conmutaciones por error. Una instancia de Azure Cache for Redis pasa por muchas conmutaciones por error durante su vigencia. 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.
Además, Azure Cache for Redis proporciona más nodos de réplica en el nivel Prémium. Una caché de varias réplicas puede configurarse con hasta tres nodos de réplica. Normalmente, la existencia de más réplicas mejora la resistencia porque hay nodos que hacen copia de seguridad del principal. Incluso con más réplicas, una instancia de Azure Cache for Redis se puede ver seriamente afectada por la interrupción de un centro de datos o una zona de disponibilidad. Puede aumentar la disponibilidad de la caché usando varias réplicas con redundancia de zona.
Redundancia de zona
Niveles aplicables: Estándar, Premium, Enterprise, Enterprise Flash
Recomendado para: Alta disponibilidad, recuperación ante desastres: dentro de la región
Azure Cache for Redis admite configuraciones con redundancia de zona en los niveles Estándar, Premium y Enterprise. Una caché con redundancia de zona puede colocar sus nodos en diferentes zonas de disponibilidad de Azure dentro de la misma región. 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é.
Si una caché está configurada para usar dos o más zonas, como se ha descrito anteriormente en el artículo, los nodos de la caché se crean en zonas diferentes. 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.
Importante
Azure Cache For Redis crea de forma predeterminada cachés con redundancia de zona para niveles Premium y Estándar mediante Automatic_Zonal_Allocation en regiones que admiten zonas. Para obtener más información, consulte Habilitar la redundancia de zona para Azure Cache for Redis.
Nivel Premium
En el diagrama siguiente se muestra la configuración de redundancia de zona para el nivel Premium:
Azure Cache for Redis distribuye mediante un mecanismo round-robin los nodos de una caché con redundancia de zona por las zonas de disponibilidad seleccionadas. También determina el nodo que actúa inicialmente como principal.
Experiencia de bajada de zona para el nivel Premium
Una caché con redundancia de zona proporciona conmutación automática por error. Cuando el nodo principal actual no está disponible, una de las réplicas toma el control. Es posible que la aplicación experimente un mayor tiempo de respuesta de la caché si el nuevo nodo principal se encuentra en otra zona de disponibilidad. Las zonas de disponibilidad están separadas geográficamente. Si se cambia de una zona de disponibilidad a otra, se altera la distancia física entre el lugar en el que se hospedan la aplicación y la caché. Este cambio afecta a las latencias de red bidireccionales entre la aplicación y la caché. La latencia adicional debería estar dentro de un intervalo aceptable en la mayoría de las aplicaciones. Se recomienda probar la aplicación para asegurarse de que funciona correctamente con una caché con redundancia de zona.
Niveles Enterprise y Enterprise Flash
Una caché en el nivel Enterprise se ejecuta en un clúster de Redis Enterprise. Siempre se requiere un número impar de nodos de servidor para que haya cuórum. De forma predeterminada, tiene tres nodos, cada uno hospedado en una máquina virtual dedicada.
- Una memoria caché de Enterprise tiene dos nodos de datos del mismo tamaño y un nodo de cuórum más pequeño.
- Una caché de Enterprise Flash tiene tres nodos de datos del mismo tamaño.
El clúster de Enterprise divide los datos de Azure Cache for Redis en particiones internamente. Cada partición tiene un elemento principal y al menos una réplica. Cada nodo de datos contiene una o más particiones. El clúster de Enterprise garantiza que el elemento principal y las réplicas de cualquier partición no se coloquen nunca en el mismo nodo de datos. Las particiones replican datos de forma asincrónica desde los elementos principales a sus réplicas correspondientes.
Experiencia de bajada de zona para los niveles Enterprise
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 de Enterprise usa un modelo basado en cuórum para determinar qué nodos disponibles 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 memorias caché de nivel Estándar con redundancia de zona están disponibles en las siguientes regiones:
| América | Europa | Oriente Medio | África | Asia Pacífico |
|---|---|---|---|---|
| Sur de Brasil | Centro de Francia | Centro de Catar | Norte de Sudáfrica | Este de Australia |
| Centro de Canadá | Norte de Italia | Norte de Emiratos Árabes Unidos | Centro de la India | |
| Centro de EE. UU. | Centro-oeste de Alemania | Centro de Israel | Japón Oriental | |
| Este de EE. UU. | Este de Noruega | |||
| Este de EE. UU. 2 | Norte de Europa | Sudeste de Asia | ||
| Centro-sur de EE. UU. | Sur de Reino Unido | Este de Asia | ||
| US Gov - Virginia | Oeste de Europa | Norte de China 3 | ||
| Oeste de EE. UU. 2 | Centro de Suecia | Centro de Corea del Sur | ||
| Oeste de EE. UU. 3 | Norte de Suiza | Norte de Nueva Zelanda | ||
| Centro de México | Centro de Polonia | |||
| Centro de España |
Las cachés de nivel Enterprise y Enterprise Flash con redundancia de zona 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 |
*El nivel Enterprise Flash no está disponible en esta región.
Reimplementación y migración de una zona de disponibilidad
Actualmente, la única manera de convertir la caché de una configuración que no es de AZ a una configuración de AZ es volver a implementarla. Para saber cómo volver a implementar la caché actual, consulte Migración de una instancia de Azure Cache for Redis a la compatibilidad con la zona de disponibilidad.
Persistencia
Niveles aplicables: Premium, Enterprise (versión preliminar), Enterprise Flash (versión preliminar)
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 la pérdida completa de datos, la persistencia de Redis permite tomar instantáneas periódicas de los datos en memoria y almacenarlas en la cuenta de almacenamiento. Si se produce un error en varios nodos que provoca la pérdida de datos, la caché carga la instantánea de la cuenta de almacenamiento. Para obtener más información, consulte Configuración de la persistencia de datos en la instancia prémium de Azure Cache for Redis.
Cuenta de almacenamiento para la persistencia
Considere la posibilidad de elegir una cuenta de almacenamiento con redundancia geográfica para garantizar la alta disponibilidad de los datos persistentes. Para más información, vea Redundancia de Azure Storage.
Import/Export
Niveles aplicables: Premium, Enterprise, Enterprise Flash
Recomendado para: Recuperación ante desastres
Azure Cache for Redis admite la opción de importar y exportar archivos de la base de datos de Redis (RDB) para proporcionar portabilidad de datos. Permite importar datos en Azure Cache for Redis o exportar datos desde Azure Cache for Redis mediante una instantánea de RDB. La instantánea de RDB de una caché prémium se exporta a un blob de una cuenta de 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 Importación y exportación de datos en Azure Cache for 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 pasiva
Niveles aplicables: Premium
Recomendado para: Recuperación ante desastres: una sola región
La replicación geográfica es un mecanismo para vincular dos instancias o más de Azure Cache for Redis, normalmente abarcando dos regiones de Azure. La replicación geográfica está diseñada principalmente para la recuperación ante desastres entre regiones. Dos instancias de caché de nivel Premium están conectadas mediante la replicación geográfica de forma que se proporcionan lecturas y escrituras a la caché principal y los datos se replican en la caché secundaria.
Para obtener más información sobre cómo llevar a cabo la configuración, consulte Configuración de la replicación geográfica para las instancias de Azure Cache for Redis prémium.
Si la región en que se hospeda la caché principal deja de funcionar, deberá iniciar la conmutación por error de la siguiente forma: primero, desvincule la caché secundaria y, a continuación, actualice la aplicación a fin de que apunte a la caché secundaria para las lecturas y las escrituras.
Replicación geográfica activa
Niveles aplicables: Enterprise, Enterprise Flash
Recomendado para: Alta disponibilidad, recuperación ante desastres: varias regiones
Los niveles Enterprise admiten una forma más avanzada de replicación geográfica llamada replicación geográfica activa que ofrece una mayor disponibilidad y recuperación ante desastres entre regiones en varias regiones. El software de Azure Cache for Redis Enterprise usa tipos de datos replicados sin conflictos para admitir escrituras en varias instancias de caché, combina cambios y resuelve conflictos. Puede unir hasta cinco instancias de caché de nivel Enterprise en distintas 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 las instancias de Azure Cache for Redis Enterprise.
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é
Niveles aplicables: Estándar, Premium, Enterprise, Enterprise Flash
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 comprender que los datos se perderán durante una interrupción regional. El código de la aplicación debe ser resistente a la pérdida de datos.
Una vez restaurada la región afectada, la instancia de Azure Cache for Redis no disponible se restaura automáticamente y está disponibles para volver a usarse. A fin de obtener más estrategias para mover la caché a otra región, consulte Traslado de instancias de Azure Cache for Redis a regiones diferentes.
Pasos siguientes
Obtenga más información sobre cómo configurar las opciones de alta disponibilidad de Azure Cache for Redis.