No momento, há muitas opções para configurar um cluster Linux.
Para o gerenciador de cluster: você pode usar o Red Hat Cluster Manager, o Pacemaker ou o Veritas Cluster Server. O primeiro tem o maior momento, o segundo vem por padrão com assinaturas RH e o último é muito caro e tem uma reputação muito boa; -)
Para armazenamento: - Você pode replicar o LUN usando o software raid / md device - Você pode usar a rede usando replicação DRBD, que oferece um pouco mais de flexibilidade - Você pode usar a tecnologia Veritas Storage Foundation para conversar com a tecnologia de replicação de SANs.
Alguém tem alguma recomendação ou experiência com essas tecnologias?
Eu iria com o GlusterFS. A versão mais recente 3.x suporta a replicação geográfica (tipo de coisa de tubo longo latente), bem como a replicação da LAN. Há vários documentos sobre como replicar e distribuir dados pelo cluster.
Eu não gosto de DRDB, porque há um limite no número de nós que você pode usar. Eu acho que o GlusterFS em hardware decente, com um pouco de ajuste de rede decente pode ser o que você está procurando. Definitivamente vale uma sessão de testes.
No momento, estou testando o "cluster estendido" usando o Red Hat Cluster Suite e o DRBD. Estou digitando isso em um hotel perto do Red Hat Summit em Boston, que acabou de terminar. Conversei com os desenvolvedores do Red Hat CLuster Suite e eles disseram que clusters estendidos não eram suportados no momento.
Isso não vai me impedir de trabalhar nisso por diversão embora. Minha configuração é de quatro blades HP em um único cluster. Duas lâminas estão em um datacenter a cerca de 15 milhas do outro datacenter que abriga as outras duas lâminas. Para fazer com que o cluster se unisse, precisei que a equipe de rede configurasse os roteadores entre os sites para transmitir o tráfego de multidifusão. Além disso, como a Red Hat codifica com rigidez um TTL de "1" para os pacotes de pulsação de multicast, tive que usar o iptables para manipular esse endereço multicast para um TTL mais alto.
Depois disso, consegui um cluster de quatro nós com meus blades. Para armazenamento, eu tenho um 3Par LUN compartilhado em cada site entre cada um de seus dois nós locais. Estes são os dispositivos de bloco que uso para meus dispositivos DRBD. Eu devo adicionar aqui que eu tenho um link 1G WAN dedicado para apenas o meu tráfego DRBD. Consegui que o DRBD rodasse facilmente entre os sites e usasse esse dispositivo DRBD como um PV em um LV em cluster com o GFS2 sendo executado nele. Ocasionalmente, tenho condições de cérebro dividido na configuração do meu DRBD que devo recuperar manualmente e estou tentando isolar esse problema.
O próximo passo foi o mais difícil. Eu quero ser capaz de failover minha montagem GFS2 para o outro nó no caso de o primário falhar. Meu serviço GFS2 consiste em um IP flutuante - > DRBD - > LVM - > GFS2. O script drbd.sh que vem no código-fonte para o armazenamento em cluster não funciona de forma alguma, então eu tenho testado com o script de inicialização normal do DRBD em /etc/init.d. Parece funcionar "às vezes", então vou precisar ajustar o que parece.
Fiquei consternado ao descobrir que nada disso é suportado no Red Hat Cluster Suite, portanto, qualquer sonho que tive de mover isso para a produção é frustrado. E onde mais você precisaria desse tipo de configuração? Muito só material de produção muito importante.
Eu conversei com a Symantec aqui e eles me disseram que suportam absolutamente clusters estendidos ativo-ativo com armazenamento compartilhado. Eu vou acreditar nisso quando eu realmente ver isso.
O DRBD é muito lento, como todos sabem. Você não pode usar isso para fins corporativos de alta carga. Ele usa funções de hash de 128 KiB que limitam as solicitações de IO ao máximo. 128 KiB, em vez de 512 KiB, o que um disco rígido normal pode fornecer. Além disso, há uma detecção de tamanho de solicitação IO estúpida. Isso só funciona quando conectado ao outro host. Se você perder a conexão, ela será redefinida para 4 KiB em seus HDDs locais. 8.4.1 e 8.3.11 têm os mesmos problemas.
Aqui estão mais alguns detalhes: link
É por isso que as empresas reais usam materiais como a Veritas.
O MD RAID 1 é muito melhor se você precisar de desempenho por um preço baixo. Ele também fornece um modo "escrever principalmente" para que você possa evitar a leitura de um dispositivo lento.
Se você tem um backend de SAN, um sistema de arquivos de armazenamento compartilhado (GFS?) faz muito mais sentido do que o armazenamento replicado.
Nós usamos o DRBD no trabalho. Funciona muito bem, mas só usamos em uma configuração de dois nós. Eu realmente não consideraria isso como algo mais complicado.
software raid / md, enquanto o DRBD superficialmente é apenas RAID 1 através da rede, na realidade o DRBD é significativamente mais complicado para lidar, e. com partições de rede temporárias sem precisar sincronizar novamente do zero e assim por diante.
Além disso, considere que o software RAID-1 normalmente tenta equilibrar a carga nas unidades, distribuindo leituras uniformemente sobre elas. Não é preciso dizer que isso não é uma boa ideia se uma unidade for local e a outra estiver em algum lugar atrás de um link de rede de largura de banda / alta latência potencialmente baixo.
IOW, o software RAID não é uma boa solução para replicação.
O cluster Metro / stretch só pode ser usado no modo de replicação assíncrona ou semi-síncrona, de modo que exclua md .
Trabalhei com o Veritas Volume Manager, cluster e cluster global em uma empresa do setor de finanças. Gostei muito.
Trabalhei com o espelhamento baseado em host de dispositivos SAN.
Eu tenho alguns clusters XEN executando o DRBD com discos locais para replicação entre dois data-centers (não muito distantes um do outro). Eu acabei de me deparar com alguns problemas na última sexta-feira, após uma curta desconexão da rede lá ...
O que realmente gostei da solução da Veritas é que ela pode ajustar todos os aspectos. Portanto, para uma aplicação db de leitura intensiva, ajustamos os volumes para que as leituras venham do data center principal colocado junto aos clientes - o que deu um enorme aumento de desempenho.
Assim, para replicação de armazenamento: se você puder pagar - vá para a Veritas.
Agora, para o software de cluster: conheci Veritas, Sun, AIX / HACMP / HAGEO, HP-Serviceguard e Linux-Heartbeat.
Eu gostei mais do Veritas e gostei especialmente do modo como ele previne cérebros divididos (modo de risco) ...
Mas você pode conseguir o mesmo em qualquer outro software de cluster, se você usar linhas independentes para heartbeats - então invista nessas linhas - ao invés do software.
Eu posso citar Alan Robertson aqui: "Um cluster não é um cluster, a menos que você o tenha testado."
E eu vi mais downtimes por causa de uma complexa configuração de cluster do que de economias com essa configuração. Então, fique simples (Heartbat v1 em vez de v2).