Compartir a través de

Configuración de la replicación geográfica pasiva para las instancias Premium de Azure Cache for Redis

  • Artículo

En este artículo, descubrirá cómo configurar la replicación geográfica pasiva en un par de instancias de Azure Cache for Redis mediante Azure Portal.

La replicación geográfica pasiva une dos instancias de Azure Cache for Redis de nivel Premium y crea una relación de replicación de datos activa-pasiva. Activa-pasiva significa que hay un par de cachés, principal y secundaria, que tienen sus datos sincronizados. Pero solo puede escribir en un lado del par, la principal. El otro lado del par, la caché secundaria, es de solo lectura.

Compare activa-pasiva con activa-activa, donde puede escribir en cualquier lado del par y, después, se sincroniza con el otro lado.

Con la replicación geográfica pasiva, las instancias de caché se encuentran normalmente en diferentes regiones de Azure, aunque no es un requisito exigido. Una instancia actúa como la principal y la otra como la secundario. La principal controla las solicitudes de lectura y escritura y propaga los cambios a la secundaria.

La conmutación por error no es automática. Para obtener más información sobre cómo usar la conmutación por error, vea Inicio de una conmutación por error de la caché geográfica principal a la geográfica secundaria.

Nota

La replicación geográfica pasiva está diseñada como una solución de recuperación ante desastres.

Ámbito de disponibilidad

Nivel Básico y Estándar Premium Enterprise o Enterprise Flash
Disponible No Sí Sí

La replicación geográfica pasiva solo está disponible en el nivel Premium de Azure Cache for Redis. Los niveles Enterprise y Enterprise Flash también ofrecen replicación geográfica, pero usan una versión más avanzada denominada replicación geográfica activa.

Requisitos previos de la replicación geográfica

Para configurar la replicación geográfica entre dos cachés, se deben cumplir los siguientes requisitos previos:

  • Ambas deben ser cachés de nivel Premium.
  • Ambas cachés deben tener solo una réplica por cada partición principal.
  • Ambas cachés deben estar en la misma suscripción de Azure.
  • La caché vinculada secundaria debe tener el mismo tamaño de caché o un tamaño de caché mayor que la caché vinculada principal. Para usar la conmutación por error geográfica, ambas cachés deben tener el mismo tamaño.
  • Ambas cachés deben estar creadas y en ejecución.
  • Ambas cachés ejecutan la misma versión del servidor de Redis.

Nota

La transferencia de datos entre regiones de Azure se cobrará según las tarifas de ancho de banda estándar.

Algunas características no son compatibles con la replicación geográfica:

  • La persistencia no es compatible con la replicación geográfica.
  • Las memorias caché con más de una réplica no se pueden replicar geográficamente.
  • Se admite la agrupación en clústeres si ambas cachés tienen la agrupación en clústeres habilitada y tienen el mismo número de particiones.
  • Se admiten las memorias caché red virtual (VNet).
  • Las memorias caché de distintas redes virtuales son compatibles con advertencias. Consulte ¿Puedo usar la replicación geográfica con cachés en una VNet? para obtener más información.

