Compartir a través de

Escalado de una instancia de Azure Cache for Redis

  • Artículo

Azure Cache for Redis tiene diferentes ofertas de nivel que proporcionan flexibilidad en la elección del tamaño y las características de la caché. Mediante el escalado, puede cambiar el tamaño, el nivel y el número de nodos después de crear una instancia de caché para que coincida con las necesidades de la aplicación. En este artículo se muestra cómo escalar la caché en Azure Portal y herramientas tales como Azure PowerShell y la CLI de Azure.

Tipos de escalado

Básicamente, hay dos maneras de escalar una instancia de Azure Cache for Redis:

  • El escalado vertical aumenta el tamaño de la máquina virtual (VM) que ejecuta el servidor Redis, agregando más memoria, CPU virtuales (vCPU) y ancho de banda de red. El escalado vertical también se denomina escalar verticalmente. Lo contrario a escalar verticalmente es reducir verticalmente.

  • Escalar horizontalmente divide la instancia de caché en más nodos del mismo tamaño, lo que aumenta la memoria, las vCPU y el ancho de banda de red mediante la paralelización. El escalado horizontal también se conoce como escalar horizontalmente o particionamiento. Lo contrario a escalar horizontalmente es reducir horizontalmente. En la comunidad Redis, el escalado horizontal se denomina con frecuencia agrupación en clústeres.

Ámbito de disponibilidad

Nivel Básico y Estándar Premium Enterprise y Enterprise Flash
Escala vertical Sí Sí Sí
Reducción vertical Sí Sí No
Escalabilidad horizontal No Sí Sí
Reducir horizontalmente No Sí No

Cuándo se debe escalar

Puede utilizar las características de supervisión de Azure Cache for Redis para supervisar el estado y el rendimiento de la memoria caché. Use esa información para determinar cuándo escalar la caché.

Puede supervisar las métricas siguientes para determinar si necesita escalar.

  • Carga de servidor de Redis
    • Una carga elevada del servidor Redis significa que el servidor no puede seguir el ritmo de las solicitudes de todos los clientes. Dado que un servidor Redis es un proceso de subprocesamiento único, normalmente resulta más útil escalar horizontalmente en lugar de escalar verticalmente. El escalado horizontal mediante la habilitación de la agrupación en clústeres permite distribuir las funciones de sobrecarga entre varios procesos de Redis. El escalado horizontal también ayuda a distribuir el cifrado/descifrado TLS y la conexión/desconexión, lo que acelera las instancias de caché mediante TLS.
    • El escalado vertical todavía puede resultar útil para reducir la carga del servidor, ya que las tareas en segundo plano pueden aprovechar más vCPU y liberar el subproceso para el proceso principal del servidor Redis.
    • Los niveles Enterprise y Enterprise Flash usan Redis Enterprise en lugar de Redis en código abierto. Una de las ventajas de estos niveles es que el proceso del servidor Redis puede aprovechar varias vCPU. Con varias vCPU, el escalado vertical y el horizontal en estos niveles pueden resultar útiles para reducir la carga del servidor. Para obtener más información, vea Procedimientos recomendados para los niveles Enterprise y Enterprise Flash de Azure Cache for Redis.
  • Uso de memoria
    • Un uso elevado de memoria indica que el tamaño de los datos es demasiado grande para el tamaño de caché actual. Considere la posibilidad de escalar a un tamaño de caché con más memoria. El escalado vertical o el escalado horizontal son efectivos aquí.
  • Conexiones de cliente
    • Cada tamaño de caché tiene un límite en el número de conexiones de cliente que puede admitir. Si las conexiones de cliente están cerca del límite del tamaño de caché, considere la posibilidad de escalar verticalmente a un nivel mayor. El escalado horizontal no aumenta el número de conexiones de cliente admitidas.
    • Para obtener más información sobre los límites de conexión por tamaño de caché, vea Precios de Azure Cache for Redis.
  • Ancho de banda de red
    • Si el servidor de Redis supera el ancho de banda disponible, las solicitudes de los clientes podrían agotar el tiempo de espera debido a la incapacidad del servidor para insertar datos en el cliente lo suficientemente rápido. Consulta las métricas de "Lectura de caché" y "Escritura de caché" para ver el ancho de banda del lado servidor que se está usando. Si su servidor Redis está excediendo el ancho de banda de red disponible, debería considerar escalar horizontalmente o verticalmente a un tamaño de caché mayor con más ancho de banda de red.
    • En el caso de las cachés de nivel Enterprise que usan la directiva de clúster Enterprise, el escalado horizontal no aumenta el ancho de banda de red.
    • Para obtener más información sobre el ancho de banda de red disponible por tamaño de caché, consulte Preguntas frecuentes sobre Azure Cache for Redis.
  • Exámenes internos de Defender
    • En las caché EstándarC0 y C1, mientras que el examen interno de Defender se ejecuta en las máquinas virtuales, es posible que veas picos cortos en la carga del servidor que no han causado un aumento en las solicitudes de caché. Verás una mayor latencia para las solicitudes mientras se ejecutan exámenes internos de Defender en estos niveles un par de veces al día. La caché en los niveles C0 y C1 solo tienen un único núcleo a varias tareas, lo que divide el trabajo de atender solicitudes internas de análisis de Defender y Redis. Puedes reducir el efecto escalando a una oferta de nivel superior con varios núcleos de CPU, como C2.
    • El aumento del tamaño de la caché en los niveles superiores ayuda a abordar cualquier problema de latencia. Además, en el nivel de C2, tienes compatibilidad con hasta 2000 conexiones de clientes.

