Comando addNode

O comando addNode incorpora uma instalação do servidor de aplicativos em uma célula.

Dependendo do tamanho e da localização do novo nó incorporado à célula, esse comando pode levar alguns minutos para ser concluído.

[AIX Solaris HP-UX Linux Windows][z/OS]É necessário ter privilégios de Administrador para utilizar a função addNode.

[IBM i]Seu perfil de usuário deve ter autoridade *ALLOBJ ou deve ter autoridade de leitura e execução para o script addNode Qshell.

O servidor do agente do nó é iniciado automaticamente como parte do comando addNode, a menos que você especifique a opção -noagent. Se você reciclar o sistema que hospeda um nó de servidor de aplicativos, e não configurou o agente do nó para agir como um daemon de sistema operacional, você deverá emitir um comando startNode para iniciar o agente do nó antes de iniciar quaisquer servidores de aplicativos.

Quando você executa o comando addNode, o comando para a execução do servidor de aplicativos que ele está incorporando em uma célula. Opcionalmente, é possível parar o servidor de aplicativos antes de executar o comando addNode.

[Windows]Serviços Windows existentes associados aos servidores antes da inclusão de um nó em uma célula são removidos quando você executa o comando addNode. Se você remover o nó da célula posteriormente, os serviços do Windows não serão criados automaticamente novamente para os servidores de base. Consulte informações sobre o comando WASService para criar um serviço do Windows para o produto.

Ao incluir um nó, o produto pode gerar portas. Os seguintes itens aplicam-se à geração de portas:
  • As portas geradas para o agente de nó são exclusivas para todos os perfis na instalação. Por motivos de desenvolvimento, é possível criar vários perfis na mesma instalação e incluí-los em uma ou mais células sem se preocupar com conflitos de portas.
  • Se desejar especificar as portas que o agente de nó utiliza, especifique as portas em um arquivo com o nome do arquivo transmitido com a opção -portprops. O formato do arquivo são pares key=value, um em cada linha, com a chave sendo a mesma do nome da porta no arquivo serverindex.xml.
  • Se você quiser usar várias portas sequenciais, considere a opção -startingport. Isso significa que conflitos de portas com outros perfis não são detectados.
Boas Práticas Boas Práticas: Use a opção -includeapps para o comando addNode para garantir que o ambiente comece com a mesma versão do aplicativo. Se algum conjunto de políticas customizado for criado no servidor antes de você executar o comando addNode, o conjunto de políticas não será copiado na nova célula após você executar o comando addNode. Portanto, ao usar a opção -installApps, um aplicativo no servidor que usa o conjunto de políticas falha ao carregar o conjunto de políticas após você executar o comando addNode. É possível exportar o conjunto de políticas customizado do servidor independente antes de você executar o comando addNode e importar o conjunto de políticas customizado na nova célula após você executar o comando addNode.bprac

Leia o tópico sobre como usar as ferramentas de linha de comandos para determinar se o comando deve ser executado a partir do perfil ou do diretório-raiz do servidor de aplicativos.

Sintaxe

Consulte a sintaxe de comando:

[AIX Solaris HP-UX Linux Windows][z/OS]
addNode dmgr_host [dmgr_port] [-conntype type] [-includeapps] [-includebuses]
[-startingport portnumber] [-portprops qualified_filename]
[-nodeagentshortname name] [-nodegroupname name] [-registerservice]
[-serviceusername name] [-servicepassword password] [-coregroupname name]
[-noagent] [-statusport 1231] [-quiet] [-nowait] [-logfile filename]
[-replacelog] [-trace] [-username uid] [-password pwd]
[-localusername localuid] [-localpassword localpwd] [-profileName profilename]
[-excludesecuritydomains true | false] [-asExistingNode] [-help]
[IBM i]
addNode dmgr_host [dmgr_port] [-conntype type] [-includeapps] [-includebuses name]
[-startingport portnumber] [-portprops qualified_filename] 
[-nodeagentshortname name] [-nodegroupname name] [-registerservice] 
[-serviceusername name] [-servicepassword password] [-coregroupname name] 
[-noagent] [-statusport port] [-quiet] [-nowait] [-logfile filename] 
[-replacelog] [-trace] [-username uid] [-password pwd] 
[-localusername localuid] [-localpassword localpwd] [-profileName profilename]
[-excludesecuritydomains true | false] [-asExistingNode] [-help]

