Organizando um raidz3 ZFS vdev para tolerar falhas JBOD inteiras?

Question

Digamos que eu vá construir um zpool de 1PB muito grande. Eu terei uma unidade principal com os HBAs dentro dela (talvez 4 placas LSI SAS de 4 portas) e eu terei talvez 7 JBODs de 45 drives conectados à unidade principal.

A maneira básica de fazer isso com o raidz3 seria criar 21 vdevs raidz3 diferentes de 15 unidades (3 vdevs de 15 unidades para cada um dos 7 JBODs) e criar um conjunto de todos os 21 desses vdevs do raidz3.

Isso funcionaria bem.

O problema aqui é que, se você perder um único vdev por qualquer motivo, perderá o conjunto inteiro. O que significa que você absolutamente nunca pode perder um JBOD inteiro, já que isso é 3 vdevs perdidos. MAS, em um tópico da lista de discussão, alguém mencionou enigmaticamente uma maneira de organizar os discos para que você pudesse realmente perder um JBOD inteiro. Eles disseram:

"Usando uma unidade principal Dell R720, além de um monte de Dell MD1200 JBODs dual caminho para um par de switches SAS LSI ... Nós fizemos a paridade tripla e nossa associação vdev é configurada de tal forma que podemos perder até três JBODs e ainda ser funcional (um disco de membro vdev por JBOD). "

... e não tenho certeza do que estão dizendo aqui. Eu acho que o que eles estão dizendo é que, em vez de ter um vdev (todos os 15 discos contíguos (ou 12 ou qualquer outro) em um HBA), você realmente tem as unidades de paridade para o vdev divididas em outro JBODs, tal que você poderia perder qualquer jbod e você ainda tem N-3 drives em outro lugar para cobrir esse vdev ...

Ou algo ...

Duas perguntas:

1. Alguém sabe como é a receita para isso

2. É complexo o suficiente para que você realmente precise de um comutador SAS, e eu não poderia simplesmente configurá-lo com um complexo cabeamento HBA < - & JBD?

Obrigado.

    

Answer 1

A explicação para a resiliência do JBOD sobre a qual você lê na lista de discussão é provavelmente algo como um conjunto de vdevs e gabinetes RAIDZ3 ... Digamos 8 discos por gabinetes RAIDZ3 (5 + 3) e 5 (ou 8?), tal que os vdevs eram compostos de um único disco de cada gabinete.

Mas para o realz, eu não faria 1 PB de armazenamento sem algum grau de alta disponibilidade ...

Aqui estão alguns projetos de referência para um cluster de HA adequado com dois HBAs por nó principal e um cabeamento SAS em cascata redundante. Se eu estivesse projetando isso, planejaria a implantação do ZFS mirror em vez do RAIDZ (1/2/3).

Eu acho que as limitações dos arrays RAIDZ são um problema na maioria das situações de produção; falta de expansibilidade , fraco desempenho , planejamento complicado e mais recuperação de falhas difícil .

Eu estaria usando espelhos ZFS e os maiores compartimentos possíveis (por exemplo, 60-disco ou < a href="http://shopping1.hp.com/is-bin/INTERSHOP.enfinity/WFS/WW-USSMBPublicStore-Site/en_US/-/USD/ViewProductDetail-Start?ProductUUID=6bAQ7EN5mqYAAAE46mR5_euL&CatalogCategoryID="> 70- unidades de disco ), discos SAS e evitar equipamentos Supermicro;)

Além disso, unidades JBOD de qualidade são muito resistentes em termos de redundâncias internas, backplanes de caminho duplo e assemblies de midplane que normalmente não falham. A maioria dos componentes é hot-swappable. Eu ficaria menos preocupado com os gabinetes e mais com o projeto de cabeamento, controlador e pool.

Se você precisar usar RAIDZ (1/2/3), configure conforme necessário e mantenha discos sobressalentes em cada JBOD. Configure-os como sobressalentes globais também.

Nó duplo:

nóúnico: