Clusterizar responde a dois requisitos diferentes que são fáceis de confundir, e vale separá-los antes do mecanismo.

Disponibilidade e capacidade

Disponibilidade significa que um membro pode falhar e o tráfego continua. Isso exige capacidade suficiente nos sobreviventes para carregar a carga, que é a parte que as pessoas esquecem: dois membros rodando cada um a 70% não sobrevivem à perda de um.

Capacidade significa que os membros dividem a carga para que o cluster carregue mais do que qualquer um sozinho. Isso exige que o tráfego seja distribuído, e exige que a distribuição mantenha os pacotes de uma conexão indo para o mesmo membro — porque um firewall tem estado, e um pacote que chega a um membro que nunca viu a conexão é descartado como fora de estado.

A maior parte da complexidade de clusters em todos os fabricantes vem desse segundo requisito.

O que o ElasticXL muda

A Check Point descreve o ElasticXL como uma solução de cluster de alto desempenho e flexível para ambientes de grande escala, e a mudança operacional é que o cluster é tratado como uma entidade.

A consequência que importa no dia a dia é o que acontece ao acrescentar um membro. Num cluster tradicional, um membro novo é um equipamento a configurar, acrescentar ao objeto de cluster, licenciar e sincronizar — vários passos, cada um com seu jeito de dar errado. Onde o cluster é uma entidade lógica única, acrescentar capacidade fica mais perto de entrar do que de construir.

O mesmo vale para a gerência: a política é instalada no cluster, e os membros são detalhe de implementação, e não uma lista a manter.

Estou descrevendo isso no nível em que o próprio material de curso da Check Point o enuncia. Os comandos específicos e o procedimento exato de entrada são o tipo de detalhe que muda entre versões, e a posição honesta é tirá-los do guia de administração da versão à sua frente, e não da memória.

O que permanece verdadeiro independentemente do mecanismo

Algumas propriedades vêm da clusterização em si, e não de implementação alguma, e são sobre elas que a investigação se apoia.

O estado precisa ser compartilhado. Os membros sincronizam estado de conexão para que um failover não derrube sessões estabelecidas. A rede de sincronização carrega isso, e é o componente cuja falha produz os sintomas mais confusos: o cluster parece saudável e as conexões quebram no failover.

As interfaces precisam coincidir. Membros precisam de configuração de interface correspondente. Uma divergência produz um membro que não consegue participar corretamente, e o erro normalmente nomeia a interface, o que é mais útil que a maioria dos erros de cluster.

O failover não é de graça. Por mais rápido que seja, há um momento em que o tráfego é redirecionado. Conexões longas podem sobreviver pelo estado sincronizado; qualquer coisa no meio de um handshake pode não sobreviver.

Um cluster não é backup. Ele protege contra a falha de um membro. Não protege contra uma política ruim, que é instalada em todos os membros simultaneamente.

Verificar

As verificações que valem antes de acreditar que um cluster funciona:

Estado — todo membro no ar, um ativo ou todos dividindo conforme o modo, e nenhum membro num estado que ninguém consiga explicar.

Saúde da sincronização — que o estado está de fato sendo replicado, e não apenas que existe uma interface de sincronização.

Um failover real, uma vez, numa janela. Force e observe o que acontece com as conexões estabelecidas. Esse é o teste que encontra a diferença entre um cluster configurado e um que funciona, e vale a janela de manutenção justamente porque a resposta às vezes é desconfortável.

O que quem vai prestar o CCSE precisa saber de cor

Clusterizar serve à disponibilidade e à capacidade, e disponibilidade exige que os sobreviventes tenham folga para carregar a carga. A inspeção com estado significa que os pacotes de uma conexão precisam alcançar o membro que detém seu estado, e é daí que vem a complexidade. O ElasticXL trata o cluster como entidade única, então acrescentar capacidade fica mais perto de entrar do que de construir, e a política é instalada no cluster, e não nos membros. Independentemente da implementação: o estado é sincronizado por uma rede cuja falha quebra o failover enquanto o cluster parece saudável, as interfaces precisam coincidir, o failover não é de graça para conexões em curso, e um cluster não protege contra uma política ruim instalada em todos de uma vez.