O argumento dmgr_host é requerido. Todos os outros argumentos são opcionais. O número da porta padrão é 8879 para a porta SOAP padrão do gerenciador de implementação. SOAP é o tipo de conector JMX (Java™ Management Extensions) padrão para o comando. Se você tiver múltiplas instalações do produto ou múltiplos perfis, a porta SOAP poderá ser diferente de 8879. Examine o arquivo SystemOut.log do gerenciador de implementação para ver as atuais portas em uso.

Nota: Esse tópico faz referência a um ou mais arquivos de log do servidor de aplicativos. Como uma recomendação alternativa, é possível configurar o servidor para usar a infraestrutura de log e rastreio do High Performance Extensible Logging (HPEL) em vez de usar os arquivos SystemOut.log , SystemErr.log, trace.log e activity.log em sistemas distribuídos e IBM® i. Também é possível usar HPEL em conjunção com os recursos de criação de log z/OS nativos. Se você estiver usando HPEL, será possível acessar todas as informações de log e rastreio usando a ferramenta de linha de comandos LogViewer a partir do diretório bin do perfil do servidor. Consulte as informações sobre a utilização do HPEL para resolução de problemas dos aplicativos para obter mais informações sobre o uso do HPEL.

Parameters

As opções a seguir estão disponíveis para o comando addNode:

-conntype <tipo>
Especifica o tipo de conector JMX a ser utilizado para conexão com o gerenciador de implementação. SOAP é o tipo de conector JMX (Java Management Extensions) padrão para o comando. Outros tipos válidos são JSR160RMI ou Remote Method Invocation (RMI).
-includeapps
Por padrão, o comando addNode não transporta aplicativos de servidores independentes no novo nó da célula. Em geral, instale aplicativos utilizando o gerenciador de implementação. A opção -includeapps diz ao comando addNode para transportar os aplicativos de um nó. Se o aplicativo já existir na célula, então um aviso será impresso e o aplicativo não será instalado na célula.

Os aplicativos são mapeados para o servidor que você associou usando o comando addNode. Quando a operação do comando addNode é concluída, os aplicativos são executados nesse servidor quando o servidor é iniciado. Como esses aplicativos fazem parte da célula de implementação da rede, é possível mapeá-los para os outros servidores e clusters na célula utilizando o console administrativo. Leia sobre como mapear módulos para servidores para obter informações adicionais.

Não utilize a opção -includeapps se o nó que você deseja federar incluir aplicativos fornecidos pelo produto, como as Amostras. Se você usar, o segundo nó a ser federado que incluir esses aplicativos será rejeitado porque os aplicativos existem na célula e a mesclagem de aplicativo não é suportada.

Se você usar a opção -includeapps em um nó que inclua um grande número de aplicativos, o tempo limite para o conector administrativo deverá ser estendido para ser levado em conta para o tempo adicional necessário para a transferência de todos os aplicativos para o gerenciador de implementação durante a operação addNode e instalá-los remotamente na célula. A opção -includeapps não é uma abordagem recomendada a não ser que existam alguns aplicativos exclusivos no nó.

[AIX Solaris HP-UX Linux Windows][z/OS]Por padrão, durante a instalação do aplicativo, os binários do aplicativo são extraídos no diretório app_server_root/installedApps/cellName. Após o comando addNode, o nome da célula da configuração no nó que você incluiu muda de nome de célula base para nome de célula do gerenciador de implementação. Os arquivos binários do aplicativo estão localizados no mesmo lugar em que estavam antes da execução do comando addNode, por exemplo, app_server_root/installedApps/old_cellName.

[IBM i]Por padrão, durante a instalação do aplicativo, os arquivos binários do aplicativo são extraídos no diretório profile_root/installedApps/cellName. Após o comando addNode, o nome da célula da configuração no nó que você incluiu muda de nome de célula base para nome de célula do gerenciador de implementação. Os arquivos binários do aplicativo estão localizados no mesmo lugar em que estavam antes da execução do comando addNode, por exemplo, profile_root/installedApps/old_cellName.

