Aumentar a confiabilidade particionando discos de tamanhos diferentes?


8

Entendo que o ZFS prefere todos os discos com o mesmo tamanho. No entanto, no caso de eu ter dois discos com tamanho diferente (1 TB e 1,5 TB), gostaria de ter certa redundância, mas sem espelhamento. Então, cortei dois discos em 5 partições, cada uma com aproximadamente 500 GB e crio um pool "raidz" ... zfs felizmente obrigado. A configuração realmente aumenta a confiabilidade? O pensamento é que, se um disco não for totalmente eliminado, e apenas parte dele falhar, ainda posso acessar os dados?


5
Isso não agrega confiabilidade e prejudica o desempenho.
Michael Hampton

1
A maioria das respostas / comentários que recebi não foi mais profunda o suficiente para explicar o porquê. O simples "contra as melhores práticas" ou "discos iguais apenas faz sentido" na verdade não significa muito para mim. Obviamente, considerando esses discos peculiares que tenho, não vou atrás do melhor dos melhores em termos de confiabilidade e desempenho. Estou perguntando o que pode ser feito, dado o que tenho. Além disso, as coisas mudam: no livro de "Master FreeBSD ZFS" ... os autores dizem claramente que antigamente / solaris, todo o provisionamento de disco era considerado crucial, agora não é. O provisionamento baseado em partições é tão bom ou até incentivado.
Python152 #

Especialmente para redundância baseada em paridade, não existe um requisito absoluto no mesmo tamanho (lembro-me vagamente que o livro zfs também dizia que a mesma capacidade de diferentes fornecedores acaba com tamanhos diferentes). Depende de como o algoritmo de posicionamento de dados do ZFS escolhe lidar com isso para equilibrar a dispersão dos bits de paridade e o desempenho.
Python152

@ python152 Depende sempre se você pode conviver com as desvantagens (o ZFS é realmente bastante flexível, as práticas recomendadas são recomendações, não regras). Se você pode aceitar o tempo de inatividade e está confiante no gerenciamento de partições, a substituição de discos com falha parcial não é tão crítica, por exemplo. Eu ainda desconfiaria do furo de gravação RAID5, que existe independentemente de seu hardware de backup ser discos, partições ou mesmo arquivos.
user121391

1
@ user121391 O ZFS raidz não sofre com o furo de gravação RAID5. Veja blogs.oracle.com/bonwick/entry/raid_z e pthree.org/2012/12/05/zfs-administration-part-ii-raidz
nickcrabtree

Respostas:


3

O pensamento é que, se um disco não for totalmente eliminado, e apenas parte dele falhar, ainda posso acessar os dados?

Em teoria, esse pensamento está correto. Contanto que você encontre um erro em um único dispositivo do seu RAIDZ1 vdev, o ZFS poderá informá-lo e corrigir o erro, assumindo que os outros dispositivos estejam livres de erros.

O que pode diferir na realidade são várias coisas:

  • Os erros podem se estender por partições e, portanto, dois ou mais dispositivos serão afetados, o que pode resultar em erros irrecuperáveis ​​ou até em perda total do pool (dependendo do local e da quantidade de erros). Você pode usar o RAIDZ2 ou Z3 para atenuar um pouco isso, mas o problema está sempre lá.
  • Durante a redefinição de uma partição, o disco precisa ler (2 vezes) e gravar (1 vez) no mesmo disco simultaneamente e aleatoriamente. A menos que você use o Solaris 11.3 com resilver sequencial, isso será muito, muito lento. Até que você termine o processo de resilver, você estará vulnerável a erros nas outras partições. Se o tempo de recuperação for maior, a chance de encontrar um URE adicional aumenta. Também coloca carga adicional na unidade, aumentando a chance de falha completa da unidade.
  • Imagine que sua terceira partição (a última no disco de 1,5 TB) mostra erros suficientes para degradar o pool e solicitar uma substituição. Se você não puder adicionar outro disco, não poderá fazer uma substituição sem desligar / exportar e, mesmo assim, será mais complicado do que o normal.

Com base nesses pontos, aconselho a não fazer isso se a confiabilidade for seu objetivo principal. Supondo uma situação de hardware fixa, eu faria o seguinte:

  1. Use espelhos e perca 500 GB, mas obtenha uma configuração simples com fácil expansão no futuro
  2. Use dois conjuntos separados e, copies = 2se desejar alguma resiliência contra erros menores (uma falha no disco inteiro mataria apenas 2/5 ou 3/5 dos dados em comparação com a configuração)
  3. Use outros sistemas de arquivos que não o ZFS, se você quiser comer seu bolo e comê-lo também

5

O que você está descrevendo é um pouco brega.

O ZFS deseja discos completos de tamanho e capacidade iguais. Isso é crítico por várias razões, mas também faz sentido.

Tudo o que você faria na situação descrita é adicionar complexidade ao ambiente e aumentar seu risco.


1
Sem mencionar a redução de desempenho.
Michael Hampton

@MichaelHampton Como é isso?
Cat #

2
@cat Como o ZFS pensa que você tem cinco eixos, quando você realmente tem dois.
Michael Hampton

4

Vamos colocar desta forma:

  • Se você tiver 1 TB de dados no disco um, poderá replicá-lo para o disco dois e poderá perder um desses discos.

  • Se você tiver 1,5 TB de dados no disco dois, poderá replicar apenas os primeiros 1 TB de dados no disco um. Nesse cenário, se o disco dois falhar, você perderá dados.

O ZFS é muito capaz, mas como regra geral, conforme os dois pontos acima, as configurações de disco misto são tolas e não são muito úteis. Se você se preocupa com confiabilidade e redundância, finja que o segundo disco também possui apenas 1 TB.


4
Estou colocando esse comentário em um comentário porque não acho que ele realmente se encaixe em uma "resposta", mas se você realmente quiser usar todo o espaço em seus discos, eu configuraria um espelho de 1 TB e use os últimos 500 GB como um volume regular e não replicado para arquivos temporários e temporários com os quais realmente não me importo (como a pasta de downloads do navegador - é bom ter coisas antigas armazenadas em cache, mas não há nada que eu realmente gostaria sinto falta se eu a perdi).
Benny Mackney
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.