Para obtener más información sobre cómo determinar el plan de tarifa de caché que se va a usar, consulte Elección del nivel correcto y Preguntas frecuentes sobre Azure Cache for Redis.

Nota:

Para obtener más información sobre cómo optimizar el proceso de escalado, consulte la guía de procedimientos recomendados para el escalado

Prerrequisitos/limitaciones del escalado de Azure Cache for Redis

Puede escalar/reducir verticalmente a un plan de tarifa diferente con las siguientes restricciones:

  • No se puede escalar desde un plan de tarifa superior a un plan de tarifa inferior.
    • No se puede reducir verticalmente desde una caché Enterprise o Enterprise Flash a ningún otro nivel.
    • No puede cambiar de una memoria caché Premium a una memoria caché Estándar o Básica.
    • No puede cambiar de una memoria caché Estándar a una memoria caché Básica.
  • Puede cambiar de una memoria caché Básica a una memoria caché Estándar, pero no puede cambiar el tamaño al mismo tiempo. Si necesita un tamaño distinto, después puede realizar una operación de escalado hasta el tamaño deseado.
  • No puede escalar de una memoria caché Básica directamente a una memoria caché Premium. En primer lugar, escale desde Básica a Estándar en una operación de escalado y, después, desde Estándar a Prémium en la siguiente operación de escalado.
  • No se puede escalar de un tamaño mayor al tamaño C0 (250 MB). Sin embargo, puede escalar a cualquier otro tamaño dentro del mismo plan de tarifa. Por ejemplo, puede escalar de C5 Estándar a C1 Estándar.
  • No se puede escalar verticalmente desde una caché Premium, Estándar o Básica a una caché Enterprise o Enterprise Flash.
  • No se puede escalar entre Enterprise y Enterprise Flash.

Puede escalar horizontalmente/ verticalmente con las siguientes restricciones:

  • El escalado horizontal solo se admite en los niveles Premium, Enterprise y Enterprise Flash.
  • La reducción horizontal solo se admite en el nivel Premium.
  • En el nivel Premium, primero debe habilitarse la agrupación en clústeres antes de escalar o reducir horizontalmente.
  • En el nivel Premium, la compatibilidad con el escalado horizontal hasta 10 particiones está disponible con carácter general. La compatibilidad con hasta 30 particiones está en versión preliminar. (Para las memorias caché con dos réplicas, el límite de particiones es 20. Con tres réplicas, el límite de particiones es 15.)
  • Solo los niveles Enterprise y Enterprise Flash pueden escalar vertical y horizontalmente de manera simultánea.

