Configuración de clústeres suministrables para la elasticidad de Liberty

Puede configurar un colectivo para que dé soporte a la elasticidad de Liberty. Con la elasticidad de Liberty, el controlador de escalado puede instalar software de Liberty en un host registrado y crear un servidor nuevo. Además, dado que el soporte para la elasticidad de Liberty incluye soporte para la elasticidad de la JVM, el controlador de escalado puede iniciar o detener servidores de Liberty en función del uso de recursos y en políticas de escalado opcionales. El número de servidores disponibles crece cuando la demanda de las aplicaciones es alta y se reduce cuando la demanda de las aplicaciones es baja.

Antes de empezar

Determine los hosts de destino en los que desea instalar el software de Liberty y el software de Liberty que se instalará. Como mínimo, desea que el controlador de escalado instale los siguientes archivos de paquete e instalables en un host de destino:

  • Un paquete que proporciona un servidor de Liberty autónomo en una única aplicación. El Paso 5c explica cómo crear el paquete de servidor.
  • Un instalable que proporciona un servidor de Liberty que contiene el directorio wlp, pero no contiene el directorio usr. El Paso 5a explica cómo crear el instalable de archivado de tiempo de ejecución de Liberty.

Cada host de destino necesita un RXA o SSH y un Java Runtime Environment (JRE) instalado que cumpla los requisitos mínimos del servidor Liberty. Consulte Configuración de RXA para operaciones de colectivo de Liberty y Establecimiento de la variable JAVA_HOME para controladores y miembros del colectivo de Liberty.

Si el host de destino no tiene un JRE instalado con su variable JAVA_HOME y la variable del sistema PATH que proporciona una vía de acceso al JRE, el controlador de escalado puede instalar el JRE en el host de destino. El Paso 5b explica cómo crear un archivado de JRE, un instalable.

Multimedia Vea: El vídeo Configuración de un clúster escalable automáticamente para la elasticidad de Liberty muestra cómo configurar un clúster que se puede suministrar. [Transcripción]

