ZFS sobre solução de alta disponibilidade iSCSI

Question

Estou considerando uma arquitetura baseada em ZFS / iSCSI para uma plataforma de banco de dados de ha / scale-out / shared-nothing executada em nós wimpy de hardware de PC simples e executando FreeBSD 9.

Funcionará? Quais são possíveis desvantagens?

Arquitetura

1. Os nós de armazenamento possuem unidades SATA / SAS baratas conectadas diretamente. Cada disco é exportado como um iSCSI LUN separado. Note que nenhum RAID (nem HW nem SW), particionamento, gerenciamento de volume ou qualquer coisa assim está envolvido nesta camada. Apenas 1 LUN por disco físico.

2. Os nós do banco de dados executam o ZFS. Um vdev espelhado do ZFS é criado a partir de LUNs iSCSI de 3 nós de armazenamento diferentes . Um pool ZFS é criado na parte superior do vdev e dentro desse sistema de arquivos que, por sua vez, faz backup de um banco de dados.

3. Quando um disco ou um nó de armazenamento falha, o respectivo vdev do ZFS continuará a operar no modo degradado (mas ainda terá dois discos espelhados). Um disco (novo) diferente é designado ao vdev para substituir o disco com falha ou o nó de armazenamento. A redistribuição do ZFS ocorre. Um nó ou disco de armazenamento com falha é sempre completamente reciclado, caso esteja disponível novamente.

4. Quando um nó de banco de dados falha, os LUNs usados anteriormente por esse nó são gratuitos. Um novo nó de banco de dados é inicializado, o que recria o ZFS vdev / pool dos LUNs em que o nó de banco de dados com falha sobrou. Não há necessidade de replicação no nível do banco de dados por motivos de alta disponibilidade.

Possíveis problemas

• Como detectar a degradação do vdev? Verifique cada 5s? Qualquer mecanismo de notificação disponível com o ZFS?

• É possível recriar um novo pool a partir de LUNs existentes que compõem um vdev? Alguma armadilha?

Answer 1

Não é uma resposta direta à sua pergunta, mas uma arquitetura mais tradicional para esse tipo de coisa seria usar HAST e CARP para cuidar da redundância de armazenamento.

Um resumo básico (consulte a documentação vinculada para obter melhores detalhes):

Máquina A ("Master")

• Configure o daemon HAST & crie um recurso apropriado para cada dispositivo do membro do pool.
• Crie seu dispositivo espelhado do ZFS como faria em qualquer sistema único, usando os dispositivos HAST.

Máquina B ("Escravo")

• Configure o daemon HAST de forma semelhante ao que você fez no mestre, mas exiba-o como um nó secundário / escravo.
  (O HAST irá espelhar todos os dados do Mestre para o Escravo para você)

Ambas as máquinas

• Configure o CARP conforme descrito na documentação HAST do Handbook do FreeBSD .
  Toda a magia de failover será tratada por você.

A grande advertência aqui é que o HAST só funciona em um nível Mestre / Escravo, então você precisa de pares de máquinas para cada LUN / conjunto de LUNs que você deseja exportar.

Outra coisa a ter em conta é que a sua arquitectura de armazenamento não será tão flexível como seria com o design que propôs:
Com o HAST você está limitado ao número de discos que você pode colocar em um par de máquinas. Com a estrutura semelhante a malha ISCSI que você propôs, você pode, teoricamente, adicionar mais máquinas exportando mais LUNs e crescer o quanto quiser (até o limite de sua rede).

Essa desvantagem na flexibilidade lhe oferece uma solução documentada, comprovada e comprovada que qualquer administrador do FreeBSD entenderá de imediato (ou poderá ler o manual e descobrir) - para mim, vale a pena: )

    

Answer 2

"zpool status -x" mostrará se todos os pools estão íntegros ou geram o status dos que não estão. Se um vDev LUN do iSCSI ficar off-line, uma tarefa do cron executando um script baseado nesse comando deve fornecer uma maneira de ter alertas do cron regularmente.

"zpool import" deve ser capaz de importar o zpool existente dos vdevs de LUNs do iSCSI. Você pode ter que forçar a importação se o pool não foi exportado de forma limpa, mas os metadados internos devem manter os dados em um estado consistente, mesmo se as gravações forem interrompidas pelo nó do banco de dados com falha.