Cómo escalar: niveles Básico, Estándar y Premium

Escalado y reducción vertical mediante Azure Portal

  1. Para escalar la caché, vaya a la caché en Azure Portal y seleccione Escalar en el menú Recursos.

    Captura de pantalla que muestra Escalar en el menú de recursos.

  2. Elija un plan de tarifa en el panel de trabajo y, a continuación, elija Seleccionar.

    Captura de pantalla que muestra los niveles de Azure Cache for Redis.

  3. Durante la operación de escalado de la memoria caché al nuevo plan de tarifa, se muestra la notificación Escalando Redis Cache.

    Captura de pantalla que muestra la notificación de escalado.

  4. Cuando se completa el escalado, el estado cambia de Escalado a En ejecución.

Nota:

Al escalar o reducir verticalmente una caché en el portal, las configuraciones maxmemory-reserved y maxfragmentationmemory-reserved se reducen horizontalmente de manera automática en proporción con el tamaño de la caché. Por ejemplo, si maxmemory-reserved se establece en 3 GB en una caché de 6 GB y se escala a una caché de 12 GB, la configuración se actualiza automáticamente a 6 GB durante el escalado. Al reducir verticalmente, ocurre lo contrario.

Escalado y reducción vertical mediante PowerShell

Las instancias de Azure Cache for Redis se pueden escalar con PowerShell con el cmdlet Set-AzRedisCache cuando se modifican las propiedades Sizeo Sku. En el ejemplo siguiente se muestra cómo escalar una caché denominada myCache a una caché de 6 GB en el mismo nivel.

   Set-AzRedisCache -ResourceGroupName myGroup -Name myCache -Size 6GB

Para obtener más información sobre cómo escalar con PowerShell, consulte Escalado de una instancia de Azure Cache for Redis con PowerShell.

Escalado y reducción vertical mediante la CLI de Azure

Para escalar las instancias de Azure Cache for Redis mediante la CLI de Azure, llame al comando az redis update. Use la propiedad sku.capcity para escalar dentro de un nivel, por ejemplo de una caché Estándar C0 a Estándar C1:

az redis update --cluster-name myCache --resource-group myGroup --set "sku.capacity"="2"

Utilice las propiedades "sku.name" y "sku.family" para escalar verticalmente a un nivel diferente, por ejemplo, de una caché Estándar C1 a una caché Premium P1:

az redis update --cluster-name myCache --resource-group myGroup --set "sku.name"="Premium" "sku.capacity"="1" "sku.family"="P"

Para obtener más información sobre el escalado con la CLI de Azure, consulte Modifique la configuración de una instancia existente de Azure Cache for Redis.

Nota:

Al escalar o reducir verticalmente una caché mediante programación (por ejemplo, usando PowerShell o la CLI de Azure), se omiten maxmemory-reserved o maxfragmentationmemory-reserved como parte de la solicitud de actualización. Solo se respeta el cambio de escalado. Puede actualizar esta configuración de memoria una vez completada la operación de escalado.

Cómo escalar vertical y horizontalmente: niveles Enterprise y Enterprise Flash

Los niveles Enterprise y Enterprise Flash pueden escalar vertical y horizontalmente en una sola operación. Otros niveles requieren operaciones independientes para cada acción.

Precaución

Los niveles Enterprise y Enterprise Flash aún no admiten las operaciones de reducción vertical ni reducción horizontal.

