Recomendação para uma infraestrutura de VM redundante pequena?

Question

Atualmente, temos um cluster ativo-ativo de 2 nós executando máquinas virtuais. Cada nó tem dois discos, cada disco é DRBD espelhado no outro nó. Cada nó executa máquinas virtuais a partir de seu dispositivo drbd principal, e o cluster de marca-passo manipulará o failover (se um nó falhar, o outro se tornará primário em ambos os dispositivos drbd e executará todas as VMs). Isso é colocado em um datacenter, portanto nossos custos (além da aquisição de hardware) são determinados por quantas unidades de rack ocupamos.

Quando você começa pequeno isso é uma ótima solução, ele se encaixa em 2U de espaço em rack (suponha que a (s) chave (s) ethernet já esteja (m)) e seja 100% redundante. Mas também é uma configuração um pouco difícil de gerenciar e ela sofre quando a carga de E / S fica muito alta (imagino que seja apenas por causa do baixo número de eixos).

Estou imaginando qual poderia ser a melhor solução para escalar acima de nossa capacidade de hardware e, ao mesmo tempo, ser econômica e ser tão redundante quanto razoável:

• vá adicionando mais dois clusters de nó com armazenamento interno, talvez com hardware maior (por exemplo, servidores 2U com mais discos)
• ainda usam clusters de dois nós, mas com armazenamento externo conectado diretamente (coisas como gabinetes de disco de 1U ou 2U com links SAS) - veja a nota abaixo
• armazenamento separado e VMs (por exemplo, um par de nós de armazenamento, espelhados pelo DRBD, que exportam iSCSI e gerenciam o failover movendo o IP de destino iSCSI, juntamente com dois ou mais nós sem disco que executam VMs fora do IP de destino estático iSCSI ) - isso parece ser o que os outros estão fazendo?
• usa algo diferente dos servidores padrão para a parte de armazenamento (soluções dedicadas de armazenamento em gigabit ethernet?)
• mais alguma coisa?

O armazenamento dividido / servidores de aplicativos parece a solução mais flexível e razoável para mim, poderíamos facilmente adicionar mais nós de armazenamento quando necessário e ainda usar os servidores de aplicativos atuais ou fazer o contrário quando atingimos os limites de capacidade.

O que você acha que são boas / más escolhas? Você já tem experiência com este tipo de coisas sem maiores orçamentos (eu tenho a tendência a descartar o canal de fibra ou dispositivos de armazenamento de 10000 euros)?

EDIT: Para ser claro, a idéia é que, aproveitando o software moderno (e gratuito), você poderia implementar redundância apenas adicionando mais hardware "commodity". Ele não vai ser tão rápido nem super-disponível, mas permitirá que a nossa VM seja executada mesmo se uma placa-mãe morrer pelo tempo que for necessário para obter uma reserva para o CD e substituir a peça.

EDIT: eu removi a usb mencionar porque realmente não vai a lugar nenhum (e obrigado por apontar isso em respostas). Eu realmente não sei como eu esqueci sobre gabinetes SAS. Como exemplo no site da Dell, um MD1000 é 2U com links SAS. Dois gabinetes anexados a dois nós de armazenamento via SAS e eles poderiam fazer redundância e exportar iSCSI.

    

Answer 1

Você definitivamente deseja separar os discos e as VMs porque deseja que os nós da VM acessem o armazenamento compartilhado (em vez de separar os espelhados) para que as operações de failover sejam quase perfeitas. Eu desaprovaria o cluster no nível do sistema operacional em favor do clustering no nível da VM, pois, na minha experiência, os armazenamentos de dados tendem a ser pontos mais vulneráveis do que o hardware e sistema operacional (desde que o SO tenha sido configurado para estabilidade) um nó de um cluster tende a passar para o outro nó (atualizações ruins, problemas de netowrk etc.), tornando ineficaz o clustering do SO. As VMs devem ter discos locais apenas para executar os hipervisores, mas os discos da máquina virtual devem estar no armazenamento compartilhado (e você desejará esse armazenamento compartilhado pelo menos no hardware RAID5). Colocar as VMs em um cluster de recursos compartilhados (a la VMWare) é o caminho a percorrer, pois permite que você faça um balanceamento de carga automático muito granular. Com essa configuração, adicionar novo hardware à configuração se torna uma questão de adicionar o novo servidor da VM ao disco compartilhado, colocar o Hypervisor nele e uni-lo ao cluster.

Eu não tenho nenhuma recomendação sobre o tipo de armazenamento compartilhado, pois as pessoas que conhecem o mundo do armazenamento compartilhado e as VMs tendem a ter dados muito bons e eu adio a opinião deles.

    

Answer 2

Os primeiros discos USB nunca proporcionam um bom desempenho.

Você parece querer duas coisas que normalmente não combinam. Uma solução altamente redundante e altamente disponível por pouco ou nenhum dinheiro. A redundância é cara, especialmente quanto mais opções você quiser. Na extremidade inferior das soluções redundantes, você tem soluções de armazenamento EMC, NetApp e Dell Equallogic menores. Todos suportam iSCSI e fibre channel para que você possa se conectar a eles como quiser. Eles praticamente começam no tamanho de 4-5U e sobem a partir daí. Eles fornecem uma boa plataforma de armazenamento que você pode criar em torno do seu cluster virtual.

Realizar replicação de armazenamento baseada em host de discos internos em uma caixa para discos internos em outra caixa simplesmente não será dimensionada por muito tempo. Eventualmente, a rede ficará sem largura de banda ou os discos não conseguirão acompanhar a carga em que você está colocando. E a replicação basicamente duplica a carga nos discos, pois cada gravação nos discos deve ser lida e, em seguida, transferida pela rede para o outro host para gravação lá. Além disso, todo o tráfego de pulsação que também precisa acontecer.

Se a empresa precisa ter uma solução de alta disponibilidade, ela deve realmente pagar por ela. Fazê-lo no pio só funcionará por tanto tempo e acabará mordendo você eventualmente.

    

Answer 3

A única maneira de você obter qualquer melhoria significativa em IO nos centros de dados ... é investir em quantidades loucas de largura de banda dedicada entre os data centers. Os sistemas de arquivos agrupados dependem muito de latência mínima & alta largura de banda para poder ter um bom desempenho. Quando há latência ... o gargalo de IO é exponencialmente pior. (1-10ms é bom não é ruim ... 10-30ms não é ótimo ... 30ms + é muito ruim.)

Existem várias maneiras de ajudar a reduzir parte dessa sobrecarga ... usando outros métodos de armazenamento ... como o armazenamento S3 ... ou um sistema de arquivos simples replicado.

O lado negativo é que, porque eles são replicados ... se um lado atualiza um arquivo quase ao mesmo tempo em que o outro ou um lado atualiza arquivos com muita freqüência ... você acaba com uma replicação separada ... o que pode ser um pesadelo para resolver. Esses tipos de armazenamento são ótimos se você fizer commits pouco frequentes ... e muitas leituras.

Tentar implementar coisas como o EBS da Amazon ... ou o S3 barato é improvável na melhor das hipóteses. Eles têm um orçamento muito maior e grandes quantidades de largura de banda entre seus datacômetros para brincar.