Configuración de un colectivo de Liberty

Puede organizar servidores Liberty en colectivos para soportar la agrupación en clústeres, la administración y otras operaciones que actúan en varios servidores Liberty. Mediante la utilización de colectivos, puede entregar de forma eficiente y precisa servicios de aplicación a la organización.

Antes de empezar

Instale Liberty con las características administrativas. Para instrucciones de instalación, consulte la sección "Antes de empezar" de Configuración del entorno de gestión del servidor para Liberty mediante el uso de colectivos. Las características administrativas de Liberty proporcionan características de gestión multiservidor para colectivos, clústeres, escalado, direccionamiento dinámico y Centro de administración.

For distributed platformsFor IBM i platformsLa característica collectiveController-1.0 y sus prestaciones solamente están disponibles en WebSphere Application Server Network Deployment Liberty y WebSphere Application Server for z/OS Liberty. La característica no está disponible en WebSphere Application Server Liberty o WebSphere Application Server Liberty Core. Si tiene una instalación de WebSphere Application Server Network Deployment Liberty, puede utilizar su característica collectiveController-1.0 para trabajar con miembros de colectivos de instalaciones de WebSphere Application Server Liberty o WebSphere Application Server Liberty Core.

Acerca de esta tarea

Un colectivo de Liberty es un conjunto de servidores Liberty que se configuran como parte del mismo dominio administrativo y operativo.

Los datos de configuración y estado sobre un colectivo de Liberty se alojan en un repositorio operativo activo.

La pertenencia a un colectivo de Liberty es opcional. Los servidores Liberty se unen a un colectivo registrándose con un controlador colectivo para convertirse en miembros. Los miembros comparten información sobre sí mismos a través del repositorio operativo del controlador.

Se aplican las reglas siguientes:
  • Un servidor Liberty solo puede ser miembro de un único colectivo.
  • Los distintos servidores Liberty en el mismo host pueden estar en distintos colectivos.
  • Los servidores Liberty en el mismo host que son miembros de un colectivo pueden coexistir con servidores Liberty que no sean miembros de un colectivo.
  • Todos los miembros de un colectivo deben estar en el mismo centro de datos. Un colectivo no debe abarcar varios centros de datos.

Multimedia Vea: el Vídeo: Introducción a la creación de un colectivo muestra el procedimiento. Este vídeo, así como otra información sobre colectivos, está disponible en el Sito web de WASdev. [Transcripción]