Escalar usando Azure Portal

  1. Para escalar la caché, vaya a la caché en Azure Portal y seleccione Escalar en el menú Recursos.

    Captura de pantalla que muestra la opción Escalar seleccionada en el menú Recurso de una caché Enterprise.

  2. Para escalar verticalmente, elija un tipo de caché diferente y, a continuación, elija Guardar.

    Importante

    Solo puede escalar verticalmente en este momento. No puede reducir verticalmente.

    Captura de pantalla que muestra los niveles Enterprise en el panel de trabajo.

  3. Para escalar horizontalmente, aumente el control deslizante Capacidad. La capacidad aumenta en incrementos de dos. Este número refleja cuántos nodos de Redis Enterprise subyacentes se están agregando. Este número siempre es un múltiplo de dos para reflejar los nodos que se agregan para las particiones principal y de réplica.

    Importante

    En este momento solo puede escalar horizontalmente, aumentando la capacidad. No puede reducir horizontalmente.

    Captura de pantalla que muestra la Capacidad en el panel de trabajo con un recuadro rojo alrededor.

  4. Durante la operación de escalado de la memoria caché al nuevo plan de tarifa, se muestra la notificación Escalando Redis Cache.

    Captura de pantalla que muestra la notificación de escalado de una caché Enterprise.

  5. Cuando se completa el escalado, el estado cambia de Escalado a En ejecución.

Escalado mediante PowerShell

Puede escalar las instancias de Azure Cache for Redis con PowerShell con el cmdlet Update-AzRedisEnterpriseCache. Puede modificar la propiedad Sku para escalar verticalmente la instancia. Puede modificar la propiedad Capacity para escalar horizontalmente la instancia. En el ejemplo siguiente se muestra cómo escalar una caché denominada myCache a una instancia de nivel Enterprise E20 (25 GB) con capacidad de 4.

   Update-AzRedisEnterpriseCache -ResourceGroupName myGroup -Name myCache -Sku Enterprise_E20 -Capacity 4

Escalado con la CLI de Azure

Para escalar las instancias de Azure Cache for Redis mediante la CLI de Azure, llame al comando az redisenterprise update. Puede modificar la propiedad sku para escalar verticalmente la instancia. Puede modificar la propiedad capacity para escalar horizontalmente la instancia. En el ejemplo siguiente se muestra cómo escalar una caché denominada myCache a una instancia de nivel Enterprise E20 (25 GB) con capacidad de 4.

az redisenterprise update --cluster-name "myCache" --resource-group "myGroup" --sku "Enterprise_E20" --capacity 4

Preguntas frecuentes de escalado

La lista siguiente contiene las respuestas a las preguntas más frecuentes sobre el escalado de Azure Cache for Redis.

¿Puedo realizar operaciones de escalado en una memoria caché Premium?

  • No puede escalar desde una caché Premium a un plan de tarifa Básico o Estándar.
  • Puede escalar desde un plan de tarifa de caché Premium a otro.
  • No puede escalar de una memoria caché Básica directamente a una memoria caché Premium. En primer lugar, escale desde Básica a Estándar en una operación de escalado y, después, desde Estándar a Prémium en una operación de escalado posterior.
  • No se puede escalar desde una caché Premium a una cachéEnterprise o Enterprise Flash.
  • Si ha habilitado la agrupación en clústeres cuando creó su caché Premium, puede cambiar el tamaño de clúster. Si su caché se creó sin habilitar la agrupación en clústeres, puede configurar la agrupación en clústeres después.

Después de escalar, ¿tengo que cambiar el nombre de la memoria caché o las teclas de acceso?

No, el nombre de la memoria caché y las claves no se cambian durante una operación de escalado.

