Neste post compartilharei um dashboard em grafana com metricas avançadas de latency/journal/queue/iops/throughput que te ajudaram a ajustar melhor as configurações do seu cluster, visto que pesquisando na internet não achei nenhum dash de ceph latência com telegraf, mas não era à toa, pois só na versão Lumiuous foi corrigido “admin socket permission” então resolvi criar do zero e compartilhar com a comunidade, explicando os principais pontos para utilizar tanto no jewel quanto no luminous.
Não irei abordar instalação do influxdb, grafana e telegraf pois tem muita coisa na internet, apenas os pontos principais para o dashboard funcionar.
Com o comando abaixo é possível verificar media latência do commit e apply do Ceph
# ceph osd perf
commit_latency(ms) apply_latency(ms)
............... ......................
Comentarei os 4 mais importantes:
A gravação do objeto em um cluster com replica de 3 gastará 6 IOs, para se concluido por conta da gravação journal(O_DIRECT) e do buffered_io para o disco efetivamente nas OSDs. Na maioria das vezes veremos mais IOs de write por conta das suboperações do ceph de replicação, diferente do read que só faz leitura na OSD primaria.
As métricas acima são as que nos dão uma media de como anda a latência do nosso cluster, o dashboard abaixo irá apresentar no grafana essas informações entre outras.
Por padrão algumas métricas de subsystem do cluster Ceph já vem ativo, outras teremos que ativar no ceph.conf ou via OSDs com inject. Verifique se seu cluster está com os perfs true.
# ceph --admin-daemon /var/run/ceph/ceph-osd.26.asok config show | grep perf
"debug_perfcounter": "0\/0",
"perf": "true",
"mutex_perf_counter": "true",
"throttler_perf_counter": "true",
Crie o arquivo abaixo e não esqueça de adicionar as tags para facilitar a seleção no grafana entre SATA e SSD ou escolha uma tag de sua preferência.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 |
|
Será nescessario adicionar o usuario telegraf no grupo ceph para que ele possa ler os sockets do /var/run/ceph
# addgroup telegraf ceph
ATENÇÃO: Aqui está o pulo do gato, nas versões anteriores ao Ceph 12.0.3 Luminous, terá que executar o seguinte comando abaixo
# chmod g+w /var/run/ceph/*
Esse comando contorna o problema “admin socket permission” que foi corrigido nas versões acima da 12.0.3
common: common/admin_socket: add config for admin socket permission bits (pr#11684, runsisi) https://github.com/ceph/ceph/pull/11684
Se a OSD for reiniciada a permissão se perder, se estiver abaixo da 12.0.3, recomendo adicionar a permissão no systemd após o startup da OSD. Se já estiver na versão superior basta adicionar no ceph.conf a config abaixo
admin_socket_mode 0775
Reiniciei o telegraf
systemctl restart telegraf
Verifique se não está ocorrendo nenhum error de socket no syslog
telegraf[986875]: 2018-09-18T21:49:03Z E! error reading from socket '/var/run/ceph/ceph-osd.51.asok': error running ceph dump: exit status 22
Teste se o telegraf está coletando as metricas do seu servidor de OSD com a permissão do telegraf
# sudo -u telegraf telegraf --debug -test -config /etc/telegraf/telegraf.conf -config-directory /etc/telegraf/telegraf.d -input-filter ceph
# sudo -u telegraf ceph --admin-daemon /var/run/ceph/ceph-osd.14.asok perf dump
Se tudo estiver ok, basta importa o dashboard para seu grafana e ser feliz! :)
Dashboard Telegraf Ceph - Latency: https://grafana.com/dashboards/7995
Plugin Utilizado: https://github.com/influxdata/telegraf/tree/master/plugins/inputs/ceph
No próximos post irei apresentar:
Referências de métricas:
]]>Recentemente eu tive um problema de badblock em um dos discos que gerou uma inconsistent na PG e o cluster não conseguiu se resolver automaticamente, mesmo tirando o disco defeituoso do cluster e parando a OSD associada.
As soluções abaixo me ajudaram a resolver meu problema que se estendeu por alguns dias. Caso tenha suporte recomendo abrir um chamado ou faça por sua conta e risco.
A solução 1 resolver a maioria dos casos e no meu caso não houver impacto nem downtime.
Problema ocorreu no Ubuntu 16.4 com Jewel utilizando FileStore replica de 3.
Antes de iniciar recomendo a leitura do meu post “Ceph Scrubbing” será fundamental você entender esse cara antes de começar.
1 - Buscando pgs inconsistente no nosso caso “5.163”
# ceph health detail | grep inconsistent
HEALTH_ERR
pg 5.163 is active+remapped+inconsistent+wait_backfill, acting [26,45,135]
Podemos ver que apresentou também em quais OSDs estão essas pgs [26,45,135] execute o comando abaixo para descobrir em quais servidores estão as OSDs
root@serv-117:/home/bruno.carvalho# ceph osd find 26
{
"osd": 16,
"ip": "10.0.0.14:6842\/21992",
"crush_location": {
"host": "stor-121",
"rack": "sata",
"root": "default"
}
}
root@serv-117:/home/bruno.carvalho# ceph osd find 45
{
"osd": 91,
"ip": "10.0.0.15:6814\/8362",
"crush_location": {
"host": "stor-122",
"rack": "sata",
"root": "default"
}
}
root@serv-117:/home/bruno.carvalho# ceph osd find 135
{
"osd": 30,
"ip": "10.0.0.17:6812\/10485",
"crush_location": {
"host": "stor-124",
"rack": "sata",
"root": "default"
}
}
2 - Logue no servidor da OSD primaria e busque o objeto problemático, se objeto problemático estiver na primaria não esqueça de descer com primary-affinity.()
# grep -Hn 'ERR' /var/log/ceph/ceph-osd.26.log (apresentar uma tripa de erro, o importante será o nome do objeto )
..... log [ERR] : 5.163 ....
udata.3b2ab5c0fdd3f.00000000000059d2__head_892078F9__4
.....
No Monitor podemos buscar com o comando abaixo (apresenta um json grande, porem o importante é o nome do objeto, algo parecido com nome do comando acima.)
# rados list-inconsistent-obj 5.163--format=json-pretty
Se nescessário jogue a OSD primário para outra OSD.
# ceph osd primary-affinity 26 0
3 - Logue nos servidores das 3 OSDs, busque o arquivo e verifique o md5 do objeto, seu tamanho e identifique o que está diferente entre os 3, no caso o objeto diferente será o que você irar remover para mandar o cluster se recuperar.
# find /var/lib/ceph/osd/ceph-26/current/5.163_head/ -name '*00000000000059d2*' -ls
...
/var/lib/ceph/osd/ceph-26/current/5.163_head/rbd\\udata.3b2ab5c0fdd3f.00000000000059d2__head_892078F9__4
# md5sum /var/lib/ceph/osd/ceph-26/current/5.163_head/rbd\\udata.3b2ab5c0fdd3f.00000000000059d2__head_892078F9__4\
d12a1f042f2a98a79943c990d3a5b2c8 /var/lib/ceph/osd/ceph-26/current/5.163_head/rbd\\udata.3b2ab5c0fdd3f.00000000000059d2__head_892078F9__4
4 - Set noout no cluster
# ceph osd set noout
5 - Pare a OSD
# systemctl stop ceph-osd@26
6 - Execute o flush do journal
# ceph-osd -i 26 --flush-journal
SG_IO: bad/missing sense data, sb[]: 70 00 05 00 00 00 00 0a 00 00 00 00 20 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
SG_IO: bad/missing sense data, sb[]: 70 00 05 00 00 00 00 0a 00 00 00 00 20 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
2018-08-23 18:31:57.691076 7f69269888c0 -1 flushed journal /var/lib/ceph/osd/ceph-26/journal for object store /var/lib/ceph/osd/ceph-26
7 - Remova o Objecto com problema
# rm -rf /var/lib/ceph/osd/ceph-26/current/5.163_head/rbd\\udata.3b2ab5c0fdd3f.00000000000059d2__head_892078F9__4
8 - Corrigindo permissão da OSD
# chown ceph:ceph -R /var/lib/ceph/osd/ceph-26/current/omap/
9 - Subindo OSD
# systemctl start ceph-osd@26
10 - Tira o noout no cluster e aguarde o cluster ficar com apenas a pg inconsistent
# ceph osd unset noout
11 - Vamos agora executar um repair para corrigir o problema.
# ceph pg repair 5.163
Agora veja o log da OSD primaria.
# tail -f /var/log/ceph/ceph-osd.26.log
2018-08-23 18:33:30.568207 7fc1ee195700 -1 log_channel(cluster) log [ERR] : 5.163 shard 26 missing 5:9f1e0491:::rbd_data.3b2ab5c0fdd3f.00000000000059d2:head
2018-08-23 18:33:30.568212 7fc1ee195700 0 log_channel(cluster) do_log log to syslog
2018-08-23 18:33:36.274075 7fc1ee195700 -1 log_channel(cluster) log [ERR] : 5.163 repair 1 missing, 0 inconsistent objects
2018-08-23 18:33:36.274079 7fc1ee195700 0 log_channel(cluster) do_log log to syslog
2018-08-23 18:33:36.274142 7fc1ee195700 -1 log_channel(cluster) log [ERR] : 5.163 repair 1 errors, 1 fixed
2018-08-23 18:33:36.274144 7fc1ee195700 0 log_channel(cluster) do_log log to syslog
No log acima podemos ver “log [ERR] : 5.163 repair 1 errors, 1 fixed” isso mostra que ele encontrou o objecto que faltava e corrigiu criando novamente a replica.
Identificar e remover o objeto problemático na OSD excluindo com ceph-object-tools executando com deep-scrub
Com o objeto problemático já identificado, execute os procedimentos: 4, 5 e 6 após sigar os procedimentos abaixo
1 - Com a OSD down localize o objeto
# ceph-objectstore-tool --data-path /var/lib/ceph/osd/ceph-26 --journal /var/lib/ceph/osd/ceph-26/journal --pgid 5.163 --op list | grep rbd_data.3b2ab5c0fdd3f.00000000000059d2
["5.163",{"oid":"rbd_data.3b2ab5c0fdd3f.00000000000059d2","key":"","snapid":-2,"hash":3828189539,"max":0,"pool":5,"namespace":"","max":0}]
2 - Removendo Objeto.
# ceph-objectstore-tool --data-path /var/lib/ceph/osd/ceph-26 --journal /var/lib/ceph/osd/ceph-26/journal --pgid 5.163 '{"oid":"rbd_data.3b2ab5c0fdd3f.00000000000059d","key":"","snapid":-2,"hash":3828189539,"max":0,"pool":5,"namespace":"","max":0}' remove
remove #5:c691b427:::rbd_data.3b2ab5c0fdd3f.00000000000059d2:head#
3 - Corrigir permissão
# chown -R ceph:ceph /var/lib/ceph/osd/ceph-135/current/omap/
4 - Iniciar OSD
# systemctl start ceph-osd@26
5 - Execute o deep-scrub na pg (Veja artigo do “Ceph Scrubbing”, para execução com espaço de tempo menor)
# ceph pg deep-scrub 5.163
O deep-scrub no CEPH é um processo que passa em todas OSDs para verificar inconsitencia dos dados e corrigir eventuais problemas, podemos comparar ao fsck. Dependendo das configurações do seu Cluster o deep-scrub não executará imediatamente, verifique no log da OSD primaria ou execute o seguinte comando query pg e veja data da ultima vez que ele passou.
Se o deep-scrub não for executado, verifique as configurações de osd_scrub_max_interval, também é importante verificar o osd_scrub_load_threshold, pois se sua CPU estiver e um certo limite o deep-scrub não rodará.
Leia mais sobre: “Ceph Scrubbing”
6 - Query pg
# ceph pg 5.163 query
..................
"last_deep_scrub_stamp": "2018-08-23 15:48:42.107928",
..................
Também podemos verificar logo no final do comando query o deep-scrub sendo executado na PG.
"scrub": {
"scrubber.epoch_start": "57000",
"scrubber.active": 1,
"scrubber.state": "WAIT_REPLICAS",
"scrubber.start": "5:578cfc17:::rbd_data.57e3dd6b7d297f.000000000000b063:0",
"scrubber.end": "5:578cff8c:::rbd_data.552a0c53cb890c.00000000000046aa:0",
"scrubber.subset_last_update": "58460'37642760",
"scrubber.deep": true,
"scrubber.seed": 4294967295,
"scrubber.waiting_on": 1,
"scrubber.waiting_on_whom": [
"48"
Após o termino do deep-scrub provavelmente sua pg já estará OK.
No próximo post irei apresentar:
- Métricas de Latência no Ceph
Referência: http://lists.ceph.com/pipermail/ceph-users-ceph.com/
]]>Olá turmadaaa, um pouco sumido, mas estou de volta com grandes novidades. A pouco mais de 2 anos realizei a implantação de 4 Cluster Ceph com Juju e MaaS na america latina que hoje tem quase 8 Petabyte raw, e quanto mais o cluster cresce, mais ajustes e problemas diferentes aparecem.
Recentemente encontrei um bug relacionado a recuperação de “Placement groups(PGs)” dentro do Jewel. O Ceph não estava conseguindo resolver a inconsistência de uma PG, mesmo executando o “ceph repair” e forçando a passagem do Scrubbing. Pelo que notei nos últimos lançamentos do CEPH tem alguns bug fix sobre o assunto.
Bem este será o primeiro de alguns posts mais avançado que irei falar de como resolver manualmente uma pg inconsistente, mas neste momento vamos entender melhor o Scrubbing no Ceph
Podemos comparar o Scrubbing do Ceph com o fsck para o armazenamento de objetos dentro do Cluster. Ao executar “ceph -s” nas ultimas linhas veremos as “placement groups(PGs)” que estão como “active+clean”, que significa que estão oks.
Para cada placement groups(PGs) o Ceph gera um catálogo de todos os objetos e compara cada objeto primário e suas réplicas garantindo assim que nenhum objeto esteja ausente ou seja incompatível. Muitas vezes vamos achar a seguinte informação “1 active+clean+inconsistent” isso nos mostrar que alguma replicar dentro do cluster está inconsistente. Como o Ceph realizado seu auto reconvery esse problema é resolvido automaticamente na passagem do scrub, porem recentemente percebi que isso não é uma verdade absoluta se você não tiver um ambiente bem configurado.
A passagem do Scrubbing é penosa para o cluster e muitas vezes só passará quando o sistema estiver com uma carga menor ou se as configurações forem alteradas via inject nas “OSDs”. Veja as 3 formas que podemos verificar as configurações no cluster e como podemos alterar a quente e força uma passagem imediata do scrub.
Verificando configurações no Ceph:
Apresenta apenas as configurações default do ceph
# ceph --show-config | grep osd_scrub_load_threshold
Apresenta a configuração permanente do ceph.conf
# ceph -n osd.X --show-config | grep osd_scrub_load_threshold
Apresentar a configuração atual
# ceph --admin-daemon /var/run/ceph/ceph-osd.21.asok config show | grep osd_scrub_load_threshold
Alterando Configuração a quente
# ceph tell osd.X injectargs '--osd_scrub_load_threshold 0.5'
O Scrubbing é muito importante para manter a integridade dos dados, mas poderá reduzir o desempenho do seu cluster, como “requests are blocked” se não for realizado ajustes nas configurações baseado na carga do seu cluster.
Existe dois tipos de Scrubbing, um e o “Light scrubbing”, ele verifica o tamanho e os atributos do objeto e por default passa todos os dias e não sobrecarrega tanto o cluster. O “deep-scrubbing” e uma limpeza mais profunda, lê os dados e usa somas de verificação para garantir a integridade, esse Scrubbing passa no decorrer da semana e gera uma carga maior no cluster. Como o “ceph -s“ conseguimos verificar em quantas “PGs” está sendo executado scrubbing no momento.
26 active+clean+scrubbing+deep 7 active+clean+scrubbing
Executando o comando abaixo, você consegue ver quando passou o último scrub/deep-scrub na PG
# Ceph osd PG_ID query
..................
"last_deep_scrub_stamp": "2018-08-23 15:48:42.107928",
..................
Algumas configurações que devemos nos atentar para ajustar:
Os Scrubbing começam após osd_scrub_min_interval desda ultima passagem, isso só ocorre se a CPU estiver abaixo do osd_scrub_load_threshold ou após osd_scrub_max_interval mesmo se o sistema estiver sobrecarregado.
Podemos também configurar um intervalo na madrugada para o Scrubbing passar osd_scrub_begin_hour/osd_scrub_end_hour. Com lançamento do Mimic, temos mais duas opções de intervalos osd_scrub_begin_week_day/osd_scrub_end_week_day
Quando executamos um ceph pg repair, ou um ceph pg deep-scrub ele não irá executar imediatamente e sim enviará um pedido a pg “instructing pg ID on osd.X to repair” porem precisa satisfazer as regras configuradas, veja a nota da documentação oficial abaixo.
Nota: “Ceph will not scrub when the system load (as defined by getloadavg() / number of onlinecpus) is higher than this number. Default is 0.5.”
A passagem deep-scrub não necessariamente depende do load_threshold, veja a nota abaixo.
Nota: “The interval for “deep” scrubbing (fully reading all data). The osd scrub load threshold does not affect this setting.”
Atenção as frags noscrub e nodeep-scrub definida no cluster e nas pools, caso esteja setada o scrub não será executado.
Creio que com essas informações já conseguimos manipular melhor os Scrubbing no cluster, que e essencial para a consistência das “Placement groups(PGs)” e da performance do cluster. Nos próximos posts vamos entrar mais a fundo na manipulação manual do objeto e na sua recuperação.
Caso tenha alguma dúvida sobre o funcionamento do Ceph não deixa de assitir meu Webinar que postei aqui no Blog Explorando o Ceph Como tiveram várias dúvidas sobre o Webinar, lançarei uma série de artigos mais básicos com informações essencias para você ir “Explorando o Ceph”.
Nos próximo posts irei apresentar:
- Resolvendo PGs inconsistent no CEPH manualmente
Referência: http://docs.ceph.com/docs/master/rados/configuration/osd-config-ref/
]]>A Internet das Coisas e a Terceira Plataforma Computacional estão levando as pessoas e as máquinas a gerarem milhões de dados digitais a cada instante. O volume de informações criadas no mundo, a médio e longo prazo, é infinito. Pesquisa da IBM mostra que, até 2020, o volume de dados previsto é de 40 zetabytes, ou seja, haverá quatro vezes mais dados digitais do que todos os grãos de areia existentes no planeta. As máquinas irão gerar 42% de todo volume de dados e haverá mais de 200 bilhões de dispositivos conectados no mundo.
O crescimento desenfreado de dados e as constantes mudanças exige das empresas respostas rápidas para os negócios. A expansão dos dispositivos móveis aumentou o uso das redes sociais e também de dados. As companhias precisam de tecnologias para tratar dados com estratégias de Big Data e gerar mais serviços online para o mundo conectado.
Atualmente as empresas precisam ter serviços disponíveis 24 horas, a Cloud Computing abraça todas as aplicações criadas para abastecer o mundo conectado, tanto para o mercado corporativo quando para atender o consumidor final. Para que isso gere menos custo e valor para empresas precisamos de um mundo com soluções hiperconvergentes, e sem um storage eficiente e escalável baseado em Software Defined isso se tornaria inviável para muitas empresas e startups.
No Webinar “Explorando Ceph” que será realizado pela TIVIT na próxima quarta-feira dia 4, falarei um pouco mais sobre o storage que está revolucionando o mercado de Software Defined, será totalmente gratuito e online. Inscreva-se: Aqui
GRAVAÇÃO:
]]>Na última Quarta-feira(25/10) rolou o primeiro Ceph Day SP e o primeiro na América Latina organizado e realizado pelo nosso Manager Comunity Leonado Vaz e nosso amigo da Savant Marcos Sungaila, além de grandes patrocinadores como RedHat, Canonical, Suse entre outros…
Para quem não teve a oportunidade de estar presente perdeu um grande dia. Discutimos sobre a nova versão do Ceph, custos x performance, implementações, cases e principalmente o futuro do SDS
A chegada da nova versão Luminous LTS que já é uma realidade, virou um divisor de águas no mundo do Software Define Storage(SDS) com várias melhorias como o novo backend BlueStorage que leva o Ceph a um nível de performance 2x mais rápido eliminando a camada do filesystem, além de grandes melhorias em toda sua estrutura.
Precisando de baixa latência e alta performance? O Ceph te entrega, tivemos uma palestra da Intel, uma das grandes colaboradoras do código, falando sobre Ceph com All-Flash.
SSDs to Build High-Performance Cloud Storage Solutions
Para os amantes do Zabbix como eu, o novo serviço de gerenciamento do Ceph(ceph-mgr) foi ampliado com vários módulos python, um deles exporta o status geral do cluster para o Zabbix habilitando o modulo no Ceph e configurando o template no zabbix.
1 2 |
|
Para os amantes da interface GUI. Agora será possível ter um dashboard no Ceph de forma simples.
1
|
|
Acesse http://you_active_mgr_host:7000/
Outra grande novidade, agora já é possível fazer Erasure Coding tanto em RBD quanto em CephFS, que antes só era possível com object. Na mudança para o BlueStorage será possível suporta compressão de dados, trazendo mais economia no armazenamento.
E tem muito mais vindo por ai! Eu particularmente estou ansioso para o tão esperado QoS que está por vir na próxima versão ou dedup que será excelente para galera de backup. Aguardem que isso será só o começo da evolução que o Ceph vem trazendo para o mundo do Software Define Storage.
Referências:
http://ceph.com/releases/v12-2-0-luminous-released/
]]>Que tal gerenciar seus Bare Metal com automação e eficiência? Te apresento o Metal as a Service (MaaS) uma ferramenta fantástica desenvolvida em Python pela Canonical que trás vários benefícios para gerenciar seus racks de Bare Metal e neste artigo irei falar um pouco das suas funções, instalação e configuração.
Segue abaixo algumas features do MaaS stable(2.2):
O MaaS foi desenvolvido para ambientes em escala Bare Metal, mais também é possível gerenciar VM com Virsh(KVM). Suporta as principais BMCs e controladores de chassi do mercado como Dell, IBM, HP, Lenovo, Huawei e Open Compute Project, está sendo utilizado por grandes plays do mercado como Microsoft, Nec, Verizon, At&t, NTT atualmente sendo considerado uma das melhores ferramentas open source para gerenciamento de Bare Metal.
O MaaS possui uma arquitetura em camadas com um banco de dados postgresql usado na ‘Region Controller (regiond)’ que lida com as solicitações. Já o Distributed Rack Controllers (rackd) fornecem serviços para cada rack.
Region controller(regiond):
Rack Controller (rackd) fornece DHCP, IPMI, PXE, TFTP e outros serviços locais. Os rackd armazenam itens como imagens de instalação do S.O no nível do rack para melhor desempenho, mas não mantenham nenhum estado além das credenciais para falar com o Region Controller.
Rack controller(rackd):
Tanto o regiond como o rackd podem ser escalados e configurados para alta disponibilidade.
Como podemos ver na arquitetura acima, em cada rack de servidor Bare Metal poderiamos ter um daemon chamado rackd que falaria via API com o regiond, isso e uma boa pratica para arquitetura de rede Layer 3 spine e leaf, mas neste exemplo vamos instalar tanto o regiond como o rackd em um unico servidor.
Adicionando repositorio e instalando o MaaS
1 2 |
|
Após instalação precisamos criar um usurário administrativo.
1
|
|
Depois da criação vamos acessar o painel via browser
Acesse a URL:http://$API_HOST:5240/MAAS
Entre com login e senha criado no passo anterior
No primeiro login será apresentado uma tela de configuração, altere o nome da sua região se achar necessário e neste primeiro momento deixe como padrão os outros valores
Agora vamos verificar quais serviços estão ativos, no painel click em “Nodes” selecione a aba “Controller” selecione o servidor da sua controller depois click na aba “Services”.
Veja se sua img está sincronizada Click na Aba “Images”
Vá para a aba “Subnets” e selecione a untagged VLAN/subnet para a qual você deseja habilitar o DHCP, e no botão “Take action” selecione “Provide DHCP”.
Após ativar o DHCP, podemos inciar os bare mental na rede configurada que automaticamente ela realizará o boot via PXE e iniciará o processo de enlist, assim aparecendo no menu “Node” do painel MaaS, abaixo veja como funciona o ciclo de vida do seu Bare Metal/VM dentro do MaaS.
Obs: para o MaaS conseguir Ligar e Desligar os servidores via IPMI será necessário um interface que chegue na rede da IDRAC e/ou ILO
Cada máquina (“nó”) gerenciada pelo MAAS passa por um ciclo de vida desde o alistamento até o comissionamento quando o nó será inventariado e iremos poder configurar elementos específicos do hardware. No ciclo também é possível alocamos um servidor para um usuário, realizar o deployer, e finalmente liberar de volta para um pool ou deletar por completo.
Qualquer dúvida comentem aííí, até a proxima!!!!
Referências:
]]>]]>
Juju é uma ferramenta open source de modelagem de aplicações desenvolvida em Go pela Canonical a mesma empresa que desenvolve o Linux Ubuntu.
Com Juju é possível implementar, configurar, gerenciar, manter e dimensionar aplicações em nuvens públicas e privadas de uma forma rápida e eficiente bem como servidores físicos, OpenStack e contêineres. O Juju pode ser usado tanto em linha de comando ou através de uma interface GUI
A partir dos charmes é possível realizar a criação de toda uma infraestrutura no nivel de configuração da maquina virtual, instalação e configuração das aplicações, interligações de dependências, tanto na AWS, Google, Azure, OpenStack entre outras nuvem suportadas ou diretamente no Bare-Metal.
O charme define tudo o que você conhece de forma colaborativa sobre a implantação da aplicação. Tudo o que você precisa fazer é usar qualquer charme disponível (ou escrever o seu próprio), e a aplicação correspondente será implantada em segundos, em qualquer nuvem, servidor físico ou máquina virtual.
O Charme nada mais é do que um receita de instalação e configuração com gerenciamento de dependencias e interligações nescessárias para sua aplicação funcionar em uma nuvem ou em um bare-metal.
Não! O Juju orquestra e escala aplicações em nuvens, ele está uma camada acima dos gereciadores de configurações, mas podemos usar todos juntos perfeitamente.
O puppet, Chef e Ansible são ótimas ferramentas para escrever arquivos de configuração. Por trabalhar uma camada acima, o Juju concentra-se nas operações de longo prazo necessárias para manter esse software em execução ao longo do tempo, independentemente da máquina na qual ele está sendo executado. O charme do Juju para um aplicativo inclui (entre outras coisas) toda a lógica para escrever arquivos de configuração para as aplicações, essa lógica em si pode ser escrita em qualquer linguagem ou ferramenta que o desenvolvedor do charme preferi.
É comum que as pessoas comecem a criar um charme juntando Puppet ou Chef ou outros scripts que eles atualmente usam para automatizar a configuração do ambiente. Se o charme vai estar escrevendo e atualizando a configuração para o aplicativo, e já existem ferramentas para abstrair esse arquivo de configuração na sua linguagem preferida (Puppet,Ansible, etc…), então use isso no charme!
Como podemos ver o Juju consegue reunir várias ferramentas de automação, deixando você livre para criar seus charme com suas receitas e ferramentas favoritas, ainda melhor, dois charmes diferentes de diferentes equipes que usam ferramentas diferentes trabalharão felizes juntos para implantar uma solução.
Para fins de teste vamos instalar o juju com o LXD, que no caso poderia ser uma nuvem ou um bare-metal
$ sudo apt install lxd zfsutils-linux
Para usar o LXD, seu usuário deve ser um membro do grupo lxd, verifique com o comando abaixo provavelmente já vai estar.
$ groups
Ao executar o comando abaixo, aceite todas respostas padrão nas configurações iniciais do LXD, ou mude caso achar melhor.
$ sudo lxd init
LXD agora está basicamente configurado para funcionar com Juju.
$ sudo add-apt-repository --update ppa:juju/stable
$ sudo apt install juju
Tanto para LXD, Bare-Metal ou nuvem será necessário a criação de um controle para gerenciar.
# juju bootstrap localhost lxd-test
Isso pode demorar alguns minutos, pois o LXD deve baixar uma imagem do linux.
Uma vez concluído o processo, veja se o controlador lxd-test foi criado com o comando abaixo:
# juju controllers
O comando a seguir mostra o controlador, modelo e o usuário atualmente ativo:
# juju whoami
Implantando um aplicativo com Juju.
O comando abaixo vai até o Juju store pega um charme pronto chamado mediawiki-single e manda instalar no ambiente LXD que configuramos no inicio.
# juju deploy cs:bundle/mediawiki-single
Após este comando, podemos verificando sua implementação:
# juju status
Comando de acesso ao ambiente criado
# juju ssh id_machine
Acesso GUI, o comando abaixo exibirá a URL de acesso a interface web do Juju.
# juju gui
Pegando a senha da controladora criada para logar no Juju Gui.
# juju show-controller --show-password
Mais comandos do Juju.
# juju help commands
Caso não queira realizar a instalação, a canonical disponibilizou um demo da sua interface GUI: https://demo.jujucharms.com/
Nos próximos posts irei apresentar:
- MaaS para integração do Juju com Bare-Metal
-Deployando Ceph com Juju.
Depois de 4 anos utilizando XenServer, chegou a hora de dá um até breve. Atualmente estou migrando alguns ambientes XenServer para Ovirt/KVM pela sua constante evolução e integração com o projeto Openstack que vem crescendo muito no cenário opensource.
Primeiro passo será exporta sua VM pelo XenCenter ou pelo seu node console conforme o comando abaixo.
# xe vm-export vm=<Name of VM> filename=<Name of file ending in ".xva">
Será gerado uma imagem com extensão .xva, jogue sua imagem exportada para seu node ovirt.
Desempacotando VM.
# tar -xvf vm.xva
No meu ambiente foi criado um diretório chamado Ref:10/
Baixe o script de migração (https://github.com/hswayne77/xenserverz_to_xen)
# wget wget https://raw.githubusercontent.com/hswayne77/xenserver_to_xen/master/xenmigrate_new.py
Execute os comandos para iniciar a migração da imagem.
# python xenmigrate.py -c Ref\:10/ vm.img
enmigrate 0.7.4 — 2011.09.13
(c)2011 Jolokia Networks and Mark Pace — jolokianetworks.com
convert ref dir : ./Ref:10/
to raw file : vm.img
last file : 20484
disk image size : 20 GB
RW notification every: 1.0GB
Converting: 1.0GBrw 2.0GBrw 3.0GBrw 4.0GBrw 5.0GBrw 6.0GBrw 7.0GBrw 8.0GBrw 9.0GBrw 10.0GBrw 11.0GBrw 12.0GBrw 13.0GBrw 14.0GBrw 15.0GBrw 16.0GBrw 17.0GBrw 18.0GBrw 19.0GBrw 20.0GBrw
Successful convert
Criando Domain Storage Export no Ovirt
Acesse no browse seu Ovirt Engine vá para:
Sistema -> Data Centers -> Default -> Storage -> Novo Domain
Crie um novo Dominio “Export” conforme a imagem abaixo.
Baixe a última versão do projeto “import-to-ovirt.pl” no seguinte link http://git.annexia.org/?p=import-to-ovirt.git
Instale as dependências
# yum install perl-XML-Writer perl-Sys-Guestfs
Agora vamos importa a vm.img para o Domain Export que criamos utilizando o import-to-ovirt.pl
# export LIBGUESTFS_BACKEND=direct
# ./import-to-ovirt.pl vm.img node1.supcom:/storage/export
Pode ser utilizado com imagem .qcow2
Verifique se tudo ocorreu bem com a criação do OVF
[root@node1 storage]# ls /storage/export/ad5e39a2-24d4-4a51-ac74-cfdf843c5f94/master/vms/88397ea1-196e-4aeb-8a57-29cff914caab/88397ea1-196e-4aeb-8a57-29cff914caab.ovf
Disponbilizando a VM no Ovirt Engine
Sistema -> Data Centers -> Default -> Cluster -> Default - > MVS -> Importar”:
Selecione o Export Domain criado, click em Carregar, Seleciona a VM, click na seta central, depois Próximo.
Click OK e aguarde a VM ser importada.
Após a importação será necessário realizar algumas alterações no momento da inicialização da VM:
Após a inicialização
Remova o “console=hvc0” /etc/default/grub e execute:
# update-grub
Verifique se seu fstab está correto e não tenha entradas xvda
Verifique sua network os uuid e MAC serão diferentes.
Edite o /etc/inittab comente a linha “co:2345:respawn:/sbin/getty … ”:
A vm migrada estava com Debian 7 e a migração foi executada com sucesso seguindo os procedimentos acima
Referências:
https://gfnork.de/blog/how-to-import-qcow2-images-to-ovirt/
https://rwmj.wordpress.com/2015/09/18/importing-kvm-guests-to-ovirt-or-rhev/
http://blog.zwiegnet.com/linux-server/export-vm-command-line-xenserver-6/
https://wiki.debian.org/HowToMigrateBackAndForthBetweenXenAndKvm
]]>Abs
]]>Objetivo
Instalar Ovirt 4.0 Hosted Engine utilizando NFS
No meu ambiente instalei tudo em um único node, o ovirt engine como VM no meu primeiro node, juntamente com NFS, mas para ambiente maiores recomendo a separação dos componentes para obter uma melhor performance e HA.
Ambiente Utilizado
Necessário servidor DNS, mas utilizei local para esta instalação
# cat /etc/hosts
192.168.10.200 ovirtengine.supcom
192.168.10.201 node1.supcom
Instando e configurando NFS
# yum -y install nfs-utils
# mkdir -p /storage/{engine,data,iso}
# chown 36:36 /storage/{engine,data,iso}
# cat /etc/exports
/storage/engine 192.168.10.0/24(rw,anonuid=36,anongid=36,all_squash)
/storage/data 192.168.10.0/24(rw,anonuid=36,anongid=36,all_squash)
/storage/iso 192.168.10.0/24(rw,anonuid=36,anongid=36,all_squash)
# exportfs -a
# systemctl enable nfs-server.service
# systemctl restart nfs-server.service
# showmount -e
Export list for node1.supcom:
/storage/engine *
/storage/data *
/storage/iso*
Instalando pacotes necessários
# yum install http://resources.ovirt.org/pub/yum-repo/ovirt-release40.rpm
# yum install ovirt-hosted-engine-setup ovirt-engine-appliance -y
Iniciando deploy hosted engine
# hosted-engine --deploy
[ INFO ] Stage: Initializing
[ INFO ] Generating a temporary VNC password.
[ INFO ] Stage: Environment setup
During customization use CTRL-D to abort.
Continuing will configure this host for serving as hypervisor and create a VM where you have to install the engine afterwards.
Are you sure you want to continue? (Yes, No)[Yes]: Yes
It has been detected that this program is executed through an SSH connection without using screen.
Continuing with the installation may lead to broken installation if the network connection fails.
It is highly recommended to abort the installation and run it inside a screen session using command "screen".
Do you want to continue anyway? (Yes, No)[No]: Yes
[ INFO ] Hardware supports virtualization
Configuration files: []
Log file: /var/log/ovirt-hosted-engine-setup/ovirt-hosted-engine-setup-20161118133413-u1wg2v.log
Version: otopi-1.5.2 (otopi-1.5.2-1.el7.centos)
[ INFO ] Stage: Environment packages setup
[ INFO ] Stage: Programs detection
[ INFO ] Stage: Environment setup
[WARNING] Cannot locate gluster packages, Hyper Converged setup support will be disabled.
[ INFO ] Please abort the setup and install vdsm-gluster, gluster-server >= 3.7.2 and restart vdsmd service in order to gain Hyper Converged setup support.
[ INFO ] Stage: Environment customization
--== STORAGE CONFIGURATION ==--
Please specify the storage you would like to use (glusterfs, iscsi, fc, nfs3, nfs4)[nfs3]: nfs3
Please specify the full shared storage connection path to use (example: host:/path): 192.168.10.201:/storage/engine
[ INFO ] Installing on first host
--== SYSTEM CONFIGURATION ==--
--== NETWORK CONFIGURATION ==--
[ INFO ] Bridge ovirtmgmt already created
iptables was detected on your computer, do you wish setup to configure it? (Yes, No)[Yes]: Yes
Please indicate a pingable gateway IP address [192.168.10.1]: 192.168.10.1
--== VM CONFIGURATION ==--
Booting from cdrom on RHEL7 is ISO image based only, as cdrom passthrough is disabled (BZ760885)
Please specify the device to boot the VM from (choose disk for the oVirt engine appliance) (cdrom, disk, pxe) [disk]: disk
Please specify the console type you would like to use to connect to the VM (vnc, spice) [vnc]: vnc
[ INFO ] Detecting available oVirt engine appliances
The following appliance have been found on your system:
[1] - The oVirt Engine Appliance image (OVA) - 4.0-20161115.1.el7.centos
[2] - Directly select an OVA file
Please select an appliance (1, 2) [1]: 1
[ INFO ] Verifying its sha1sum
[ INFO ] Checking OVF archive content (could take a few minutes depending on archive size)
[ INFO ] Checking OVF XML content (could take a few minutes depending on archive size)
[WARNING] OVF does not contain a valid image description, using default.
Would you like to use cloud-init to customize the appliance on the first boot (Yes, No)[Yes]? Yes
Would you like to generate on-fly a cloud-init ISO image (of no-cloud type) or do you have an existing one (Generate, Existing)[Generate]? Generate
Please provide the FQDN you would like to use for the engine appliance.
Note: This will be the FQDN of the engine VM you are now going to launch,
it should not point to the base host or to any other existing machine.
Engine VM FQDN: (leave it empty to skip): []: ovirtengine.supcom
Automatically execute engine-setup on the engine appliance on first boot (Yes, No)[Yes]? No
Please provide the domain name you would like to use for the engine appliance.
Engine VM domain: [supcom]
Enter root password that will be used for the engine appliance (leave it empty to skip):
Confirm appliance root password:
The following CPU types are supported by this host:
- model_SandyBridge: Intel SandyBridge Family
- model_Westmere: Intel Westmere Family
- model_Nehalem: Intel Nehalem Family
- model_Penryn: Intel Penryn Family
- model_Conroe: Intel Conroe Family
Please specify the CPU type to be used by the VM [model_SandyBridge]:
Please specify the number of virtual CPUs for the VM (Defaults to appliance OVF value): [4]:
[WARNING] Minimum requirements for disk size not met
You may specify a unicast MAC address for the VM or accept a randomly generated default [00:16:3e:77:82:77]:
Please specify the memory size of the VM in MB (Defaults to appliance OVF value): [16384]:
How should the engine VM network be configured (DHCP, Static)[DHCP]? Static Please enter the IP address to be used for the engine VM [192.168.10.2]: 192.168.10.200
[ INFO ] The engine VM will be configured to use 192.168.10.200/24
Please provide a comma-separated list (max 3) of IP addresses of domain name servers for the engine VM
Engine VM DNS (leave it empty to skip) [8.8.8.8]: 8.8.8.8
Add lines for the appliance itself and for this host to /etc/hosts on the engine VM?
Note: ensuring that this host could resolve the engine VM hostname is still up to you (Yes, No)[No] Yes
--== HOSTED ENGINE CONFIGURATION ==--
Enter engine admin password:
Confirm engine admin password:
Enter the name which will be used to identify this host inside the Administrator Portal [hosted_engine_1]: node1-engine
Please provide the name of the SMTP server through which we will send notifications [localhost]:
Please provide the TCP port number of the SMTP server [25]:
Please provide the email address from which notifications will be sent [root@localhost]:
Please provide a comma-separated list of email addresses which will get notifications [root@localhost]:
[ INFO ] Stage: Setup validation
--== CONFIGURATION PREVIEW ==--
Bridge interface : em2
Engine FQDN : ovirtengine.supcom
Bridge name : ovirtmgmt
Host address : node1.supcom
SSH daemon port : 22
Firewall manager : iptables
Gateway address : 192.168.10.1
Host name for web application : node1-engine
Storage Domain type : nfs3
Host ID : 1
Image size GB : 10
Storage connection : 192.168.10.201:/storage/engine
Console type : vnc
Memory size MB : 16384
MAC address : 00:16:3e:17:ac:23
Boot type : disk
Number of CPUs : 4
OVF archive (for disk boot) : /usr/share/ovirt-engine-appliance/ovirt-engine-appliance-4.0-20161115.1.el7.centos.ova
Appliance version : 4.0-20161115.1.el7.centos
Restart engine VM after engine-setup: True
CPU Type : model_SandyBridge
Acima o resumo da minha configuração, mude o que achar necessário conforme seu ambiente.
Please confirm installation settings (Yes, No)[Yes]: Yes
[ INFO ] Stage: Transaction setup
[ INFO ] Stage: Misc configuration
[ INFO ] Stage: Package installation
[ INFO ] Stage: Misc configuration
[ INFO ] Configuring libvirt
[ INFO ] Configuring VDSM
[ INFO ] Starting vdsmd
[ INFO ] Waiting for VDSM to reply
[ INFO ] Creating Storage Domain
[ INFO ] Creating Storage Pool
[ INFO ] Connecting Storage Pool
[ INFO ] Verifying sanlock lockspace initialization
[ INFO ] Creating Image for 'hosted-engine.lockspace' ...
[ INFO ] Image for 'hosted-engine.lockspace' created successfully
[ INFO ] Creating Image for 'hosted-engine.metadata' ...
[ INFO ] Image for 'hosted-engine.metadata' created successfully
[ INFO ] Creating VM Image
[ INFO ] Extracting disk image from OVF archive (could take a few minutes depending on archive size)
[ INFO ] Validating pre-allocated volume size
[ INFO ] Uploading volume to data domain (could take a few minutes depending on archive size)
[ INFO ] Image successfully imported from OVF
[ INFO ] Destroying Storage Pool
[ INFO ] Start monitoring domain
[ INFO ] Configuring VM
[ INFO ] Updating hosted-engine configuration
[ INFO ] Stage: Transaction commit
[ INFO ] Stage: Closing up
[ INFO ] Creating VM
You can now connect to the VM with the following command:
hosted-engine --console
You can also graphically connect to the VM from your system with the following command:
remote-viewer vnc://node1.supcom:5900
Use temporary password "1485XCFX" to connect to vnc console.
Please ensure that your Guest OS is properly configured to support serial console according to your distro documentation.
Follow http://www.ovirt.org/Serial_Console_Setup#I_need_to_access_the_console_the_old_way for more info.
If you need to reboot the VM you will need to start it manually using the command:
hosted-engine --vm-start
You can then set a temporary password using the command:
hosted-engine --add-console-password
Please install and setup the engine in the VM.
You may also be interested in installing ovirt-guest-agent-common package in the VM.
The VM has been rebooted.
To continue please install oVirt-Engine in the VM
(Follow http://www.ovirt.org/Quick_Start_Guide for more info).
Make a selection from the options below:
(1) Continue setup - oVirt-Engine installation is ready and ovirt-engine service is up
(2) Abort setup
(3) Power off and restart the VM
(4) Destroy VM and abort setup
(1, 2, 3, 4)[1]:
A partir desse ponto você precisar conectar na VM via VNC, para inciar o setup da engine.
Na minha instalação eu utilizei o Tightvnc (http://www.tightvnc.com/download.php)
Após acessar via vnc a maquina virtual, execute o seguinte comando
[root@ovirtengine ~]# engine-setup
[ INFO ] Stage: Initializing
[ INFO ] Stage: Environment setup
Configuration files: ['/etc/ovirt-engine-setup.conf.d/10-packaging-jboss.conf', '/etc/ovirt-engine-setup.conf.d/10-packaging.conf']
Log file: /var/log/ovirt-engine/setup/ovirt-engine-setup-20161118191609-oxmvpo.log
Version: otopi-1.5.2 (otopi-1.5.2-1.el7.centos)
[ INFO ] Stage: Environment packages setup
......................
......................
--== END OF CONFIGURATION ==--
[ INFO ] Stage: Setup validation
[WARNING] Cannot validate host name settings, reason: cannot resolve own name 'ovirtengine'
--== CONFIGURATION PREVIEW ==--
Application mode : both
Default SAN wipe after delete : False
Firewall manager : firewalld
Update Firewall : True
Host FQDN : ovirtengine.supcom
Engine database secured connection : False
Engine database host : localhost
Engine database user name : engine
Engine database name : engine
Engine database port : 5432
Engine database host name validation : False
DWH database secured connection : False
DWH database host : localhost
DWH database user name : ovirt_engine_history
DWH database name : ovirt_engine_history
DWH database port : 5432
DWH database host name validation : False
Engine installation : True
NFS setup : False
PKI organization : supcom
Configure local Engine database : True
Set application as default page : True
Configure Apache SSL : True
DWH installation : True
Configure local DWH database : True
Engine Host FQDN : ovirtengine.supcom
Configure Image I/O Proxy : True
Configure VMConsole Proxy : True
Configure WebSocket Proxy : True
Please confirm installation settings (OK, Cancel) [OK]: OK
Retirei parte do log padrão para não ficar muito grande o post, acima segue o resumo da minha configuração. Visto que todo ambiente será instalado nessa vm, tanto banco de dados como o DWH, então basta confirmar e seguir a configuração padrão.
[ INFO ] Stage: Transaction setup
[ INFO ] Stopping engine service
[ INFO ] Stopping ovirt-fence-kdump-listener service
[ INFO ] Stopping dwh service
[ INFO ] Stopping Image I/O Proxy service
[ INFO ] Stopping websocket-proxy service
[ INFO ] Stage: Misc configuration
[ INFO ] Stage: Package installation
[ INFO ] Stage: Misc configuration
[ INFO ] Upgrading CA
[ INFO ] Initializing PostgreSQL
[ INFO ] Creating PostgreSQL 'engine' database
[ INFO ] Configuring PostgreSQL
[ INFO ] Creating PostgreSQL 'ovirt_engine_history' database
[ INFO ] Configuring PostgreSQL
[ INFO ] Creating CA
[ INFO ] Creating/refreshing Engine database schema
[ INFO ] Creating/refreshing DWH database schema
[ INFO ] Configuring Image I/O Proxy
[ INFO ] Setting up ovirt-vmconsole proxy helper PKI artifacts
[ INFO ] Setting up ovirt-vmconsole SSH PKI artifacts
[ INFO ] Configuring WebSocket Proxy
[ INFO ] Creating/refreshing Engine 'internal' domain database schema
[ INFO ] Generating post install configuration file '/etc/ovirt-engine-setup.conf.d/20-setup-ovirt-post.conf'
[ INFO ] Stage: Transaction commit
[ INFO ] Stage: Closing up
[ INFO ] Starting engine service
[ INFO ] Restarting nfs services
[ INFO ] Starting dwh service
[ INFO ] Restarting ovirt-vmconsole proxy service
--== SUMMARY ==--
[ INFO ] Restarting httpd
Please use the user 'admin@internal' and password specified in order to login
Web access is enabled at:
http://ovirtengine.supcom:80/ovirt-engine
https://ovirtengine.supcom:443/ovirt-engine
Internal CA 81:C1:01:AD:28:0E:46:8F:86:A8:BB:12:E9:BB:2B:5F:0E:8C:F0:8D
SSH fingerprint: d7:7b:83:5b:54:6e:46:7b:c1:2c:c0:6e:ae:a1:4c:1e
--== END OF SUMMARY ==--
[ INFO ] Stage: Clean up
Log file is located at /var/log/ovirt-engine/setup/ovirt-engine-setup-20161118192015-muij8n.log
[ INFO ] Generating answer file '/var/lib/ovirt-engine/setup/answers/20161118192638-setup.conf'
[ INFO ] Stage: Pre-termination
[ INFO ] Stage: Termination
[ INFO ] Execution of setup completed successfully
Após a finalização, vamos voltar para o node1 e selecionar a primeira opção, para finalizar.
Make a selection from the options below:
(1) Continue setup - oVirt-Engine installation is ready and ovirt-engine service is up
(2) Abort setup
(3) Power off and restart the VM
(4) Destroy VM and abort setup
(1, 2, 3, 4)[1]: 1
Checking for oVirt-Engine status at ovirtengine.supcom...
[ INFO ] Engine replied: DB Up!Welcome to Health Status!
[ INFO ] Acquiring internal CA cert from the engine
[ INFO ] The following CA certificate is going to be used, please immediately interrupt if not correct:
[ INFO ] Issuer: C=US, O=supcom, CN=ovirtengine.supcom.60122, Subject: C=US, O=supcom, CN=ovirtengine.supcom.60122, Fingerprint (SHA-1): 81C101AD280E468F86A8BB12E9BB2B5F0E8CF08D
[ INFO ] Connecting to the Engine
[ INFO ] Waiting for the host to become operational in the engine. This may take several minutes...
[ INFO ] Still waiting for VDSM host to become operational...
[ INFO ] The VDSM Host is now operational
[ INFO ] Saving hosted-engine configuration on the shared storage domain
Please shutdown the VM allowing the system to launch it as a monitored service.
The system will wait until the VM is down.
Agora vamos voltar ao ovirtengine e reiniciar a vm.
[root@ovirtengine ~]# shutdown -r now
Voltando ao node1, percebemos que a instalação finalizou com sucesso.
[ INFO ] Enabling and starting HA services
[ INFO ] Stage: Clean up
[ INFO ] Generating answer file '/var/lib/ovirt-hosted-engine-setup/answers/answers-20161118174208.conf'
[ INFO ] Generating answer file '/etc/ovirt-hosted-engine/answers.conf'
[ INFO ] Stage: Pre-termination
[ INFO ] Stage: Termination
[ INFO ] Hosted Engine successfully deployed
[root@node1 ~]#
Vamos agora iniciar o hosted-engine
[root@node1 ~]# hosted-engine --vm-start
Caso a vm ovirtengine não inicie, restart os serviços
[root@node1 ~]# systemctl restart ovirt-ha-agent && systemctl restart ovirt-ha-broker && systemctl restart vdsmd
[root@node1 ~]# hosted-engine --vm-start
[root@node1 ~]# hosted-engine --vm-status
--== Host 1 status ==--
Status up-to-date : True
Hostname : node1.supcom
Host ID: 1
Engine status : {"health": "good", "vm": "up", "detail": "up"}
Score : 3400
stopped: False
Local maintenance : False
crc32 : f322c3c1
Host timestamp : 235828
Extra metadata (valid at timestamp):
metadata_parse_version=1
metadata_feature_version=1
timestamp=235828 (Mon Nov 21 13:29:31 2016)
host-id=1
score=3400
maintenance=False
state=EngineUp
stopped=False
Agora vá para browser e acesse o portal de administração
https://ovirtengine.supcom/ovirt-engine/
login:admin
senha: que você configurou na instalação
Adicionando Storage Data
Sistema -> Data Centers -> Default -> Storage -> Novo Dominio”:
Adicionando Storage ISO
Agora basta aguarda o storage ficar ativo.
Adicionando imagem ISO no Dominio criado
Acesse o ovirtengine e digite os comandos abaixo
[root@ovirtengine ~]# wget http://mirror.globo.com/centos/7/isos/x86_64/CentOS-7-x86_64-Minimal-1511.iso
[root@ovirtengine ~]# engine-iso-uploader upload -i node1-iso CentOS-7-x86_64-Minimal-1511.iso -r ovirtengine.supcom --insecure
Please provide the REST API password for the admin@internal oVirt Engine user (CTRL+D to abort):
Uploading, please wait...
INFO: Start uploading CentOS-7-x86_64-Minimal-1511.iso
Uploading: [########################################] 100%
INFO: CentOS-7-x86_64-Minimal-1511.iso uploaded successfully
Caso receba nfs timeout verifique se o firewall do node1.supcom não está bloqueando.
Criando VM
Sistema -> Data Centers -> Default -> Cluster -> Default - > MVS -> Novo MV”:
Após digitar o nome da VM, vamos criar o disco da VM em “Imagens de Instâncias” click em Criar
Digite o Tamanho, verifique se o storage domain está correto e click em OK
Selecione a rede que foi configurada por padrão na instalação.(bridge ovirtmgmt)
Configure a memória e o CPU e click em OK.
Agora vamos iniciar a VM clicando em “Executar uma vez” para iniciar o sistema com boot da nossa ISO CentOS
Selecione nossa ISO e marque a opção “Colocar CD”
Agora vamos Abrir o Console da VM para iniciar a Instalação.
Para o Remote Viewer abrir será nescessario baixar O Virt Manager (https://virt-manager.org/download/)
Troubleshooting:
Resolvendo problema com “ Failed to acquire lock: No space left on device ” ao iniciar a vm hosted engine
[root@node1 ~]# vdsClient -s 0 list
.........
.........
exitMessage = Failed to acquire lock: No space left on device
..........
..........
[root@node1 ~]# hosted-engine --vm-poweroff
[root@node1 ~]# sanlock direct init -s hosted-engine:0:/rhev/data-center/mnt/<INTERNAL HE SD>/<SDUUID>/ha_agent/hosted-engine.lockspace:0
[root@node1 ~]# systemctl restart ovirt-ha-agent && systemctl restart ovirt-ha-broker && systemctl restart vdsmd && systemctl restart supervdsmd
[root@node1 ~]# hosted-engine --vm-start
Referência:
]]>Olá turmadaaa, precisei realizar uma transferência de uma VM do XenServer com 300G que estava em um ponto de montagem NFS para um outro local remoto e para evitar problemas de interrupção, utilizei o comando abaixo que me permiti continuar a transferência em casos de problemas, como perda de conexão etc…
# rsync -vrlPtz --append /mnt/web.xva /storage/export/
sending incremental file list
web.xva 4641783808 1% 6.89MB/s 9:57:11
O Comando acima basicamente irá comprimir, continuar e salvar parcialmente apresentando a saída em detalhes. Pode ser utilizado com apenas um arquivo ou com diretórios.
Caso queira usar com ssh:
# rsync -vrlPtz --append -e 'ssh -p 2222' login@host:/tmp/web.xva /tmp/web.xva
Dica SSH Com Tunnel: ssh -L 2222:hostlocal:2222 root@hostremoto
Referência:
]]>No Brasil funciona assim:
Itaú Digital = Desemprego
Uber = Desemprego
Passamos da era agrícola, industrial, o mundo já está entrando na era pós tecnológica. Porque será que apenas no Brasil não dá certo? Será que nosso País não evoluiu ao ponto de entender que o mundo mudou?
Em vários lugares a era digital foi melhor para o consumidor, está claro que proibir o progresso e o desenvolvimento para manter empregos antiquados será menos efetivo e pior para todos! Alguns dos empregos mais desejados hoje não existiam a 10 anos atrás, estamos entrando em uma era de novas oportunidades, entenda que empregos morrem e empregos nascem.
]]>Este problema ocorre por alguma mudança na interface que foi atualizado pelo factor do satellite e no momento a interface não existe mais e/ou está inconsistente com os dados fornecidos.
Abaixo executo comandos para contorna esse problema, removendo uma interface invalida no host.
# foreman-rake console
Loading production environment (Rails 4.1.5)
irb(main):001:0> host = Host.find_by_name('HOSTNAME')
irb(main):003:0> i = host.interfaces[1]
irb(main):004:0> i.destroy
Trocando o array “host.interfaces[0,1,2]” você pode navegar em todas interfaces, veja no dashboard ao editar e atualizar o host, quais estão apresentado problemas e remova pelo foreman-rake.
Caso queira editar algum atributo da interface pelo foreman-rake utilize da seguinte forma.
# foreman-rake console
Loading production environment (Rails 4.1.5)
irb(main):001:0> host = Host.find_by_name('HOSTNAME')
irb(main):002:0> i = host.interfaces[0]
irb(main):003:0> i.name = "hostname"
irb(main):004:0> i.save!
Adpatando os comandos acima pode ser alterar varios atributos do provisionamento pelo foreman-rake.
]]>O Satellite se tornou um produto essencial para gerenciamento de ciclo de vida de sistemas da Red Hat em ambientes físicos, virtuais, nuvens privadas e públicas. A ferramenta apresenta implementação remota e estende a capacidade de gestão de pacotes, configurações, máquinas virtuais, containers, segurança entre grandes outras funcionalidades.
Uma das funcionalidades mais interessante dessa nova versão e o Remote Execute e Job Scheduling utilizando ssh. Agora será possível agenda execuções remotas em todos hosts. O OpenSCAP utilizado para auditoria de segurança, agora já vem instalado junto com o Satellite 6.2, antes precisava ser instalado manualmente. Melhorias no console web ficou notório, também percebi que a interface web está mais rápida.
Então amigos administradores de RHEL/CentOS, se você utiliza o Red Hat Satellite 5 e está pensando em implementar o Satellite 6, pode iniciar sua jornada, o Satellite 6.2 GA está finalmente atingindo o nível de maturidade necessária para gerir ambientes de pequeno e grande porte.
Atualmente estou utilizando a versão 6.1 e abaixo vou listar os passos e dificuldades encontradas no meu ambiente para migração do 6.2 GA.
Não será possível realizar migração de 6.2 Beta para 6.2 GA, antes de iniciar a migração para 6.2 verifique se seu ambiente está atualizado e com a versão 6.1.9. Não se esqueça de realizar o backup do ambiente atual.
Verificando se existe alguma atualização recente. Desabilite todos repositórios, deixe apenas os seguintes habilitado:
# subscription-manager repos --disable=*
# subscription-manager repos --enable=rhel-7-server-rpms
# subscription-manager repos --enable=rhel-7-server-satellite-6.1-rpms
# yum update
Caso atualize o kernel será necessário reiniciar o sistema
Após o update do S.O e dos novos pacotes, o satellite já estará com a versão 6.1.9, execute o seguinte comando para finalizar:
# katello-installer --upgrade
Upgrading...
Upgrade Step: stop_services...
Upgrade Step: start_mongo...
Upgrade Step: migrate_pulp...
Upgrade Step: start_httpd...
Upgrade Step: migrate_candlepin...
Upgrade Step: migrate_foreman...
Upgrade Step: Running installer...
Installing Done [100%]
[......................................................]
The full log is at /var/log/katello-installer/katello-installer.log
Upgrade Step: restart_services...
Upgrade Step: db_seed...
Upgrade Step: errata_import (this may take a while) ...
Upgrade Step: update_gpg_urls (this may take a while) ...
Upgrade Step: update_repository_metadata (this may take a while) ...
Katello upgrade completed!
Vamos realizar um check antes de realizar a migração para o 6.2.
# foreman-rake katello:upgrade_check
This script makes no modifications and can be re-run multiple times for the most up to date results.
Checking upgradeability...
Checking for running tasks...
[FAIL] - There are 35 active tasks.
Checking the current version...
[PASS] - Current version of the Katello Ruby RPM is 2.2.0.92 and needs to greater than or equal to 2.2.0.90
Checking content hosts...
Calculating Host changes on upgrade. This may take a few minutes.
Summary:
Content hosts to be preserved: 169
Content hosts to be deleted: 3
Details on Content Hosts planned for deletion saved to /tmp/pre-upgrade-1471033031.csv
You may want to manually resolve some of the conflicts and duplicate Content Hosts.
Upon upgrade those found for deletion will be removed permanently.
Como podemos ver minha migração apresentará falha “ [FAIL] - There are 35 active tasks.” Resolvendo active tasks provável lock, podemos ir manualmente na Web gui Monitor->Tasks e filtrar pelas tasks que estão em lock, assim executando manualmente os skip, também podemos identificar pelo hammer.
Apresenta um resumo das tasks em pausa
# hammer task resume --search "state=paused"
Apresenta todas tasks em pausa
# hammer task list --search "state=paused"
Removendo tasks em lock pelo foreman-rake
# service foreman-tasks stop
# foreman-rake console
irb(main):001:0> ForemanTasks::Task.where(:state => :planned).where(:label => "Actions::Katello::Repository::Sync").destroy_all
irb(main):002:0> ForemanTasks::Task.where(:state => :planned).where(:label => "Actions::Katello::System::GenerateApplicability").destroy_all
irb(main):003:0> ForemanTasks::Task.where(:state => :paused).where(:label => "Actions::Katello::Repository::Sync").destroy_all
irb(main):004:0> ForemanTasks::Task.where(:state => :paused).where(:label => "Actions::Katello::System::GenerateApplicability").destroy_all
irb(main):005:0> ForemanTasks::Task.where(:label => "Actions::Candlepin::ListenOnCandlepinEvents").destroy_all
Caso nescessário remova a task pelo id
irb(main):001:0> ForemanTasks::Task.find("799bc5fb-2d4c-4d0d-9d7d-4e42e9a8ace8").destroy
Saindo do Foreman rake
irb(main):002:0> exit
# service foreman-tasks start
Reindexando o banco de dados para evitar futuras inconsistências
# foreman-rake katello:reindex
# katello-service restart
Executando novamente o upgrade_check podemos notar que as pendência de tasks foram solucionadas.
# foreman-rake katello:upgrade_check
This script makes no modifications and can be re-run multiple times for the most up to date results.
Checking upgradeability...
Checking for running tasks...
[PASS] - There are 0 active tasks.
Checking the current version...
[PASS] - Current version of the Katello Ruby RPM is 2.2.0.92 and needs to greater than or equal to 2.2.0.90
Checking content hosts...
Calculating Host changes on upgrade. This may take a few minutes.
Summary:
Content hosts to be preserved: 169
Content hosts to be deleted: 3
Details on Content Hosts planned for deletion saved to /tmp/pre-upgrade-1471269446.csv
You may want to manually resolve some of the conflicts and duplicate Content Hosts.
Upon upgrade those found for deletion will be removed permanently.
Desabilitar repositório Satellite 6.1
# subscription-manager repos --disable rhel-7-server-satellite-6.1-rpms
Habilitando repositórios necessário
# subscription-manager repos --enable rhel-7-server-satellite-6.2-rpms
# subscription-manager repos --enable=rhel-server-rhscl-7-rpms
Parando serviço
# katello-service stop
Limpando cache yum
# yum clean all
Upgrade de todos pacotes do sistema
# yum update
Upgrade do ambiente satellite
# satellite-installer --scenario satellite --upgrade
Nessa etapa acima encontrei um erro de migração que estava relacionado a ambiente puppet orfão, caso ocorra um erro parecido, tente remove o ambiente puppet informado na msg e execute o comando novamente.
foreman-rake katello:upgrades:3.0:update_puppet_repository_distributors Updating Puppet Repository Distributors Updating Content View Puppet Environment Distributors rake aborted! ForemanTasks::TaskError: Task 541787f6-ad56-449a-be6f-1b2001fc3538: Katello::Errors::PulpError: PLP0034: The distributor Library-ccv_rhel72_puppet-jboss indicated a failed response when publishing repository Library-ccv_rhel72_puppet-jboss.
Iniciando serviço
# katello-service start
Verificando serviço
# hammer ping
candlepin:
Estado: ok
Server Response: Duration: 19ms
candlepin_auth:
Estado: ok
Server Response: Duration: 23ms
pulp:
Estado: ok
Server Response: Duration: 66ms
foreman_tasks:
Estado: ok
Server Response: Duration: 882ms
Verique também na interface web se todos os serviços estão ok, na aba Administer->About
Caso ao logar na interface Web, apresente um erro de “undefined method `label' for nil:NilClass” atualize o pacote tfm-rubygem-katello e reinicie o serviço. (https://bugzilla.redhat.com/show_bug.cgi?id=1361793)
# rpm -Uvh tfm-rubygem-katello-3.0.0.73-1.el7sat.noarch.rpm
# katello-service restart
Desabilite repositório antigo
# subscription-manager repos --disable rhel-7-server-satellite-tools-6.1-rpms
Habilite novo repositório
# subscription-manager repos --enable=rhel-7-server-satellite-tools-6.2-rpms
Realize upgrade do katello-agent
# yum upgrade katello-agent
Sempre execute um snapshot da VM antes de executar os procedimentos abaixo.
Primeiro passo temos que aumentando nosso disco, no Vmware.
Selecione a VM no seu vSphere depois, vá em “Edit Settings”, selecione o “Virtual Disk” que deseje aumentar. No meu caso aumentarei 20G.
Verificando as partições do sistema:
# df -h
FilesystemSize Used Avail Use% Mounted on
/dev/mapper/vg_web01-lv_root 45G 1.5G 42G 4% /
tmpfs 1.9G 0 1.9G 0% /dev/shm
/dev/sda1 477M 78M 374M 18% /boot
Partição que sera expandida (/dev/mapper/vg_web01-lv_root)
Todo procedimento será realizado com a VM ligada e a partição montada.
Vamos agora realizar um procedimento para que o seu Linux reconheça o novo espaço adicionado sem precisar do reboot.
# ls /sys/class/scsi_device/
0:0:0:0 2:0:0:0
# echo 1 > /sys/class/scsi_device/0\:0\:0\:0/device/rescan
No meu caso tenho duas controladoras e meu disco se encontra na primeira. Pronto agora quando for executar o cfdisk ou fdisk você já consegue visualizar o espaço adicionado no Vmware, no meu caso foi criado o /dev/sda3.
Caso seja um novo Virutal Disk, execute os comando abaixo para identificar o novo device no seu ambiente sem precisar realizar o reboot.
Buscando host bus number # grep mpt /sys/class/scsi_host/host?/proc_name /sys/class/scsi_host/host0/proc_name:mptspi Execute o comando abaixo no host encontrado # echo "- - -" > /sys/class/scsi_host/host0/scan
Vamos utilizar o cfdisk para criar uma nova partição com o espaço disponível do tipo LVM(8e)
# cfdisk /dev/sda3 (a utilização do cfdisk não será abordada passo-a-passo)
Após a criação da nova partição, execute o comando abaixo
# partprobe /dev/sda (RHEL7)
# partx -a /dev/sda (RHEL6)
Podemos visualizar com o comando abaixo a nova partição reconhecida pelo sistema chamada sda3
# cat /proc/partitions
major minor #blocks name
80 73400320 sda
81 512000 sda1
82 51915776 sda2
83 20971520 sda3
2530 47849472 dm-0
25314063232 dm-1
Após a nova partição ser reconhecida vamos adiciona ao LVM.
# pvcreate /dev/sda3
Physical volume "/dev/sda3" successfully created
Expandindo grupo vg_web01
# vgextend vg_web01 /dev/sda3
Volume group "vg_web01" successfully extended
Expandindo Partição vg_web01-lv_root
# lvextend -L+20GB /dev/mapper/vg_web01-lv_root
Size of logical volume vg_web01/lv_root changed from 45.63 GiB (11682 extents) to 65.63 GiB (16546 extents).
Logical volume lv_root successfully resized.
Redimensionar sistema de arquivo ext4
# resize2fs /dev/vg_web01/lv_root
resize2fs 1.41.12 (17-May-2010)
Filesystem at /dev/vg_web01/lv_root is mounted on /; on-line resizing required
old desc_blocks = 3, new_desc_blocks = 5
Performing an on-line resize of /dev/vg_web01/lv_root to 16943104 (4k) blocks.
The filesystem on /dev/vg_web01/lv_root is now 16943104 blocks long.
Podemos agora verificar que a partição foi redimensionada para 65G sem precisar reiniciar ou muito menos desmontar.
# df -h
FilesystemSize Used Avail Use% Mounted on
/dev/mapper/vg_web01-lv_root 65G 1.5G 59G 3% /
tmpfs 1.9G 0 1.9G 0% /dev/shm
/dev/sda1 477M 78M 374M 18% /boot
Caso sua partição seja xfs basta executar o seguinte comando
# xfs_growfs /dev/vg_web01/lv_root
A Oracle tem um servidor Mbean chamado DomainRuntime, que está disponível no AdminServer. Conectando-se nesse servidor é possível coletar todas informações das JVM e do domínio. Assim não será necessário exportar JMX de cada JVM. Com essa solução ganha-se tempo de configuração, segurança, melhor administração de itens e gráficos agregados, além de não haver necessidade de abrir porta JMX em nenhuma JVM. Então, se tenho um domínio com 10 instancias(JVM), será possível apenas com a URL do console admin pegar todos Mbeans desse domínio.
O Middleware Weblogic é composto por três MBeanServers próprios que são exportados via RMI/IIOP como JSR-160. Estes podem ser consultados por meio de nome JNDI como mostra a lista abaixo. Além disso, existe a PlatformMBeanServer que pode ser exportado juntamente com o MbeanServer do weblogic.
O MbeanServer que vamos utilizar para buscar toda árvore do domínio weblogic será o Domínio Runtime MBean Servidor (weblogic.management.mbeanservers.domainruntime). Esse Mbean só está disponível na JVM do AdminServer.
Domínio->Geral->Avançado
- Servidor MBean de Compatibilidade Ativado
- Servidor MBean da Plataforma Ativado
- Servidor MBean da Plataforma Usado
Entre em cada JVM e adicione a seguinte linha no argumento que se encontra na aba Inicialização dos servidores
Domínio->Ambientes->Servidores->”NAME JVM”->Inicialização do Servidor
-Djavax.management.builder.initial=weblogic.management.jmx.mbeanserver.WLSMBeanServerBuilder
Será necessário reiniciar o AdminServer e as JVM do domínio.
Para facilitar a configuração, vamos utilizar a leitura dos Mbeans como anonymous, mas também poderíamos utilizar autenticação fixada no JNDI.
Permitir anonymous acesso de leitura, caso deseja monitorar sem autenticação no AdminServer.
Domínio->Segurança->Geral - Marque o "Acesso Anônimo Ativado”
Dominio->Ambientes->Servidores->AdminServer->Protocolos->IIOP
Será necessário reiniciar o AdminServer.
Agora abra o jconsole com os seguintes parâmetros:
jconsole -J- Djava.class.path=$JAVA_HOME/lib/jconsole.jar:$JAVA_HOME/lib/tools.jar$WL_HOME/server/lib/wljmxclient.jar -J-Djmx.remote.protocol.provider.pkgs=weblogic.management.remote
Use a URL de serviço JMX via IIOP DomainRuntime:
service:jmx:rmi:///jndi/iiop://IPADMINSERVER:7001/weblogic.management.mbeanservers.domainruntime
Primeiro tente se conectar utilizando o login e a senha do AdminServer e veja se consegue ler a arvore com.bea/DomainRuntimeService. Depois tente sem autenticação e veja se consegue ler via anonymous.
Caso não consiga ler como anonymous vamos alterar a permissão do JNDI.
1. Entre no AdminConsole(http://IP:7001/), click no AdminServer -> Exibir Árvore JNDI
2. Vá para o weblogic->management
3. Click no mbeanservers
4. Click em Segurança->Politicas
5. Escolha o Methods= lookup e adicione a politica "Allow access to everyone"
6. Restart AdminServer
7. Abra o jconsole com os parâmetros informados
8. Conecte novamente URL : service:jmx:rmi:///jndi/iiop://IPADMINCSERVER:7001/weblogic.management.mbeanservers.domainruntime
Após Conseguir ler a arvore DomainRuntime do AdminServer com jconsole, vamos alterar o external script para realizar as coletas.
External Script original: github.com/RiotGamesMinions/zabbix_jmxdiscovery
Modificações que foram feita na class JMXDiscovery.java libs adicionadas:
import java.io.PrintStream;
import javax.naming.*;
Alteração na linha 46:
this.jmxServerUrl = new JMXServiceURL("service:jmx:rmi:///jndi/rmi://" + hostname + ":" + port + "/jmxrmi");
Para:
this.jmxServerUrl = new JMXServiceURL("service:jmx:rmi:///jndi/iiop://" + hostname + ":" + port + "/weblogic.management.mbeanservers.domainruntime");
Como o DomainRuntime se conecta com IIOP e utiliza algumas libs especificar, foi necessário adicionar o pacote wlfullclient.jar(Pacote encontrado no servidor weblogic)
Coloque o wlfullclient.jar na pasta lib do pacote zabbix_jmxdiscovery. Após esses ajustes recompile o pacote utilizando ant.
Não irei aborta a utilização do ant, pois não e proposito deste post. Futuramente posso está criando um post especifico.
Obs: O /etc/hosts precisa estar resolvendo o nome da própria máquina local
Vá para diretório do binário compilado que foi realizado as modificações do jmx_discovery e execute o comando abaixo:
[brunocarvalho@zabbix zabbix_jmxdiscovery]# ./jmx_discovery com.bea:Name=DomainRuntimeService,Type=* 192.168.10.1:7001
{"data":[{"{#PROPTYPE}":"weblogic.management.mbeanservers.domainruntime.DomainRuntimeServiceMBean","{#JMXOBJ}":"com.bea:Name=DomainRuntimeService,Type=weblogic.management.mbeanservers.domainruntime.DomainRuntimeServiceMBean","{#JMXDESC}":"<p>Provides a common access point for navigating to all runtime and configuration MBeans in the…
Se a saída for parecida com a de cima seu external script está funcional.
Para que o zabbix-java-gateway comece a coletar utilizando o DomainRuntime, será necessário recompilar o jar do zabbix, alterando a url do jmx na class JMXItemChecker.java.
Vamos precisar colocar a lib wlfullclient.jar na pasta src para compilar o zabbix-java-gateway
Não irei aborta a compilação do Zabbix, pois não é proposito deste post. Futuramente posso está criando um post especifico.
Fiz alterações simples para atender minha demanda, mas pode ser melhorada, de uma olhada no seguinte link: support.zabbix.com/browse/ZBXNEXT-1274
Class alterada: /opt/install/zabbix-2.4.1/src/zabbix_java/src/com/zabbix/gateway/JMXItemChecker.java
public JMXItemChecker(JSONObject request) throws ZabbixException
{
super(request);
try
{
String conn = request.getString(JSON_TAG_CONN);
int port = request.getInt(JSON_TAG_PORT);
Integer remoting = new Integer("7777");
Integer weblogic = new Integer("7001");
int retvaljboss = remoting.compareTo(port);
int retvalweblogic = weblogic.compareTo(port);
if (retvaljboss == 0)
{
//suporta jboss7 na porta jmx 7777
url = new JMXServiceURL("service:jmx:remoting-jmx://" + conn + ":" + port);
}
if (retvalweblogic == 0)
{
url = new JMXServiceURL("service:jmx:rmi:///jndi/iiop://" + conn + ":" + port + "/weblogic.management.mbeanservers.domainruntime");
}
else
{url = new JMXServiceURL("service:jmx:rmi:///jndi/rmi://" + conn + ":" + port + "/jmxrmi");
}
Agora sua imaginação não tem limites! Basta configurar seu zabbix para fazer LLD no server Domainruntime do weblogic utilizando o jmx_discovery igualmente como é feito no jmxrmi.
1. Adicione o host na interface jmx com o ip do AdminConole na porta 7001
2. Adicione o template weblogic anexo no host
3. Adicione macro para o host
{$ADMINSERVER} - ipadminserver:7001
{$DOMINIO} - nomedoseudominio
Segue anexo arquivos utilizados:
github.com/brunowcs/zabbix_weblogic/
O .RAR ficou um pouco grande por conta dos binários java, então tive que dividir em 3 partes para o github aceitar o upload.
Template Weblogic.xml LLD com 42 itens, 4 triggers, 16 gráficos criado para weblogic DomainRuntime (Não esqueça de configurar as macros)
JMXDiscovery.jar com alteração da class JMXDiscovery.java do zabbix_jmxdiscovery, recopilação alterações para connect IIOP com inclusão da lib própria do weblogic para comunicação do server Domainruntime
Bash do jmx_discovery para se colocar junto com o JMX na pasta do externalscripts do zabbix
zabbix-java-gateway-2.4.1.jar alteração da class JMXItemChecker.java do zabbix-java-gateway, compilação alterações para connect IIOP com inclusão da lib própria do weblogic comunicação do server Domainruntime
wlfullclient.jar (lib utilizada na compilação)
org-json-2010-12-28.jar (lib utilizada na compilação)
Recomendo realizar testes no seu em ambiente de homologação antes de entrar em produção
Resultado:
Nesse meu primeiro post, vou falar um pouco sobre o intuito desse blog.
Bem… para começar, as escritas por aqui serão bem informal e técnicas, então prenda-se apenas o proposito.
Essa ideia já é velha, mas venho adiando por muitos longos anos, porem recentemente tive a necessidade de relembrar alguns procedimentos executados há um bom tempo atrás, e fiquei tanto tempo pesquisando nas minhas mídias externas e na internet que agora tomei a iniciativa de documentar tudo em um só lugar, assim quando quiser compartilhar algo e relembrar algo pesquiso aqui! :)
Concluindo… esse será meu disco virtual, onde vou compartilhar com todos meus estudos, ideias, implementações e procedimentos do meu dia a dia…
Qualquer coisa comente, critique, ajude a enrique os posts o importante é a troca de experiências e conhecimentos.
Quem sou eu? Sobre.
]]>