Como posso executar um cluster do CentOS (Red Hat) no modo degradado?

Question

Instalei o software de cluster da Red Hat em uma instalação do CentOS 6.5 e o uso para fornecer roteamento redundante de uma rede para outra. Isso funciona bem, e eu tenho um par de caixas fornecendo o serviço, de modo que, se uma falhar (por exemplo, se eu testar removendo suas conexões de rede), a outra assume o roteamento.

No entanto, se eu tiver que fazer algo na caixa restante, não posso reiniciá-lo devido a problemas com o rgmanager:

service rgmanager stop

trava, e a única maneira de parar o processo é kill -9 it. Isso obviamente também afeta qualquer ação que tente interromper o serviço, como reboot ou poweroff .

Quando eu consigo iniciar o servidor sozinho, embora o cluster seja iniciado, o rgmanager não é mostrado como sendo executado em clustat e nenhum dos serviços de roteamento redundantes é visível, quanto mais iniciar.

Isso pode causar problemas se, por exemplo, as caixas forem implantadas em um local remoto e precisarem ser desativadas antes de termos a chance de substituir a caixa com falha.

Aqui está o meu cluster.conf:

<?xml version="1.0"?>
<cluster config_version="2" name="router-ha">
        <fence_daemon/>
        <clusternodes>
                <clusternode name="router-01" nodeid="1"/>
                <clusternode name="router-02" nodeid="2"/>
        </clusternodes>
        <cman expected_votes="1" two_node="1"/>
        <fencedevices/>
        <rm>
                <failoverdomains/>
                <resources>
                        <ip address="10.0.0.1" monitor_link="1" sleeptime="0"/>
                        <ip address="10.0.0.2" monitor_link="1" sleeptime="0"/>
                        <ip address="10.2.0.1" monitor_link="1" sleeptime="0"/>
                        <ip address="10.4.0.1" monitor_link="1" sleeptime="0"/>
                </resources>
                <service autostart="1" name="routing-a" recovery="restart">
                        <ip ref="10.0.0.1"/>
                        <ip ref="10.2.0.1"/>
                </service>
                <service autostart="1" name="routing-b" recovery="restart">
                        <ip ref="10.0.0.2"/>
                        <ip ref="10.4.0.1"/>
                </service>
        </rm>
</cluster>

Por que não consigo iniciar o serviço em uma única caixa se ele não puder ver o outro? Certamente, é uma parte necessária de ser um par redundante que você não depende da outra máquina para poder iniciar um serviço de cluster?

    

Answer 1

Para executar serviços em cluster, é necessário um quorum. Normalmente, por exemplo, em um cluster de três nós, cada membro tem um voto cada: se você puxar o plugue em um, ele saberá que ele é inquirido, pois tem menos da metade dos votos disponíveis (o valor é realmente configurável). Um cluster sem quorum não é adequado para executar serviços em cluster.

Este princípio não é apenas para os clusters da Red Hat, mas um princípio geral. As soluções e implementações podem variar. Além disso, as implementações de clusters de dois nós, desde que se você der a ambos os nós um voto cada, nem um único deles seria normalmente quorate.

Surely it's a required part of being a redundant pair that you don't depend on the other machine to be able to start a cluster service?

No caso do Red Hat, em um cluster de dois nós, uma condição especial se aplica:

    <cman expected_votes="1" two_node="1"/>

O que acontecerá quando você puxar o plugue é que ambos os nós perderão contato um com o outro.

Para determinar qual deles tem quorum, eles tentarão STONITH um ao outro.

STONITH is an acronym for Shoot-The-Other-Node-In-The-Head and it protects your data from being corrupted by rogue nodes or concurrent access. Just because a node is unresponsive, this does not mean it is not accessing your data. The only way to be 100% sure that your data is safe, is to fence the node using STONITH so we can be certain that the node is truly offline, before allowing the data to be accessed from another node.

Portanto, a suposição que você faz está correta, seu cluster está configurado incorretamente e requer que um agente fence funcione, porque, ao extrair o plugue, você não apenas torna seu serviço indisponível, o que normalmente faria com que rgmanager falhasse. para outro nó (ou como você já o configurou para fazer), você também remove o link heartbeat entre os nós em cluster. Mesmo que rgmanager tente fazer o que você configurou, cman ainda não consegue descobrir qual desses nós tem quorum. Em vez disso, ele tentará cercar o outro nó de forma consistente, mas, como você não configurou o agente de fence, ele ficará preso indefinidamente.

Então, aqui estão dois bons conselhos para você:

1. separe o tráfego do cluster do tráfego da rede incluindo uma interface adicional nos nós do cluster, em uma rede isolada, para que, quando você puxar o plug na interface voltada para o aplicativo, o cluster faça um failover limpo
2. Configurar cercas.