CentOS 7: Dependência HAProxy ativa / ativa Corosync do PCS Pacemaker

Question

Estou tentando configurar o PCS para HAProxy no CentOS7 em uma configuração ativa / ativa. Já fiz ativo / ativo antes, mas não estou familiarizado com restrições e grupos de dependência.

Até aqui tudo bem:

 2 nodes configured
 4 resources configured

 Online: [ HOST1 HOST2 ]

 Full list of resources:

  Clone Set: VIPHA-clone [VIPHA] (unique)
      VIPHA:0     (ocf::heartbeat:IPaddr2):       Started HOST2
      VIPHA:1     (ocf::heartbeat:IPaddr2):       Started HOST1
  Clone Set: haproxy-clone [haproxy]
      Started: [ HOST2 HOST1 ]

No entanto, agora gostaria de adicionar uma restrição que o HAPRoxy deve estar executando para que o IP seja atendido por um host:

pcs constraint order haproxy-clone then VIPHA-clone

O problema é que o HAProxy nunca será iniciado porque não pode se ligar ao IP, a menos que seja iniciado primeiro.

Como eu configuraria isso para que:

1. pcs colocará o IP offline em um host se uma verificação de integridade (ou seja, processo haproxy em execução) falhar?

2. pcs só aumentará o IP se uma verificação de integridade (ou seja, processo haproxy em execução) for bem-sucedida?

   • Se isso não for possível, como descrito acima, comece ao mesmo tempo e se comporte como # 1

Eu aprecio qualquer entrada. Obrigada!

    

Answer 1

Eu ouço um curinga no haproxy.cfg

bind *:443

em vez de

bind myvip:443

Desta forma, o recurso haproxy pode ser executado o tempo todo, independentemente de o nó ter recursos VIP ou não. Se o nó receber um VIP, o haproxy responderá imediatamente.

O efeito colateral óbvio é que o haproxy escuta em todos os seus endereços IP, não apenas no VIP.

Se um número de porta entrar em conflito (por exemplo, eu preciso de uma porta 443 diferente configurada em outro IP ou VIP), eu o defino como bind *:9443 e depois o coloco atrás de um DNAT.

    

Answer 2

Se você não estiver vinculado ao marca-passo / corosync, o comportamento que você descreve pode ser obtido com opensvc , usando o arquivo de configuração de serviço abaixo:

[DEFAULT]
id = 84327b87-13f6-4d32-b90a-a7fad87a8d92
nodes = server1 server2
flex_min_nodes = 2
topology = flex
orchestrate = ha
monitor_action = freezestop

[ip#vip]
ipname@server1 = 192.168.100.240
ipname@server2 = 192.168.100.241
ipdev = br0
monitor = true

[app#haproxy]
type = simple
start = /sbin/haproxy -f /etc/haproxy/haproxy.cfg
restart = 1
monitor = true

Explicações:

[DEFAULT section são as configurações globais:

• id = .... ID de serviço exclusivo, gerado automaticamente no momento da criação do serviço ( svcmgr -s myservice create e, em seguida, svcmgr -s myservice edit config )

• nodes = server1 server2 significa que estamos executando dois nós opensvc cluster

• flex_min_nodes = 2 informam que esperamos que o serviço execute pelo menos 2 instâncias. Neste cluster de 2 nós, teremos 1 instância por nó.

• topology = flex especificam que estamos executando uma topologia de serviço ativo / ativo

• orchestrate = ha informa que o serviço precisa ser gerenciado automaticamente pelo daemon opensvc

• monitor_action = freezestop é usado para forçar o comportamento quando um recurso crítico é desativado (como um processo de falha do haproxy ou kill). Se isso acontecer, o O daemon opensvc tem que tomar uma decisão. 3 parâmetros possíveis:

  • freezestop : a instância do serviço local é interrompida e colocada no estado congelado.
  • reboot : o nó é reinicializado.
  • crash : o nó está com falha.

[ip#vip] : é usado para declarar o serviço vip:

• em server1 o ip 192.168.100.240 será configurado na interface br0 no início do serviço
• em server2 o ip 192.168.100.241 será configurado na interface br0 no início do serviço
• monitor = true informa opensvc agente que este recurso é crítico (se ele cair, acione o serviço monitor_action )

[app#haproxy] : descreve o material do aplicativo:

• type = simple especifica que o serviço gerencia um aplicativo de processo único (daemon não de bifurcação)
• start = /sbin/haproxy -f /etc/haproxy/haproxy.cfg é o comando a ser executado quando o serviço é iniciado
• restart = 1 diz ao daemon opensvc para tentar reiniciar 1 tempo este recurso se ele cair.
• monitor = true haproxy é um recurso crítico. Se ele cair, tente reiniciar 1 vez devido ao parâmetro anterior e, se ele falhar, acione o monitor_action

Como o serviço confia no vip, você não é obrigado a ligar *: 443, mas somente o serviço vip.

Sobre sua pergunta sobre restart / stonith se o haproxy cair, basta colocar um restart = 1 no [app#haproxy] para tentar reiniciar, e também um monitor_action = crash na seção DEFAULT . Dessa forma, 1 restart é tentado e, se isso não funcionar, o nó está com falha.

Espero que isso ajude.