Una vez que se configura la replicación geográfica, se aplican las siguientes restricciones al par de cachés vinculadas:

  • La caché vinculada secundaria es de solo lectura. Puede leer desde ella, pero no puede escribir ningún dato en ella. Si decide leer desde la instancia de replicación geográfica secundaria, cuando se produzca una sincronización de datos completa entre las instancias principal y secundaria de replicación geográfica, la instancia secundaria de replicación geográfica generará errores en cualquier operación de Redis que realice en ella hasta que finalice la sincronización de datos completa. Los errores indicarán que hay en curso una sincronización de datos completa. Además, los errores se producirán en el momento en que se actualice la instancia principal o secundaria de replicación geográfica y en algunos escenarios de reinicio. Las aplicaciones que leen desde la instancia de replicación geográfica secundaria deben crearse para revertir a la instancia de replicación geográfica principal cada vez que la secundaria genere tales errores.

  • Se quitarán los datos existentes en la caché vinculada secundaria antes de la vinculación. Sin embargo, si la replicación geográfica se quita posteriormente, los datos replicados permanecen en la caché vinculada secundaria.

  • No puede escalar ninguna de las cachés mientras están vinculadas.

  • No puede cambiar el número de particiones si la caché tiene la agrupación en clústeres habilitada.

  • No puede habilitar la persistencia en ninguna de las cachés.

  • Puede exportar desde cualquier caché.

  • No puede importar en la caché vinculada secundaria.

  • No puede eliminar la caché vinculada, ni el grupo de recursos que las contiene, hasta que se desvinculen las cachés. Para más información, vea ¿Por qué no se pudo realizar la operación al intentar eliminar la memoria caché vinculada?

  • Si las memorias caché se encuentran en regiones diferentes, los costes de salida de red se aplican a los datos que se mueven entre regiones. Para más información, consulte el artículo sobre cuánto cuesta replicar datos entre regiones de Azure.

  • La conmutación por error no es automática. Debe iniciar la conmutación por error de la caché principal a la caché secundaria vinculada. Para obtener más información sobre cómo usar la conmutación por error, vea Inicio de una conmutación por error de la caché geográfica principal a la geográfica secundaria.

  • Los vínculos privados no se pueden agregar a las cachés que ya tienen replicación geográfica. Para agregar un vínculo privado a una caché con replicación geográfica, siga estos pasos: 1. Desvincule la replicación geográfica. 2. Agregue un vínculo privado. 3. Por último, vuelva a vincular la replicación geográfica.

  1. Para vincular dos cachés para la replicación geográfica, primero seleccione Replicación geográfica en el menú Recursos de la caché que vaya a ser la caché vinculada principal. Después, seleccione Agregar vínculo de replicación de caché en el panel de trabajo.

    Captura de pantalla en la que se muestra el menú Replicación geográfica de la caché.

  2. Seleccione el nombre de la caché secundaria deseada en la lista Cachés compatibles. Si la caché secundaria no aparece en la lista, compruebe que se cumplen los requisitos previos de replicación geográfica para la caché secundaria. Para filtrar las cachés por región, seleccione la región en el mapa para mostrar solo esas cachés en la lista de cachés disponibles.

    Captura de pantalla en la que se muestran las cachés compatibles para vincular con la replicación geográfica.

    También puede iniciar el proceso de vinculación o ver detalles sobre la caché secundaria mediante el menú contextual.

    Captura de pantalla en la que se muestra el menú contextual de replicación geográfica.

  3. Seleccione Vincular para vincular las dos cachés y comenzar el proceso de replicación.

    Captura de pantalla en la que se muestra cómo vincular las cachés para la replicación geográfica.

  4. Puede ver el progreso del proceso de replicación por medio de Replicación geográfica en el menú Recurso.

    Captura de pantalla en la que se muestra el estado de vinculación actual.

    También puede consultar el estado de la vinculación en el menú Recurso, en Información general, para las dos cachés, la principal y la secundaria.

    Captura de pantalla que destaca cómo ver el estado de vinculación de las memorias caché principales y secundarias.

    Una vez que se completa el proceso de replicación, el estado de aprovisionamiento del vínculo cambia a Correcto.

    Captura de pantalla en la que se muestra el estado de vinculación de la caché como Correcto.

    La caché vinculada principal sigue estando disponible para su uso durante el proceso de vinculación. La caché vinculada secundaria no está disponible hasta que se complete el proceso de vinculación.

URL principal geográfica

Después de vincular las memorias caché, se genera una dirección URL para cada caché que apunta siempre a la caché principal geográfica. Si se inicia una conmutación por error desde la base de datos geográfica principal a la geográfica secundaria, la dirección URL sigue siendo la misma y el registro DNS subyacente se actualiza automáticamente para que apunte a la nueva base de datos geográfica principal.

Captura de pantalla en la que se muestran cuatro direcciones URL creadas al incorporar replicación geográfica.

Se muestran tres direcciones URL:

  • La dirección URL geográfica principal es una dirección URL de proxy con el formato <cachename>.geo.redis.cache.windows.net. La dirección URL siempre apunta a la memoria caché del par de replicación geográfica actual.
  • La caché geográfica principal actual es la dirección directa de la caché que actualmente es la geográfica principal. La dirección es redis.cache.windows.net, no geo.redis.cache.windows.net. La dirección que aparece en el campo cambia si se inicia una conmutación por error.
  • La caché geográfica secundaria actual es la dirección directa de la caché que actualmente es la geográfica secundaria. La dirección es redis.cache.windows.net, no geo.redis.cache.windows.net. La dirección que aparece en el campo cambia si se inicia una conmutación por error.

