Monitoramento de verniz com pulsação e marcapasso

Question

Eu tenho um par de servidores configurados como balanceadores de carga de alta disponibilidade / proxies reversos. Cada um roda o Ubuntu 12.04 x64 Server, Varnish, Heartbeat e Pacemaker, com o tráfego de balanceamento de carga do Varnish para servidores back-end.

Se um dos balanceadores de carga cair, o Heartbeat / Pacemaker transfere um grupo de IPs virtuais para o outro servidor e o fluxo de tráfego é retomado. Esse bit funciona bem.

O que eu não expliquei é se o Varnish não está sendo executado em nenhum dos servidores. Atualmente, é possível parar o verniz sem desencadear qualquer tipo de ação do Heartbeat / Pacemaker. Eu gostaria que a falta de um Varnish operacional no servidor atual desencadeasse uma mudança para o backup (em vez de tentar reiniciar o Varnish), mas estou com dificuldades para encontrar qualquer tipo de orientação on-line. Alguém pode ajudar?

Editar assistência pós-Daff:

Acabei com algo um pouco diferente da minha solicitação original: o Pacemaker tenta reiniciar o Verniz uma vez e, se isso falhar, ele move todos os recursos para o nó passivo.

Minha configuração é de dois servidores, serverA (ativo) e serverB (passivo). Presumo que a camada de mensagens (Heartbeat ou Corosync) já esteja configurada e funcionando. Para permitir que o Pacemaker controle o verniz, precisamos corrigir o script de inicialização do Varnish do Ubuntu:

sudo vim /etc/init.d/varnish

Substituir:

--start --quiet --pidfile ${PIDFILE} --exec ${DAEMON} -- \

na função start_varnish_d () com:

--start --quiet --pidfile ${PIDFILE} --oknodo --exec ${DAEMON} -- \

Funciona de acordo com as regras descritas aqui . Agora configure um cluster básico do Pacemaker no serverA com dois IPs virtuais:

sudo crm configure property no-quorum-policy=ignore
sudo crm configure property stonith-enabled=false
sudo crm configure primitive virtual_ip_1 ocf:heartbeat:IPaddr params ip="192.168.1.134" nic="eth1" cidr_netmask="24" broadcast="192.168.1.255" op monitor interval="10s" timeout="20s"
sudo crm configure primitive virtual_ip_2 ocf:heartbeat:IPaddr params ip="192.168.1.135" nic="eth1" cidr_netmask="24" broadcast="192.168.1.255" op monitor interval="10s" timeout="20s"

Adicione uma primitiva para Varnish, fornecendo uma frequência de monitoramento e intervalos generosos para iniciar e parar o verniz:

sudo crm configure primitive varnish lsb:varnish op monitor interval="10s" timeout="20s" op
start interval="0" timeout="15s" op stop interval="0" timeout="15s"

Agrupe a primitiva de verniz com os IPs virtuais, para que o Pacemaker migre todos os recursos para o nó passivo no caso de uma falha:

sudo crm configure group cluster virtual_ip_1 virtual_ip_2 varnish

Defina o limite de migração, para que o Pacemaker tolere duas falhas antes de mover todos os recursos para o nó passivo. Para o Varnish, isso significa uma falha inicial e uma tentativa de reinicialização com falha:

sudo crm_attribute --type rsc_defaults --attr-name migration-threshold --attr-value 2

Defina um tempo limite de falha. Isto parece para fazer duas coisas:

1. Dá ao Pacemaker tempo para uma tentativa de reinício do Varnish antes migrando para o nó passivo.

2. Impede que o nó com falha seja marcado como com falha após 30s, permitindo que os recursos sejam movidos de volta para ele sem ter que executar manualmente o verniz de limpeza de recurso crm após uma falha. Isso é bom para minha configuração, já que não tenho nenhuma ponderação definida nos nós, mas pode ser uma ideia muito ruim em um ambiente diferente.

sudo crm_attribute --type rsc_defaults --attr-name failure-timeout --attr-value 30s

E é isso, mas veja a resposta de Daff abaixo para comentários sobre viscosidade, que eu não acabei usando. A única desvantagem que posso ver é que, se você colocar manualmente um nó no modo de espera, o Pacemaker desligará o verniz nesse nó, limpando assim o cache na memória. Para mim, isso não é particularmente importante.

    

Answer 1

Sua arquitetura de cluster me confunde, pois parece que você está executando serviços que devem ser gerenciados em cluster (como o Varnish) autônomo em dois nós ao mesmo tempo e deixar o gerenciador de recursos de cluster (CRM) manipular apenas os endereços IP.

O que você deseja alcançar com sua configuração de cluster? Tolerância ao erro? Balanceamento de carga? Ambos? Lembre-se, estou falando sobre os recursos do cluster (verniz, endereços IP, etc.), não os servidores de backend para os quais o Varnish distribui a carga.

Para mim, parece que você quer um cluster ativo-passivo de dois nós, que fornece tolerância a falhas. Um nó está ativo e executa Varnish, os endereços IP virtuais e possivelmente outros recursos, e o outro nó é passivo e não faz nada até que o gerenciador de recursos do cluster mova os recursos para o nó passivo, quando fica ativo. Essa é uma arquitetura testada e verdadeira que é tão antiga quanto o próprio tempo. Mas para que isso funcione, você precisa dar ao CRM controle total sobre os recursos. Recomendo seguir os Clusters do Scratch e modelar seu cluster depois disso .

Editar após sua pergunta atualizada: seu CIB parece ser bom, e uma vez que você corrigiu o script init para que as chamadas repetidas para "start" retornem 0, você deve poder adicionar o seguinte primitivo (ajustar os tempos limite e intervalos ao seu gosto):

primitive p_varnish lsb:varnish \
    op monitor interval="10s" timeout="15s" \
    op start interval="0" timeout="10s" \
    op stop interval="0" timeout="10s" 

Não se esqueça de adicioná-lo ao grupo de balanceadores (o último elemento da lista):

group balancer eth0_gateway eth1_iceman_slider eth1_iceman_slider_ts \
    eth1_iceman_slider_pm eth1_iceman_slider_jy eth1_iceman eth1_slider \
    eth1_viper eth1_jester p_varnish

Editar 2 : para diminuir o limite de migração, adicione uma seção de padrões de recursos no final do seu CIB e defina a propriedade migration-threshold como um número baixo. Configurar para 1 significa que o recurso será migrado após uma única falha. Também é uma boa ideia definir a rigidez do recurso para que um recurso que tenha sido migrado devido à falha do nó (reinicialização ou desligamento) não seja automaticamente migrado de volta mais tarde quando o nó estiver disponível novamente.

rsc_defaults $id="rsc-options" \
    resource-stickiness="100" \
    migration-threshold="1"