Atualizando o tamanho do pool do ZFS com discos de tamanhos diferentes

Question

Atualmente tenho uma configuração em que estou usando uma área de trabalho antiga como um servidor de mídia, mas não tenho tolerância a falhas e a quantidade de mídia existente é muito grande para que eu possa razoavelmente fazer o backup. Eu não estou muito preocupado em perdê-lo no caso de uma falha no drive, já que são apenas filmes, programas de TV e coisas do tipo (muitas das quais eu ainda tenho DVDs, em algum lugar), mas No momento estou atualizando meu sistema e gostaria de adicionar alguma tolerância a falhas aqui.

Atualmente, tenho uma unidade de 1 TB, 2 TB e 3 TB, provavelmente com cerca de 5,5 TB usada, e estou pensando em comprar mais duas unidades de 4 TB e configurar uma matriz RAIDZ de 4 TB x 4 TB x 3 TB.

Minhas perguntas são:

1. Meu entendimento é que, para matrizes de disco heterogêneo como esse, o tamanho do pool será limitado ao tamanho do menor disco, o que significaria que eu estaria olhando para um 3 x 3 x 3 TB RAIDZ com espaço utilizável de 6 TB e 2 TB de espaço tolerante a falhas - isso é verdade? *
2. Assumindo que o número 1 é verdadeiro, quando eu precisar de mais espaço, se eu adicionar uma única unidade de 4 TB ou 6 TB ao array, será simples estender o pool para se tornar um array de 4 x 4 x 4 TB, ou preciso encontrar algum lugar para armazenar os 6 TB de dados durante a atualização da matriz?

^{_{* Os 2TB de espaço não tolerante a falhas não são tão grandes, porque eu estava planejando reservar cerca de 2TB para "coisas que precisam de um backup adequado" (fotos pessoais, instantâneos de computador, etc), que eu iria espelhar para o disco restante 2TB e uma segunda unidade externa de 2TB que vou manter em outro lugar.}}

    

Answer 1

Currently, I have a 1TB, 2TB and 3TB drive, with probably around 5.5TB used, and I'm thinking that I will buy two more 4TB drives and set up a 4TB x 4TB x 3TB RAIDZ array.

Com unidades de 4 TB, você não deve estar olhando para RAIDZ de redundância única. Eu recomendaria o RAIDZ2 por causa da proteção adicional que ele oferece, caso um drive de alguma forma quebre ou desenvolva problemas.

Lembre-se de que as unidades de consumo geralmente são especificadas para uma taxa de URE de um setor com falha por leitura de 10 ^ 14 bits. 1 TB (terabyte do fabricante da unidade de disco rígido, isto é) é 10 ^ 12 bytes ou próximo de 10 ^ 13 bits, com uma pequena quantidade de alteração. Uma passagem de leitura completa da matriz que você tem em mente é estatisticamente provável encontrar um problema e, na prática, os problemas de leitura tendem a se desenvolver em lotes.

I'm not sure why you are suggesting RAIDZ2. Is it more likely that I will develop two simultaneous drive failures if I use RAIDZ1 than if I use no RAID? I want some improvement to the fault tolerance of my system. Nothing unrecoverable will exist in only one place, so the RAID, array is just a matter of convenience.

O RAIDZ1 usa um único disco para fornecer redundância em um vdev, enquanto o RAIDZ2 usa dois (e alguns cálculos mais complexos, mas é improvável que você tenha throughput limitado por cálculos RAIDZ). O benefício de um segundo disco redundante é no caso de o primeiro falhar ou se tornar indisponível. Com apenas um disco de redundância, quaisquer erros adicionais são agora críticos. Com 4 + 4 + 3 TB, você tem 11 TB de armazenamento bruto, inicialmente 6 TB talvez precise ser lido para reconstruir um disco perdido (8 TB ao atualizar esse disco de 3 TB para um disco de 4 TB e expandir o pool para combinar). Para estimativas de ordem de grandeza, isso arredonda muito bem para algo entre 10 ^ 13 e 10 ^ 14 bits. Estatisticamente, você tem algo como uma probabilidade de 50% a 100% de acertar um erro de leitura irrecuperável durante o resilvering ao usar redundância única com um array dessa ordem de tamanho de magnitude. Claro, você pode muito bem ter sorte, mas de repente significa que você tem a proteção no em caso de falha na unidade.

My understanding is that for heterogeneous disk arrays like this, the pool size will be limited to the size of the smallest disk, which would mean I'd be looking at a 3 x 3 x 3 TB RAIDZ with 6TB usable space and 2TB of non-fault-tolerant space - is this true?

Quase. O ZFS restringirá o vdev ao tamanho do menor dispositivo constituinte, de modo que você obtenha a capacidade efetiva de um vdev RAIDZ de três dispositivos composto de dispositivos de 3 TB, ou seja, 6 TB de armazenamento acessível ao usuário (metadados). Os 2 TB restantes de espaço de armazenamento bruto são desperdiçados; não está disponível para uso mesmo sem redundância. (Eles aparecerão na coluna EXPANDSZ em zpool list , mas não estão sendo usados.)

