Procedimientos recomendados para el mandato addNode
Utilice el mandato addNode para añadir un nodo autónomo a una célula.
- Copia la configuración de célula base de WebSphere Application Server en una nueva estructura de células. Esta nueva estructura de células coincide con la estructura del gestor de despliegue.
- Crea una definición nueva de agente de nodo correspondiente al nodo que la célula incorpora.
- Envía mandatos al gestor de despliegue para añadir los documentos del nuevo nodo al repositorio de células.
- Realiza la primera sincronización de la configuración del nuevo nodo y verifica que está sincronizado con la célula.
- Ejecuta el proceso agente del nuevo nodo.
- Actualiza los archivos setupCmdLine.bat o setupCmdline.sh y el archivo wsadmin.properties para apuntar a la nueva célula.
- Después de federar el nodo, el mandato addNode copia el
archivo plugin-cfg.xml del directorio raíz_servidor_aplicaciones/config/cells
en el directorio config/backup/base/cells. El mandato
addNode vuelve a crear un nuevo archivo
plugin-cfg.xml en el gestor de despliegue y la
operación nodeSync copia los archivos a nivel de nodo.
Para obtener información sobre los números de puerto, consulte el tema Valores de número de puerto .
- Si añade un nodo a una célula, el nombre de célula del nodo que está federando debe ser diferente del nombre de la célula a la que se ha federado el nodo. De lo contrario, recibirá el mensaje ADMU0027E y el mandato addNode no añadirá el nodo a la célula.
- Verifique que el gestor de despliegue y los nodos se han actualizado al mismo nivel de revisión dentro de WebSphere Application Server. Por ejemplo, un gestor de despliegue del nivel 6.0.1 no podrá federarse con nodos del nivel 6.0.2.
- No coloque archivos WebSphere Application Server .jar en la variable genérica CLASSPATH (vía de acceso de clases predeterminada) para todo el sistema).
Si el producto WebSphere Application Server, Network Deployment no puede determinar el nombre de host del servidor, pueden producirse problemas en algunas situaciones como, por ejemplo, cuando se añaden o administran nodos o cuando el agente de nodos se pone en contacto con el servidor de aplicaciones. Para resolver el nombre de host, el producto abre un puerto o consulta una dirección IP. A continuación, el producto espera a que el sistema operativo devuelva la información correcta. El sistema operativo podría buscar en varios lugares para encontrar la dirección IP, pero el producto no se ocupa del orden en que el sistema operativo hace esto, si se devuelve la información correcta. Si el nombre de host del servidor no se puede resolver, consulte la documentación de la administración de red para resolver el problema. La información adicional siguiente puede ayudarle a asegurarse de que se ha resuelto el nombre de host.
- Algunos sistemas operativos crean una asociación entre el nombre de host de
la máquina y la dirección de bucle de retorno de 127.0.0.1. Las instalaciones de Red Hat
crean la asociación predeterminada. Las instalaciones SuSE crean una asociación
similar con la dirección de bucle de retorno 127.0.0.2.
La asociación está en el archivo hosts.
Si el archivo hosts contiene correlaciones desde la dirección IP 127.0.0.1 o 127.0.0.2 a un nombre de host distinto de localhost, elimine las correlaciones. El ejemplo siguiente ilustra lo que puede suceder si las correlaciones no se suprimen: cuando un agente de nodo se comunica con el gestor de despliegue, envía su dirección IP al gestor de despliegue. El agente de nodo resuelve el nombre de host del agente de nodo con 127.0.0.1 si el sistema operativo devuelve una correlación para el nombre de host del archivo de hosts. Esta resolución impide que el gestor de despliegue envíe mensajes al agente de nodo porque la dirección IP 127.0.0.1 también es la dirección IP de la máquina local del gestor de despliegue.
El archivo hosts reside en /etc/hosts.
El archivo hosts reside en \WINDOWS\system32\drivers\etc\hosts.
La instalación AIX por omisión comprueba en primer lugar el servidor de nombres de dominio, DNS, para devolver la información a un servidor, de modo que se pueda resolver el nombre de host de este servidor o de otro. Si el nombre de host no se puede resolver o no se puede resolver en un intervalo de tiempo razonable, puede añadir la sentencia siguiente al archivo /etc/netsvc.conf de manera que el sistema operativo AIX comprueba primero si existe en el archivo de hosts local el nombre de host.
hosts=local,bind
- Algunos sistemas operativos crean una asociación entre el nombre de host de
la máquina y la dirección de bucle de retorno de 127.0.0.1. Las instalaciones de Red Hat
crean la asociación predeterminada. Las instalaciones SuSE crean una asociación
similar con la dirección de bucle de retorno 127.0.0.2.
La asociación está en el archivo hosts.
- De forma predeterminada, a las aplicaciones que están instaladas en el nodo no se copiarán en la célula. Si instala una aplicación después de utilizar el mandato addNode, la aplicación se instalará en la célula. Al especificar la opción -includeapps, fuerza al mandato addNode a copiar las aplicaciones del nodo a la célula. Las aplicaciones con nombres duplicados no se copiarán en la célula.
- Los documento a nivel de célula no se fusionan. Cualquier cambio que realice en los documentos autónomos a nivel de célula antes de utilizar el mandato addNode se debe repetir en la nueva célula. Por ejemplo, los hosts virtuales.
- Si recibe una excepción OutOfMemory mientras utiliza el mandato addNode, es posible que necesite aumentar el tamaño de almacenamiento dinámico del gestor de despliegue.
Para aumentar el tamaño del almacenamiento dinámico del gestor de despliegue,
ajuste el parámetro Tamaño máximo de almacenamiento dinámico. Por ejemplo, en la consola de administración, vaya a
Administración del
sistema > Gestor de despliegue > Java y
gestión de procesos > Definición de
proceso > Máquina virtual
Java y aumente el valor Tamaño
máximo del almacenamiento dinámico.
Avoid trouble: En los sistemas operativos HP-UX o Solaris, puede producirse un problema de espacio java.lang.OutOfMemoryError: PermGen durante la ejecución de tareas grandes y complejas. Por ejemplo, puede encontrarse con este problema al ejecutar mandatos como addNode en nodos con aplicaciones de gran tamaño. Cuando la demanda de recursos exceda el tamaño predeterminado de almacenamiento, la tarea puede fallar con un error de espacio java.lang.OutOfMemoryError: PermGen. Para resolver este problema, aumente el tamaño mínimo de la región permanente. Establezca la opción -XX:PermSize de la máquina virtual Java™ (JVM) a un valor como, por ejemplo, 128MB, que es suficiente en muchas situaciones en las que se produce este problema:
gotchaXX:PermSize=128m
- En algunas instancias es posible que el gestor de despliegue tarde más de lo previsto en responder al mandato
addNode. El valor de tiempo de espera predeterminado, que determina cuánto tiempo esperará el cliente la respuesta del servidor, es apropiado en la mayoría de los casos. Sin embargo, en situaciones de gran cantidad de
procesos es posible que el servidor necesite más tiempo para responder. Por ejemplo, si incluye la opción
-includeapps y tiene una gran cantidad de aplicaciones, o las aplicaciones son muy grandes, es posible que el valor predeterminado de 180 segundos no sea suficiente.
Para cambiar el valor de tiempo de espera predeterminado, abra el archivo
raíz_servidor_aplic/profiles/nombre_perfil/properties/soap.client.props
en un editor de texto ASCII cualquiera y localice la línea siguiente (aquí
aparece con el valor predeterminado de 180 segundos):
Si necesita cambiar el valor predeterminado puede editar esta línea y establecer el tiempo de espera en un valor más apropiado para su situación.com.ibm.SOAP.requestTimeout=180
Nota: si establece el valor predeterminado de tiempo de espera en 0, se inhabilitará la comprobación del tiempo de espera.si el tiempo de espera se establece en un valor demasiado alto, deberá esperar mucho tiempo para determinar si el mandato addNode completará satisfactoriamente su solicitud al gestor de despliegue. Si se establece un valor demasiado pequeño, el gestor de despliegue no tendrá tiempo suficiente para completar la solicitud antes de que el mandato addNode decida que el gestor de despliegue no responde y responderá con un error. Otros factores que pueden afectar a tiempos de espera del servidor incluyen la carga de proceso o la paginación excesiva en el gestor de despliegue y la latencia de red. Algunas de estas condiciones pueden ser temporales.
- Si recibe un mensaje de error de addNode que hace referencia a sincronizaciones de reloj incorrectas, asegúrese de que la máquina con el nodo que se va a federar está en sincronización con la máquina del gestor de despliegue con la que el nodo se va a federar.
- Si utiliza el mandato addNode desde un nodo que se federó
en un gestor de despliegue existente, el gestor de despliegue estará dañado. No podrá iniciar el segundo gestor de despliegue después de detenerlo.
Esto es debido a que el mandato addNode crea un directorio
PerfilGestorDespliegue/config/cells/CélulaGestorDespliegue/CélulaGestorDespliegue
en la configuración maestra. Se trata de un directorio de configuración de nodo incompleto.
Experimentará el problema si tiene un nodo federado y vuelve a ejecutar el mandato addNode para un gestor de despliegue diferente. Estos provoca que el gestor de despliegue se dañe y no podrá iniciarlo más adelante debido al directorio del nodo incompleto.
Realice una de las soluciones siguientes para resolver este problema:- Si el gestor de despliegue está en ejecución, puede utilizar el mandato cleanupNode en el gestor de despliegue donde reside el nodo incompleto.
- Suprima manualmente el directorio que fue creado en la configuración del gestor de despliegue durante la operación de un mandato addNode que no se completó. Por ejemplo: raíz_servidor_aplic/profiles/PerfilGestorDespliegue/config/cells/CélulaGestorDespliegue/nombreNodo.


http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-mp&topic=rxml_nodetips
File name: rxml_nodetips.html