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
- 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.
- Comparta un servidor web entre varias instancias de instalación.
- Utilice el asistente de instalación de plug-in para seleccionar un
plug-in de servidor web.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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
- 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 archivo
portprops 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.