Depois de substituir a unidade de 3 TB por uma unidade de 4 TB e expandir o vdev (ambos operações online no ZFS), o pool pode usar o espaço de armazenamento adicional.

Existem formas em torno disso - por exemplo, você pode particionar as unidades para apresentar três dispositivos de 3 TB e dois dispositivos de 1 TB (restante dos dois drives de 4 TB) ao ZFS - mas Vai complicar seriamente sua configuração e é improvável que ela funcione da maneira que você planeja. Eu recomendo strongmente contra isso.

The 2 TB of non-fault tolerant space would not be backed up by ZFS to the offline disks, sorry if that was not clear. I was suggesting that I would back it up by normal disk syncing operations like rsync.

Isso implica que o ZFS não tem conhecimento desses 2 x 1 TB e que você está criando algum outro sistema de arquivos no espaço. Sim, você pode fazer isso, mas, novamente, isso vai complicar seriamente sua configuração para, francamente, o que parece ser um ganho muito pequeno.

Assuming #1 is true, when I eventually need more space, if I add a single 4TB or 6TB drive to the array, will it be a simple matter to extend the pool to become a 4 x 4 x 4 TB array, or will I need to find somewhere to stash the 6TB of data while upgrading the array?

Como eu disse acima, os vdevs e pools do ZFS podem ser desenvolvidos como uma operação on-line, se você fizer isso substituindo gradualmente os dispositivos. (Não é, no entanto, possível reduzir um pool ou vdev do ZFS.) O que você não pode fazer é adicionar dispositivos adicionais a um vdev existente (como o RAIDZ vdev de três dispositivos que você está visualizando criação); um vdev inteiramente novo deve ser incluído no conjunto e os dados que são gravados posteriormente serão distribuídos entre os dois vdevs no conjunto. Cada vdev tem seus próprios requisitos de redundância, mas eles podem compartilhar hot spares. Você também não pode remover dispositivos de um vdev, exceto no caso de espelhos (em que a remoção de um dispositivo reduz apenas o nível de redundância desse espelhamento específico vdev e não afeta a quantidade de espaço de armazenamento acessível pelo usuário) e não é possível remover vdevs de uma piscina. A única maneira de fazer o último (e por conseqüência, a única maneira de corrigir alguns contratempos de configuração do conjunto) é recriar o conjunto e transferir os dados do conjunto antigo, possivelmente por meio de backups, para o novo conjunto.

The 2TB of non-fault-tolerant space is not that big a deal, because I was planning on setting aside around 2TB for "stuff that needs proper backup" (personal photos, computer snapshots, etc), which I would mirror to the remaining 2TB disk and a 2nd 2TB external drive that I will keep somewhere else.

A redundância do ZFS não é realmente projetada para o caso de uso principalmente off-line off-line-backup-drive. Eu discuto isso com alguma profundidade em Será que um ZFS espelharia com um trabalho principalmente offline? , mas o pão e a manteiga dele é que é melhor usar zfs send / zfs receive para copiar o conteúdo de um sistema de arquivos ZFS (incluindo instantâneos e outros itens periphernalia) ou usar% espelhado rsync se você não se importar com instantâneos, do que usar espelhos em um configuração principalmente off-line.

If I'm using half my disks for fault tolerance, I might as well just use traditional offline backups.

Isso certamente depende muito da sua situação. Qual é o seu tempo para os requisitos de recuperação em diferentes situações? O RAID tem a ver com tempo de atividade e tempo para recuperação, não com a proteção de dados; você precisa de backups de qualquer maneira .

    

Answer 2

My understanding is that for heterogeneous disk arrays like this, the pool size will be limited to the size of the smallest disk, which would mean I'd be looking at a 3 x 3 x 3 TB RAIDZ with 6TB usable space and 2TB of non-fault-tolerant space - is this true?*

Sim.

Assuming #1 is true, when I eventually need more space, if I add a single 4TB or 6TB drive to the array, will it be a simple matter to extend the pool to become a 4 x 4 x 4 TB array, or will I need to find somewhere to stash the 6TB of data while upgrading the array?

Sim, isso é possível.

Você pode substituir todos os seus discos dentro de um Z1 / Z2 / Z3 vdev um por um, onde sua capacidade será igual ao menor disco atualmente em uso no vdev (você também pode definir a propriedade autoexpand to on para fazer isso automaticamente em vez de manualmente).

Por outro lado, não é possível adicionar (em vez de substituir) qualquer unidade a um vdev Z1 / Z2 / Z3 existente sem destruir e recriar completamente o conjunto (perdendo todos os seus dados no processo). Em espelhos e vdevs básicos, você pode adicionar mais drives para criar um 2-mirror, 3-mirror, 4-mirror etc, mas isso só aumenta a confiabilidade, não o tamanho utilizável.