El número de particiones en una solución específica se debe gestionar con cuidado. Generalmente, siempre que sea posible, la utilización de menos particiones es más sencilla y más eficaz. Cada partición consume recursos del sistema para implementarse en la gestión de carga de trabajo, supone un trabajo adicional del administrador desde el punto de vista de la gestión del sistema y reduce el rendimiento del clúster cuando se realiza un seguimiento desde el punto de vista de la supervisión del rendimiento.
Cuando una solución necesita más particiones, cada una de ellas empieza a escalarse y necesita recursos adicionales y/o rendimiento adicional para mantenerse. Algunas soluciones son complicadas y pueden necesitar un número mayor de particiones, o incluso crear dos o tres tipos diferentes de particiones para aumentar la eficacia (consulte la partición híbrida comparada con una solución clave del servidor de aplicaciones); en cuyo caso la solución debe gestionarse con mucha atención. Una posible solución es crear particiones de forma dinámica a medida que sean necesarias y, cuando ya no lo sean, eliminarlas.
Por ejemplo, desde el punto de vista administrativo, a menudo uno de los aspectos más caros a largo plazo de una implementación, la gestión de varios miles de particiones y la carga que se coloca en ellas en el clúster supone un reto mayor si se compara con una solución que necesita la gestión de cientos de particiones. No obstante, si son varias las soluciones que necesitan miles de particiones, los recursos de proceso, los desarrolladores y los recursos administrativos necesarios para solucionar el problema serán todavía mayores.
Internamente en IBM, Partitioning Facility se ha probado de forma satisfactoria con 10.000 particiones en condiciones de carga entre varias máquinas. Un descubrimiento clave de estas pruebas es que el número de coordinadores activos debe ser como mínimo 4. Asimismo, la utilización de la política de Highly Available (HA) Manager para establecer estos coordinadores en máquinas físicas específicas del clúster y establecer los servidores preferidos de las particiones fuera de estas máquinas (o incluso servidores de aplicaciones, si hay un número reducido de máquinas) demostró sus ventajas. Además, cuando ejecuta conjuntos de particiones de gran tamaño podría tener que aumentar los tamaños de almacenamiento dinámico de la Java Virtual Machine (JVM) para el gestor de despliegue y los servidores de aplicaciones que asigne como coordinadores activos.
En la sección de gestión se proporciona más información, pero en general gestione los recursos de forma moderada. Este enfoque garantiza que cuando se produzcan picos de rendimiento y aparezcan anomalías, la integridad operativa del clúster no se vea comprometida.
Related concepts
Consideraciones generales sobre clústeres y la gestión de WPF