Conozca las respuestas a preguntas comunes, patrones y procedimientos recomendados para Azure Cache for Redis.
Cambio de licencias de Redis
¿Cuáles son los cambios realizados en las licencias de Redis?
El proyecto de código abierto de Redis ha cambiado a un modelo de licencia dual con compatibilidad con la versión 2 (RSALv2) o la licencia pública del lado servidor 1 (SSPLv1). Consulte la versión de prensa de Redis para obtener más información. Consulte también la entrada de Blog de Microsoft en el cambio de licencias de Redis.
¿Azure Cache for Redis ahora también está cubierto por las licencias RSALv2 y SSPLv1?
No, Azure Cache for Redis se ofrece a los clientes en virtud de los términos de servicio de Microsoft. Las licencias RSALv2 y SSPLv1 no se aplican al uso de Azure Cache for Redis.
¿Mi instancia de Azure Cache for Redis seguirá recibiendo revisiones y correcciones de errores?
Sí, Azure Cache for Redis, Azure Cache for Redis Enterprise y Enterprise Flash seguirán recibiendo revisiones y correcciones de errores incluso después del anuncio de licencia.
¿Qué debo hacer como cliente de Azure Cache for Redis en respuesta a este anuncio de licencia?
No se requiere ninguna acción para nuestros clientes de Azure con respecto al anuncio de licencias.
Servicios desusados
¿Qué servicios Azure Cache for Redis han quedado en desuso?
Managed Cache Service: Managed Cache Service se retiró el 30 de noviembre de 2016.
In-Role Cache: In-Role Cache se retiró el 30 de noviembre de 2016.
Memorias caché con una dependencia de Cloud Services (clásico)
¿Qué debo hacer con las instancias de Azure Cache for Redis que dependan de Cloud Services (clásico)?
Debe migrar todas las memorias caché con una dependencia de Cloud Services (clásico). En agosto de 2021, anunciamos que Cloud Services (clásico) se retirará el 31 de agosto de 2024. Las instancias de Azure Cache for Redis que dependen de Cloud Services (clásico) se deben retirar para la misma fecha.
Debe migrar las memorias caché con una dependencia de Cloud Services (clásico) antes del 31 de agosto de 2024.
¿Cuántas memorias caché se han visto afectadas?
Hemos hecho un esfuerzo por migrar tantas memorias caché como sea posible de forma transparente. Debido a esto, se ven afectadas algunas memorias caché y clientes.
¿Cómo puedo saber si una memoria caché se ve afectada?
Consulte Recomendaciones de Azure Advisor. Si la caché se ve afectada, verá una recomendación en la suscripción.
¿Cómo migrar cachés de Cloud Services (clásico) a Microsoft Azure Virtual Machine Scale Sets?
Hemos migrado la mayoría de las cachés de su creación en Cloud Services (clásica) a su creación en Microsoft Azure Virtual Machine Scale Sets. La migración a Microsoft Azure Virtual Machine Scale Sets quita la dependencia. Hay tres maneras de iniciar este proceso para las memorias caché de una red virtual:
Migrar a una nueva memoria caché mediante vínculos privados.
Cree una nueva memoria caché que use Private Link para el aislamiento de red en lugar de la inserción de red virtual y migre los datos a esta memoria caché. Esta opción proporciona la mejor y más segura experiencia de aislamiento de red, al mismo tiempo que garantiza que todas las nuevas memorias caché se creen con la infraestructura actualizada.
Migrar a una nueva memoria caché en una nueva subred de red virtual de Azure Resource Manager.
La creación de una caché dentro de una red virtual clásica crea una caché Cloud Services (clásica) y no una caché de Azure Virtual Machine Scale Sets. La migración a una caché nueva en una subred nueva de red virtual de Azure Resource Manager corrige la dependencia subyacente de Cloud Services manteniendo una experiencia de red virtual similar.
Hemos migrado la mayoría de las cachés de su creación en Cloud Services (clásica) a su creación en Microsoft Azure Virtual Machine Scale Sets. Para la migración, elimine la memoria caché existente y cree una nueva memoria caché en una nueva subred de red virtual de Azure Resource Manager. Se recomienda encarecidamente no usar subredes antiguas durante la migración de cachés. Para ver las opciones recomendadas para migrar los datos de la memoria caché, consulte Migración a Azure Cache for Redis.
Migración automática con pérdida de datos (recomendado).
Podemos migrar las memorias caché para dejar de usar Cloud Services (clásico) y pasar a usar Virtual Machine Scale Sets automáticamente, con la configuración de caché (incluyendo la claves de acceso y nombre de host) conservada. Sin embargo, este método requiere aproximadamente 30 minutos de tiempo de inactividad y la pérdida completa de datos en la memoria caché. Puede usar la característica importación y exportación para guardar una copia de los datos antes de la migración.
Para usar esta opción, póngase en contacto con azurecachemigration@microsoft.com o cree una solicitud de soporte técnico para solicitar una migración.
Mi memoria caché no usa la inserción de red virtual, pero he recibido un aviso de que tengo que migrarla. ¿Cuál debo hacer?
Compruebe si la memoria caché usa la replicación geográfica. Si es así, debe migrar los datos del par con replicación geográfica actual a un par con replicación geográfica nuevo.
Por ejemplo:
- Cree un nuevo par con replicación geográfica de memorias caché Premium que coincidan con la misma configuración que el par actual de memorias caché.
- Desvincule el par original de memorias caché con replicación geográfica y exporte un archivo RDB desde la memoria caché principal.
- Importe el archivo RDB en la memoria caché principal en el nuevo par con replicación geográfica.
El nuevo par de memorias caché con replicación geográfica no tendrá la misma dependencia en Cloud Services.
¿Qué debo hacer si no puedo crear una nueva instancia de caché con el mensaje de error "la subred se ve afectada por Cloud Services retirada"?
Estamos empezando a bloquear la creación de nuevas memorias caché mediante el modelo de implementación de Cloud Services (clásico). Todavía se pueden crear nuevas memorias caché con este modelo de implementación anterior si se crean en una subred de red virtual que una vez contenía una caché Cloud Services o si se implementa una caché en una red virtual clásica. Si ve este mensaje, cree una nueva subred en la red virtual en la que implementar la memoria caché. La creación de una subred en la red virtual garantiza que se cree una memoria caché sin la dependencia de Cloud Services.
Para comprobar si tiene una o varias memorias caché basadas en Cloud Services en la subred, puede comprobar Azure Advisor en el portal o usar la API REST resource-navigation-links.
Use la API de resource-navigation-links
con el identificador de suscripción, el nombre del grupo de recursos, el nombre de red virtual y el nombre de subred para obtener las memorias caché de esa subred que usen Cloud Services.
Si va a crear una nueva caché mediante la API de REST asegúrese también de que no pasa la configuración de redis de {"CacheVmType": "CloudService"}
junto con la solicitud de creación. Esos parámetros son un parámetro no documentado, por lo que es poco probable que lo haga.
Si necesita crear nuevas memorias caché con el modelo de implementación de Cloud Services (clásico), póngase en contacto con azurecachemigration@microsoft.com o cree una solicitud de soporte técnico para solicitar una exención.
¿Qué ocurre si las memorias caché no se actualizan o migran el 31 de agosto de 2024?
Estas memorias caché se apagarán y perderá los datos de las memorias caché.
¿Cuál es la escala de tiempo de soporte técnico?
La retirada se producirá en tres fases para que tenga la cantidad máxima de tiempo para la migración:
Fase activa (desde ahora hasta el 30 de abril de 2023)
Las memorias caché tienen compatibilidad completa, sin cambios en el estado actual. Este período se concede para permitir que los clientes dejen el servicio en la nube (clásico) con una interrupción mínima.
Fase de mantenimiento (del 1 de mayo de 2023 al 31 de diciembre de 2023)
Las memorias caché recibirán correcciones críticas de errores, estabilidad y seguridad, pero no características nuevas.
Fase inactiva (del 1 de enero de 2024 al 31 de agosto de 2024)
Las memorias caché solo reciben correcciones de seguridad críticas. Se solicitará a todos los clientes con problemas de soporte técnico migrar a una memoria caché basada en VMSS antes de recibir soporte técnico. Los clientes deben retirar sus memorias caché antes del 31 de agosto de 2024.
¿Esta escala de tiempo se aplica a las memorias caché que se ejecutan en Redis 4.0?
No. Esta escala de tiempo solo se aplica a las memorias caché que se ejecutan en Redis 6.0. Redis 4.0 forma parte de una retirada independiente que finaliza antes de la retirada de Cloud Services (clásico). Todas las cachés restantes que usan Redis 4.0 en Cloud Services (clásico) se migrarán automáticamente para usar Virtual Machine Scale Sets y Redis 6.0 después del 31 de octubre de 2023. Este método de migración requiere tiempo de inactividad y la pérdida de datos completa en la memoria caché, por lo que debe migrar antes de esta fecha si desea evitar el tiempo de inactividad o la pérdida de datos. Póngase en contacto con azurecachemigration@microsoft.com o cree una solicitud de soporte técnico para solicitar una actualización automática antes del 31 de octubre de 2023.
¿Dónde puedo obtener más información si tengo más preguntas sobre esta retirada?
Publique cualquiera de sus preguntas en la Página de Q&A para la retirada de Cloud Services (clásico). Además, puede enviar un correo electrónico a azurecachemigration@microsoft.com para obtener más información.
Preguntas generales
¿Qué ocurre si mi pregunta Azure Cache for Redis no se responde aquí?
Si su pregunta no aparece aquí, háganoslo saber para que podamos ayudarlo a encontrar una respuesta.
Para llegar a más público, puede publicar una pregunta en la página de preguntas y respuestas de Microsoft sobre Azure Cache e interactuar con el equipo de Azure Cache y otros miembros de la comunidad.
Si desea presentar una solicitud para una característica, puede enviar sus solicitudes e ideas al foro UserVoice sobre Azure Redis Cache.
También puede enviarnos su pregunta a la dirección de correo azurecache@microsoft.com.