No seguinte exemplo, o aplicativo foi instalado especificando explicitamente o local para os arquivos binários:
${APP_INSTALL_ROOT}/${CELL}
A variável ${CELL}, especifica o nome da célula atual. Em seguida, quando o comando addNode é executado, os arquivos binários são movidos para o diretório profile_root/installedApps/currentCellName.

A associação do nó a uma célula usando o comando addNode não mescla nenhuma configuração em nível de célula, incluindo informações do host virtual. Se o host virtual e os aliases da nova célula não corresponderem ao produto, você não poderá acessar os aplicativos em execução nos servidores. Você precisa incluir manualmente todos os aliases do host virtual e do host à nova célula, utilizando o console administrativo em execução no gerenciador de implementação.

Evitar Problemas Evitar Problemas: Quando o parâmetro -includeapps estiver especificado, um OutOfMemoryError poderá ocorrer se o tamanho de heap da Java virtual machine (JVM) for muito pequeno. Quando esse erro ocorre, a seguinte mensagem de erro é emitida:
ADMU0111E: Saída do programa com erro: java.lang.OutOfMemoryError

Esse erro pode ocorrer quando grandes aplicativos forem processados, ou quando houver um grande número de aplicativos no Base Application Server.

Para recuperar desse erro e federar com êxito o servidor de aplicativos, conclua as seguintes ações:

  1. Emita o comando cleanupNode no servidor do gerenciador de implementação. Leia sobre o comando cleanupNode para obter informações adicionais sobre ele.
  2. Aumentar o tamanho de heap da JVM para o script addNode. Quando você emite o comando addNode, o tamanho de heap da JVM é configurado para -Xms128m -Xmx512m. Para aumentar esses valores, utilize o parâmetro -javaoption. Por exemplo, é possível especificar o seguinte (tudo em uma linha):[Windows]
    addNode localhost 8879 -javaoption java_option "-Xmx512m"
    [Linux][AIX]
    addNode.sh localhost 8879 -javaoption java_option "-Xmx512m"
  3. Emita o comando addNode novamente.
gotcha
-includebuses
Copia os barramentos do nó para serem federados para a célula. Esse parâmetro tenta também copiar a configuração do barramento de integração de serviços do nó remoto na célula. Se a célula de destino já contiver um barramento com o mesmo nome que qualquer barramento no nó remoto, o nó incluído falhará. Para evitar essa falha, é possível agir antes de usar o comando addNode. É possível excluir o barramento com esse nome na célula de destino, renomeá-lo para ser incluído na célula, ou configurar manualmente o barramento já localizado na célula.
-startingport <portNumber>
Suporta a especificação de um número de porta para usar como o número da porta base para todos os agentes de nó e portas do servidor Java Messaging Service (JMS) cridas quando o comando addNode é executado. Com esse suporte, é possível controlar quais portas são definidas para os servidores, em vez de utilizar os valores de porta padrão. O número da porta inicial é incrementado em uma unidade para calcular o número da porta para cada porta do agente do nó e porta do servidor JMS configuradas durante o comando addNode.

[AIX Solaris HP-UX Linux Windows]Para evitar conflitos de porta potenciais, leia sobre configurações de número da porta para obter mais informações sobre configurações de porta padrão.

Se múltiplos agentes do nó existirem no mesmo servidor físico, é possível definir o número da porta base para cada um utilizando o parâmetro -startingport antes da federação ou modificando as portas na seção do agente do nó do arquivo serverindex.xml.

-portprops <filename>
Transmite o nome do arquivo que contém os pares de key-value de portas explícitas que você deseja que o novo agente de nós utilize. Por exemplo, para definir suas portas SOAP e RMI para 3000 e 3001, crie um arquivo com as duas linhas a seguir e transmita-o como o parâmetro:
SOAP_CONNECTOR_ADDRESS=3000
BOOTSTRAP_ADDRESS=3001
-nodeagentshortname <name>
O nome abreviado para ser utilizado para o novo agente de nó.
-nodegroupname <name>
O nome do grupo de nós no qual esse nó deve ser incluído. Se você não especificar, o nó é incluído no DefaultNodeGroup.
[Windows]-registerservice
Registra o agente de nó como um serviço do Windows.