Inicio de una conmutación por error de la caché geográfica principal a la geográfica secundaria

Con un solo clic en seleccionar, puede desencadenar una conmutación por error de la caché geográfica principal a la geográfica secundaria.

Captura de pantalla de las cachés vinculadas con la opción Conmutación por error resaltada.

Esto hace que se tengan que seguir los pasos siguientes:

  1. La caché geográfica secundaria se promueve a la geográfica principal.
  2. Los registros DNS se actualizan para redirigir las direcciones URL geográficas principales a la nueva caché geográfica principal.
  3. La caché geográfica principal antigua se degrada a la secundaria e intenta formar un vínculo a la caché geográfica principal nueva.

El proceso de conmutación por error geográfica tarda algunos minutos en completarse.

Configuración para comprobar antes de iniciar la conmutación por error geográfica

Cuando se inicia la conmutación por error, las cachés geográficas principales y secundarias se intercambian. Si la caché geográfica principal nueva está configurada de forma diferente a la geográfica secundaria, puede crear problemas para la aplicación.

Asegúrese de comprobar los elementos siguientes:

  • Si usa un firewall en cualquier caché, asegúrese de que la configuración del firewall sea similar para que no tenga problemas de conexión.
  • Asegúrese de que ambas cachés usan el mismo puerto y la misma configuración de TLS/SSL.
  • Las cachés geográfica principal y geográfica secundaria tienen claves de acceso diferentes. Si se desencadena una conmutación por error, asegúrese de que la aplicación puede actualizar la clave de acceso que usa para que coincida con la caché geográfica principal nueva. O bien, use tokens de Microsoft Entra para la autenticación en caché, lo que le permite usar la misma credencial de autenticación para las cachés geográficas principal y secundaria.

Conmutación por error con pérdida de datos mínima

Los eventos de conmutación por error geográfica pueden introducir incoherencias de datos durante la transición, especialmente si el cliente mantiene una conexión con la caché geográfica principal antigua durante el proceso de conmutación por error. Es posible minimizar la pérdida de datos en un evento de conmutación por error geográfica planeada; para ello, siga las sugerencias siguientes:

  • Compruebe la métrica de desplazamiento de sincronización de datos de replicación geográfica. La métrica la emite la caché geográfica principal actual. Esta métrica indica la cantidad de datos que todavía se van a replicar en la caché geográfica principal. Si es posible, inicie solo la conmutación por error si la métrica indica que quedan por escribir menos de 14 bytes.
  • Ejecute el comando CLIENT PAUSE en la caché geográfica principal actual antes de iniciar la conmutación por error. La ejecución de CLIENT PAUSE bloquea las solicitudes nuevas de escritura y, en su lugar, devuelve errores de tiempo de espera en el cliente de Azure Cache for Redis. El comando CLIENT PAUSE requiere proporcionar un periodo de tiempo de espera en milisegundos. Asegúrese de que se proporciona un periodo de tiempo de espera suficiente para permitir que se produzca la conmutación por error. Un buen punto de partida sería establecer el valor de pausa en alrededor de 30 minutos (1 800 000 milisegundos). Siempre puede reducir este número según sea necesario.

No es necesario ejecutar el comando CLIENT UNPAUSE, ya que la caché geográfica principal nueva conserva la pausa del cliente.

Nota:

El uso de la autenticación basada en Microsoft Entra ID para la caché se recomienda en escenarios de conmutación por error geográficos, ya que elimina la dificultad de tener que administrar diferentes claves de acceso para las cachés geográficas principal y secundaria.

  1. Para quitar el vínculo entre dos cachés y detener la replicación geográfica, seleccione Replicación geográfica a la izquierda y elija Desvincular cachés.

    Captura de pantalla en la que se muestra cómo desvincular las cachés.

    Una vez que se completa el proceso de desvinculación, la caché secundaria queda disponible tanto para lecturas como para escrituras.

Nota