¿Cómo funciona el escalado?

  • Cuando se escala una caché Básica a un tamaño diferente, esta se cierra y se aprovisiona una nueva caché con el nuevo tamaño. Durante este tiempo, la caché no está disponible y se pierden todos los datos en la memoria caché.
  • Cuando se escala una memoria caché del plan Básico al plan Estándar, se aprovisiona una caché de réplica y los datos se copian de la caché principal a la de réplica. La memoria caché permanece disponible durante el proceso de escalado.
  • Cuando se escala una caché Estándar, Premium, Enterprise o Enterprise Flash a un tamaño diferente, se apaga una de las réplicas y se vuelve a aprovisionar para el nuevo tamaño y los datos se transfieren a través de ella y, después, la otra realiza una conmutación por error antes de volverse a aprovisionar, un proceso que es similar al que se produce durante un error en uno de los nodos de la caché.
  • Al escalar horizontalmente una caché en clúster, se aprovisionan nuevas particiones y se agregan al clúster de servidores de Redis. A continuación, los datos se vuelven a particionar en todas las particiones.
  • Cuando se reduce horizontalmente una caché en clúster, primero se vuelven a particionar los datos y, a continuación, el tamaño del clúster se reduce a las particiones necesarias.
  • En algunos casos, como el escalado o la migración de la memoria caché a otro clúster, la dirección IP subyacente de la memoria caché puede cambiar. El registro de DNS de la caché cambia y es transparente para la mayoría de las aplicaciones. Sin embargo, si usa una dirección IP para configurar la conexión a la caché o para configurar los grupos de seguridad de red o los firewalls que permiten el tráfico a la caché, puede que la aplicación tenga problemas para conectarse en algún momento después de que el registro DNS se actualice.

¿Se pierden los datos de mi caché durante el escalado?

  • Cuando se escala una memoria caché Básica a un nuevo tamaño, se pierden todos los datos y la memoria caché no está disponible durante la operación de escalado.
  • Cuando se escala una memoria caché del plan Básico al plan Estándar, normalmente se conservan los datos de la memoria caché.
  • Cuando se escala una caché Estándar, Premium, Enterprise o Enterprise Flash a un tamaño mayor, normalmente se conservan todos los datos. Al escalar una caché del plan Estándar o Premium a un tamaño más pequeño, los datos se pueden perder si el tamaño de los datos supera el nuevo tamaño menor cuando la caché se reduce verticalmente. Si se pierden datos al reducir, las claves se expulsan mediante el directiva de expulsión allkeys-lru .

¿Puedo usar todas las características del nivel Premium después del escalado?

No, algunas características solo se pueden establecer al crear una caché en el nivel Premium y no están disponibles después del escalado.

Estas características no se pueden agregar después de crear la memoria caché Premium:

  • Inserción de red virtual
  • Adición de redundancia de zona
  • Varias réplicas por una instancia principal

Para usar cualquiera de estas características, debe crear una nueva instancia de caché en el nivel Premium.

¿Mi configuración de bases de datos personalizada se ve afectada durante el escalado?

Si ha configurado un valor personalizado para el parámetro databases al crear la memoria caché, tenga en cuenta que algunos planes de tarifa tienen diferentes límites de bases de datos. Estos son algunas de los aspectos que considerar al escalar en este escenario:

  • Cuando se escala a un plan de tarifa con un límite de databases menor que el nivel actual:
    • Si usa el número predeterminado de databases, que es 16 para todos los planes de tarifa, no se pierden datos.
    • Si utiliza un número personalizado de databases que está dentro de los límites del plan al que va a escalar, se mantiene la configuración de databases y no se pierden datos.
    • Si usa un número personalizado de databases que supera los límites del nuevo plan, la configuración de databases se reduce a los límites del nuevo plan y se pierden todos los datos de las bases de datos quitadas.
  • Cuando se escala a un plan de tarifa con el mismo límite de databases o mayor que el nivel actual, la configuración de databases se mantiene y no se pierden datos.

Mientras que las cachés Estándar, Premium, Enterprise y Enterprise Flash tienen un SLA de disponibilidad, no hay ningún SLA para la pérdida de datos.

