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

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

  1. 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.
  2. 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.
  3. 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.
  4. 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.

    Multimedia 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]


Icono que indica el tipo de tema Tema de tarea

Nombre de archivo: twlp_wve_configjvmelast.html