Cuando se quita el vínculo de replicación geográfica, los datos replicados de la caché vinculada principal se mantienen en la caché secundaria.

Preguntas más frecuentes sobre la replicación geográfica

¿Puedo usar la replicación geográfica con una caché de nivel Estándar o Básico?

No, la replicación geográfica pasiva solo está disponible en el nivel Premium. Hay disponible una versión más avanzada de replicación geográfica denominada replicación geográfica activa en el nivel Enterprise y Enterprise Flash.

¿La caché está disponible para usarla durante los procesos de vinculación o desvinculación?

  • La caché vinculada principal sigue estando disponible hasta que se completa el proceso de vinculación.
  • La caché vinculada secundaria no está disponible hasta que se complete el proceso de vinculación.
  • Ambas cachés siguen estando disponibles hasta que se completa el proceso de desvinculación.

¿Cuándo puedo escribir en la nueva base de datos geográfica principal después de iniciar la conmutación por error?

Cuando se inicie el proceso de conmutación por error, verá la actualización del estado de aprovisionamiento del vínculo en Eliminación en curso, lo que indica que se está limpiando el vínculo anterior. Después de completar esto, el estado de aprovisionamiento del vínculo se actualiza a Creación en curso. Esto indica que la nueva base de datos geográfica principal está en funcionamiento e intenta volver a establecer un vínculo de replicación geográfica a la caché principal geográfica antigua. En este momento, podrá conectarse inmediatamente a la nueva instancia de caché principal geográfica para lecturas y escrituras.

Sí, hay varias métricas disponibles que permiten realizar un seguimiento del estado de la replicación geográfica. Estas métricas están disponibles en Azure Portal.

  • Geo Replication Healthy muestra el estado del vínculo de replicación geográfica. El vínculo se muestra como incorrecto si la caché geográfica principal o la geográfica secundaria está inactiva. Esto suele deberse a operaciones estándar de aplicación de revisiones, pero también podría indicar una situación de error.
  • Geo Replication Connectivity Lag muestra el tiempo transcurrido desde la última sincronización de datos correcta entre la caché geográfica principal y la geográfica secundaria.
  • Geo Replication Data Sync Offset muestra la cantidad de datos que aún no se han sincronizado con la caché geográfica secundaria.
  • Geo Replication Fully Sync Event Started indica que se ha iniciado una acción de sincronización completa entre la caché geográfica principal y la geográfica secundaria. Esto ocurre si la replicación estándar no puede mantenerse al día con el número de escrituras nuevas.
  • Geo Replication Full Sync Event Finished indica que se ha completado una acción de sincronización completa.

También hay un libro pregenerado denominado Panel de replicación geográfica que incluye todas las métricas de mantenimiento de replicación geográfica en una sola vista. Se recomienda usar esta vista porque agrega información que se emite solo desde las instancias de caché geográfica principal o secundaria.

No, solo puede vincular dos cachés cuando se usa la replicación geográfica pasiva. La replicación geográfica activa admite hasta cinco cachés vinculadas.

No, ambas cachés deben estar en la misma suscripción de Azure.

Sí, siempre que la caché vinculada secundaria sea mayor que la caché vinculada principal. Pero no puede usar la característica de conmutación por error si las cachés tienen diferentes tamaños.

¿Puedo usar la replicación geográfica con la agrupación en clústeres habilitada?

Sí, siempre que ambas cachés tengan la misma cantidad de particiones.

¿Puedo usar la replicación geográfica con mis memorias caché en una VNet?

Se recomienda usar Azure Private Link en lugar de la inyección de VNet en la mayoría de los casos. Para más información, consulte Migración de cachés de inserción de red virtual a cachés de Private Link.

Aunque técnicamente es posible usar la inyección de VNet al replicar geográficamente las memorias caché, se recomienda Azure Private Link.

Importante

Azure Cache for Redis recomienda usar Azure Private Link, que simplifica la arquitectura de red y protege la conexión entre los puntos de conexión en Azure. Puede conectarse a una instancia de Azure Cache desde la red virtual a través de un punto de conexión privado, al que se le asigna una dirección IP privada en una subred dentro de la red virtual. Azure Private Links se ofrece en todos nuestros niveles, incluye compatibilidad con Azure Policy y administración simplificada de reglas de NSG. Para más información, consulte Documentación de Private Link. Para migrar las memorias caché de red virtual Private Link, consulte Migración de cachés de inserción de red virtual a Private Link cachés.