É possível opcionalmente definir um nome de usuário e senha para o serviço do Windows utilizando o parâmetro -serviceusername e o parâmetro -servicepassword. Se definir um nome de usuário, deverá fornecer o Logon do nome de usuário como uma autoridade de serviço para que o serviço seja executado corretamente.

Se não especificar um nome de usuário e uma senha, o serviço será executado com a conta do sistema local.

[Windows]-serviceusername <user>
[Windows]Utilize o nome de usuário especificado como o usuário de serviço do Windows.
[Windows]-servicepassword <password>
[Windows]Use a senha do Windows especificada como a senha de serviço do Windows.
-coregroupname <name>
O nome do grupo principal no qual esse nó deve ser incluído. Se você não especificar essa opção, o nó será incluído no DefaultCoreGroup.
-noagent
Instrui o comando addNode a não ativar o processo do agente de nó para o novo nó.
-statusport
Um parâmetro opcional que permite a um administrador definir o número da porta para o retorno de chamada do status do agente do nó. A ferramenta abre essa porta e aguarda pelo retorno de chamada do status do agente do nó, indicando que o agente do nó foi iniciado. Se o parâmetro não for configurado, uma porta não utilizada será alocada automaticamente.
-quiet
Suprime informações de progresso que o comando addNode imprime no modo normal.
-nowait
Diz ao comando addNode para não aguardar uma inicialização bem sucedida do processo do agente do nó ativado.
-logfile <nome_do_arquivo>
Especifica o local do arquivo de log no qual as informações de rastreio são gravadas. Por padrão, o arquivo de log é addNode.log e é criado no diretório de logs do perfil do nó que está sendo incluído.
-replacelog
Substitui o arquivo de log em vez de anexá-lo ao arquivo de log atual. Por padrão, o comando addNode é anexado ao arquivo de rastreio existente. Essa opção faz o comando addNode sobrescrever o arquivo de rastreio.
-trace
Gera informações de rastreio adicionais no arquivo de registro para finalidades de depuração.
-user <nome> ou -username <nome>
Especifica o nome de usuário para autenticação caso a segurança esteja ativada. Age da mesma forma que a opção -user. O nome do usuário escolhido deve ser um nome do usuário preexistente.
-password <senha>
Especifica a senha para autenticação caso a segurança esteja ativada. A senha escolhida deve ser uma que esteja associada ao nome do usuário preexistente.
-localusername <name>
Especifica o nome do usuário para autenticação de servidores de aplicativos existentes no nó a ser federado. Esse parâmetro aplica-se apenas se a segurança estiver ativada para o servidor de aplicativos.
-localpassword <password>
Especifica a senha para autenticação de servidores de aplicativos existentes no nó a ser federado. A senha escolhida deve ser uma que esteja associada ao nome do usuário preexistente. Esse parâmetro aplica-se apenas se a segurança estiver ativada para o servidor de aplicativos.
-profileName
Define o perfil do processo do Servidor de Aplicativos em uma instalação com vários perfis. A opção -profileName não é requerida para execução em um ambiente de perfil único. O padrão para esta opção é o perfil padrão. Se você estiver incluindo um perfil fora do padrão na célula do gerenciador de implementação, então esse parâmetro será necessário.
-excludesecuritydomains true | false
Configure o parâmetro -excludesecuritydomains para true se não desejar que os domínios de segurança sejam configurados no nó do servidor de aplicativos associado na célula. Quando o parâmetro é configurado para true, a configuração de segurança da célula é utilizada. Esse parâmetro se aplica somente quando você tem os domínios de segurança configurados no servidor de aplicativos não-federados. Por padrão, se houver um domínio de segurança associado a um servidor de aplicativos, o domínio de segurança será associado à célula para que o servidor utilize as mesmas informações do domínio de segurança após a associação.
-asExistingNode
Especifica para recuperar um nó gerenciado existente de uma célula do gerenciador de implementação.
Use o parâmetro -asExistingNode do comando addNode para recuperar rapidamente um nó danificado. Por exemplo, se uma falha de máquina resulta em um nó indisponível, mas as informações do nó permanecem no gerenciador de implementação, é possível usar a opção addNode -asExistingNode para recriar o nó indisponível concluindo as seguintes etapas:
  1. Crie um novo perfil com o mesmo nome de nó e de perfil que o nó indisponível. É possível criar o perfil em uma máquina diferente do nó original.
  2. Para o novo perfil, execute o comando addNode com a opção -asExistingNode.

