La función de gestor de Load Balancer realiza el equilibrio de carga basándose en los siguientes valores:
Si lo desea, modifique estos valores para optimizar el equilibrio de carga para la red.
El gestor puede tener en cuenta algunos de los siguientes factores externos o todos cuando se sopesan las decisiones:
O —
CPU: el porcentaje de la CPU en uso en cada máquina servidor con equilibrio de carga (entrada del agente de Metric Server). En Site Selector, esta proporción aparece en lugar de la columna de proporción de conexiones activas.
O —
Memoria: el porcentaje de la memoria en uso (entrada del agente de Metric Server) en cada servidor con equilibrio de carga. En Site Selector, esta proporción aparece en lugar de la columna de proporción de conexiones nuevas.
Junto con el peso actual para cada servidor y alguna otra información necesaria para sus cálculos, el gestor obtiene los dos primeros valores (conexiones activas y nuevas) del ejecutor. Estos valores se basan en la información generada y almacenada internamente en el ejecutor.
Puede cambiar la proporción de importancia relativa de los cuatros valores clúster por clúster (o nombre de sitio). Piense en las proporciones como si fueran porcentajes; la suma de las proporciones relativas debe ser 100%. La proporción predeterminada es 50/50/0/0, que ignora la información del asesor y del sistema. En el entorno, es posible que necesite probar diferentes proporciones para encontrar la combinación que ofrece el mejor rendimiento.
Al añadir el asesor WLM, si la proporción de métrica del sistema es cero, el gestor aumenta este valor hasta 1. Puesto que la suma de las proporciones relativas debe ser 100, se restará 1 al valor más alto.
El número de conexiones activas depende del número de clientes así como del periodo de tiempo necesario para utilizar los servicios proporcionados por las máquinas de servidor con equilibrio de carga. Si las conexiones de cliente son rápidas (como páginas Web pequeñas servidas mediante HTTP GET), el número de conexiones activas será bastante bajo. Si la conexiones de cliente son más lentas (como una consulta a una base de datos), el número de conexiones activas será más alto.
Debe evitar establecer demasiado bajos los valores de las proporciones de conexiones activas y nuevas. Debe inhabilitar el equilibrio de carga y el suavizado, a menos que estos dos valores estén establecidos como mínimo en 20 cada uno.
Para definir la proporción de los valores de importancia, emita el mandato dscontrol cluster set clúster proportions. Consulte dscontrol cluster — configurar clústeres para obtener más información.
La función de gestor establece los pesos basándose en contadores internos del ejecutor, información de retorno de los asesores y la información de retorno un programa de supervisión del sistema, por ejemplo Metric Server. Si desea establecer pesos manualmente mientras ejecuta el gestor, especifique la opción fixedweight en el mandato dscontrol server. Para obtener una descripción de la opción fixedweight, consulte Pesos fijados por el gestor.
Los pesos se aplican a todos los servidores de un puerto. Para cualquier puerto concreto, las solicitudes se distribuyen entre los servidores en función del peso relativo que dichos servidores tienen entre sí. Por ejemplo, si el peso de un servidor se establece en 10 y el de otro en 5, el servidor establecido en 10 debería recibir el doble de solicitudes que el servidor establecido en 5.
Para especificar el límite máximo de peso que un servidor puede tener, utilice el mandato dscontrol port set puerto weightbound peso. Este mandato afecta a la diferencia permitida entre la cantidad de solicitudes que cada servidor obtendrá. Si establece el valor máximo de weightbound en 1, todos los servidores podrán tener un peso de 1, 0 si está inmovilizado o -1 si se marca inactivo. Cuando se incrementa este número, aumentará la diferencia entre el peso que se puede otorgar a los servidores. A un valor de weightbound máximo de 2, un servidor puede obtener el doble de solicitudes que otro. A un máximo de ponderación de 10, un servidor puede obtener 10 veces más solicitudes que otro. El valor máximo predeterminado de weightbound es 20.
Si un asesor encuentra que un servidor ha concluido, lo comunica al gestor y éste establecerá el peso para el servidor en cero. Como resultado, el ejecutor no enviará ninguna conexión adicional a dicho servidor siempre que dicho peso permanezca en cero. Si hay alguna conexión activa con dicho servidor antes de que cambie el peso, ésta se dejará que se complete normalmente.
Si todos los servidores están inactivos, el gestor establece los pesos a la mitad de la ponderación.
Sin el gestor, los asesores no se pueden ejecutar y no pueden detectar si un servidor está inactivo. Si opta por ejecutar los asesores, pero no desea que el gestor actualice el peso establecido para un servidor concreto, utilice la opción fixedweight en el mandato dscontrol server. Por ejemplo:
dscontrol server set cluster:port:server fixedweight yes
Una vez que fixedweight se establece en yes, utilice el mandato dscontrol server set weight para establecer el peso en el valor que desee. El valor de peso de servidor permanece fijo mientras el gestor se está ejecutando hasta que emite otro mandato dscontrol server con el valor de fixedweight establecido en no. Para obtener más información, consulte dscontrol server — configurar servidores.
Si se activa una restauración TCP, Dispatcher enviará una restauración TCP al cliente cuando éste tenga una conexión con un servidor con un peso 0. El peso de un servidor puede ser 0 si se ha configurado 0 o si un asesor lo marca como inactivo. Una restauración TCP hará que la conexión se cierre inmediatamente. Esta característica es útil para conexiones de larga duración donde acelera la capacidad el cliente para renegociar una conexión anómala. Para activar la restauración TCP, utilice el mandato dscontrol port add|set puerto reset yes. El valor predeterminado para reset es no.
Una característica que será de gran utilidad configurar, junto con la restauración TCP, es advisor retry. Con esta característica, un asesor tiene la posibilidad de volver a intentar una conexión antes de marcar un servidor como inactivo. Esto ayudará a impedir que el asesor marque prematuramente el servidor como inactivo, lo que podría provocar problemas en la restauración de la conexión. Es decir, sólo porque el asesor haya fallado en el primer intento, no significa necesariamente que las conexiones existentes también están sufriendo anomalías. Consulte Reintento del asesor para obtener más información.
Para optimizar el rendimiento general, se restringe la frecuencia con la que el gestor puede interactuar con el ejecutor. Puede realizar cambios en este intervalo entrando los mandatos dscontrol manager interval y dscontrol manager refresh.
El intervalo del gestor especifica la frecuencia con la que el gestor actualizará los pesos del servidor que el ejecutor utiliza en el direccionamiento de conexiones. Si el intervalo del gestor es demasiado bajo, puede suponer un bajo rendimiento como resultado de que el gestor interrumpe constantemente al ejecutor. Si el valor de intervalo del gestor es demasiado alto, puede indicar que el direccionamiento de solicitudes del ejecutor no se basará en información actualizada y precisa.
Por ejemplo, para establecer el intervalo en 1 segundo, escriba el siguiente mandato:
dscontrol manager interval 1
El ciclo de renovación del gestor especifica con qué frecuencia el gestor solicitará información de estado al ejecutor. El ciclo de renovación se basa en el intervalo de tiempo.
Por ejemplo, para establecer el ciclo de renovación del gestor en 3, escriba el siguiente mandato:
dscontrol manager refresh 3
Esto hará que el gestor espere 3 intervalos antes de solicitar el estado al ejecutor.
Hay otros métodos disponibles para optimizar el equilibrio de carga para los servidores. Para trabajar a máxima velocidad, sólo se actualizan los pesos de los servidores si dichos pesos han cambiado de una manera significativa. Si se actualizan constantemente los pesos cuando no se produce ningún cambio en el estado del servidor o dicho cambio es muy pequeño, supondrá una carga adicional innecesaria. Cuando el cambio de porcentaje del peso total de todos los servidores de un puerto es mayor que el umbral de sensibilidad, el gestor actualiza los pesos utilizados por el ejecutor para distribuir las conexiones. Por ejemplo, suponga que el total de los cambios de pesos pasa de 100 a 105. El cambio es del 5%. Con el umbral de sensibilidad predeterminada 5, el gestor no actualizará los pesos utilizados por el ejecutor, porque el cambio del porcentaje no está por encima del umbral. Sin embargo, si el peso total pasa de 100 a 106, el gestor actualizará los pesos. Para establecer el umbral de sensibilidad el gestor en un valor distinto del valor predeterminado (por ejemplo, 6), especifique el siguiente mandato:
dscontrol manager sensitivity 6
En la mayoría de los casos, no es necesario cambiar este valor.
El gestor calcula los pesos de servidores de forma dinámica. En consecuencia, un peso actualizado puede ser muy distinto de uno anterior. En la mayoría de casos, esto no será un problema. Sin embargo, en algunas ocasiones puede causar un efecto de fluctuación en la forma en que se realiza el equilibrio de carga en las solicitudes. Por ejemplo, un servidor puede acabar recibiendo la mayoría de las solicitudes debido a un peso alto. El gestor verá que el servidor tiene un elevado número de conexiones activas y que el servidor responde muy lentamente. Entonces pasará el peso a los servidores libres, lo que producirá el mismo efecto y provocará una utilización de recursos ineficaz.
Para aliviar este problema, el gestor utiliza un índice de suavizado. El índice de suavizado limita la cantidad que el peso de un servidor puede cambiar, mitigando el cambio en la distribución de solicitudes. Un índice de suavizado más alto hará que los pesos de servidores cambien menos radicalmente. Un índice más bajo hará que los pesos de servidores cambien de forma más radical. El valor predeterminado para el índice de suavizado es 1,5. Con un índice de 1,5, los pesos de servidores pueden ser bastante dinámicos. Si se especifica un índice de 4 o 5, los pesos serán más estables. Por ejemplo, para establecer el índice de suavizado en 4, escriba el siguiente mandato:
dscontrol manager smoothing 4
En la mayoría de los casos, no es necesario cambiar este valor.
Load Balancer proporciona salidas de usuario que desencadenan scripts que se pueden personalizar. Puede crear los scripts para realizar acciones automatizadas, como avisar a un administrador cuando el gestor ha marcado que los servidores están inactivos o simplemente anotar el suceso de la anomalía. Los scripts de ejemplo, que puede personalizar, están en el directorio siguiente:
Para ejecutar los archivos, debe ponerlos en el directorio siguiente y eliminar la extensión de archivo "sample".
Se proporcionan los siguientes scripts de ejemplo:
Si todos los servidores de un clúster se marcan como inactivos (por el usuario o por los asesores), se inicia managerAlert (si está configurado) y Load Balancer intenta direccionar el tráfico a los servidores utilizando una técnica de turno rotativo. El script serverDown no se inicia cuando se ha detectado que el último servidor del clúster está fuera de línea.
Load Balancer se ha diseñado de modo que intente continuar direccionando el tráfico en caso de que un servidor vuelva a estar en línea y responda a la solicitud. Si en lugar de esto, Load Balancer dejara de direccionar todo el tráfico, el cliente no recibiría ninguna respuesta.
Cuando Load Balancer detecta que el primer servidor de un clúster vuelve a estar en línea, se inicia el script managerClear (si está configurado), aunque el script serverUp (si está configurado) no se ejecutará hasta que no vuelva a estar en línea un servidor adicional.
Factores que deben tenerse en cuenta cuando se utilizan los scripts serverUp y serverDown: