addNode (mandato)
El mandato addNode incorpora una instalación de servidor de aplicaciones en una célula.
En función del tamaño y de la ubicación del nodo nuevo que incorpora a la célula, puede llevar unos minutos completar este mandato.
Debe tener los privilegios de administrador para utilizar la función addNode.
El perfil de usuario debe tener la autoridad *ALLOBJ o debe tener autorización para leer y ejecutar el script addNode de Qshell.
El servidor de agente de nodo se inicia automáticamente como parte del mandato addNode, a menos que especifique la opción -noagent. Si recicla el sistema que aloja un nodo de servidor de aplicaciones y no ha configurado el agente de nodo para actuar como daemon de sistema operativo, debe emitir un mandato startNode para iniciar el agente de nodo antes de iniciar cualquier servidor de aplicaciones.
Cuando se ejecuta el mandato addNode, el mandato detiene el servidor de aplicaciones en ejecución que se está incorporando en una célula. Opcionalmente puede detener el servidor de aplicaciones antes de ejecutar el mandato addNode.
Antes de añadir un nodo a una célula, se eliminarán los servicios Windows existentes que están asociados a servidores, cuando ejecute un mandato addNode. Si elimina el nodo de la célula más adelante, los servicios Windows no se volverán a crear automáticamente para los servidores base. Consulte la información sobre el mandato WASService para crear un servicio Windows para el producto.
- Los puertos generados para el agente de nodo son exclusivos para todos los perfiles en la instalación. A efectos de desarrollo, puede crear varios perfiles en la misma instalación y añadirlos a una o más células sin preocuparse de que existan conflictos entre los puertos.
- Si desea especificar los puertos que utiliza el agente de nodo, especifíquelos en un archivo con el nombre de archivo pasado con la opción -portprops. El formato del archivo es pares de clave valor uno en cada línea, siendo la clave la misma que el nombre del puerto en el archivo en el archivo serverindex.xml.
- Si desea utilizar un número de puertos secuenciales, considere la opción -startingport. Esto significa que no se detectan los conflictos de puerto con otros perfiles.