É possível também usar a opção -asExistingNode do comando addNode para mover um nó para uma instalação do produto em um computador diferente mas no mesmo caminho, para mover um nó para uma instalação do produto em um sistema operacional diferente ou com um caminho diferente ou para criar células a partir de uma célula de modelo. Consulte o tópico sobre como recuperar ou mover nós com o comando addNode -asExistingNode.

Evitar Problemas Evitar Problemas: Outras opções addNode para a configuração do nó são incompatíveis com essa opção -asExistingNode. Não use -asExistingNode com as seguintes opções incompatíveis: -includeapps, -includebuses, -startingport, -portprops, -nodeagentshortname, -nodegroupname, -registerservice, -serviceusername, -servicepassword, -coregroupname ou -excludesecuritydomains.gotcha
-help
Imprime uma instrução de uso.
-?
Imprime uma instrução de uso.

Cenário de uso

Os exemplos a seguir demonstram a sintaxe correta:
addNode testhost 8879 (inclui um servidor de aplicativos no gerenciador de implementação)

addNode deploymgr 8879 -trace (produz o arquivo addNode.log)

addNode host25 8879 -nowait (não aguarda o processo de um agente de nó)
O valor 8879 é a porta padrão.
[IBM i]
addNode mydmgr 11383 -profileName mynode (adds profile, mynode, to the cell managed by profile mydmgr, which listens on SOAP port 11383)

Considerações de segurança ao incluir um nó de servidor de aplicativos na célula do WebSphere Application Server, Network Deployment

[IBM i][AIX Solaris HP-UX Linux Windows]Ao adicionar um nó à célula, você herda automaticamente o registro de usuário e o mecanismo de autenticação da célula.

[z/OS]Ao incluir um nó em uma célula, o nó recém-federado automaticamente herda o registro do usuário (S.O. Local, protocolo LDAP ou Customizado), mecanismo de autenticação (LTPA) e configuração de autorização (ligações WebSphere ou perfis EJBROLE SAF (System Authorization Facility)) da célula WebSphere Application Server, Network Deployment existente.

Para a segurança distribuída, todos os servidores da célula devem utilizar o mesmo registro de usuário e mecanismo de autenticação. Para recuperar-se de uma alteração no registro do usuário, você deve modificar os aplicativos para que os mapeamentos de usuário e grupo para as funções estejam corretos para o novo registro do usuário. Consulte o artigo sobre como designar usuários e grupos às funções.

Outra consideração importante é a infraestrutura de chave pública do SSL (Secure Sockets Layer). Antes da execução do comando addNode com o gerenciador de implementação, verifique se o comando addNode pode se comunicar como um cliente SSL com o gerenciador de implementação. Essa comunicação requer que o truststore addNode configurado no arquivo sas.client.props tenha o certificado signatário do certificado pessoal do gerenciador de implementação, conforme localizado no armazenamento de chave e especificado no console administrativo.