¿La caché estará disponible durante el escalado?

  • Las cachés Estándar, Premium, Enterprise y Enterprise Flash permanecen disponibles durante la operación de escalado. Sin embargo, pueden producirse interrupciones momentáneas de conexión mientras al escalar de cachés Básicas a Estándar. Estas interrupciones momentáneas de conexión deberían ser breves y los clientes de Redis, por lo general, deberían poder volver a establecer su conexión al instante.
  • En el caso de las cachés Enterprise y Enterprise Flash que usan la replicación geográfica activa, el escalado solo de un subconjunto de cachés vinculadas puede presentar problemas con el tiempo en algunos casos. Se recomienda escalar todas las cachés posibles del grupo de replicación geográfica juntas.
  • Las memorias caché Básicas están sin conexión durante las operaciones de escalado a un tamaño diferente. Las memorias caché Básicas siguen estando disponibles al escalar del plan Básico al Estándar, pero pueden experimentar una breve interrupción momentánea de conexión. En caso de producirse una interrupción momentánea de la conexión, por lo general los clientes de Redis pueden volver a establecer conexión al instante.

¿Qué limitaciones de escalado se aplican a la replicación geográfica?

Con la replicación geográfica pasiva configurada, es posible que observe que no puede escalar una caché o cambiar las particiones de un clúster. Un vínculo de replicación geográfica entre dos cachés impide la operación de escalado o el cambio del número de particiones de un clúster. Debe desvincular la memoria caché para emitir estos comandos. Para obtener más información, consulte Configuración de replicación geográfica.

Con la replicación geográfica activa configurada, no puede escalar una caché. Todas las cachés de un grupo de replicación geográfica deben tener el mismo tamaño y capacidad.

Operaciones que no se admiten

  • No se puede escalar desde un plan de tarifa superior a un plan de tarifa inferior.
    • No puede cambiar de una memoria caché Premium a una memoria caché Estándar o Básica.
    • No puede cambiar de una memoria caché Estándar a una memoria caché Básica.
  • Puede cambiar de una memoria caché Básica a una memoria caché Estándar, pero no puede cambiar el tamaño al mismo tiempo. Si necesita un tamaño distinto, puede realizar una operación de escalado hasta el tamaño deseado en un momento posterior.
  • No puede escalar de una memoria caché Básica directamente a una memoria caché Premium. En primer lugar, escale del plan Básico al Estándar en una operación de escalado y, después, del plan Estándar al Prémium en una operación posterior.
  • No se puede escalar desde una caché Premium a una cachéEnterprise o Enterprise Flash.
  • No puede escalar desde un tamaño mayor hasta el tamaño C0 (250 MB) .

Si se produce un error en una operación de escalado, el servicio intenta revertir la operación y la memoria caché se restablecerá al tamaño original.

¿Cuánto tarda el escalado?

El tiempo de escalado depende de algunos factores. Estos son algunos factores que pueden afectar al tiempo que tarda el escalado.

  • Cantidad de datos: las grandes cantidades de datos tardan más tiempo en replicarse.
  • Solicitudes de escritura elevadas: un mayor número de escrituras significa más replicaciones de datos entre nodos o particiones.
  • Carga elevada del servidor: una mayor carga de servidor significa que el servidor de Redis está ocupado y hay disponibles ciclos de CPU limitados para completar la redistribución de datos.

El escalado de una caché no es una acción trivial y puede tardar mucho tiempo.

En función de ejemplos reales, el tiempo para escalar la memoria caché con una a dos particiones puede ser de 1 a 2 horas cuando la memoria caché no está bajo cargas pesadas. Si tiene más particiones, el tiempo de escalado no aumenta de forma lineal.

¿Cómo puedo saber si el escalado ha terminado?

En Azure Portal puede ver la operación de escalado en curso. Cuando se completa el escalado, el estado de la memoria caché cambia de En ejecución.

¿Es necesario realizar algún cambio en mi aplicación cliente para usar la agrupación en clústeres?

Importante

Al usar los niveles Enterprise o Enterprise FLash, se le da la opción de elegir entre Modo de clúster de OSS o Modo de clúster Enterprise. El Modo de clúster de OSS es el mismo que la agrupación en clústeres en el nivel Premium y sigue la especificación de agrupación en clústeres de código abierto. El Modo de clúster Enterprise puede tener un rendimiento menor, pero usa la agrupación en clústeres de Redis Enterprise que no requiere ningún cambio del cliente para usarlo. Para obtener más información, consulte Agrupación en clústeres en Enterprise.