Consulte el tema sobre cómo utilizar las herramientas de línea de mandatos para determinar si se ha de ejecutar el mandato desde el perfil o desde el directorio raíz del servidor de aplicaciones.
Sintaxis
Observe la sintaxis del mandato:
![[AIX Solaris HP-UX Linux Windows]](../images/dist.gif)
![[z/OS]](../images/ngzos.gif)
addNode dmgr_host [dmgr_port] [-conntype type] [-includeapps] [-includebuses]
[-startingport númeropuerto] [-portprops nombre_cualificado]
[-nodeagentshortname nombre] [-nodegroupname nombre] [-registerservice]
[-serviceusername nombre] [-servicepassword contraseña] [-coregroupname nombre]
[-noagent] [-statusport 1231] [-quiet] [-nowait] [-logfile nombre_archivo]
[-replacelog] [-trace] [-username uid] [-password contraseña]
[-localusername lUID_local] [-localpassword contraseña_local] [-profileName nombre_perfil]
[-excludesecuritydomains true | false] [-asExistingNode] [-help]
![[IBM i]](../images/iseries.gif)
addNode dmgr_host [dmgr_port] [-conntype type] [-includeapps] [-includebuses name]
[-startingport númeropuerto] [-portprops nombre_cualificado]
[-nodeagentshortname nombre] [-nodegroupname nombre] [-registerservice]
[-serviceusername nombre] [-servicepassword contraseña] [-coregroupname nombre]
[-noagent] [-statusport puerto] [-quiet] [-nowait] [-logfile nombre_archivo]
[-replacelog] [-trace] [-username uid] [-password contraseña]
[-localusername lUID_local] [-localpassword contraseña_local] [-profileName nombre_perfil]
[-excludesecuritydomains true | false] [-asExistingNode] [-help]
Es necesario el argumento dmgr_host. Todos los demás argumentos son opcionales. El número de puerto predeterminado es 8879 para el puerto SOAP del gestor de despliegue. SOAP es el tipo de conector JMX (Java™ Management Extensions) del mandato. Si tiene varias instalaciones del producto o varios perfiles, el puerto SOAP podría ser distinto a 8879. Examine el archivo SystemOut.log del gestor de despliegue para consultar los puertos que actualmente se están utilizando.
Parámetros
Para el mandato addNode están disponibles las opciones siguientes:
- -conntype <tipo>
- Especifica el tipo de conector JMX que se utilizará para conectar con el gestor de despliegue. SOAP es el tipo de conector JMX (Java Management Extensions) del mandato. Otros tipos válidos son JSR160RMI o RMI (Remote Method Invocation).
- -includeapps
- De forma predeterminada, el mandato addNode no transfiere las aplicaciones desde
los servidores autónomos en el nuevo nodo a la célula. En general, instale las aplicaciones utilizando el gestor de despliegue.
La opción -includeapps indica al mandato addNode que transfiera las aplicaciones desde un nodo. Si la aplicación ya existe en la célula, se imprime un aviso y la aplicación no se instala en la célula.
Las aplicaciones se correlacionan con el servidor que ha federado utilizando el mandato addNode. Cuando se completa la operación del mandato addNode, las aplicaciones se ejecutan en dicho servidor cuando el servidor se haya iniciado. Como estas aplicaciones forman parte de la célula de Network Deployment, puede correlacionarlas con otros servidores y clústeres de la célula mediante la consola administrativa. Consulte el artículo Correlación de módulos con servidores si desea más información.
No utilice la opción -includeapps si el nodo que desea federar incluye las aplicaciones proporcionadas por el producto como, por ejemplo, los ejemplos. Si la utiliza, se rechazará el segundo nodo que va a federarse que incluya estas aplicaciones porque las aplicaciones existen en la célula y no se da soporte a la fusión de aplicaciones.
Si utiliza la opción -includeapps en un nodo que incluye una gran cantidad de aplicaciones, se debe ampliar el tiempo de espera para el conector administrativo para justificar el tiempo adicional necesario para transferir todas las aplicaciones al gestor de despliegue durante la operación de addNode y para instalarlas de forma remota en la célula. La opción -includeapps no es un método recomendado salvo en una situación en la que hayan pocas aplicaciones exclusivas en el nodo.
De forma predeterminada, durante la instalación de aplicaciones, los archivos binarios de aplicación se colocan en el directorio raíz_servidor_aplicaciones/installedApps/nombre_célula. Después del mandato addNode, el nombre de célula de la configuración en el nodo que ha añadido cambia del nombre de célula base al nombre de célula del gestor de despliegue. Los archivos binarios de la aplicación se encuentran donde estaban antes de ejecutar el mandato addNode, por ejemplo, raíz_servidor_aplicaciones/installedApps/nombreCélula_antiguo.
De forma predeterminada, durante la instalación de aplicaciones, los archivos binarios de aplicación se colocan en el directorio raíz_perfil/installedApps/nombre_célula. Después del mandato addNode, el nombre de célula de la configuración en el nodo que ha añadido cambia del nombre de célula base al nombre de célula del gestor de despliegue. Los archivos binarios de la aplicación se encuentran donde estaban antes de ejecutar el mandato addNode, por ejemplo, raíz_perfil/installedApps/Nombre_célula_anterior.
En el ejemplo siguiente, la aplicación se había instalado especificando de forma explícita la ubicación de los archivos binarios:
La variable ${CELL}, especifica el nombre de célula actual. A continuación, cuando se ejecuta el mandato addNode los archivos binarios se transfieren al directorio profile_root/installedApps/nombreCélulaActual.${APP_INSTALL_ROOT}/${CELL}
La federación del nodo en una célula utilizando el mandato addNode no fusiona ninguna configuración a nivel de célula, incluida la información del host virtual. Si el host virtual y los alias de la célula nueva no coinciden con el producto, no puede acceder a las aplicaciones que se ejecutan en los servidores. Deberá añadir manualmente todos los alias de host virtual y host a la nueva célula utilizando la consola administrativa que se ejecuta en el gestor de despliegue.
Avoid trouble: Cuando se especifica el parámetro -includeapps, se podría producir un error OutOfMemoryError si el tamaño del almacenamiento dinámico de la máquina virtual Java (JVM) es demasiado pequeño. Cuando se produce este error, se emite el siguiente mensaje de error.
ADMU0111E: Saliendo del programa con el error: java.lang.OutOfMemoryError
Este error puede producirse cuando se procesan aplicaciones de tamaño considerable o existe un gran número de aplicaciones en el servidor de aplicaciones base.
Para recuperarse de este error y federar correctamente el servidor de aplicaciones, complete las acciones siguientes:
- Emita el mandato cleanupNode en el servidor del gestor de despliegue. Lea la información sobre el mandato cleanupNode para obtener más información acerca de este mandato.
- Aumente el tamaño de almacenamiento dinámico de JVM para un script
addNode. Cuando se emite el mandato addNode, el tamaño de almacenamiento dinámico de JVM está establecido en -xms128m -xmx512m. Para aumentar estos valores, utilice el parámetro -javaoption.
Por ejemplo, podría especificar la siguiente
información (todo en una línea):
addNode localhost 8879 -javaoption java_option "-Xmx512m"
addNode.sh localhost 8879 -javaoption java_option "-Xmx512m"
- Vuelva a emitir el mandato addNode .
- -includebuses
- Copia en la célula los buses del nodo que se va a federar. Este parámetro también intenta copiar la configuración del bus de integración de servicios del nodo remoto en la célula. Si la célula del destino ya contiene un bus con el mismo nombre que cualquier bus el nodo remoto, no se podrá añadir el nodo. Para que no se produzca este error, puede actuar antes de utilizar el mandato addNode. Puede suprimir el bus con ese nombre en la célula de destino, renombrar el bus que se debe añadir a la célula o configurar manualmente el bus que ya se encuentra en la célula.
- -startingport <númeropuerto>
- Soporta la especificación de un número de puerto para utilizarlo como número de puerto base para todos los puertos de agente de nodo y de servidor Java Messaging
Service (JMS) creados durante la ejecución del mandato addNode. Con este soporte puede controlar
qué puertos se definen para estos servidores, en lugar de utilizar los valores de puerto predeterminados. El número de puerto de inicio se incrementa en una unidad para calcular el número de puerto para cada puerto de agente de nodo y cada puerto de servidor JMS configurados durante el mandato addNode.
Para evitar posibles conflictos entre puertos, consulte la información acerca de los valores de números de puertos para obtener más información acerca de los valores de puertos por omisión.
Si existen varios agentes de nodo en el mismo servidor físico, puede definir el número de puerto base para cada uno mediante el uso del parámetro -startingport antes de la federación, o mediante la modificación de los puertos en la sección del agente de nodo del archivo serverindex.xml.
- -portprops <nombrearchivo>
- Pasa el nombre del archivo que contiene los pares clave-valor de puertos explícitos que desea que utilice el nuevo agente de nodo. Por ejemplo, para establecer los puertos SOAP y RMI en 3000 y 3001, cree un archivo con las dos líneas siguientes y páselo como el parámetro:
SOAP_CONNECTOR_ADDRESS=3000 BOOTSTRAP_ADDRESS=3001
- -nodeagentshortname <nombre>
- Nombre corto que se utilizará para el nuevo agente de nodo.
- -nodegroupname <nombre>
- Nombre del grupo de nodos al que añadir este nodo. Si no lo especifica, el nodo se añade a DefaultNodeGroup.
-registerservice
- Registra el agente de nodo como un servicio Windows.
Opcionalmente, puede definir un nombre de usuario y una contraseña para el servicio Windows con los parámetros -serviceusername y -servicepassword. Si define un nombre de usuario, debe asignar al nombre de usuario de Iniciar sesión como servicio para que el servicio se ejecute correctamente.
Si no especifica un nombre de usuario y una contraseña, el servicio se ejecutará con la cuenta del sistema local.
-serviceusername <usuario>
Utilice el nombre de usuario especificado como el usuario del servicio Windows.
-servicepassword <contraseña>
Utilice la contraseña Windows predeterminada como la contraseña del servicio Windows.
- -coregroupname <nombre>
- Nombre del grupo principal al que se añadirá este nodo. Si no especifica esta opción, el nodo se añade al grupo DefaultCoreGroup.
- -noagent
- Indica al mandato addNode que no ejecute el proceso agente de nodo para el nuevo nodo.
- -statusport
- Un parámetro opcional que permite a un administrador establecer el número de puerto para la devolución de llamada del estado del agente de nodo. La herramienta abre este puerto y espera la devolución de llamada del estado procedente del agente de nodo que indica que el agente de nodo se ha iniciado. Si este parámetro no se establece, se asigna automáticamente un puerto no utilizado.
- -quiet
- Suprime la información sobre el progreso que el mandato addNode imprime en modalidad normal.
- -nowait
- Indica al mandato addNode que no espere a que la inicialización del proceso del agente de nodos se realice correctamente.
- -logfile <nombre_archivo>
- Especifica la ubicación del archivo de registro en el que se escribe la información de rastreo. De manera predeterminada, el archivo de registro es addNode.log y se crea en el directorio logs del perfil del nodo que se va a añadir.
- -replacelog
- Sustituye el archivo de registro cronológico en lugar de anexarlo al archivo de registro cronológico actual. De forma predeterminada, el mandato addNode se anexa al archivo de rastreo existente. Esta opción hace que el mandato addNode sobrescriba el archivo de rastreo.
- -trace
- Genera información de rastreo adicional en el archivo de registro cronológico para depuración.
- -user <nombre> o -username <nombre>
- Especifica el nombre de usuario para autenticación si está habilitada la seguridad. Funciona igual que la opción -user. El nombre de usuario que elija debe ser uno pre-existente.
- -password<contraseña>
- Especifica la contraseña para autenticación si está habilitada la seguridad. La contraseña que elija debe estar asociada a una pre-existente.
- -localusername <nombre>
- Especifica el nombre de usuario para la autenticación de los servidores de aplicaciones existentes en el nodo que desea federar. Este parámetro sólo es aplicable si la seguridad está habilitada para el servidor de aplicaciones.
- -localpassword <contraseña>
- Especifica la contraseña para la autenticación de los servidores de aplicaciones existentes en el nodo que desea federar. La contraseña que elija debe estar asociada a una pre-existente. Este parámetro sólo es aplicable si la seguridad está habilitada para el servidor de aplicaciones.
- -profileName
- Define el perfil del proceso del servidor de aplicaciones en una instalación de varios perfiles. La opción -profileName no es necesaria para la ejecución en un entorno de perfil único. El valor predeterminado de esta opción es el perfil predeterminado. Si añade un perfil no predeterminado a la célula del gestor de despliegue, es necesario este parámetro.
- -excludesecuritydomains true | false
- Establezca el parámetro -excludesecuritydomains en true si no desea configurar los dominios de seguridad en el nodo del servidor de aplicaciones federado en la célula. Si el parámetro se establece en true, se utiliza la configuración de seguridad de la célula. Este parámetro únicamente se aplica si tiene dominios de seguridad configurados en el servidor de aplicaciones no federado. De forma predeterminada, si existe un dominio de seguridad asociado con un servidor de aplicaciones, el dominio de seguridad se federa con la célula para que el servidor utilice la misma información de dominio de seguridad después de federarse.
- -asExistingNode
- Especifica que se ha de recuperar un nodo gestionado existente de una célula del gestor de despliegue. Utilice el parámetro -asExistingNode del mandato addNode para recuperar rápidamente un nodo dañado. Por ejemplo, si una anomalía de la máquina hace que un nodo no esté disponible pero la información de nodo permanece en el gestor de despliegue, puede utilizar la opción -asexistingnode de addNode para volver a crear el nodo que no está disponible realizando los pasos siguientes:
- Crear un perfil nuevo con el mismo nombre de nodo y perfil que el nodo no disponible. Puede crear el perfil en una máquina distinta de la del nodo original.
- Para el nuevo perfil, ejecute el mandato addNode con la opción -asexistingnode.
También puede utilizar la opción -asExistingNode del mandato addNode para mover un nodo a una instalación del producto en otro sistema, pero en la misma vía de acceso, para mover un nodo a una instalación del producto en otro sistema operativo o con una vía de acceso distinta, o para crear células nuevas a partir de una célula de plantilla. Consulte el tema sobre cómo recuperar o mover nodos con el mandato addNode -asexistingnode.
Avoid trouble: Otras opciones de addNode para la configuración del nodo son incompatibles con esta opción -asExistingNode. No utilice -asExistingNode con las siguientes opciones incompatibles: -includeapps, -includebuses, -startingport, -portprops, -nodeagentshortname, -nodegroupname, -registerservice, -serviceusername, -servicepassword, -coregroupname o -excludesecuritydomains.gotcha
- -help
- Imprime una sentencia de uso.
- -?
- Imprime una sentencia de uso.
Ejemplo de uso
addNode testhost 8879 (añade un servidor de aplicaciones al gestor de despliegue)
addNode deploymgr 8879 -trace (produce el archivo addNode.log)
addNode host25 8879 -nowait (no espera al proceso agente del nodo)
El valor 8879 es el puerto predeterminado.![[IBM i]](../images/iseries.gif)
addNode mydmgr 11383 -profileName mynode (se añade el perfil, mynode, a la célula gestionada por el perfil mydmgr, que permanece a la escucha en el puerto SOAP 11383)
Consideraciones de seguridad al añadir un nodo de servidor de aplicaciones a la célula de WebSphere Application Server, Network Deployment
Al añadir un nodo a la célula, se puede heredar automáticamente tanto el registro de usuario como el mecanismo de autenticación de la célula.
Cuando se añade un nodo a una célula, el nodo acabado de federar hereda automáticamente el registro de
usuario (sistema operativo local, protocolo LDAP (Lightweight Directory Access Protocol) o personalizado, el
mecanismo de autenticación (LTPA ), y el valor de autorización (enlaces de
WebSphere o perfiles
EJBROLE de SAF (System Authorization Facility) de la célula de WebSphere Application Server, Network Deployment existente.
En el caso de la seguridad distribuida, todos los servidores de la célula deben utilizar el mismo registro de usuarios y mecanismo de autenticación. Para recuperarse de un cambio de registro de usuarios, debe modificar las aplicaciones para que las correlaciones de usuario y grupo a rol sean correctas para el nuevo registro de usuarios. Consulte el artículo sobre la asignación de usuario y grupos a roles.
Otra cuestión importante a tener en cuenta es la infraestructura de claves públicas SSL (Secure Sockets Layer). Antes de ejecutar el mandato addNode con el gestor de despliegue, verifique que el mandato addNode puede comunicarse como un cliente SSL con el gestor de despliegue. Esta comunicación requiere que el almacén de confianza de addNode configurado en el archivo sas.client.props contenga el certificado de firmante del certificado personal del gestor de despliegue que se encuentra en el almacén de claves y se especifica en la consola administrativa.
A continuación se indican otras cuestiones que deben tenerse en cuenta al ejecutar el mandato addNode con la seguridad:- Al intentar ejecutar mandatos de gestión de sistema como el mandato addNode, especifique de forma explícita las credenciales
administrativas para realizar la operación. El mandato addNode acepta los parámetros -username y -password para especificar el ID de usuario y la contraseña. El ID de usuario y la contraseña que se especifican deben ser para un usuario
administrativo. Por ejemplo, especifique un usuario que sea miembro
de los usuarios de la consola con privilegios de administrador o el ID de usuario administrativo configurados en el registro de usuarios. Consulte el ejemplo siguiente del mandato addNode:
addNode CELL_HOST 8879 -includeapps -username user -password pass
El parámetro -includeapps es opcional. Esta opción intenta incluir las aplicaciones de servidor en el gestor de despliegue. El mandato addNode podría fallar si los registros de usuarios utilizados por el servidor de aplicaciones y el gestor de despliegue no son los mismos. Para corregir esta anomalía, haga que coincidan los registros de usuarios o desactive la seguridad. Si modifica los registros de usuario, recuerde verificar que las correlaciones de usuarios a roles y grupos a roles son correctas. Lea acerca del mandato addNode para obtener más información sobre la sintaxis de addNode.
Si emite el mandato addNode con la seguridad habilitada, debe utilizar un ID de usuario con autorización y especificar las opciones -user y -password.
- La adición de un nodo remoto seguro utilizando la consola administrativa no está soportada. Puede inhabilitar la seguridad en el nodo remoto antes de realizar la operación o realizar la operación desde el indicador de mandatos utilizando el script addNode.
Antes de ejecutar el mandato addNode, debe verificar que los archivos de almacén de confianza de los nodos se comunican con los archivos de almacén de claves y el conjunto de claves SAF (System Authorization Facility) propiedad del gestor de despliegue y viceversa. Si genera los certificados para el gestor de despliegue utilizando la misma autoridad certificadora que la utilizada para el proceso del agente de nodo, todo resultará satisfactorio. Las configuraciones SSL siguientes deben contener almacenes de claves y de confianza que puedan operar conjuntamente:
- El repertorio SSL del sistema que se ha especificado en la consola administrativa. Pulse .
- El repertorio SSL para un conector JMX apropiado si se ha especificado SOAP. Pulse .
- El repertorio SSL que se ha especificado en NodeAgent. Pulse .
Preste atención cuando añada un nodo a la configuración de Deployment Manager que define un dominio de seguridad diferente.
Antes de ejecutar el mandato addNode, debe verificar que los archivos de almacén de confianza de los nodos se pueden comunicar con los archivos de almacén de claves del gestor de despliegue y viceversa. Si se utilizan los valores predeterminados DummyServerKeyFile y DummyServerTrustFile, no se producen errores de comunicación porque éstos ya se han podido comunicar. Sin embargo, no utilice nunca estos archivos ficticios en un entorno de producción ni cuando se transmitan datos sensibles.
- Si la seguridad está habilitada para el gestor de despliegue de la versión 7 o 8, el gestor de despliegue no puede utilizar el ID de servidor interno generado automáticamente para federar un nodo de la versión 6.x. El ID de servidor interno generado automáticamente se utiliza de manera predeterminada al habilitar la seguridad.
- Cuando un cliente de un release anterior intenta utilizar el mandato addNode para federar en un gestor de despliegue de la versión 7 u 8, el cliente primero debe obtener los firmantes para que el reconocimiento sea satisfactorio. Para obtener más información sobre los cambios necesarios antes de ejecutar el mandato addNode en este escenario, lea sobre cómo obtener firmantes de un release anterior en el tema sobre instalación segura para la recuperación de cliente, específicamente la sección Obtención de firmantes para clientes y servidores de un release anterior. El
registro de usuarios se puede modificar mediante una de estas acciones:
- En la consola administrativa, pulse Seguridad global. En Definiciones de reino disponibles, pulse . Especifique el nombre de usuario y la contraseña y pulse Aplicar.
- Ejecute un mandato de wsadmin:
AdminTask.configureAdminWIMUserRegistry('[-autoGenerateServerId false -serverId testuser -serverIdPassword testuserpwd -primaryAdminId testuser -ignoreCase true ]')
- Después de ejecutar el mandato addNode, el servidor de aplicaciones está en un nuevo dominio SSL. Es posible que contenga configuraciones SSL que señalen los archivos de almacén de claves y los archivos de almacén de confianza que no están preparados para interoperar con otros servidores que están en el mismo dominio. Tenga en cuenta cuáles son los servidores que se comunican entre sí y asegúrese de que se confía en los servidores en los archivos de almacén de confianza.