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.
En este artículo se explica por qué y cómo migrar de Azure Cache for Redis (incluidos los niveles Básico, Estándar, Premium y Enterprise) a Azure Managed Redis.
Obtendrá información sobre:
- Las ventajas de elegir Azure Managed Redis frente a niveles anteriores.
- Diferencias clave de características entre los servicios.
- Estrategias para migrar los datos de caché.
- Formas de garantizar un proceso de migración sin problemas.
- Instrucciones sobre cómo seleccionar la SKU y el nivel de rendimiento de Azure Managed Redis adecuados para sus necesidades.
- Consideraciones y recomendaciones para actualizar las aplicaciones cliente.
Independientemente de si usa los niveles Básico, Estándar, Premium oEnterprise o OSS, esta guía le ayuda a planear y ejecutar la migración a Azure Managed Redis.
El documento se divide en dos secciones. Una es acerca de las instancias empresariales. El otro es sobre los niveles Básico, Estándar y Premium de Azure Cache for Redis.
- Ventajas de pasar de Enterprise a Azure Managed Redis
- Ventajas de la migración de cachés básicas, estándar o premium a Azure Managed Redis
Ventajas de pasar de Enterprise a Azure Managed Redis
Azure Managed Redis se basa en el software avanzado de Redis Enterprise. Azure Managed Redis es una oferta de primera entidad de Azure, lo que significa que no hay ningún componente de Azure Marketplace implicado y los usuarios no tienen que realizar transacciones con Marketplace por separado. Aprovisiona, administra y paga por Azure Managed Redis como cualquier otro servicio o producto nativo de Azure.
Azure Managed Redis no necesita el nodo de cuórum que conduce a recursos infrautilizados y limita las regiones o nubes donde se puede ofrecer Azure Cache for Redis Enterprise. Azure Managed Redis ya está disponible en la mayoría de las regiones de Azure y se planea soporte en otras nubes soberanas. Para obtener más información sobre el nodo de cuórum, consulte Niveles Enterprise y Enterprise Flash. Al quitar el nodo de cuórum sin usar, se obtiene una mayor rentabilidad porque todos los nodos se pueden usar como nodos de datos.
Azure Managed Redis tiene redundancia de zona por defecto.
Puede usar Azure Managed Redis sin alta disponibilidad (HA) para los entornos de desarrollo y prueba. El uso de entornos no productivos sin alta disponibilidad reduce a la mitad el costo de su instancia.
La estructura de SKU para Azure Managed Redis se basa en las necesidades de memoria y rendimiento. En lugar de administrar factores de escala o capacidad como con Azure Cache for Redis Enterprise, puede seleccionar entre tres niveles de rendimiento en Azure Managed Redis. Para obtener más información, consulte Elección del nivel correcto.
Por último, Azure Managed Redis ofrece la autenticación de Microsoft Entra ID al crear una caché para mejorar la postura de seguridad de la carga de trabajo.
Comparación de características
| Característica | Cache de Azure para Redis Enterprise | Azure Managed Redis |
|---|---|---|
| Versión de Redis | 7.2 | 7.4 |
| Directiva de agrupación en clústeres | OSS, Empresarial | OSS (Software de Código Abierto), Empresarial, No agrupado |
| Geo-replication | Active | Active |
| Acuerdo de nivel de servicio | Hasta 99,999% | Hasta 99,999% |
| Redundancia de zona | Yes | *Sí con alta disponibilidad |
| Modo no HA | No | Sí (para desarrollo/pruebas) |
| Persistencia de los datos | Sí (en versión preliminar) | Yes |
| Scaling | Yes | Yes |
| Compatibilidad con la versión de TLS | 1.2,1.3 | 1.2,1.3 |
| Autenticación de Microsoft Entra ID | No | Yes |
| Compatibilidad con regiones de Azure | Limitado | Extenso |
| Compatibilidad con la nube soberana de Azure | No | Sí (próximamente) |
| Sufijo DNS del nombre de host | <name>.<region>.redisenterprise.cache.azure.net |
<name>.<region>.redis.azure.net |
* Cuando alta disponibilidad está habilitada, Azure Managed Redis es redundante por zonas en regiones con varias zonas de disponibilidad.
Consideraciones al pasar de Enterprise a Azure Managed Redis
Azure Managed Redis usa la misma pila de software que Azure Cache for Redis Enterprise, por lo que las aplicaciones existentes que usan el nivel Enterprise no necesitan muchos cambios. La excepción significativa es la necesidad de cambiar las credenciales de conexión.
Nombre de host y sufijo diferentes
Aunque el software principal de Azure Cache for Redis Enterprise y Azure Managed Redis es similar, el sufijo DNS del nombre de host del clúster de Redis es diferente. Al pasar a Azure Managed Redis, la aplicación debe cambiar el nombre de host del clúster de Redis. Si usa claves de acceso para conectarse a la memoria caché, también debe actualizar la clave de acceso que usa para conectarse a la memoria caché.
Importante
Considere la posibilidad de actualizar el código que se conecta a la memoria caché. En lugar de usar claves de acceso, use Microsoft Entra ID. Se recomienda usar microsoft Entra ID en lugar de claves de acceso.
Elección del tamaño adecuado y de la SKU adecuada de Azure Managed Redis.
Azure Managed Redis ofrece muchos tamaños de memoria y tres niveles de rendimiento. Puede leer más información sobre los tamaños de memoria y los niveles de rendimiento aquí Elegir el nivel correcto.
Identificación del tamaño de memoria de la instancia existente de Azure Cache for Redis Enterprise
Las instancias de Azure Cache for Redis Enterprise se pueden escalar horizontalmente para proporcionar más memoria y más recursos de proceso, por lo que es importante tener en cuenta el factor de escalabilidad horizontal de la memoria caché. El escalado horizontal también está relacionado con la capacidad, que es esencialmente el número de máquinas virtuales que se ejecutan en el clúster.
Para elegir el tamaño correcto de memoria de Azure Managed Redis:
- Vaya a Azure Portal y seleccione Información general en el menú de recursos.
- Compruebe el campo Estado en la información general de la instancia de Enterprise. El campo Estado muestra el tamaño de memoria de la instancia de Redis Enterprise.
Echemos un vistazo a un escenario posible.
Si examina el estado en el panel Información general , verá Running - Enterprise 8GB (2 x 4GB). Esta notación significa que la memoria caché usa actualmente una SKU de E5 Enterprise con una escala de 2, lo que produce una caché de 8 GB. Por lo tanto, debe empezar con al menos 10 GB de caché en Azure Managed Redis.
En este caso, use cualquiera de los niveles que ofrecen 12 GB de memoria.
| SKU | Nivel |
|---|---|
| M10 | Memory Optimized |
| B10 | Balanced |
| X10 | Compute Optimized |
Identificación del nivel de rendimiento
También debe tener en cuenta si la carga de trabajo es intensiva en uso de memoria o intensiva en computación. Si es más probable que la instancia empresarial actual se quede sin memoria antes de que la CPU, entonces su carga de trabajo es intensiva en memoria. Considere la posibilidad de elegir entre el nivel de rendimiento optimizado para memoria .
Si su carga de trabajo es intensiva en rendimiento o tiene demasiada latencia, entonces su carga de trabajo es intensiva en cómputo. Considere elegir el nivel de rendimiento optimizado para cómputo.
Si no está seguro, puede empezar con el nivel de rendimiento Equilibrado porque ofrece una combinación correcta de memoria y rendimiento.
Si actualmente usa el nivel Flash enterprise de Redis, debe elegir el nivel Optimizado para Flash.
Creación de una nueva instancia de Azure Managed Redis
Después de elegir el nivel de memoria y rendimiento de la nueva instancia de Azure Managed Redis, puede crear la nueva instancia de Azure Managed Redis. Para más información sobre cómo crear una memoria caché, consulte Inicio rápido: Creación de una instancia de Azure Managed Redis.
A continuación, debe elegir una estrategia para mover los datos. Por último, debe actualizar la aplicación para usar la nueva caché.
Actualización de la aplicación para conectarse a la instancia de Azure Managed Redis
Una vez creada una nueva instancia de Azure Managed Redis, debe cambiar el punto de conexión o el nombre de host de Redis y la clave de acceso de la aplicación para que apunte a la nueva instancia de Azure Managed Redis. Se recomienda publicar este cambio de punto de conexión fuera del horario comercial, ya que provoca una breve interrupción en la conectividad.
Note
Si se conecta a la instancia de Redis Enterprise existente a través de un punto de conexión privado, asegúrese de que la nueva instancia de Azure Managed Redis Cache también esté emparejada con la red virtual de su aplicación. La nueva caché debe tener una configuración similar a la existente de Redis Enterprise.
Compruebe que la aplicación se está ejecutando según lo previsto y elimine la instancia anterior de Redis Enterprise.
Mover sus datos desde su caché empresarial a una nueva instancia de Azure Managed Redis Cache
Al migrar a la instancia de Azure Managed Redis, debe tener en cuenta la mejor manera de mover los datos de la instancia de Redis Enterprise existente a la nueva instancia de Azure Managed Redis. Si la aplicación puede tolerar la pérdida de datos o tiene otros mecanismos para rehidratar la memoria caché sin efectos negativos, omita este paso y continúe con los pasos siguientes.
Si la aplicación necesita asegurarse de que los datos también se migran a la nueva instancia de Azure Managed Redis, elija una de las siguientes opciones:
Exportación e importación de datos mediante un archivo RDB
- Ventajas: conserva la instantánea de datos.
- Desventajas: riesgo de pérdida de información si las escrituras se realizan después de las copias de seguridad instantáneas.
Este es el procedimiento básico de exportación e importación:
- Exporte RDB desde la caché de Redis Enterprise existente a la cuenta de Azure Storage.
- Importe datos de la cuenta de Azure Storage en una nueva instancia de Azure Managed Redis Cache.
- Obtenga más información sobre la exportación o importación de datos aquí Importación y exportación de datos en Azure Managed Redis.
Estrategia de "Dual-Write"
- Ventajas: tiempo de inactividad cero, transición segura.
- Desventajas: requiere una configuración temporal de caché doble.
Este es el procedimiento básico de escritura doble:
- Modifique su aplicación para escribir tanto en la caché existente de Azure Cache for Redis Enterprise como en la nueva caché administrada de Azure Managed Redis.
- Continúe leyendo y escribiendo desde la caché de Redis Enterprise.
- Después de una sincronización de datos adecuada, redireccione las lecturas hacia Redis Gestionado de Azure y elimine la instancia de Redis Enterprise.
Migración mediante programación mediante RIOT-X
RIOT-X proporciona una manera de migrar el contenido de Enterprise a Azure Managed Redis. Para más información, consulte Migración de datos con RIOT-X para Azure Managed Redis.
- Ventajas: Control total, personalizable.
- Desventajas: requiere un esfuerzo de desarrollo.
Ventajas de la migración de cachés básicas, estándar o premium a Azure Managed Redis
Si utiliza cualquiera de las SKU de OSS, Básica, Estándar o Premium, la transición a Azure Managed Redis le ofrece más características en cada nivel de caché.
Esta es una tabla que compara las características de Azure Cache for Redis con las características de Azure Managed Redis.
| Descripción de la característica | Basic OSS |
Standard OSS |
Premium OSS |
Balanced AMR |
Memory Optimized AMR |
Compute Optimized AMR |
|---|---|---|---|---|---|---|
| Availability | N/A | 99.9% | 99.9% | Hasta 99,999% | Hasta 99,999% | Hasta 99,999% |
| Cifrado de datos en tránsito | Yes | Yes | Yes | Yes | Yes | Yes |
| Aislamiento de red | Yes | Yes | Yes | Yes | Yes | Yes |
| Escalado vertical o horizontal | Yes | Yes | Yes | Yes | Yes | Yes |
| Reducción vertical u horizontal | Yes | Yes | Yes | No | No | No |
| Agrupación en clústeres de OSS | No | No | Yes | Yes | Yes | Yes |
| Persistencia de los datos | No | No | Yes | Yes | Yes | Yes |
| Redundancia de zona | No | Sí (versión preliminar) | Yes | *Sí con alta disponibilidad | *Sí con alta disponibilidad | *Sí con alta disponibilidad |
| Geo-replication | No | No | Sí (pasivo) | Sí (activo) | Sí (activo) | Sí (activo) |
| Registros de auditoría de conexión | No | No | Yes | Yes(Event-based) | Yes(Event-based) | Yes(Event-based) |
| Módulos de Redis | No | No | No | Yes | Yes | Yes |
| Import/Export | No | No | Yes | Yes | Yes | Yes |
| Reboot | Yes | Yes | Yes | No | No | No |
| Actualizaciones programadas | Yes | Yes | Yes | No | No | No |
| Autenticación de Microsoft Entra ID | Yes | Yes | Yes | Yes | Yes | Yes |
| RBAC de Microsoft Entra ID | Yes | Yes | Yes | No | No | No |
| Notificación de keyspace | Yes | Yes | Yes | No | No | No |
| Sin alta disponibilidad | N/A | No | No | Yes | Yes | Yes |
OSS hace referencia a Azure Cache for Redis
AMR hace referencia a Azure Managed Redis
* Cuando alta disponibilidad está habilitada, Azure Managed Redis es redundante por zonas en regiones con varias zonas de disponibilidad.
Estas son algunas otras diferencias que se deben tener en cuenta al implementar Azure Managed Redis. Tenga en cuenta estos cambios en la aplicación cliente:
| Descripción de la característica | Caché de Azure para Redis | Azure Managed Redis |
|---|---|---|
| Sufijo DNS (solo para la nube de PROD) | .redis.cache.windows.net |
<region>.redis.azure.net |
| Puerto TLS | 6380 | 10000 |
| Puerto que no es TLS | 6379 | No está soportado |
| Puertos TLS de nodo individuales | 13XXX | 85xx |
| Puerto no TLS de nodo individual | 15XXX | No está soportado |
| Compatibilidad con la agrupación en clústeres | Modo de agrupación en clústeres de OSS | Modos de clúster de OSS y Enterprise |
| Comandos no admitidos | Comandos no admitidos | Comandos de varias claves |
| Disponibilidad regional | Todas las regiones de Azure | * Vea la lista de regiones después de esta sección. |
| Versión de Redis | 6 | 7.4 |
| Versiones de TLS admitidas | 1.2 y 1.3 | 1.2 y 1.3 |
Migración de la caché Básica, Estándar o Premium a Azure Managed Redis
En función de la tabla, estas son algunas asignaciones entre las SKU de Azure Cache for Redis y las opciones de las cachés en Azure Managed Redis.
Note
Uso de la opción de alta disponibilidad de Azure Managed Redis para migrar SKU básicas
| Caché de Azure para Redis | Azure Managed Redis | Memoria adicional (%) |
|---|---|---|
| Básico, Estándar: C0 | Equilibrado: B0 | 50 |
| Básico, Estándar: C1 | Equilibrado: B1 | 0 |
| Básico, Estándar: C2 | Equilibrado: B3 | 17 |
| Básico/Estándar: C3 | Equilibrado: B5 | 0 |
| Básico/Estándar: C4 | Optimizado para memoria: M10* | -8 |
| Básico/Estándar: C4 | Optimizado para memoria: M20** | 46 |
| Básico/Estándar: C5 | Optimizado para memoria: M20* | -8 |
| Básico/Estándar: C5 | Optimizado para memoria: M50** | 57 |
| Básico/Estándar: C6 | Optimizado para memoria: M50 | 12 |
| Premium: P1 | Equilibrado: B5 | 0 |
| Premium: P2 | Equilibrado: B10* | -8 |
| Premium: P2 | Equilibrado: B20** | 46 |
| Premium: P3 | Equilibrado: B20* | -8 |
| Premium: P3 | Equilibrado: B50** | 57 |
| Premium: P4 | Equilibrado: B50 | 12 |
| Premium: P5 | Equilibrado: B100 | 0 |
- * Esta opción es para la rentabilidad. Asegúrese de que el pico de memoria total usada en el último mes sea menor que la memoria sugerida de Azure Managed Redis para elegir esta opción.
- ** Esta opción es para un consumo abundante de memoria.
Azure Cache for Redis Premium en clúster
- Para el clúster particionado, elija un nivel optimizado para memoria que tenga memoria total equivalente.
- Para los clústeres con más de una réplica de lectura, elija un nivel Optimizado para proceso con memoria total equivalente como réplica principal.
Opciones de migración
Las aplicaciones cliente deben poder usar una instancia de Azure Managed Redis que tenga diferentes modos de agrupación en clústeres y puntos de conexión. Azure Cache for Redis y Azure Managed Redis son compatibles, por lo que no se requieren cambios de código de aplicación distintos de las configuraciones de conexión para la mayoría de los escenarios.
Más información en:
Opciones para migrar Azure Cache for Redis a Azure Managed Redis
| Option | Advantages | Disadvantages |
|---|---|---|
| Crear una nueva caché | La más sencilla de implementar. | Es necesario volver a rellenar los datos en la nueva caché, lo que puede no funcionar con varias aplicaciones. |
| Exportar e importar datos mediante un archivo RDB | Es compatible con cualquier caché en Redis en general. | Algunos datos pueden perderse si se escriben en la caché existente después de generar el archivo RDB. |
| Doble escritura de datos en dos cachés | Sin pérdida de datos ni tiempo de inactividad. No se interrumpen las operaciones de la caché existente. Pruebas más sencillas de la nueva caché. | Necesita dos cachés durante un período de tiempo prolongado. |
| Migración de datos mediante programación | Control total sobre cómo se mueven los datos. | Requiere código personalizado. |
Creación de una instancia de Azure Managed Redis
Técnicamente, esta estrategia no es una migración. Si la pérdida de datos no es un problema, la manera más fácil de pasar al nivel Azure Managed Redis es crear una nueva instancia de caché y conectar la aplicación a ella. Por ejemplo, si usa Redis como una caché de búsqueda de registros de base de datos, puede volver a generar fácilmente la memoria caché desde cero. Los pasos generales para implementar esta opción son los siguientes:
- Cree una nueva instancia de Azure Managed Redis.
- Actualice la aplicación para que use la nueva instancia.
- Elimine la instancia anterior de Azure Cache for Redis.
Exportación de datos a un archivo RDB e importación a Azure Managed Redis
Esta opción solo se aplica a las memorias caché de nivel Premium. La instancia de Redis de código abierto define un mecanismo estándar para tomar una instantánea del conjunto de datos en memoria de la caché y guardarla en un archivo. Otra caché de Redis puede leer el archivo RDB que se exportó. El nivel Premium de Azure Cache for Redis admite la exportación de datos de una instancia de caché mediante archivos RDB. Puede usar un archivo RDB para transferir datos de una instancia de Azure Cache for Redis existente a una instancia de Azure Managed Redis.
Los pasos generales para implementar esta opción son los siguientes:
- Cree una nueva instancia de Azure Managed Redis con el mismo tamaño (o mayor que) la instancia de Azure Cache for Redis existente.
- Exporta el archivo RDB desde la instancia de Azure Cache para Redis existente mediante estas instrucciones de exportación o el cmdlet de exportación de PowerShell
- Importación del archivo RDB en una nueva instancia de Azure Managed Redis mediante estas instrucciones de importación o el cmdlet de importación de PowerShell
- Actualice la aplicación para usar la nueva cadena de conexión de instancia de Azure Managed Redis.
Escritura en dos cachés en Redis simultáneamente durante el período de migración
En lugar de mover los datos directamente entre cachés, puede usar su aplicación para escribir datos en una caché existente y en una nueva que esté configurando. La aplicación sigue leyendo datos de la memoria caché existente inicialmente. Cuando la nueva caché tenga los datos necesarios, la aplicación pasará a esa caché y se retirará la anterior. Supongamos, por ejemplo, que usa Redis como almacén de sesión y las sesiones de la aplicación son válidas durante siete días. Después de escribir en las dos cachés durante una semana, estará seguro de que la nueva caché contiene toda la información de sesión que no ha expirado. Podrá confiar en ella con total seguridad a partir de ese momento sin preocuparse por la pérdida de datos.
Los pasos generales para implementar esta opción son los siguientes:
- Cree una nueva instancia de Azure Managed Redis con el mismo tamaño (o mayor que) la instancia de Azure Cache for Redis existente.
- Modifique el código de la aplicación para que escriba tanto en la instancia nueva como en la original.
- Siga leyendo los datos de la instancia original hasta que la instancia nueva se haya rellenado con suficientes datos.
- Actualice el código de la aplicación para que lea y escriba únicamente desde la nueva instancia.
- Elimine la instancia original.
Migración mediante programación
Cree un proceso de migración personalizado leyendo mediante programación los datos de una instancia de Azure Cache for Redis existente y escribiéndolos en la instancia de Azure Managed Redis. Hay dos herramientas de código abierto que puede probar:
-
Redis-copy
- Esta herramienta de código abierto se puede usar para copiar datos de una instancia de Azure Cache for Redis a otra. Esta herramienta resulta útil para mover datos entre instancias de caché en diferentes regiones de Azure Cache. También está disponible la versión compilada. También puede usar el código fuente como una guía útil para escribir su propia herramienta de migración.
-
RIOT
- RIOT es otra herramienta de migración popular probada por la comunidad de Redis. Es una utilidad de línea de comandos diseñada para ayudarle a obtener datos dentro y fuera de Redis.
Note
Oficialmente, Microsoft no admite esta herramienta.
Los pasos generales para implementar esta opción son los siguientes:
- Cree una máquina virtual en la región en la que se encuentra la caché existente. Si el conjunto de datos es de gran tamaño, elija una máquina virtual relativamente eficaz para reducir el tiempo de copia.
- Cree una nueva instancia de Azure Managed Redis.
- Vacíe los datos de la nueva caché para asegurarse de que está vacía. Eso es necesario porque la herramienta de copia no sobrescribe ninguna de las claves existentes en la caché de destino. Importante: No vacíe la memoria caché de origen.
- Use una aplicación como la herramienta de código abierto mencionada anteriormente para automatizar la copia de los datos desde la caché de origen a la de destino. No olvide que el proceso de copia puede tardar varios minutos en completarse, según el tamaño del conjunto de datos.
Disponibilidad regional para Azure Managed Redis
Azure Managed Redis se expande continuamente a nuevas regiones. Para ver la disponibilidad en su región consulte Productos disponibles por región.