Puede configurar un colectivo para dar soporte a la elasticidad de la máquina
virtual Java (JVM). Con la elasticidad de la JVM, el controlador de escalado
puede iniciar o detener servidores Liberty basándose en el uso de los recursos y las
políticas de escalado. Sólo los servidores que ya están en el colectivo son elegibles
para el escalado. No se suministran nuevos servidores.
Antes de empezar
Los tipos de información de uso de recursos recopilada varían entre los
JDK. IBM JDK 1.7 para los sistemas operativos Windows y Linux proporciona toda la
información de uso necesaria para el escalado automático y es el JDK preferido. Es posible que otros JDK
no proporcionen toda la información de uso necesaria para el escalado automático
basándose en el uso de recursos JVM individuales.
Evite problemas: La
consola administrativa permite un inicio y una detención de un servidor de Liberty que es un miembro
de clúster de un clúster escalable automáticamente, pero sólo cuando el servidor está en modalidad de
mantenimiento. El inicio o la detención de un servidor de Liberty desde la línea de mandatos cuando
el servidor de Liberty es un miembro de clúster de un clúster escalable automáticamente puede tener
resultados imprevisibles.
Procedimiento
- Cree un colectivo.
Si desea detalles sobre cómo crear un controlador colectivo y un servidor miembro, consulte Configuración de un colectivo de Liberty.
Nota: Se recomienda que complete el primer paso antes de
continuar con el procedimiento.
El primer paso indica al usuario que cree el colectivo, añada
miembros e inicie los controladores y miembros.
- Añada la característica scalingController-1.0 al archivo
server.xml de uno o varios controladores de colectivos. Cuando
guarde el archivo server.xml, las políticas
predeterminadas se aplican, a menos que se especifique lo contrario.
<featureManager>
<feature>jsp-2.2</feature>
<feature>collectiveController-1.0</feature>
<feature>scalingController-1.0</feature>
</featureManager>
Tras añadir la característica, los mensajes siguientes se muestran
en cualquier orden en el messages.log del
controlador colectivo, siempre que el controlador colectivo se esté
ejecutando:
CWWKV0300I: El servicio StackManager se ha iniciado.
CWWKV0302I: Las pilas existentes son []
CWWKV0100I: La característica ScalingController está activada.
CWWKX1002I: Servicio de singleton ScalingControllerSingletonService para el ámbito
CWWKV0102I: Este servidor se ha elegido como el controlador de escalado primario.
CWWKF0012I: El servidor ha instalado las siguientes características: [scalingController-1.0].
Nota: Puesto que la configuración de Liberty es
dinámica, cuando se añade el controlador de escalado, la
política de escalado predeterminada del controlador entra en vigor y
puede obtener resultados inesperados. Por ejemplo, la política
predeterminada tiene min=2 servidores, de forma que cuando se guarda
el archivo server.xml del controlador de
escalado para iniciar dos servidores. Si no desea ese comportamiento, puede definir
una política para el controlador al mismo tiempo.
Nota: Puede tardar algún tiempo
mientras el controlador de escalado registra el miembro y muestra el mensaje CWWKV0121I.
- Opcional: Cambie el valor predeterminado de las
políticas de escalado para que cumpla las necesidades del entorno. Si
desea más información, consulte
Definición de políticas de escalado para gestionar la carga de trabajo.
- Añada la característica scalingMember-1.0 a todos los miembros de colectivo que desea que controle
el controlador del escalado. Defina un elemento hostSingleton con un puerto en los archivos
server.xml del miembro. Cada miembro de escalado debe definir un
elemento hostSingleton con un puerto en el
archivo server.xml. Todos los miembros de escalado en el mismo host
deben utilizar el mismo puerto. Puede especificar cualquier número de puerto, pero debe
ser exclusivo en el sistema principal. En el ejemplo siguiente, se utiliza el número de
puerto 20020:
<featureManager>
<feature>jsp-2.2</feature>
<feature>scalingMember-1.0</feature>
</featureManager>
<hostSingleton name="ScalingMemberSingletonService" port="20020 " />
Si el servidor no se inicia cuando añade las características y el elemento
hostSingleton, debe iniciarlo manualmente una vez para que el controlador
de escalado reconozca las características añadidas.
Aparecen los siguientes mensajes en cualquier orden en el archivo
messages.log del miembro de colectivo:
CWWKX1000I: El bean gestionado SingletonMessenger está disponible.
CWWKX7400I: El bean gestionado ClusterMember está disponible.
CWWKX1002I: El servicio de singleton ScalingMemberSingletonService para el host de ámbito
se ha creado.
CWWKV0200I: La característica ScalingMember está activada.
CWWKX1004I: La conexión de mensajería está conectada a
host=nombre_host_controlador,
port=número_puerto_controlador.
Sólo un miembro de escalado por host se comunica con el controlador de escalado. El
primer miembro de escalado que se conecta a
ScalingMemberSingletonService se elige como líder de host. Si
el líder de host se detiene, otro miembro de escalado toma el control
como el líder de host mediante un proceso de elección que es
controlado por scalingMemberSingletonService. Todos los miembros de escalado en el mismo host y clúster deben utilizar el mismo puerto
de ScalingMemberSingletonService.
Nota: Cuando un miembro de escalado se elige como el líder de
host, verá el mensaje siguiente en el
messages.log del miembro de colectivo:
CWWKV0203I: El servidor host=nombre_host;
userdir=vía_acceso_directorio_usr;
server=nombre_miembro;
port=número_puerto_miembro;
service=ScalingMemberSingletonService; scope=host se ha elegido como líder de host.
Nota: Si no añade el elemento
hostSingleton al archivo
server.xml de scalingMember o utiliza puertos diferentes en
cada scalingMember del mismo host, pueden elegirse varios líderes de host. Esto
puede generar unas decisiones de escalado incorrectas. Verá este
mensaje en el
messages.log del controlador:
CWWKV0123E: Se
han detectado líderes de singleton de host en el host nombre_host. Esta condición puede
degradar las decisiones del controlador de escalado. La identidad del líder del
servidor server_name1 es leader_id1. La identidad del líder del servidor server_name2 es
leader_id2.
Para obtener más
información sobre el elemento hostSingleton, consulte
Miembro de colectivo.
Vea: El vídeo Configuración de un clúster escalable automáticamente de Liberty para la elasticidad de JVM demuestra el procedimiento. [Transcripción]