Procedimiento

  1. Configure un colectivo para dar soporte a la elasticidad de la máquina virtual Java (JVM). Asegúrese de que el colectivo tenga al menos un miembro de clúster dinámico.

    Para obtener detalles sobre la configuración de controladores de escalado con miembros de clúster dinámicos, consulte Configuración de clústeres autoescalables para la elasticidad de JVM.

  2. Asegúrese de que cada miembro de clúster dinámico existente pertenezca a un clúster especificado con el convenio de denominación NombreGrupoPila.NombrePaquete.

    Los miembros de clúster dinámico y servidores existentes que el controlador de escalado suministrará serán miembros de este clúster. NombreGrupoPila es el nombre del directorio compartido que contendrá los instalables y paquetes que un controlador de escalado suministrará a los host de destino en función de las políticas de escalado. NombrePaquete es el nombre del paquete del servidor que el controlador de escalado suministrará a los hosts de destino.

    Para un clúster denominado myStackGroup.cluster1, coloque la sentencia siguiente en el archivo server.xml de cada miembro de clúster dinámico existente:

    <clusterMember name="myStackGroup.cluster1"/>

    Utilizará el nombre de clúster en los pasos 5c y 7 de este tema. En el paso 5c, utilizará cluster1.zip para el nombre de paquete de servidor. En el paso 7, creará el directorio myStackGroup para los instalables y paquetes que se desplegarán.

  3. Opcional: Añada políticas de escalado al controlador de escalado. Consulte la sección Definición de políticas de escalado.
  4. Registre cada host de destino con un controlador de escalado.

    El hecho de registrar un host permite al controlador de escalado transferir archivos a ese host, así como acceder a archivos, mandatos y otros recursos del host. Utilice el mandato registerHost para registrar un host de destino. Busque en el archivo server.xml del controlador de escalado los valores de los parámetros --host, --port, --user y --password. Para no utilizar un archivo de claves privado SSH, por ejemplo para los hosts de destino en los sistemas operativos Linux o Windows, incluya un usuario y una contraseña de inicio de sesión en el sistema operativo estableciendo los parámetros --rpcUser y --rpcUserPassword. El usuario especificado por --rpcUser debe tener derechos de sistema operativo sobre la ubicación de despliegue de destino.

    wlp/bin/collective registerHost targetHost --host=controllerHost --port=controllerHTTPSPort --user=controllerAdmin --password=controllerAdminPassword --rpcUser=osUser --rpcUserPassword=osUserPassword

    Para transferir archivos a los hosts de destino, no es necesario incluir un parámetro --hostWritePath en el mandato; el código de suministro de la pila establece automáticamente las vías de acceso de grabación. Si un host ya está registrado, puede utilizar el mandato updateHost para restablecer la información de registro. Para obtener más información, consulte Registro de sistemas principales con un colectivo de Liberty.

    Si el host de destino se encuentra en el mismo sistema que el host de controlador, debe ejecutar también el mandato updateHost para el host de controlador.

  5. Cree y configure instalables y paquetes que un controlador de escalado pueda desplegar en un host registrado.

    Un instalable es un archivo binario que la aplicación que desea instalar en un host registrado necesita para ejecutarse, por ejemplo, un tiempo de ejecución de Liberty o JRE. Un paquete es dicha aplicación empaquetada en un archivo comprimido.

    1. Cree un archivo de tiempo de ejecución de Liberty que contenga el directorio wlp, pero no el directorio usr. El convenio de denominación para este instalable es tipo.nombre.zip; por ejemplo, wlp.855.zip. Para crear un archivo de tiempo de ejecución de Liberty, tiene las opciones siguientes:
      • Ejecute el mandato package del servidor de Liberty con la opción --include=wlp; por ejemplo:
        wlp/bin/server package --include=wlp

        Para especificar un nombre de archivo y una ubicación de destino, añada la opción --archive=nombre_vía_acceso_archivo; por ejemplo:

        wlp/bin/server package --include=wlp --archive=c:\temp\wlp.855.zip

        Si no especifica un nombre de archivo o una ubicación de destino válidos con la opción --archive, el mandato crea el archivo de tiempo de ejecución wlp.zip en la ubicación $WLP_OUTPUT_DIR, que es el directorio ${wlp.install.dir}/usr/servers de forma predeterminada. La ubicación de destino debe existir antes de ejecutar el mandato. Por tanto, si la ubicación de destino es c:\temp, el directorio C:\temp debe existir y tener permiso de grabación sobre el mandato de grabación del archivo en el directorio C:\temp.

      • Ejecute el mandato package con la opción --include=all y, a continuación, suprima el directorio usr. El mandato package es parecido al siguiente:
        wlp/bin/server package myServer --include=all --archive=myArchive.zip
      • Cree un archivo comprimido (.zip) que contenga el directorio wlp, sin el directorio usr.

      Después de crear el archivo de tiempo de ejecución de Liberty, asegúrese de que el nombre de archivo sigue el convenio de denominación wlp.nombre.zip.

    2. Cree u obtenga archivos para el kit de desarrollo Java (JDK) y cualquier otro instalable necesario. El convenio de denominación para un instalables es tipo.nombre.zip; por ejemplo, jre.17.zip. Los valores de tipo válidos para los instalables son:
      • wlp para un tiempo de ejecución de Liberty.
      • jre para un entorno de tiempo de ejecución Java.
      • other para un tipo de archivo diferente. Este es el valor predeterminado.

      Por ejemplo, para crear un archivado para un JRE, cree un archivo comprimido (.zip) que contenga el contenido del directorio java de su instalación de IBM JRE. No incluya el directorio java, pero incluya todas las carpetas y archivos en el directorio java. Siga el convenio de denominación jre.nombre.zip cuando dé nombre al archivado.

    3. Para desplegar un servidor Liberty y aplicaciones, cree un archivo ZIP de paquete de servidor que contenga el servidor y las aplicaciones Liberty. El convenido de denominación de un paquete de servidor es nombre_paquete.zip; por ejemplo, cluster1.zip. Las opciones de creación de un paquete de servidor son:
      • Ejecutar el mandato package:
        wlp/bin/server package cluster1 --include=usr
        El mandato crea un paquete de servidor denominado, por ejemplo, C:\wlp\usr\servers\cluster1\cluster1.zip.
      • Ejecutar el mandato package con la opción --include=all y, a continuación, suprima el directorio wlp. El mandato package es parecido al siguiente:
        wlp/bin/server package cluster1 --include=all --archive=cluster1.zip
      • Crear un archivo comprimido (.zip) que contenga el directorio usr, sin el directorio wlp.

      Por ejemplo, para crear un paquete de servidor denominado cluster1.zip que conste de un servidor de Liberty autónomo con una única aplicación:

      1. Cree un servidor:
        wlp/bin/server create cluster1
      2. Copie una aplicación en el directorio dropins del servidor cluster1.
      3. Empaquete el servidor:
        wlp/bin/server package cluster1 --include=usr
      Se crea el archivo wlp/usr/servers/cluster1/cluster1.zip.
      Importante: Asegúrese de que el archivo server.env en el paquete tenga valores de entorno que sean válidos en los hosts de destino. Si JAVA_HOME está establecido, se debe establecer en una ubicación que exista en los hosts de destino para evitar despliegues fallidos.
      For Windows platformsNota: Para hosts de destino Windows, cree un archivo server.env que establezca JAVA_HOME en la ubicación de JRE en los hosts de destino. Después de ejecutar el mandato package, coloque server.env en el mismo directorio que el archivo server.xml en el ZIP del paquete del servidor. El contenido de server.env de ejemplo es:
      JAVA_HOME=C:\wlp.jre\jre.17.zip\jre
  6. Establezca un nombre de usuario y una contraseña para el controlador colectivo o el gestor de pilas en el archivo server.xml del gestor de escalado.
    <collectiveController user="adminUser"
    password="adminPassword" />
    o
    <stackManager controllerUser="adminUser" controllerUserPassword="adminPassword" />
  7. Coloque los instalables y paquetes en la ubicación WLP_STACK_GROUPS_DIR, que de forma predeterminada es $WLP_USER_DIR/shared/stackGroups.

    Los controladores de escalado supervisan las ubicaciones predeterminadas de instalables y paquetes del sistema de archivos y reaccionan dinámicamente a las actualizaciones. Si coloca los instalables y paquetes en las ubicaciones predeterminadas, no es necesario cambiar ninguno de los atributos predeterminados.

    Puede utilizar el grupo de pilas predeterminado, defaultStackGroup. También puede crear su propio subdirectorio de stackGroups, como por ejemplo myStackGroup, y añadirle los subdirectorios instalables y packages.

    wlp/usr
          /servers
          /shared
             ...
             /stackGroups
                /defaultStackGroup
                   /installables
                   /packages
                /myStackGroup
                   /installables
                   /packages

    Los controladores de escalado despliegan los instalables y paquetes en el host registrado y crean un servidor.

    Consejo: Se crea un nuevo servidor solo si la política de escalado está habilitada y requiere un nuevo servidor. Para forzar a un controlador de escalado a crear un nuevo servidor, ajuste el valor min y posiblemente el valor max de la política de escalado para el controlador de escalado. Por ejemplo, si el controlador de escalado no tiene una política de escalado y el colectivo tiene tres miembros de escalado, añada al archivo server.xml del controlador de escalado una política que fuerce al controlador de escalado a tener al menos cuatro miembros en ejecución:
    <scalingDefinitions>
       <defaultScalingPolicy enabled="true" min="4" max="6"/>
    </scalingDefinitions>

    El convenio de denominación de clústeres para la elasticidad de Liberty es NombreGrupoPila.NombrePaquete. Cuando se despliega una pila, <clusterMember name="StackGroupname.PackageName" se establece automáticamente en el archivo server.xml del servidor desplegado. El elemento <scalingPolicy> correspondiente incluye una sentencia <bind clusters="StackGroupName.Packagename"/>.

    Tabla 1. Ubicaciones predeterminadas de instalables y paquetes. Las variables de entorno de Liberty establecen los directorios de instalación predeterminados. Para alterar temporalmente las ubicaciones predeterminadas, consulte Personalizar el entorno Liberty.
    Archivo Directorio de instalación predeterminado
    Tipo de instalable wlp /wlp
    Tipo de instalable jre /wlp/jre
    Tipo de instalable other /wlp/other
    Paquete /wlp/usr
  8. Examine los atributos de configuración para grupos de pilas e instalables y cambie las configuraciones de los grupos de pilas e instalables según sea necesario para definir cuándo y dónde se ejecuta el suministro de Liberty. Puede que sea necesario alterar temporalmente las configuraciones predeterminadas.

    Altere temporalmente las configuraciones predeterminadas estableciendo valores nuevos en los elementos stackGroup e installable del archivo server.xml del controlador de escalado. Consulte Controlador de escalado para obtener información sobre los elementos stackGroup y installable.

    A continuación se muestran algunas sugerencias para alterar temporalmente los valores predeterminados para algunos elementos:

    • El elemento installable define un instalable para un grupo de pilas. El elemento installable puede ser un elemento hijo del elemento stackGroup o un hermano referenciado por un elemento hijo installableRef del elemento stackGroup.
      Los ejemplos siguientes muestran cómo cambiar los valores del archivo server.xml del controlador de escalado para alterar temporalmente el valor predeterminado para el atributo installable de un grupo de pila:
      <stackGroup name="myStackGroup">
         <installable name="wlp.v8555.zip" sourceDir="c:\myStackGroup\installables"/>
      </stackGroup>
      o
      <stackGroup name="myStackGroup" installDir="/myInstallDir" installableRef="myInstallable1, myInstallable2"/>
      <installable name="wlp.v8555.zip" id="myInstallable1" sourceDir="c:\myStackGroup\installablesOne" />
      <installable name="jre.v1.6.zip" id="myInstallable2" sourceDir="c:\myStackGroup\installablesTwo"/>
    • El elemento hijo deployVariable especifica una variable de sustitución que se inyecta en la pila desplegada. Puede especificar que la variable de sustitución se incremente automáticamente cada vez que se despliegue la pila. Por ejemplo, utilice un atributo deployVariable para especificar un valor de número de puerto inicial e incrementar el valor en cada despliegue. El objetivo de deployVariable en esta situación es evitar conflictos de puerto en el host de destino. El elemento deployVariable utiliza aritmética en el archivo server.xml del servidor desplegado para obtener el número de puerto de tiempo de ejecución.

      Por ejemplo, para definir un valor de punto de inicio y la cantidad de incremento:

      1. Establezca httpPort="${http.port}" en el elemento httpEndpoint del archivo server.xml del servidor empaquetado:
        <httpEndpoint ... httpPort="${http.port}" />
      2. Añada una definición deployVariable que establezca el punto de inicio y los valores de incremento en el archivo server.xml del controlador de escalado:
        <stackGroup name="DefaultStackGroup" installDir="">
          <deployVariable name="http.port" value="9080" increment="1"/>
        </stackGroup>

      A continuación, cada vez sucesiva que la pila se despliega en el host, el valor httpPort se incrementa en 1. Por lo tanto, la primera vez que la pila se despliega en host1, el elemento de punto final HTTP es el siguiente:

      <httpEndpoint ... httpPort="9080" />

      y la segunda vez que la pila se despliega en host1, el elemento es:

      <httpEndpoint ... httpPort="9081" />

      En cuanto al atributo deployVariable, el valor predeterminado para valor es null. El valor predeterminado para increment es 0 (cero).

      Si se especifica deployVariable en el archivo server.xml del controlador de escalado, el número de puerto de tiempo de ejecución de un servidor desplegado es la serie value de puerto inicial incrementada con el entero increment.

    • Si el archivo server.xml del controlador de escalado define el grupo de pila de la forma siguiente, no defina de nuevo httpPort en el archivo bootstrap.properties para el directorio del servidor con el que crea un paquete de servidor. Si lo hace, se utilizará el valor httpPort definido en bootstrap.properties, no el generado por el elemento de configuración deployVariable.
      <stackGroup name="DefaultStackGroup" installDir="">
        <deployVariable name="http.port" value="9080" increment="1"/>
      </stackGroup>
  9. Opcional: Cambie el intervalo con el que el controlador de escalado comprueba si existen adiciones, actualizaciones y supresiones de grupo de pilas en el sistema de archivos.

    El controlador de escalado explora el contenido del directorio stackGroups y sus subdirectorios para ver si hay cambios. Los cambios de contenido pueden hacer que el controlador suministre clústeres que anteriormente no tenían paquetes disponibles. La actualización de los paquetes no hace que el controlador suministre de nuevo clústeres existentes.

    De forma predeterminada, el controlador explora la ubicación WLP_STACK_GROUPS_DIR cada 5000 milisegundos (cinco segundos). Para cambiar el intervalo de exploración o inhabilitar la exploración, establezca valores nuevos para los atributos del gestor de pila scanningInterval y scanningEnable en el archivo server.xml del controlador de escalado. Por ejemplo, para establecer el intervalo de exploración en seis segundos y habilitar la exploración, añada una sentencia parecida a la siguiente al archivo server.xml del controlador de escalado:

    <stackManager groupsDir="${wlp.install.dir}/usr/shared/stackGroups/"
                  controllerUser="adminUser" controllerUserPassword="adminPassword"
                  scanningInterval="6000" scanningEnable="true">
    </stackManager>

    Para inhabilitar la exploración, establezca scanningEnable en false.

  10. Opcional: Indique al controlador de escalado que debe explorar el sistema de archivos para detectar nuevas adiciones, actualizaciones y supresiones de grupo de pilas.

    Ejecute una operación del MBean StackManager para obligar al controlador de escalado a comprobar si en la ubicación WLP_STACK_GROUPS_DIR existen adiciones, actualizaciones y supresiones de grupo de pilas. Aunque el archivo server.xml del controlador de escalado especifique scanningEnable="false", puede ejecutar una operación del MBean StackManager para forzar una exploración de adiciones, actualizaciones y supresiones.

    Consulte Lista de MBeans proporcionados para obtener información acerca del MBean StackManager.

  11. Opcional: Inicie IHS para habilitar el direccionamiento a los servidores.

    Para que IBM HTTP Server (IHS) descubra y direccione a aplicaciones web en clústeres suministrados dinámicamente, habilite el direccionamiento dinámico en el host donde residirá el controlador de escalado. IHS recuperará la información de direccionamiento para los servidores suministrados a partir del servicio de direccionamiento dinámico. Si el estado del servidor es habilitado, puede visualizar la información de direccionamiento.

    Si no tiene IHS instalado, consulte Configuración del direccionamiento dinámico para los colectivos de Liberty. Además, el vídeo siguiente muestra cómo instalar soporte para el direccionamiento dinámico mediante IBM Installation Manager:

    Multimedia Vea: El vídeo Enabling IHS for Liberty Dynamic Routing muestra cómo instalar IHS, instalar el plug-in de servidor web para WebSphere Application Server y aplicar el arreglo temporal para el direccionamiento dinámico. [Transcripción]


Icono que indica el tipo de tema Tema de tarea

Nombre de archivo: twlp_autoscale_configlibertyelast.html