Configuración de instalaciones de producto coexistentes

Puede instalar WebSphere Application Server para que coexista con otra instancia de instalación de producto, siempre que no haya puertos en conflicto. Al instalar instalaciones coexistentes, puede compartir un único servidor web.

Acerca de esta tarea

Cada instalación del producto tiene su propio conjunto de archivos de configuración exclusivos.

Gestión de perfiles mediante la interfaz gráfica de usuario describe la instalación de WebSphere Application Server una vez y la creación de varios perfiles.

Procedimiento

  1. Utilice el IBM Installation Manager para instalar otra instancia de WebSphere Application Server.

    Si tiene previsto compartir un único servidor web entre instalaciones, instale el plug-in del servidor web Versión 9.0 apropiado.

    Si desea más información, consulte Instalación y configuración del entorno de servicio a aplicaciones.

  2. Comparta un servidor web entre varias instancias de instalación.
    1. Utilice el asistente de instalación de plug-in para seleccionar un plug-in de servidor web.
    2. Utilice la consola administrativa para generar los archivos de configuración de plug-in para cada instancia de instalación y fusiónelos en una configuración primaria.
    3. Utilice la consola administrativa para sustituir el archivo plugin-cfg.xml original por el archivo primario del servidor web.
    Se puede acceder a los ejemplos sólo desde una de las instancias de instalación.
  3. Si un nodo no se puede iniciar debido a conflictos de puertos, cambie las asignaciones de puerto en los archivos de configuración.

    Para obtener más información, consulte Valores de número de puerto.

    Nota: Si los puertos ya están definidos en una configuración que está migrando, las herramientas de migración arreglan los conflictos de puerto en la configuración de Versión 9.0 y registran los cambios para la verificación.
  4. Evite conflictos de puertos en los agentes de nodo coexistentes.

    Si crea un nodo federado en el mismo sistema donde existe otro nodo federado, el mandato addNode aumenta las asignaciones de puerto en el segundo proceso de agente de nodo, para que no se produzca ningún conflicto. La herramienta de gestión de perfiles también gestiona las asignaciones de puerto correctamente cuando se federa un nodo personalizado durante la creación del perfil personalizado.

    Si instala un producto Versión 9.0 en un sistema donde está instalada una versión anterior del producto, ni el mandato addNode, ni la herramienta Gestión de perfiles tiene un registro de las asignaciones de puerto de la versión anterior. Las asignaciones de puerto del segundo proceso de agente de nodo de la Versión 9.0 no se incrementan. Se producen conflictos que impiden que se inicien varios nodos.

    Realice el procedimiento siguiente para crear un nodo federado de la Versión 9.0 sin que existan conflictos de puerto.

    1. Cree un perfil de servidor de aplicaciones de Versión 9.0 o el perfil personalizado.

      No federe el nodo cuando cree el perfil. Seleccione el recuadro de selección en el panel de la herramienta de gestión de perfiles que especifica que federará el nodo más adelante.

    2. Compruebe los puertos que están en uso para determinar el primer número de puerto para el proceso de agente de nodo de la Versión 9.0.

      Utilice el mandato netstat -a para comprobar las asignaciones de puerto existentes. Analice las asignaciones de puerto para determinar 12 puertos secuenciales.

      En este procedimiento se presupone que no existen asignaciones de puerto entre los puertos 3320 y 3380.

    3. Vaya al directorio bin del nuevo perfil.

      Suponga que crea un perfil de servidor de aplicaciones llamado V90MngNode en el directorio raíz de instalación predeterminado en un sistema Linux.

      cd /opt/IBM/WebSphere/AppServer/profiles/V90MngdNode/bin
    4. Utilice el mandato addNode con el parámetro -startingport para federar el nodo en la célula del gestor de despliegue y para asignar puertos a partir de un valor de inicio.
      Supongamos que el gestor de despliegue tiene las características siguientes:
      • El nombre de host es la dirección del sistema de nombres de dominio: nittany.ibm.raleigh.com
      • Tipo de conector JMX es: RMI (invocación a método remoto)
      • Asignación de puerto RMI: 8879
      • Estado de seguridad: Habilitado
      • Aplicaciones por instalar: DefaultApplication y los ejemplos
      En un entorno Linux, por ejemplo, ejecute el mandato siguiente:
      ./addNode.sh nittany.ibm.raleigh.com \
      -conntype RMI 8879 \
      -includeapps \
      -user lions44 \
      -password PSU
      -startingport 3333

      El carácter \ es un carácter de continuación para utilizar más de una línea para enviar mandatos.

    El parámetro -startingport proporciona el número de puerto base para todos los puertos de agente de nodo y aumenta todos los valores de puerto a partir del punto de inicio. Las asignaciones de puertos sin conflictos permiten la ejecución del nuevo agente de nodo cuando el proceso del agente de nodo ya se está ejecutando.

    Este procedimiento genera la capacidad de iniciar el nodo anterior a la vez que el nodo de Versión 9.0. Los agentes de nodo pueden ejecutarse en el mismo servidor.

    También puede asignar puertos individualmente estableciendo el parámetro -portprops. El parámetro identifica un archivo de texto que contiene palabras clave y asignaciones de números de puerto que deben crearse. El siguiente ejemplo de un archivoportprops muestra todas las palabras clave y sus asignaciones de puerto predeterminado:
    WC_defaulthost 9081
    WC_adminhost 9062
    WC_defaulthost_secure 9444
    WC_adminhost_secure 9045
    BOOTSTRAP_ADDRESS 2810
    SOAP_CONNECTOR_ADDRESS 8881
    SAS_SSL_SERVERAUTH_LISTENER_ADDRESS 9901
    CSIV2_SSL_SERVERAUTH_LISTENER_ADDRESS 9201
    CSIV2_SSL_MUTUALAUTH_LISTENER_ADDRESS 9102
    ORB_LISTENER_ADDRESS 9900
    CELL_DISCOVERY_ADDRESS 7272
    DCS_UNICAST_ADDRESS 9354

Qué hacer a continuación

Tras migrar un gestor de despliegue de Versión 7.0 o posterior a un gestor de despliegue de Versión 9.0, puede migrar los nodos federados de Versión 7.0 o posterior de forma incremental. Para obtener más información, consulte Migración de un nodo federado de Versión 7.0 o posterior.


Icon that indicates the type of topic Task topic



Timestamp icon Last updated: last_date
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-dist&topic=tmig_6coexist70
File name: tmig_6coexist70.html