¿Cómo se distribuyen las claves en un clúster?

Según la documentación de Redis sobre el modelo de distribución de claves: el espacio de clave se divide en 16 384 ranuras. Cada clave tiene un hash y se asigna a una de estas ranuras, que se distribuyen por todos los nodos del clúster. Puede configurar qué parte de la clave está con hash para asegurarse de que varias claves se encuentran en la misma partición con etiquetas hash.

  • Claves con una etiqueta hash: si cualquier parte de la clave está encerrada entre { y }, se aplica un algoritmo hash únicamente a esa parte de la clave para determinar la ranura hash de una clave. Por ejemplo, las siguientes tres claves se encontrarían en la misma partición: {key}1, {key}2 y {key}3, ya que solo se aplica el hash a la parte key del nombre. Para obtener una lista completa de especificaciones de etiquetas hash de claves, consulte Etiquetas hash de claves.
  • Claves sin una etiqueta hash: se usa todo el nombre de la clave para aplicar el hash, lo que produce una distribución estadísticamente uniforme entre las particiones de la memoria caché.

Para optimizar el rendimiento, se recomienda distribuir las claves de manera uniforme. Si usa claves con una etiqueta hash, es responsabilidad de la aplicación asegurarse de que las claves se distribuyan de manera uniforme.

Para obtener más información, consulte Modelo de distribución de claves, Particionamiento de datos de clúster Redis y Etiquetas hash de claves.

Para obtener el código de ejemplo sobre cómo trabajar con clústeres y buscar claves en la misma partición con el cliente StackExchange.Redis, consulte la parte clustering.cs del ejemplo Hola mundo.

¿Cuál es el mayor tamaño de caché que puedo crear?

El tamaño más grande de caché que se puede tener es de 4,5 TB. Este resultado es una caché F1500 agrupada con capacidad de 9. Para más información, consulte Precios de Azure Cache for Redis.

¿Todos los clientes de Redis admiten la agrupación en clústeres?

Muchas bibliotecas cliente admiten la agrupación en clústeres de Redis, pero no todas. Consulte la documentación de la biblioteca que está usando para comprobar si usa una biblioteca y una versión que admiten la agrupación en clústeres. StackExchange.Redis es una biblioteca que admite la agrupación en clústeres, en sus versiones más recientes. Para obtener más información sobre otros clientes, consulte la sección Jugar con el clúster del Tutorial de clúster de Redis.

El protocolo de agrupación en clústeres de Redis requiere que cada cliente se conecte a cada partición directamente en modo de agrupación en clústeres y también define nuevas respuestas de error, como MOVED y CROSSSLOTS. Si se intenta usar una biblioteca cliente que no admite la agrupación en clústeres con una caché en modo de clúster, se pueden producir muchas excepciones de redireccionamiento MOVED, o simplemente se interrumpe la aplicación si se realizan solicitudes de varias claves entre espacios.

Nota

Si está usando StackExchange.Redis como su cliente, asegúrese de que está usando la versión más reciente de StackExchange.Redis 1.0.481 o posterior para que la agrupación en clústeres funcione correctamente. Para obtener más información sobre los problemas con las excepciones MOVE, consulte el apartado sobre las excepciones MOVE.

¿Cómo me conecto a mi memoria caché cuando la agrupación en clústeres esté habilitada?

Puede conectarse a su memoria caché con los mismos puntos de conexión, puertos y claves que usa al conectarse a una memoria caché que no tiene la agrupación en clústeres habilitada. Redis administra la agrupación en clústeres en el back-end para que no tenga que administrarla desde el cliente.

¿Puedo conectarme directamente a las particiones individuales de mi memoria caché?

