Um cluster no Pacemaker é um sistema orientado a eventos, onde um evento pode ser uma falha de recurso ou nó, uma mudança de configuração ou um recurso iniciando ou parando. Você pode configurar alertas de cluster do Pacemaker para executar alguma ação externa quando um evento de cluster ocorre por meio de agentes de alerta, que são programas externos que o cluster chama da mesma maneira que o cluster chama os agentes de recursos para lidar com a configuração e operação de recursos.
O cluster passa informações sobre o evento para o agente por meio de variáveis de ambiente. Os agentes podem fazer qualquer coisa com essas informações, como enviar uma mensagem de e-mail ou registrar em um arquivo ou atualizar um sistema de monitoramento.
- Pacemaker fornece vários agentes de alerta de amostra(arquivos “pré-prontos” que podemos aproveitar e reusar), que são instalados em /usr/share/pacemaker/alerts por padrão. Esses scripts de amostra podem ser copiados e usados como estão ou podem ser usados como modelos a serem editados para atender às suas finalidades. Consulte o código-fonte dos agentes de amostra para obter o conjunto completo de atributos que eles suportam.
- Se os agentes de alerta de amostra não atenderem às suas necessidades, você poderá escrever seus próprios agentes de alerta para um alerta Pacemaker chamar.
Exemplo Simples
Esse exemplo é bastante simples mas tem o objetivo de clarear o entendimento do conteúdo seguinte.
É importante saber que os eventos são executados pelo usuário hacluster. Então, se você não está tendo êxito na execução de um script ou comando pode ser que o usuário hacluster não tenha permissão. Uma dica que dou é habilitar esse usuário para usar sudo sem senha.
Vamos ao passo a passo. Vou fazer com que toda vez que ocorra uma alteração no cluster seja adicionada uma linha contendo o texto “teste do pacemaker” dentro do arquivo /tmp/teste.txt
#1 crie o arquivo /tmp/teste.txt
touch /tmp/teste.txt
#2 agora, crie um script /usr/bin/teste.sh com o seguinte conteúdo
#! /bin/bash echo "teste do pacemaker" >> /tmp/teste.txt
#3 vamos criar o alerta. Execute o comando abaixo
pcs alert create id=teste path=/usr/bin/teste.sh
Agora, qualquer evento gerado executará o script /usr/bin/teste.sh será executado.
Instalando e configurando agentes de alerta de amostra com pacemaker
Ao usar um dos agentes de alerta de amostra, você deve revisar o script para garantir que ele atenda às suas necessidades. Esses agentes de amostra são fornecidos como ponto de partida para scripts customizados para ambientes de cluster específicos. Observe que, embora a Red Hat suporte as interfaces que os scripts dos agentes de alerta usam para se comunicar com o Pacemaker, a Red Hat não fornece suporte para os próprios agentes personalizados.
Para usar um dos agentes de alerta de amostra, você deve instalar o agente em cada nó no cluster. Por exemplo, o comando a seguir instala o script alert_file.sh.sample como alert_file.sh.
install --mode=0755 /usr/share/pacemaker/alerts/alert_file.sh.sample /var/lib/pacemaker/alert_file.sh
O programa install, que usamos acima, copia arquivos (geralmente apenas compilados) para localizações de destino que você escolher. Se você deseja baixar e instalar um pacote pronto-para-uso em um sistema GNU/Linux, você deve usar um gerenciador de pacotes como yum ou apt-get.
Depois de instalar o script, você pode criar um alerta que usa o script.
O exemploacima configura um alerta que usa o agente de alerta alert_file.sh instalado para registrar eventos em um arquivo. Os agentes de alerta são executados como o usuário hacluster, que possui um conjunto mínimo de permissões.
Este exemplo cria o arquivo de log pcmk_alert_file.log que será usado para registrar os eventos. Em seguida, ele cria o agente de alerta e inclui o caminho no arquivo de log como seu destinatário.
touch /var/log/pcmk_alert_file.log chown hacluster:haclient /var/log/pcmk_alert_file.log chmod 600 /var/log/pcmk_alert_file.log pcs alert create id=alert_file description="Log events to a file." path=/var/lib/pacemaker/alert_file.sh pcs alert recipient add alert_file id=my-alert_logfile value=/var/log/pcmk_alert_file.log
O exemplo a seguir instala o script alert_snmp.sh.sample como alert_snmp.sh e configura um alerta que usa o agente de alerta alert_snmp.sh instalado para enviar eventos de cluster como traps SNMP. Por padrão, o script enviará todos os eventos, exceto chamadas de monitor bem-sucedidas para o servidor SNMP. Este exemplo configura o formato de carimbo de data/hora como uma opção meta. Depois de configurar o alerta, este exemplo configura um destinatário para o alerta e exibe a configuração do alerta.
install --mode=0755 /usr/share/pacemaker/alerts/alert_snmp.sh.sample /var/lib/pacemaker/alert_snmp.sh pcs alert create id=snmp_alert path=/var/lib/pacemaker/alert_snmp.sh meta timestamp-format="%Y-%m-%d,%H:%M:%S.%01N" pcs alert recipient add snmp_alert value=192.168.1.2 pcs alert
O exemplo a seguir instala o agente alert_smtp.sh e, em seguida, configura um alerta que usa o agente de alerta instalado para enviar eventos de cluster como mensagens de email. Depois de configurar o alerta, este exemplo configura um destinatário e exibe a configuração do alerta.
install --mode=0755 /usr/share/pacemaker/alerts/alert_smtp.sh.sample /var/lib/pacemaker/alert_smtp.sh pcs alert create id=smtp_alert path=/var/lib/pacemaker/alert_smtp.sh options email_sender=donotreply@example.com pcs alert recipient add smtp_alert value=admin@example.com pcs alert
Criando um alerta de cluster com pacemaker
O comando a seguir cria um alerta de cluster. As opções que você configura são valores de configuração específicos do agente que são transmitidos para o script do agente de alerta no caminho especificado como variáveis de ambiente adicionais. Se você não especificar um valor para id, um será gerado.
pcs alert create path=path [id=alert-id] [description=description] [options [option=value]...] [meta [meta-option=value]...]
Vários agentes de alerta podem ser configurados; o cluster chamará todos eles para cada evento. Os agentes de alerta serão chamados apenas nos nós do cluster. Eles serão chamados para eventos envolvendo nós Remotos do Pacemaker, mas nunca serão chamados nesses nós.
O exemplo a seguir cria um alerta simples que chamará myscript.sh para cada evento.
pcs alert create id=my_alert path=/path/to/myscript.sh
Exibindo, modificando e removendo alertas de cluster no pacemaker
Há uma variedade de comandos pcs que você pode usar para exibir, modificar e remover alertas de cluster.
O comando a seguir mostra todos os alertas configurados junto com os valores das opções configuradas.
pcs alert [config|show]
O comando a seguir atualiza um alerta existente com o valor alert-id especificado.
pcs alert update alert-id [path=path] [description=description] [options [option=value]...] [meta [meta-option=value]...]
O comando a seguir remove um alerta com o valor alert-id especificado.
pcs alert remove alert-id
Como alternativa, você pode executar o comando pcs alert delete, que é idêntico ao comando pcs alert remove. Os comandos pcs alert delete e pcs alert remove permitem que você especifique mais de um alerta a ser excluído.
Configurando destinatários de alerta de cluster
Normalmente, os alertas são direcionados a um destinatário. Assim, cada alerta pode ser configurado adicionalmente com um ou mais destinatários. O cluster chamará o agente separadamente para cada destinatário.
O destinatário pode ser qualquer coisa que o agente de alerta possa reconhecer: um endereço IP, um endereço de e-mail, um nome de arquivo ou qualquer coisa que o agente específico suporte.
O comando a seguir adiciona um novo destinatário ao alerta especificado.
pcs alert recipient add alert-id value=recipient-value [id=recipient-id] [description=description] [options [option=value]...] [meta [meta-option=value]...]
O comando a seguir atualiza um destinatário de alerta existente.
pcs alert recipient update recipient-id [value=recipient-value] [description=description] [options [option=value]...] [meta [meta-option=value]...]
O comando a seguir remove o destinatário do alerta especificado.
pcs alert recipient remove recipient-id
Como alternativa, você pode executar o comando pcs alert recipient delete, que é idêntico ao comando pcs alert recipient remove. Ambos os comandos permitem que você remova mais de um destinatário de alerta.
O comando de exemplo a seguir adiciona o destinatário do alerta my-alert-recipient com um ID de destinatário my-recipient-id ao alerta my-alert. Isso configurará o cluster para chamar o script de alerta que foi configurado para my-alert para cada evento, passando o destinatário some-address como uma variável de ambiente.
pcs alert recipient add my-alert value=my-alert-recipient id=my-recipient-id options value=some-address
Opções de meta de alerta
Assim como acontece com os agentes de recursos, as metaopções podem ser configuradas para que os agentes de alerta afetem como o Pacemaker os chama. A tabela a seguir descreve as metaopções de alerta. As opções meta podem ser configuradas por agente de alerta, bem como por destinatário.
Table 28.1. Alert Meta Options
| Meta-Attribute | Padrão | Descrição |
|---|---|---|
timestamp-format | %H:%M:%S.%06N | Formato que o cluster usará ao enviar o timestamp do evento para o agente. Esta é uma string usada com o comando date(1). |
timeout | 30s | Se o agente de alerta não for concluído dentro desse período de tempo, ele será encerrado. |
O exemplo a seguir configura um alerta que chama o script myscript.sh e adiciona dois destinatários ao alerta. O primeiro destinatário tem um ID de my-alert-recipient1 e o segundo destinatário tem um ID de my-alert-recipient2. O script será chamado duas vezes para cada evento, com cada chamada usando um tempo limite de 15 segundos. Uma chamada será passada para o destinatário someuser@example.com com um timestamp no formato %D %H:%M, enquanto a outra chamada será passada para o destinatário otheruser@example.com com um timestamp no formato %c
pcs alert create id=my-alert path=/path/to/myscript.sh meta timeout=15s pcs alert recipient add my-alert value=someuser@example.com id=my-alert-recipient1 meta timestamp-format="%D %H:%M" pcs alert recipient add my-alert value=otheruser@example.com id=my-alert-recipient2 meta timestamp-format="%c"
Exemplos de comando de configuração de alerta de cluster
Os exemplos a seguir mostram alguns comandos básicos de configuração de alerta para mostrar o formato a ser usado para criar alertas, adicionar destinatários e exibir os alertas configurados. Observe que, embora você deva instalar os próprios agentes de alerta em cada nó em um cluster, é necessário executar os comandos pcs apenas uma vez. Os comandos a seguir criam um alerta simples, adicionam dois destinatários ao alerta e exibem os valores configurados.
- Como nenhum valor de ID de alerta é especificado, o sistema cria um valor de ID de alerta de alert.
- O primeiro comando de criação de destinatário especifica um destinatário de rec_value. Como esse comando não especifica um ID de destinatário, o valor de alert-recipient é usado como o ID de destinatário.
- O segundo comando de criação de destinatário especifica um destinatário de rec_value2. Este comando especifica um ID de destinatário de my-recipient para o destinatário.
# pcs alert create path=/my/path # pcs alert recipient add alert value=rec_value # pcs alert recipient add alert value=rec_value2 id=my-recipient # pcs alert config Alerts: Alert: alert (path=/my/path) Recipients: Recipient: alert-recipient (value=rec_value) Recipient: my-recipient (value=rec_value2)
Os seguintes comandos adicionam um segundo alerta e um destinatário para esse alerta. O ID de alerta para o segundo alerta é my-alert e o valor do destinatário é my-other-recipient. Como nenhum ID de destinatário é especificado, o sistema fornece um ID de destinatário de my-alert-recipient.
# pcs alert create id=my-alert path=/path/to/script description=alert_description options option1=value1 opt=val meta timeout=50s timestamp-format="%H%B%S" # pcs alert recipient add my-alert value=my-other-recipient # pcs alert Alerts: Alert: alert (path=/my/path) Recipients: Recipient: alert-recipient (value=rec_value) Recipient: my-recipient (value=rec_value2) Alert: my-alert (path=/path/to/script) Description: alert_description Options: opt=val option1=value1 Meta options: timestamp-format=%H%B%S timeout=50s Recipients: Recipient: my-alert-recipient (value=my-other-recipient)
Os comandos a seguir modificam os valores de alerta para o alerta my-alert e para o destinatário my-alert-recipient.
# pcs alert update my-alert options option1=newvalue1 meta timestamp-format="%H%M%S"
# pcs alert recipient update my-alert-recipient options option1=new meta timeout=60s
# pcs alert
Alerts:
Alert: alert (path=/my/path)
Recipients:
Recipient: alert-recipient (value=rec_value)
Recipient: my-recipient (value=rec_value2)
Alert: my-alert (path=/path/to/script)
Description: alert_description
Options: opt=val option1=newvalue1
Meta options: timestamp-format=%H%M%S timeout=50s
Recipients:
Recipient: my-alert-recipient (value=my-other-recipient)
Options: option1=new
Meta options: timeout=60s
O comando a seguir remove o destinatário my-alert-recipient do alerta.
# pcs alert recipient remove my-recipient
# pcs alert
Alerts:
Alert: alert (path=/my/path)
Recipients:
Recipient: alert-recipient (value=rec_value)
Alert: my-alert (path=/path/to/script)
Description: alert_description
Options: opt=val option1=newvalue1
Meta options: timestamp-format="%M%B%S" timeout=50s
Recipients:
Recipient: my-alert-recipient (value=my-other-recipient)
Options: option1=new
Meta options: timeout=60s
O comando a seguir remove myalert da configuração.
# pcs alert remove myalert # pcs alert Alerts: Alert: alert (path=/my/path) Recipients: Recipient: alert-recipient (value=rec_value)
Criando um agente de alerta de cluster
Existem três tipos de alertas de cluster do Pacemaker:
- node alerts,
- fencing alerts,
- resource alerts.
As variáveis de ambiente transmitidas aos agentes de alerta podem ser diferentes, dependendo do tipo de alerta. A tabela a seguir descreve as variáveis de ambiente que são transmitidas aos agentes de alerta e especifica quando a variável de ambiente é associada a um tipo de alerta específico.
Obs.: as palavras resources e recursos têm o mesmo sentido.
| Variável de ambiente | Descrição |
|---|---|
CRM_alert_kind | O tipo de alerta (node, fencing, ou resource)) |
CRM_alert_version | A versão do Pacemaker que envia o alerta |
CRM_alert_recipient | O destinatário configurado |
CRM_alert_node_sequence | Um número de sequência aumentado sempre que um alerta está sendo emitido no nó local, que pode ser usado para referenciar a ordem em que os alertas foram emitidos pelo Pacemaker. Um alerta para um evento que ocorreu posteriormente no tempo tem de forma confiável um número de sequência maior do que os alertas para eventos anteriores. Esteja ciente de que esse número não tem significado em todo o cluster. |
CRM_alert_timestamp | Um carimbo de data/hora criado antes da execução do agente, no formato especificado pela timestamp-formatopção meta. Isso permite que o agente tenha um tempo confiável e de alta precisão de quando o evento ocorreu, independentemente de quando o próprio agente foi chamado (o que pode ser atrasado devido à carga do sistema ou outras circunstâncias). |
CRM_alert_node | Nome do nó afetado |
CRM_alert_desc | Detalhe sobre o evento. Para alertas de nó, este é o estado atual do nó (membro ou perdido). Para alertas de fencing, este é um resumo da operação de fencing solicitada, incluindo origem, destino e código de erro da operação de fencing, se houver. Para alertas de recursos, esta é uma string legível equivalente a CRM_alert_status. |
CRM_alert_nodeid | ID do nó cujo status foi alterado (fornecido apenas com alertas de nó) |
CRM_alert_task | A operação de proteção ou recurso solicitada (fornecida apenas com alertas de proteção e recurso) |
CRM_alert_rc | O código numérico de retorno da operação de fencing ou recurso (fornecido apenas com alertas de fencing e recurso) |
CRM_alert_rsc | O nome do resource afetado (somente alertas de recurso) |
CRM_alert_interval | O intervalo da operação de resource (somente alertas de recurso) |
CRM_alert_target_rc | O código de retorno numérico esperado da operação (somente alertas de recursos) |
CRM_alert_status | Um código numérico usado pelo Pacemaker para representar o resultado da operação (somente alertas de recursos) |
Ao escrever um agente de alerta, você deve levar em consideração as seguintes preocupações.
- Os agentes de alerta podem ser chamados sem destinatário (se nenhum estiver configurado), portanto o agente deve ser capaz de lidar com essa situação, mesmo que só saia nesse caso. Os usuários podem modificar a configuração em etapas e adicionar um destinatário posteriormente.
- Se mais de um destinatário for configurado para um alerta, o agente de alerta será chamado uma vez por destinatário. Se um agente não puder ser executado simultaneamente, ele deverá ser configurado com apenas um único destinatário. O agente é livre, no entanto, para interpretar o destinatário como uma lista.
- Quando ocorre um evento de cluster, todos os alertas são disparados ao mesmo tempo como processos separados. Dependendo de quantos alertas e destinatários estão configurados e do que é feito nos agentes de alerta, pode ocorrer uma explosão de carga significativa. O agente pode ser escrito para levar isso em consideração, por exemplo, enfileirando ações com uso intensivo de recursos em alguma outra instância, em vez de executá-las diretamente.
- Os agentes de alerta são executados como o
haclusterusuário, que possui um conjunto mínimo de permissões. Se um agente exigir privilégios adicionais, é recomendável configurarsudopara permitir que o agente execute os comandos necessários como outro usuário com os privilégios apropriados. - Tome cuidado para validar e limpar os parâmetros configurados pelo usuário, como
CRM_alert_timestamp(cujo conteúdo é especificado pelo configurado pelo usuáriotimestamp-format),CRM_alert_recipiente todas as opções de alerta. Isso é necessário para proteger contra erros de configuração. Além disso, se algum usuário puder modificar o CIB sem terhaclusteracesso de nível aos nós do cluster, isso também é uma preocupação de segurança potencial e você deve evitar a possibilidade de injeção de código. - Se um cluster contém recursos com operações para as quais o
on-failparâmetro é definido comofence, haverá várias notificações de cerca em caso de falha, uma para cada recurso para o qual esse parâmetro é definido mais uma notificação adicional. Tanto opacemaker-fencedquantopacemaker-controldenviarão notificações. O pacemaker executa apenas uma operação de cerca real neste caso, no entanto, não importa quantas notificações sejam enviadas.
Nota: A interface de alertas foi projetada para ser compatível com a interface de scripts externos usada pelo resource ocf:pacemaker:ClusterMon. Para preservar essa compatibilidade, as variáveis de ambiente transmitidas aos agentes de alerta estão disponíveis acompanhadas CRM_notify_de CRM_alert_. Uma quebra na compatibilidade é que o resource ClusterMon executou scripts externos como o usuário raiz, enquanto os agentes de alerta são executados como o haclusterusuário.
Fontes: redhat