![[8.5.5.5 o posterior]](../ng_v8555.gif)
Configuración de clústeres autoescalables para la elasticidad de JVM
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
Procedimiento
- Cree un colectivo.
Para obtener más detalles sobre la creación de un controlador de colectivo y un servidor miembro, consulte Configuración de un colectivo de Liberty.
Nota: Se recomienda realizar el primer paso antes de continuar. El paso uno indica al usuario que debe crear el colectivo, añadir miembros, e iniciar los controladores y los miembros. - Añada la característica scalingController-1.0 al archivo
server.xml de uno o varios controladores de colectivos. Cuando
guarda el archivo server.xml, se
aplican las políticas predeterminadas, a menos que se especifique lo contrario.
<featureManager> <feature>jsp-2.2</feature> <feature>collectiveController-1.0</feature> <feature>scalingController-1.0</feature> </featureManager>
Después de añadir la característica, aparecen los siguientes mensajes en cualquier orden en el archivo messages.log del controlador de colectivo, siempre que se esté ejecutando el controlador de colectivo:
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: Como la configuración de Liberty es dinámica, cuando añade el controlador de escalado, se aplica la política de escalado predeterminada del controlador y puede obtener resultados inesperados. Por ejemplo, la política predeterminada tiene min=2 servers, por lo que cuando guarda el archivo server.xml del controlador de escalado, el controlador intentará 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 las políticas de escalado predeterminadas para cumplir las necesidades de su entorno. Consulte Definición de políticas de escalado para gestionar la carga de trabajo para obtener más información.
- Añada las características clusterMember-1.0 y
scalingMember-1.0 a todos los miembros de colectivo que desea que
controle el controlador de 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>clusterMember-1.0</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 tomará de control como líder de host mediante un proceso de elección arbitrado 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 siguiente mensaje en el archivo 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 dar como resultado decisiones de escalado incorrectas. Verá este mensaje en el archivo 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 Collective Member.
Vea: En el vídeo Configuración de un clúster autoescalable de Liberty para la elasticidad de JVM se muestra este procedimiento. [Transcripción]

Términos y condiciones para centros de información | Comentarios

http://www14.software.ibm.com/webapp/wsbroker/redirect?version=phil&product=was-libcore-mp&topic=twlp_wve_configjvmelast
Nombre de archivo:twlp_wve_configjvmelast.html