El protocolo de agrupación en clústeres requiere que el cliente realice las conexiones correctas entre particiones, por lo que el cliente debe realizar las conexiones de recursos compartidos por usted. Dicho esto, cada partición consta de un par de caché principal/réplica que se conoce colectivamente como una instancia de caché. Puede conectarse a estas instancias de caché mediante la utilidad redis-cli en la rama inestable del repositorio de Redis en GitHub. Esta versión implementa compatibilidad básica cuando se inicia con el conmutador -c . Para más información, consulte la sección Jugar con el clúster en https://redis.io, en el tutorial de clústeres de Redis.

Necesita utilizar el conmutador -p para especificar el puerto correcto al que conectarse. Use el comando CLUSTER NODES para determinar los puertos exactos usados para los nodos principal y de réplica. Se usan los siguientes intervalos de puertos:

  • En el caso de las cachés de nivel Premium no TLS, los puertos están disponibles en el intervalo 130XX
  • En el caso de las cachés de nivel Premium habilitadas para TLS, los puertos están disponibles en el intervalo 150XX
  • En el caso de las cachés Enterprise y Enterprise Flash que usan la agrupación en clústeres de OSS, la conexión inicial se realiza a través del puerto 10000. La conexión a los nodos individuales se puede realizar mediante puertos en el intervalo 85XX. Los puertos 85xx cambiarán con el tiempo y no deben codificarse de forma rígida en su aplicación.

¿Puedo configurar la agrupación en clústeres para una memoria caché creada anteriormente?

Sí. En primer lugar, asegúrese de que su caché se encuentra en el nivel Premium ampliándolo. Después, podrá ver las opciones de configuración del clúster, incluida una opción para habilitarlo. Cambia el tamaño del clúster una vez creada la memoria caché o después de habilitar la agrupación en clústeres por primera vez.

Importante

La habilitación de la agrupación en clústeres no se puede deshacer. Hay que tener en cuenta que una caché que tiene habilitada la agrupación en clústeres y solo una partición se comporta de modo diferente que una caché del mismo tamaño sin agrupación en clústeres.

Todas las cachés de nivel Enterprise y Enterprise Flash siempre se agrupan en clústeres.

¿Puedo configurar la agrupación en clústeres para una caché básica o estándar?

La agrupación en clústeres solo está disponible para las cachés Premium, Enterprise y Enterprise Flash.

¿Puedo usar la agrupación en clústeres con los proveedores de estado de sesión y de almacenamiento en caché de salida de ASP.NET de Redis?.

  • Proveedor de caché de salida de Redis : no se requieren cambios.
  • Proveedor de estado de sesión de Redis: para usar la agrupación en clústeres, debe usar RedisSessionStateProvider 2.0.1 o una versión superior; de lo contrario, se producirá una excepción, lo que supone un cambio importante. Para obtener más información, consulte la página de detalles sobre cambios importantes de la versión 2.0.0.

Estoy recibiendo excepciones MOVE al usar StackExchange.Redis y agrupaciones en clústeres, ¿qué debo hacer?

Si usa StackExchange.Redis y recibe excepciones MOVE al emplear agrupaciones en clústeres, asegúrese de que está usando la versión 1.1.603 de StackExchange.Redis o una versión posterior. Para obtener instrucciones sobre cómo configurar las aplicaciones .NET para usar StackExchange.Redis, consulte Configuración de los clientes de caché.

¿Cuál es la diferencia entre la agrupación en clústeres OSS y la agrupación en clústeres Enterprise en cachés de nivel Enterprise?

El Modo de clúster de OSS es el mismo que la agrupación en clústeres en el nivel Premium y sigue la especificación de agrupación en clústeres de código abierto. El Modo de clúster Enterprise puede tener un rendimiento menor, pero usa la agrupación en clústeres de Redis Enterprise que no requiere ningún cambio del cliente para usarlo. Para obtener más información, consulte Agrupación en clústeres en Enterprise.

¿Cuántas particiones usan las cachés de nivel Enterprise?

A diferencia de las cachés de nivel Básico, Estándar y Premium, las cachés Enterprise y Enterprise Flash pueden aprovechar varias particiones en un solo nodo. Para obtener más información, consulte Particionamiento y uso de CPU.

Pasos siguientes