Procedimiento

  1. Cree y configure el controlador.
    1. Cree un servidor que actúe de controlador colectivo.
      wlp/bin/server create myController
    2. Cree la configuración del controlador colectivo.

      La configuración del controlador colectivo consta principalmente de la configuración de seguridad de dominio administrativo que se utiliza para una comunicación segura entre controladores y miembros.

      wlp/bin/collective create myController --keystorePassword=controllerKSPassword
      De forma predeterminada, este mandato de colectivo escribe toda la salida en una pantalla de la consola. En el siguiente paso, copie la salida de configuración en server.xml. Para escribir la configuración en un archivo, en lugar de en una pantalla de consola, especifique un parámetro --createConfigFile=vía_acceso_archivo_salida, por ejemplo:
      wlp/bin/collective create myController --keystorePassword=controllerKSPassword --createConfigFile=c:/wlp/usr/servers/myController/collective-create-include.xml
      Después de ejecutar el mandato create, se visualiza la sentencia include que debe utilizarse. Para incluir el archivo de salida en la configuración de colectivo, añada la sentencia include al archivo server.xml en el ejemplo siguiente:
      <include location="c:\wlp\usr\servers\myController\collective-create-include.xml" />
    3. Actualice el archivo server.xml del controlador colectivo.
      • Copie y pegue la salida.

        Si el mandato ha escrito la salida en una pantalla de la consola, continúe con los pasos siguientes.

        1. Copia la salida del mandato colectivo y péguela en el archivo server.xml.
        2. Especifique los valores de ID de usuario administrativo y contraseña para el colectivo. Por ejemplo, cambie:
          <quickStartSecurity userName="" userPassword="" />
          por:
          <quickStartSecurity userName="adminUser" userPassword="adminPassword" />
        La vía de acceso predeterminada del archivo server.xml del controlador colectivo es ${wlp.install.dir}/usr/servers/myController/server.xml o, si la variable $WLP_USER_DIR está establecida en una ventana de mandatos o archivo server.env, $WLP_USER_DIR/servers/myController/server.xml. Después de editarlo, el archivo será parecido al ejemplo siguiente:
        <server description="controller server">
        
            <!-- Habilitar las características -->
        
            <featureManager>
                <feature>jsp-2.2</feature>
            </featureManager>
        
            <httpEndpoint id="defaultHttpEndpoint"
                          host="*"
                          httpPort="9080"
                          httpsPort="9443" />
        
            <featureManager>
                <feature>collectiveController-1.0</feature>
            </featureManager>
        
            <!-- Defina el nombre de host que vaya a utilizar el colectivo. 
            Si se debe cambiar el nombre de host, el servidor debe
            eliminarse del colectivo y volverse a unir o replicarse. -->
        
            <variable name="defaultHostName" value="nombreHostControlador" />
        
            <!-- TODO: Establezca la configuración de seguridad para acceso administrativo -->
        
            <quickStartSecurity userName="adminUser" userPassword="adminPassword" />
        
            <!-- clientAuthenticationSupported establecido para habilitar la confianza bidireccional -->
        
            <ssl id="defaultSSLConfig"
                 keyStoreRef="defaultKeyStore"
                 trustStoreRef="defaultTrustStore"
                 clientAuthenticationSupported="true" />
        
            <!-- almacén de claves de entrada (HTTPS) -->
            <keyStore id="defaultKeyStore" password="suContraseña"
                      location="${server.config.dir}/resources/security/key.jks" />
        
            <!-- almacén de confianza de entrada (HTTPS) -->
            <keyStore id="defaultTrustStore" password="suContraseña"
                      location="${server.config.dir}/resources/security/trust.jks" />
        
            <!-- almacén de claves de identidad de servidor -->
            <keyStore id="serverIdentity" password="suContraseña"
                      location="${server.config.dir}/resources/collective/serverIdentity.jks" />
        
            <!-- almacén de claves de confianza de colectivo -->
            <keyStore id="collectiveTrust" password="suContraseña"
                      location="${server.config.dir}/resources/collective/collectiveTrust.jks" />
        
            <!-- almacén de claves de firmantes raíz de colectivo -->
            <keyStore id="collectiveRootKeys" password="suContraseña"
                      location="${server.config.dir}/resources/collective/rootKeys.jks" />
        </server>
      • Añada una sentencia include.
        Si ha escrito la salida en un archivo utilizando el parámetro --createConfigFile=vía_acceso_archivo_salida, añada una declaración include a $WLP_USER_DIR/servers/myController/server.xml para incluir un archivo de salida en la configuración del colectivo. Después de editarlo, el contenido del archivo será parecido al ejemplo siguiente:
        <server description="controller server">
        
            <!-- Habilitar las características -->
        
            <featureManager>
                <feature>jsp-2.2</feature>
            </featureManager>
        
            <httpEndpoint id="defaultHttpEndpoint"
                          host="*"
                          httpPort="9080"
                          httpsPort="9443" />
        
            <include location="c:\wlp\usr\servers\myController\collective-create-include.xml" />
        
        </server>
        Asegúrese de que el archivo de salida establece los valores de ID de usuario administrativo y contraseña para el colectivo como en el ejemplo siguiente:
        <quickStartSecurity userName="adminUser" userPassword="adminPassword" />
    4. Inicie el servidor de controlador colectivo.
      wlp/bin/server start myController
      Figura 1. Colectivo de uno
      Colectivo de uno
    5. Verifique que el servidor del controlador colectivo se ha iniciado correctamente y está preparado para recibir miembros.
      1. Abra un editor en registro de mensajes del controlador colectivo, $WLP_USER_DIR/servers/myController/logs/messages.log.
      2. Busque este mensaje:
        CWWKX9003I: El MBean CollectiveRegistration está disponible.
  2. Cree y configure un miembro para unirlo al colectivo.

    El controlador y los miembros pueden estar en distintos hosts. En este ejemplo, el controlador y el miembro están en el mismo host.

    1. Cree un servidor miembro.
      wlp/bin/server create myMember
    2. Una al miembro.

      Ejecute el mandato join de colectivo para unir el servidor al colectivo como miembro. Ejecute el mandato join desde la instalación de Liberty en el host miembro.

      El mandato join requiere una conexión de red con el controlador colectivo y un ID de usuario administrativo y la contraseña para realizar operaciones de MBean en el controlador. Busque en el archivo server.xml del controlador colectivo los valores de los parámetros --host, --port, --usery --password. Para --keystorePassword, establezca un valor que se utilizará como contraseña del almacén de claves del miembro, como por ejemplo memberKSPassword. Puede especificar diferentes valores de --keystorePassword diferentes para cada servidor que se una al colectivo.

      wlp/bin/collective join myMember --host=nombreHostControlador --port=9443 --user=adminUser --password=adminPassword --keystorePassword=memberKSPassword

      El parámetro opcional --hostname especifica el nombre de host que se utilizará para el sistema. Establezca --hostname sólo si el sistema tiene varios nombres de host o no tiene su nombre de host configurado. Si se establece, el valor debe coincidir con la variable defaultHostName definida en el archivo server.xml.

      [18.0.0.1 and later]Para reducir el número de opciones necesarias, utilice la opción --controller en lugar de --user, --password, --host y --port.

      wlp/bin/collective join myMember 
      --controller=usuario[:contraseña]@host:PuertoHttps
      --keystorePassword=memberKSPassword

      Puede especificar variables de despliegue mediante el parámetro opcional genDeployVariable. Para obtener más información, consulte Generación de variables de despliegue al unir un servidor miembro a un colectivo.

      Para grabar la salida de este mandato de colectivo en un archivo, en lugar de escribirlo en una pantalla de la consola, especifique un parámetro --createConfigFile=vía_acceso_archivo_salida opcional. A continuación, incluya el archivo de salida en la configuración de colectivo añadiendo una sentencia include al archivo server.xml del miembro.
      <include location=vía_acceso_archivo_salida />

      De forma predeterminada, la operación join deja sin definir las credenciales de llamada a procedimiento remoto (RPC). Debe especificar valores para rpcUser, rpcUserPassword y el usuario y la contraseña de inicio de sesión en el sistema operativo del host en el que reside el servidor miembro. Si el host miembro está registrado en el controlador colectivo y el host miembro no está habilitado para SSH, especifique un parámetro --useHostCredentials opcional para permitir que el miembro herede las credenciales RPC de su registro de host en el controlador. Normalmente, los hosts Linux están habilitados para SSH y los hosts Windows no están habilitados para SSH; por lo tanto, el parámetro --useHostCredentials es útil para los hosts de miembro de Windows. La especificación de --useHostCredentials añade <hostAuthInfo useHostCredentials="true" /> al archivo server.xml del miembro. A continuación, puede ejecutar mandatos de servidor miembro de colectivo como start o stop sin especificar credenciales RPC, ya que el miembro hereda las credenciales de su host. Consulte Alteración temporal de información de host de servidor de Liberty para obtener información acerca de hostAuthInfo, el parámetro --useHostCredentials y la conexión del controlador colectivo al servidor. Consulte Configuración de RXA para operaciones de colectivo de Liberty para obtener información sobre cómo habilitar SSH en el sistema host.

      Para obtener información sobre estos parámetros obligatorios y sobre los parámetros opcionales, ejecute collective help join en una línea de mandatos.

    3. Si se le solicita que acepte la cadena de certificados, especifique y (sí).
    4. Actualice el archivo server.xml del miembro.
      • Copie y pegue la salida.

        Si el mandato ha escrito la salida en una pantalla de la consola, continúe con los pasos siguientes:

        1. Copia la salida del mandato colectivo y péguela en el archivo server.xml del miembro.
        2. Modifique los puertos de modo que el servidor pueda abrir sus puertos HTTP. Asegúrese de que el archivo server.xml del miembro números de puerto HTTP exclusivos en su host. Por ejemplo, si el miembro se encuentra en el mismo host que el controlador colectivo, cambie los números de puerto HTTP:
          <httpEndpoint id="defaultHttpEndpoint" httpPort="9081" httpsPort="9444" />
          De forma opcional, para acceder al servidor miembro desde un cliente remoto, establezca también host="*" en el elemento httpEndpoint.
        Después de editarlo, el archivo $WLP_USER_DIR/servers/myMember/server.xml será similar al ejemplo siguiente:
        <server description="member server">
        
            <!-- Habilitar las características -->
        
            <featureManager>
                <feature>jsp-2.2</feature>
            </featureManager>
        
            <httpEndpoint id="defaultHttpEndpoint"
                          host="*"
                          httpPort="9081"
                          httpsPort="9444" />
        
            <featureManager>
                <feature>collectiveMember-1.0</feature>
            </featureManager>
        
            <!-- Defina el nombre de host que vaya a utilizar el colectivo.
            Si se debe cambiar el nombre de host, el servidor debe
            eliminarse del colectivo y volverse a unir o replicarse. -->
        
            <variable name="defaultHostName" value="nombreHostMiembro" />
        
        <!-- Configuración de autenticación de host remoto -->
            <hostAuthInfo rpcUser="id_usuario_admin" rpcUserPassword="contraseña_usuario_admin" />
        
            <!-- Conexión al controlador colectivo -->
            <collectiveMember controllerHost="nombreHostControlador"
                              controllerPort="9443" />
        
            <!-- clientAuthenticationSupported establecido para habilitar la confianza bidireccional -->
        
            <ssl id="defaultSSLConfig"
                 keyStoreRef="defaultKeyStore"
                 trustStoreRef="defaultTrustStore"
                 clientAuthenticationSupported="true" />
        
            <!-- almacén de claves de entrada (HTTPS) -->
            <keyStore id="defaultKeyStore" password="suContraseña"
                      location="${server.config.dir}/resources/security/key.jks" />
        
            <!-- almacén de confianza de entrada (HTTPS) -->
            <keyStore id="defaultTrustStore" password="suContraseña"
                      location="${server.config.dir}/resources/security/trust.jks" />
        
            <!-- almacén de claves de identidad de servidor -->
            <keyStore id="serverIdentity" password="suContraseña"
                      location="${server.config.dir}/resources/collective/serverIdentity.jks" />
        
            <!-- almacén de confianza de colectivo -->
            <keyStore id="collectiveTrust" password="suContraseña"
                      location="${server.config.dir}/resources/collective/collectiveTrust.jks" />
        </server>
      • Añada una sentencia include.
        Si ha escrito la salida en un archivo utilizando el parámetro --createConfigFile=vía_acceso_archivo_salida, añada una sentencia include a $WLP_USER_DIR/servers/myMember/server.xml para incluir el archivo de salida como en el ejemplo siguiente:
        <server description="member server">
        
            <!-- Habilitar las características -->
        
            <featureManager>
                <feature>jsp-2.2</feature>
            </featureManager>
        
            <httpEndpoint id="defaultHttpEndpoint"
                          host="*"
                          httpPort="9081"
                          httpsPort="9444" />
        
            <include location="c:\wlp\usr\servers\myMember\collective-join-include.xml" />
        
        </server>
    5. Si no ha especificado --useHostCredentials en el mandato join y el host miembro no está habilitado para SSH, establezca las credenciales RPC para hostAuthInfo en el archivo server.xml de miembro o en el archivo de salida. Puede establecer credenciales RPC para el servidor miembro de dos formas:
      • Establezca los valores de usuario y contraseña RPC en hostAuthInfo. Establezca rpcUser en un ID de usuario de inicio de sesión en el sistema operativo del host en el que reside el servidor miembro, y establezca rpcUserPassword en la contraseña de inicio de sesión en el sistema operativo para el ID de usuario. Por ejemplo, si inicia la sesión en el sistema miembro con el usuario test1 y la contraseña test1pwd, cambie el elemento hostAuthInfo:
        <hostAuthInfo rpcUser="test1" rpcUserPassword="test1pwd" />
      • Si el host miembro está registrado con el controlador colectivo, establezca hostAuthInfo useHostCredentials en true para que el servidor miembro herede las credenciales RPC de su host.
        <hostAuthInfo useHostCredentials="true" />

      Consulte Alteración temporal de información de host de servidor de Liberty para obtener información acerca de los valores de hostAuthInfo y para obtener un ejemplo que muestra cómo registrar un host miembro y ejecutar el mandato unión con --useHostCredentials.

    6. For z/OS platformsSolo para z/OS, emita el mandato updateHost para especificar el directorio JAVA_HOME del miembro para el controlador.
      wlp/bin/collective updateHost controllerHostname --host=controllerHostname
      --port=9443 --user=adminUser --password=adminPassword
      --hostWritePath=/dir1 --rpcUser=rpcUser
      --rpcUserPassword=rpcUserPassword --hostJavaHome=JAVA_HOME

      [18.0.0.1 and later]Para reducir el número de opciones necesarias, utilice la opción --controller en lugar de --user, --password, --host y --port:

      wlp/bin/collective updateHost controllerHostname 
      --controller=adminUser:adminPassword@controllerHostname:9443
      --hostWritePath=/dir1 --rpcUser=rpcUser
      --rpcUserPassword=rpcUserPassword --hostJavaHome=JAVA_HOME

      El parámetro hostWritePath especifica los directorios en los cuales el controlador colectivo puede escribir. Las vías de acceso especificadas por el parámetro también son legibles.

      hostWritePath

      El parámetro hostJavaHome especifica la vía de acceso absoluta a dónde está la JVM en el sistema y dónde se ejecuta el servidor miembro, por ejemplo: /usr/lpp/java/java_1.7_64.

      Si desea más información sobre la especificación de JAVA_HOME, consulte Establecimiento de la variable JAVA_HOME para controladores y miembros del colectivo de Liberty.

    7. Inicie el servidor miembro.
      wlp/bin/server start myMember
      Figura 2. Colectivo simple
      Colectivo simple
    8. Verifique que el servidor miembro se ha iniciado correctamente y está publicando información en el controlador.
      1. Abra un editor en el registro de mensajes de miembros $WLP_USER_DIR/servers/myMember/logs/messages.log.
      2. Busque los mensajes siguientes en cualquier orden:
        CWWKX8112I: La información de host del servidor se ha publicado
        satisfactoriamente en el repositorio de colectivo.
        CWWKX8114I: Las vías de acceso del servidor se han publicado satisfactoriamente en el repositorio de colectivo.
        CWWKX8116I: El estado de servidor INICIADO se ha publicado satisfactoriamente en el repositorio de colectivo.
    9. Opcional: [18.0.0.1 and later]Utilice el mandato testConnection para validar la conectividad. El mandato valida la conectividad RXA entre el controlador y el host donde reside el miembro. También valida la conectividad segura JMX entre el controlador colectivo y el miembro de colectivo.
      wlp/bin/collective testConnection nombreHost,víaAccesoDirUsr,nombreServidor  --host=hostControlador
      --port=puertoHTTPScontrolador --user=adminControlador 
      --password=contraseñaAdminControlador--autoAcceptCertificates
      Donde nombreHost,víaAccesoDirUsr,nombreServidor es la tupla que describe el servidor miembro que se acaba de unir: nombreHost es el nombre del host donde reside el miembro de colectivo. víaAccesoDirUsuario es el directorio de usuario del miembro de colectivo.nombreServidor es el nombre del miembro de colectivo.
      [18.0.0.1 and later]Como alternativa, utilice la opción --controller simplificada para proporcionar la información específica de controlador.
      wlp/bin/collective testConnection nombreHost,víaAccesoDirUsuario,nombreServidor
      --controller=usuario[:contraseña]@host:PuertoHttps
      --autoAcceptCertificates

Icono que indica el tipo de tema Tema de tarea

Nombre de archivo: tagt_wlp_configure_collective.html