Configurei um ha-cluster pacemaker/corosync em uma configuração de failover com dois nós: produtivo e em espera. Existem três partições DRBD. Tudo funciona bem até agora.
Estou usando o Nagios NRPE em ambos os nós para monitorar o servidor com icinga2 como ferramenta de relatório e visualização. Agora, como as partições DRBD no nó de espera não são montadas até que haja um switch de failover, sempre recebo avisos críticos para estes:
Portanto, este é um alerta falso. Eu já me deparei com DISABLE_SVC_CHECK e tentei implementá-lo, aqui está um exemplo:
echo "[`date +%s`] DISABLE_SVC_CHECK;$host_name;$service_name" >> "/var/run/icinga2/cmd/icinga2.cmd"
Não existe uma maneira fácil/prática recomendada para desabilitar essa verificação para DRBD no nó de espera no Nagios ou no Icinga2? É claro que quero que essa verificação entre em vigor para o modo de espera após um failover.
Eu aconselharia não monitorar isso diretamente no host. Em nosso ambiente, utilizamos o Pacemaker para automatizar failovers. Uma das coisas que o Pacemaker faz por nós é mover um endereço IP no failover. Isso garante que nossos clientes estejam sempre apontando para o primário e ajuda a tornar os failovers transparentes do lado do cliente.
Para o Nagios, monitoramos uma série de serviços em cada host para ficar de olho nas coisas, mas temos um "host" adicional configurado para o endereço IP virtual/flutuante para monitorar os dispositivos e serviços DRBD que estão sendo executados apenas no primário.
No meu ambiente, gerenciamos vários serviços executados em cima de dispositivos drbd (tradicional, contêineres lxc, contêineres docker, bancos de dados, ...). Usamos a pilha opensvc ( https://www.opensvc.com ), que é gratuita e de código aberto, e fornece recursos de failover automático. Abaixo está um serviço de teste com drbd e um aplicativo redis (desativado no exemplo)
Primeiro no nível do cluster, podemos ver na
svcmonsaída que:No nível de serviço
svcmgr -s servdrbd print status, podemos ver:Para simular um problema, desconectei o dispositivo drbd no nó secundário e isso produz os seguintes avisos
É importante ver que o status de disponibilidade do serviço ainda está ativo , mas o status geral do serviço está degradado para avisar , o que significa "ok, a produção ainda está funcionando bem, mas algo dá errado, dê uma olhada"
Assim que você estiver ciente de que todos os comandos opensvc podem ser usados com o seletor de saída json (
nodemgr daemon status --format jsonousvcmgr -s servdrbd print status --format json), é fácil conectá-lo a um script NRPE e apenas monitorar os estados do serviço. E como você viu, qualquer problema no primário ou secundário está preso.O
nodemgr daemon statusé melhor porque é a mesma saída em todos os nós do cluster e todas as informações dos serviços opensvc são exibidas em uma única chamada de comando.Se você estiver interessado no arquivo de configuração do serviço para esta configuração, postei no pastebin aqui
Você pode usar check_multi para executar ambas as verificações do DRBD como uma única verificação do Nagios e configurá-lo para retornar OK se exatamente uma das subverificações estiver OK.
No entanto, fica complicado quando você precisa decidir qual host anexar o cheque também. Você pode anexá-lo a um host usando o VIP ou anexar a verificação a ambos os hosts e usar NRPE/ssh em cada um para verificar o outro, etc.