As questões a seguir devem ser levadas em consideração ao executar o comando addNode com segurança:
  • Ao tentar executar comandos de gerenciamento de sistemas, como o comando addNode, especifique credenciais administrativas para executar a operação. O comando addNode aceita os parâmetros -username e -password para especificar o ID do usuário e a senha. O ID do usuário e a senha especificados devem ser para um usuário administrativo. Por exemplo, especifique um usuário que seja um membro dos usuários do console com privilégios de Administrador ou o ID do usuário administrativo configurado no registro do usuário. Consulte o seguinte exemplo do comando addNode:
    addNode CELL_HOST 8879 -includeapps -username user
    -password pass

    O parâmetro -includeapps é opcional. Esta opção tenta incluir os aplicativos do servidor no gerenciador de implementação. O comando addNode pode falhar se os registros do usuário usados pelo servidor de aplicativos e gerenciador de implementação não forem os mesmos. Para corrigir essa falha, torne os registros do usuário iguais ou desative a segurança. Se você alterar os registros de usuários, lembre-se de verificar se os mapeamentos de usuários para funções e grupos para funções estão corretos. Leia sobre o comando addNode para obter informações adicionais sobre a sintaxe addNode.

    [z/OS]Se emitir o comando addNode com a segurança ativada, você deverá usar um ID do usuário com autoridade e especificar as opções -user e -password.

  • A inclusão de um nó remoto protegido por meio do Administrative Console não é suportada. É possível desativar a segurança no nó remoto antes de executar a operação ou executar a operação no prompt de comandos utilizando o script addNode.
  • [z/OS]Antes de executar o comando addNode, você deve verificar se os arquivos de armazenamento confiável nos nós se comunicam com os arquivos keystore e o conjunto de chaves SAF (System Authorization Facility) de propriedade do gerenciador de implementação e vice-versa. Se você gerar certificados para o gerenciador de implementação utilizando a mesma autoridade de certificação utilizada para o processo do agente de nós, será bem-sucedido. As configurações SSL a seguir devem conter armazenamentos de chaves e armazenamentos confiáveis que possam interoperar:
    • Repertório SSL do sistema especificado no console administrativo. Clique em Administração do Sistema > Gerenciador de Implementação > Transportes HTTP > sslportno > SSL.
    • Repertório SSL para conector JMX apropriado se SOAP for especificado. Clique em Administração do Sistema > Gerenciador de Implementação > Serviços de Administração > Conectores JMX > SOAPConnector > Propriedades Customizadas > sslConfig.
    • Repertório de SSL que é especificado no NodeAgent. Clique em Administração do Sistema > Agentes de Nó > Servidor NodeAgent > Serviços de Administração > Conectores JMX > SOAPConnector > Propriedades Customizadas > sslConfig.

    [z/OS]Tome cuidado ao incluir um nó em uma configuração de gerenciador de implementação que define um domínio de segurança diferente.

  • [IBM i][AIX Solaris HP-UX Linux Windows]Antes de executar o comando addNode, você deve verificar se os arquivos de armazenamento confiável nos nós podem se comunicar com os arquivos keystore do gerenciador de implementação e vice-versa. Ao utilizar o DummyServerKeyFile e o DummyServerTrustFile padrão, nenhum erro de comunicação ocorrerá, pois eles já podem se comunicar. Entretanto, nunca utilize esses arquivos dummy em um ambiente de produção nem quando dados sensíveis estiverem sendo transmitidos.
  • Se a segurança está ativada para o gerenciador de implementação Versão 7 ou 8, o gerenciador de implementação não pode usar o ID do servidor interno gerado automaticamente para federar um nó da Versão 6.x. O ID do servidor interno gerado automaticamente é utilizado por padrão ao ativar a segurança.
  • Quando um cliente de uma liberação anterior tenta usar o comando addNode para se associar a um gerenciador de implementação Versão 7 ou 8, primeiro o cliente deve obter assinantes para um handshake bem sucedido. Para obter informações adicionais sobre as mudanças necessárias antes da execução do comando addNode neste cenário, leia sobre como obter assinantes de uma liberação anterior no tópico Instalação Segura para Recuperação de Cliente, especificamente a seção Obtendo Assinantes para Clientes e Servidores de uma Liberação Anterior. O registro do usuário pode ser alterado executando-se uma das seguintes ações:
    • No console administrativo, clique em Segurança Global. Em Definições de Região Disponíveis, clique em Configurar > Identidade do servidor que está armazenada no repositório. Digite o nome de usuário e a senha e clique em Aplicar.
    • Execute um comando wsadmin:
      AdminTask.configureAdminWIMUserRegistry('[-autoGenerateServerId false -serverId testuser
       -serverIdPassword testuserpwd -primaryAdminId testuser -ignoreCase true ]')
    O servidor deve ser reiniciado para que essas alterações sejam efetivadas.
  • Após executar o comando addNode, o servidor de aplicativos está em um novo domínio SSL. Ele pode conter as configurações SSL que apontam para os arquivos de armazenamento de chaves e de armazenamento confiável que não estejam preparados para interoperar com outros servidores do mesmo domínio. Considere quais servidores estão se intercomunicando e assegure-se de que os servidores sejam confiáveis dentro de seus arquivos de armazenamento confiável.

Ícone que indica o tipo de tópico Tópico de Referência



Ícone de registro de data e hora Última atualização: last_date
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-mp&topic=rxml_addnode
Nome do arquivo: rxml_addnode.html