Já aviso de antemão que este post é uma gambiarra, mas que funciona e muito bem. Foi testado e aprovado.

Um dos clientes que presto consultoria possui um ambiente rodando SOA Suíte com mais de 10 JVMs. Estamos passando por um processo de análise e tuning, e diversos problemas já foram mapeados e estão sendo resolvidos.

Nessa última semana, foi necessário adicionar novas JVMS, 6 a mais. Para isso, adicionamos um novo servidor no ambiente.

Depois de prepararmos o S.O, que foi alterar o sysctl.conf, o /etc/security/limits.conf, copiar o Middleware Directory de outro server, validar que o uid e o gid dos servidores pertencentes ao mesmo ambiente possuíam os mesmos valores e configurar o hugepages, executei o seguinte comando.

Bom, antes de falarem que sou um FDP, aqui vai o /etc/sysctl.conf que foi parametrizado, mas atenção para o hugepage – marcados em negrito, o qual terá os valores alterados de acordo com a quantidade de memória ram que está disponível no seu servidor – mais infos sobre ele no seguinte link.

# Kernel sysctl configuration file for Red Hat Linux
#
# For binary values, 0 is disabled, 1 is enabled. See sysctl(8) and
# sysctl.conf(5) for more details.

# Controls IP packet forwarding
net.ipv4.ip_forward = 0

# Controls source route verification
net.ipv4.conf.default.rp_filter = 0

# Do not accept source routing
net.ipv4.conf.default.accept_source_route = 1

# Controls the System Request debugging functionality of the kernel
kernel.sysrq = 0

# Controls whether core dumps will append the PID to the core filename.
# Useful for debugging multi-threaded applications.
kernel.core_uses_pid = 1

# Controls the use of TCP syncookies
net.ipv4.tcp_syncookies = 1

# Disable netfilter on bridges.
net.bridge.bridge-nf-call-ip6tables = 0
net.bridge.bridge-nf-call-iptables = 0
net.bridge.bridge-nf-call-arptables = 0

# Controls the default maxmimum size of a mesage queue
kernel.msgmnb = 65536

# Controls the maximum size of a message, in bytes
kernel.msgmax = 65536

# Controls the maximum shared segment size, in bytes
kernel.shmmax = 68719476736 #deverá ser igual a quantidade de memória disponível no seu servidor.
#kernel.shmmax = 82313216000

# Controls the maximum number of shared memory segments, in pages
kernel.shmall = 4294967296
net.core.rmem_max = 4194304
net.core.wmem_max = 2096304
net.core.somaxconn =3000
net.ipv4.tcp_keepalive_intvl =15
net.ipv4.tcp_fin_timeout =15
net.ipv4.tcp_syn_retries =1
#net.core.netdev_max_backlog = 2000
#net.ipv4.tcp_max_syn_backlog = 2048
#net.core.somaxconn = 256

# hugepages configuration
#vm.nr_hugepages=49768
vm.nr_hugepages=28500
vm.hugetlb_shm_group=502
vm.swappiness=20
##CHANGE REALIZADA A PEDIDO DA SERVICE.
# Send redirects, if router, but this is just server
net.ipv4.conf.all.send_redirects = 0
net.ipv4.conf.default.send_redirects = 0
# # Accept packets with SRR option? No
net.ipv4.conf.all.accept_source_route = 0
# # Accept Redirects? No, this is not router
net.ipv4.conf.all.accept_redirects = 0
net.ipv4.conf.all.secure_redirects = 0
# #Allow for more PIDs
kernel.pid_max = 65536
net.ipv4.ip_local_port_range = 1024 61000
net.ipv4.tcp_tw_reuse = 1
net.ipv6.conf.all.disable_ipv6 = 1

agora vem os parâmetros que foram parametrizados no /etc/security/limits.conf – lembrando que o apache faz bind na porta 80, sendo assim, o usuário root também precisa ter parâmetros configurados, mesmo com o bit stick 4755 setados para o apachectl e o httpd.

root soft nofile 90000 #número de open files, já que tudo no linux é um arquivo
root hard nofile 90000
root soft nproc 50000 #número de processos que o usuário abrirá – lembrando que cada thread é um processo – ps -eafL | grep tem poder.
root hard nproc 50000

weblogic soft nproc 20000
weblogic hard nproc 20000
weblogic soft nofile 65535
weblogic hard nofile 65535
weblogic soft core 10240000
weblogic hard core 10240000
weblogic soft memlock 58368000 # mesma quantidade de memória que foi configurada para o hugepages 🙂
weblogic hard memlock 58368000

Agora vamos para extensão do domínio, e isso deverá ser feito a partir do servidor que o managed server está rodando, pois é ele o responsável pelos arquivos de configuração do seu domínio WebLogic.

Aí começa o pulo do gato, como dizia uma ex-chefe que tive na IBM, que por sinal está mandando embora meio mundo aqui no Brasil, mas isso vale um outro post.

Rodando o quickstart, já que ele tem a capacidade de analisar o domínio e suas configurações, e a partir daí, adicionar novos recursos.

dentro do diretório do produto Weblogic/SOA instalado, dê um find . -name quickstart.sh

Encontrou, agora rode o ./quickstart.sh

Clique em getting started with WebLogic Server versão tal, pois não sei qual foi instalada em seu ambiente.

Depois selecione o Extend an existing WebLogic Domain e clique next.

Agora selecione o diretório exato aonde está instalado o seu domínio WebLogic, aonde ficam os diretórios servers, config e afins. Clique em next.

Vejam que a tela abaixo não deixa a gente prosseguir, correto. Pois bem, então selecione o WebLogic SIP, pois depois de tudo feito, vc o removerá diretamente do config.xml – tirando as linhas que dizem respeito a porta TCP 5561 (sempre um número acima da porta que o Nodemanager faz o bind, que por default é 5560, e da aplicação SIP)

Screen Shot 2014-02-27 at 11.53.05 PM

Feito isso, o quickwizard deixará vc prosseguir e adicionar os novos nós.

Passe reto na tela abaixo, quero dizer, dê next, pois este schema já foi configurado no momento que vc criou o seu domínio SOA.

Screen Shot 2014-02-27 at 11.55.15 PM

 

A próxima tela é para validar a conexão acima, vc também poderá dar next.

E a tela abaixo que começa a brincadeira, pois vc deverá selecionar a adição de Managed Server

Screen Shot 2014-02-27 at 11.58.31 PM

Adicione os servidores no final dos que já estão funcionando, não esquecendo de colocar o novo nome, o ip do servidor novo e a porta TCP, a qual aconselho ser diferente das que já estão rodando, pois pode acontecer de vc ter que remanejar estes servidores, caso falte recurso ou ocorra um desastre.

Atenção – o motivo pelo qual utilizo o quickwizard é porque ele facilita, e muito a nossa vida, no processo de adição de novas JVMS em um domínio já em funcionamento, pois ele cria, de forma automaticamente, as filas JMS e tudo que é pre-req para que estas JVMS funcionem e recebam, sem erro, o deployment do SOA-INFRA, a aplicação responsável por todos os composites.

Adicionarei as telas e todo o passo nos próximos dias, pois terei os print screens, como também, quais linhas precisam ser removidas do config.xml para que vc não tenha o SIP em funcionamento, já que ele foi utilizado para dar um by-pass na tela de instalação.. 

Lembrando que no final deste processo, há necessidade de restar do managed server para que estas novas configurações sejam carregadas e o EM reconheça estes novos nós.

Compartilhar:

Deixe uma resposta

Fechar Menu