Para más información sobre la compatibilidad con la replicación geográfica con redes virtuales, consulte Replicación geográfica mediante inyección de VNet con cachés Premium.

¿Qué es la programación de replicación para la replicación geográfica de Redis?

La replicación es continua y asincrónica. No ocurre según una programación específica. Todas las escrituras realizadas en el servidor principal se replican asincrónicamente y al instante en el servidor secundario.

¿Cuánto tiempo tarda la replicación geográfica?

La replicación es incremental, asincrónica y continua, y el tiempo empleado no es muy diferente de la latencia entre regiones. En determinadas circunstancias, la caché secundaria puede requerir la realización de una sincronización completa de los datos del servidor principal. El tiempo de replicación en este caso depende de muchos factores, como la carga en la caché principal, el ancho de banda de red disponible y la latencia interregional. Hemos detectado que el tiempo de replicación para un par de replicación geográfica de 53 GB completa puede estar entre 5 y 10 minutos. Puede realizar un seguimiento de la cantidad de datos que aún no se han replicado mediante la métrica Geo Replication Data Sync Offset de Azure Monitor.

¿Se garantiza el punto de recuperación de replicación?

Para las cachés en un modo de replicación geográfica, la persistencia está deshabilitada. Si se ha desvinculado un par de replicación geográfica, como una conmutación por error iniciada por el cliente, la caché vinculada secundaria mantiene sus datos sincronizados hasta ese momento. En esas situaciones no se garantiza ningún punto de recuperación.

Para obtener un punto de recuperación, exporte desde cualquier caché. Más adelante, puede importar en la caché vinculada principal.

¿Puedo usar PowerShell o la CLI de Azure para administrar la replicación geográfica?

Sí, se puede administrar la replicación geográfica mediante Azure Portal, PowerShell o la CLI de Azure. Para obtener más información, consulte los documentos de PowerShell o los documentos de la CLI de Azure.

¿Cuánto cuesta replicar datos entre regiones de Azure?

Cuando se usa la replicación geográfica, los datos de la caché vinculada principal se replican a la caché vinculada secundaria. Si las dos cachés vinculadas están en la misma región, no hay ningún cargo por la transferencia de datos. Si las dos cachés vinculadas se encuentran en regiones diferentes, el cargo por transferencia de datos es el coste de salida de red de los datos que se transfieren entre cualquier región. Para más información, consulte Detalles de precios de ancho de banda.

¿Por qué no se pudo realizar la operación al intentar eliminar la memoria caché vinculada?

Las cachés con replicación geográfica y sus grupos de recursos no se pueden eliminar si están vinculados hasta que quite el vínculo de replicación geográfica. Si intenta eliminar el grupo de recursos que contiene una o las dos cachés vinculadas, se eliminan los otros recursos del grupo de recursos, pero el grupo de recursos permanece en el estado deleting y las cachés en el grupo de recursos permanecen en el estado running. Para completar la eliminación del grupo de recursos y las cachés vinculadas dentro de él, desvincule las cachés como se describe en Quitar un vínculo de replicación geográfica.

¿Qué región se debe usar para la caché vinculada secundaria?

En general, se recomienda que la caché esté en la misma región de Azure que la aplicación que accede a ella. Si las aplicaciones tienen regiones principales y de reserva, se recomiendan que las cachés principal y secundaria estén en esas mismas regiones. Para más información sobre regiones emparejadas, consulte el artículo sobre procedimientos recomendados: regiones emparejadas de Azure.

¿Puedo configurar un firewall con la replicación geográfica?

Sí, puede configurar un firewall con la replicación geográfica. Para que la replicación geográfica funcione junto con un firewall, asegúrese de que la dirección IP de la caché secundaria está agregada a las reglas de firewall de la caché principal. Sin embargo, si el acceso a la red pública está deshabilitado en la memoria caché y solo está habilitado el punto de conexión privado, no se admite el uso del firewall en la memoria caché.

Pasos siguientes

Más información sobre las características de Azure Cache for Redis.