Prácticas recomendadas: redimensionamiento de clústeres en línea

Antes de iniciar el cambio de las particiones, recomendamos lo siguiente:

• Probar la aplicación: si es posible, pruebe el comportamiento de la aplicación durante el cambio de las particiones en un entorno de ensayo.

• Recibir notificaciones anticipadas sobre problemas de escalado: el cambio de particiones es una operación que requiere mucho procesamiento. Por ello, recomendamos mantener la CPU utilización por debajo del 80 por ciento en las instancias multinúcleo y menos del 50 por ciento en las instancias de un solo núcleo durante la refragmentación. Monitoree las métricas de MemoryDB e inicie el cambio de las particiones antes de que la aplicación comience a observar problemas de escalado. Las métricas de las que se puede realizar un seguimiento son CPUUtilization, NetworkBytesIn, NetworkBytesOut, CurrConnections, NewConnections, FreeableMemory, SwapUsage y BytesUsedForMemoryDB.

• Comprobar que hay suficiente memoria libre disponible antes de la reducción horizontal: si va a realizar una reducción horizontal, asegúrese de que la memoria libre disponible en las particiones que se van a retener sea al menos 1,5 veces la memoria utilizada en las particiones que tiene previsto eliminar.

• Iniciar el cambio de las particiones durante las horas de menor actividad: esta práctica contribuye a reducir la latencia y el impacto en el rendimiento en el cliente durante la operación de cambio de las particiones. También ayuda a completar el cambio de las particiones con mayor rapidez ya que se pueden usar más recursos para la redistribución de ranuras.

• Revisar el comportamiento de tiempo de espera de cliente: es posible que algunos clientes observen una latencia más alta durante el cambio de tamaño del clúster en línea. La configuración de la biblioteca de cliente con un tiempo de espera más alto puede ayudar a conceder al sistema tiempo para conectar incluso en condiciones de carga más altas en servidor. En algunos casos, es posible que abra un gran número de conexiones al servidor. En estos casos, considere la posibilidad de agregar retardo exponencial a la lógica de reconexión. Si lo hace, puede ayudar a evitar que llegue una ráfaga de conexiones nuevas al servidor al mismo tiempo.

Durante el cambio de las particiones, recomendamos lo siguiente:

• Evitar los comandos costosos: evite ejecutar operaciones que hagan una utilización intensiva de procesamiento y de E/S, como los comandos KEYS y SMEMBERS. Recomendamos este enfoque porque estas operaciones aumentan la carga en el clúster e influyen en el rendimiento del clúster. En su lugar, utilice los comandos SCAN y SSCAN.

• Seguir las prácticas recomendadas de Lua: evite los scripts Lua de ejecución prolongada y siempre declare por adelantado las claves que utiliza en los scripts Lua. Recomendamos este enfoque para determinar que el script Lua no está utilizando comandos de ranura cruzada. Asegúrese de que las claves utilizadas en scripts Lua pertenezcan a la misma ranura.

Después del cambio de las particiones, tenga en cuenta lo siguiente:

• La reducción horizontal se puede realizar parcialmente si no hay suficiente memoria disponible en las particiones de destino. Si se produce este resultado, revise la memoria disponible y, si es necesario, reintente la operación.

• Las ranuras con elementos grandes no se migran. En concreto, no se migran las ranuras con elementos que superen los 256 MB después de la serialización.

• No se admiten los comandos FLUSHALL y FLUSHDB en los scripts Lua dentro durante una operación de cambio de particiones.