Uma proposta de armazenamento heterogêneo redundante para ZFS ou LVM ou MD


10

Tenho o mesmo problema que a maioria das pessoas tem: como criar uma solução de armazenamento pessoal confiável com o fato de que:

  1. Os discos rígidos falham com regularidade alarmante. Perder arquivos é inaceitável.
  2. Vou comprar um novo HDD de tempos em tempos. Inevitavelmente, o melhor preço / GB é de um tamanho diferente da última compra do HD.
  3. 2 significa que, com o tempo, tenho uma coleção heterogênea de discos. Quero usá-los todos, e os discos com falha geralmente serão substituídos por discos maiores.

  4. A integridade e a confiabilidade dos dados são mais importantes para mim do que a velocidade.

Então, depois de bater minha cabeça contra esse problema por alguns dias (e na minha cabeça por anos), proponho a seguinte solução. Descreverei uma solução que testei com base no ZFS do Linux nativo, disponível em um PPA do Ubuntu , mas LVM, MD e btrfs podem ser usados ​​para obter o mesmo. Para isso, usarei RAID1 (espelho ZFS vdevs).

  1. Dado o seu conjunto de unidades, agrupe-os em dois conjuntos de discos, de modo que a capacidade de cada conjunto seja o mais próxima possível do outro.
  2. Particione os discos maiores, de modo que exista uma partição exatamente do mesmo tamanho que um dos discos menores, no outro grupo.
  3. Crie vdevs espelhados para que cada disco tenha seu espelho em outro disco.

Por exemplo, considere um conjunto de discos de uma nova unidade de 2 TB, uma de 750 GB mais antiga, duas de 400 GB e uma de 500 GB. O particionamento espelhado ideal possui 2 TB de espaço útil e é descrito no diagrama a seguir, onde ':' separa partições e '|' separa discos:

+------------------------------------------------------------------+
| 2TB (sda1)        : (sda2)       : (sda3)       : (sda4)         |
+------------------------------------------------------------------+--+
| 750 GB (sdb)      | 400 GB (sdc) | 400 GB (sdd) | 500 GB (sde1)  :XX|
+---------------------------------------------------------------------+

Crie seu zpool como

zpool create archive mirror /dev/sda1 /dev/sdb mirror /dev/sda2 /dev/sdc mirror /dev/sda3 /dev/sdd mirror /dev/sda4 /dev/sde1

Isso cria 4 vdevs espelhados. Se qualquer um dos discos falhar, ele poderá ser substituído (com qualquer tamanho de disco) e particionado para recriar as partições ausentes. É importante que o ZFS vdevs possa ser adicionado a um pool, mas não removido . Portanto, se possível, ao comprar uma nova unidade, você deseja reorganizar os vdevs existentes. Digamos que a próxima compra foi uma unidade de 3 TB. Sua configuração ideal é utilizável em 3,5 TB, conforme descrito no diagrama a seguir. Agora são 5 pares de vdev. Isso pode ser alcançado através do particionamento apropriado e da falha e reparticionamento sucessivo das unidades.

+--------------------------------------------------------------+-------------+
| 3 TB (sdf1)       : (sdf2)      : (sdf3)      : (sdf4)       | 500GB (sde) |
+--------------------------------------------------------------+-------------+-+
| 2TB (sda1)        | 400GB (sdb) | 400GB (sdc) | 750GB (sdd1) : (sdd2)      :X| 
+------------------------------------------------------------------------------+

A manutenção desse emparelhamento de unidades espelhadas também pode ser feita com o LVM ou com o MD RAID, com a idéia de garantir que cada unidade tenha sempre uma unidade ou parição de espelho. Como tudo é espelhado, estamos livres para falhar nas unidades e reorganizar as partições quando as unidades são adicionadas ou removidas. Usando o LVM ou MD, seria possível remover unidades e reduzir a matriz, se desejado, às custas de ferramentas de recuperação menos sofisticadas no ZFS em comparação com o BTRFS.

Algum comentário sobre este procedimento? Um bom script pode lidar com a alocação sem perdas e o rearranjo de unidades. Algum comentário sobre LVM vs. MD vs. ZFS? Algum comentário sobre o desempenho da matriz particionada estranhamente resultante? O arranjo de dados em várias partições na mesma unidade causará procura excessiva de cabeçote e falha precoce?

Desenvolvedores de BTRFS: todo mundo quer isso e LVM ou MD não são tecnicamente necessários (e, na minha opinião, não são ótimos). Facilitar a manutenção de uma matriz heterogênea redundante seria um recurso essencial para o btrfs. É um hack no LVM / MD / ZFS como é. Minimizar ressiver / ressincronizar é massivamente desejável.

Sim, é obviamente um Drobo de pobre. Não se deve precisar de hardware dedicado para isso ...

Respostas:


4

Eu testei isso com o ZFS e o desempenho de gravação é cerca da metade do que deveria ser, porque o ZFS distribui leituras e gravações em todos os vdevs (portanto, dividindo a E / S em vários locais no mesmo disco). Assim, a velocidade é limitada pela velocidade do disco com mais partições. A velocidade de leitura parece ser igual à largura de banda do disco. Observe que um par de partições ZFS em dois discos praticamente duplicou a velocidade de leitura de qualquer disco único, porque pode ler os discos em paralelo.

O uso de matrizes MD LINEAR ou LVM para criar as duas metades resulta em duas vezes o desempenho de gravação em comparação com a proposta ZFS acima, mas tem a desvantagem de que LVM e MD não têm idéia de onde os dados são armazenados. No caso de uma falha ou atualização do disco, um lado da matriz deve ser totalmente destruído e ressincronizado / reenviado, seguido pelo outro lado. (por exemplo, o resync / resliver precisa copiar 2 * (tamanho da matriz))

Portanto, parece que a solução ideal é criar um único espelho ZFS vdev entre dois dispositivos LVM ou MD LINEAR que combinam os discos em "metades" de tamanho igual. Isso tem aproximadamente o dobro da largura de banda de leitura de qualquer disco e a largura de banda de gravação é igual às larguras de banda individuais do disco.

Usar o BTRFS raid1 em vez do ZFS também funciona, mas possui metade da largura de banda de leitura porque o ZFS distribui suas leituras para dobrar a largura de banda, enquanto parece que o BTRFS não (de acordo com meus testes). O BTRFS tem a vantagem de que as partições podem ser reduzidas, enquanto não o podem com o ZFS (por isso, se após uma falha você tiver muito espaço vazio, com o BTRFS é possível reconstruir uma matriz redundante menor diminuindo o sistema de arquivos e reorganizando os discos).

É tedioso fazer isso manualmente, mas é fácil com alguns bons scripts.

Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.