Estou considerando o FreeNAS; e quero confirmar de antemão se meu entendimento do que posso/não posso fazer com o armazenamento está correto.
Construção inicial: 1 pool de armazenamento com 2 unidades de 6 TB espelhando umas às outras; para uma capacidade efetiva total de 6 TB (ignorando arredondamentos e despesas gerais).
Primeira expansão (2,5 - 3 anos): Adicione 2 unidades de 12 TB ao servidor. Configure-os como um segundo par espelhado e adicione-os ao conjunto de armazenamento existente; aumentando meu armazenamento disponível para 18 TB.
Segunda fase de expansão 1 (5,5 - 7,5 anos): Adicione 2 unidades de 24 TB ao servidor. Configure-os como um par espelhado e adicione-os ao pool de armazenamento existente; aumentando meu armazenamento disponível para 42 TB.
Segunda fase de expansão 2 (imediatamente após a fase 1): reequilibre todos os dados das unidades de 6 TB, remova-os do pool e, em seguida, fisicamente do servidor. Armazenamento restante disponível 36 TB.
Meus pensamentos aqui são:
A duplicação da capacidade de armazenamento necessária a cada três anos é uma continuação de minhas experiências com servidores WHS de 2008 até o presente.
Depois de adicionar as unidades de 24 TB, as de 6 TB fornecerão apenas uma fração insignificante do armazenamento total (1/7) e estão envelhecendo o suficiente para que a confiabilidade se torne uma preocupação mais significativa se eu mantê-las (lado errado da curva da banheira) . Se eles sobrevivessem, na minha taxa de crescimento apenas estenderia o tempo até que eu precisasse comprar unidades de 48 TB em um pouco mais de meio ano; então eles realmente não me dariam muito tempo.
Limitar-me a 4 unidades me permite usar um formato mini-ITX compacto para meu NAS. Ir acima disso significa uma configuração maior e mais cara. (2 unidades colocadas na parte superior de um gabinete aberto com fios serpenteando são aceitáveis por um ou dois dias de transição; mas não por um longo prazo.)
Também estou assumindo os negócios normalmente para a disponibilidade de unidades maiores, como foram nas minhas atualizações anteriores de cerca de 3 anos: 1,5-3 TB (2012) e 3-6 TB (agora/futuro próximo). E que quaisquer novas unidades que se tornem disponíveis serão confiáveis o suficiente para serem utilizáveis (ou seja, o apocalipse do ataque nunca acontece).
Responder1
Primeiramente:Não vou especular sobre o desenvolvimento daqui a 6 a 7 anos.Trata-se de hoje e do futuro próximo. Para oDR, veja o final desta resposta.
O ZFS hoje não permite remover um vdev de um pool. Também não possui nenhuma funcionalidade nativa de "rebalanceamento" (procure porreescrita de ponteiro de bloco,reescrever bpoureescrever bpopara saber mais sobre isso). ZFSfazpermitem reduzir o nível de redundância de um espelhado, mas não de raidzN, vdev, mas não é isso que você deseja. (No ZFS, striping é o que você obtém quando não diz nada.)
Basicamente, os pools podem ser considerados conjuntos distribuídos compostos de um ou mais dispositivos de armazenamento cada, dos quais apenas o último (vdevs) pode ser organizado em uma configuração redundante. Você pode configurar cada vdev para níveis arbitrariamente altos de redundância, mastodoO vdev no pool deve permanecer acima do limite de redundância para que o pool seja totalmente funcional. Se um vdev falhar,no melhorvocê perde apenas os dados armazenados naquele vdev e não há como controlar ativamente quais dados são armazenados em quais vdevs (além de colocá-los em pools separados, o que tem outras desvantagens).
Quando você tem um pool "espelhado" como o descrito após a primeira expansão, o que você realmente tem são dois vdevs, cada um composto de um par espelhado de dispositivos de armazenamento físico, onde os dois vdevs são distribuídos para formar o pool. Um pool de dois vdev e duas unidades de cada espelho pode ser desativado por uma unidade com falha eumerro infeliz na outra unidade desse conjunto de espelhos, mesmo que o outro conjunto de espelhos esteja funcionando perfeitamente. No caso de tal falha, não importa o que aconteça, você perderá alguns dados.
A maneira normal de aumentar a capacidade em um pool ZFS ésubstitua as unidades no localcom os maiores, permita que o pool seja resilver na nova unidade e, em seguida, remova fisicamente a unidade antiga que não é mais usada. Normalmente deseja-se usar zpool replacepara isso tanto a unidade antiga quanto a nova conectada, para manter o nível de redundância desejado durante todo o processo. A alternativa normal é adicionar vdevs com o mesmo nível de redundância dos vdevs existentes no pool. Novamente, observe que, como o ZFS não suporta a remoção de uma parte de um conjunto distribuído e os pools são compostos estritamente de vdevs distribuídos, você não pode remover um vdev depois de adicioná-lo. Muitos novatos no ZFS caem nessa armadilha, e é fácil errar se você não prestar atenção aos comandos exatos que usa.
Devido à forma como os resilvers ZFS funcionam, a resilvering é terrivelmente dolorosa para as unidades envolvidas. Embora os resilvers RAID tradicionais sejam geralmente sequenciais, com pequenas quantidades de E/S aleatórias intercaladas da atividade do usuário, os resilvers ZFS são E/S quase completamente aleatórios intercalados com E/S aleatória da atividade do usuário. Um conjunto de espelhos viu basicamente a mesma atividade ao longo de sua vida; se uma pulsão é marginal, ou mesmo morreu, é bem possível que a outra pulsão também seja, na melhor das hipóteses, marginal. Fazer com que ele sofra a provação de recuperação por dias a fio pode facilmente levá-lo ao limite. (Com base na experiência pessoal, eu acho que, para resilver 6 TB de dados, você está olhando para um processo de resilver de aproximadamente uma semana. Mesmo se você girar todos os botõesaté 11, com base na taxa de transferência sequencial pura - o que é totalmente irrealista, dado o formato em disco e a estratégia de resilvering do ZFS - você está olhandopelo menoscerca de 17 horas de puro terror durante a viagem. Meu melhor palpite é que não haveria como reduzir um resilver de 6 TB para menos do que talvez o dobro disso, ou um dia e meio, de abuso total de unidade.)
Eu também teria sérias dúvidas sobre uma configuração de espelho de 2x24 TB ou mesmo de 2x12 TB, supondo que tais unidades se materializem; já estamos ultrapassando um pouco os limites da física (sem trocadilhos) com os tamanhos atuais das unidades. Assumindo a confiabilidade do drive, em termos deURE, permanece semelhante a hoje (10^-14 a 10^-15 erros de setor por bit lido, que é onde ele pairou para sempre nas planilhas de dados do fabricante), estatisticamente você não será capaz de fazer uma leitura completa do seu Unidade de 12 TB sem encontrar pelo menos um erro (12 TB é aproximadamente 9 × 10 ^ 13 bits, que é arredondado para 10 ^ 14). No momento em que você aumentar isso para unidades de 24 TB, estatisticamente você atingirápelo menosum ou dois erros de setor completo em uma passagem de leitura completa (porque você está lendo cerca de 2*10^14 bits). Mesmo se você usar 10 ^ -15 unidades URE, isso não vai lhe custar muito (você estará olhando para cinco passagens de leitura, em vez de meia passagem de leitura). Isto, claro, são estatísticas e especificações; na prática, os erros de leitura tendem a se agrupar, e uma unidade pode fornecer um serviço sem problemas para muitas leituras completas antes de, em algum momento, começar a lançar erros à esquerda, à direita e no centro.
Dado que a maioria dos spinners que não são servidores têm garantia de apenas 1 a 3 anos, eu não contaria com nenhum conjunto para continuar funcionando por muito mais tempo do que isso, enquanto seu plano exige que eles permaneçam funcionais por pelo menos seis anos antes de serem substituídos . Mesmo os spinners de servidor geralmente têm garantia de apenas cinco anos, embora normalmente cinco anos de operação 24 horas por dia, 7 dias por semana. Minha experiência pessoal é que unidades de consumo de última geração, como a série Constellation ES da Seagate, podem fornecer quase esse nível de serviço antes de desistir do fantasma e ir para o paraíso dos dados. (Anedota pessoal: um Constellation ES.2 de 1 TB Eu já tinha cerca de 4 anos e 9 a 10 meses de experiência quando ele começou a agir de maneira engraçada, embora nunca o tenha levado ao fracasso.)
Em geral, considere que muitas pessoas que executam o ZFS usam redundância dupla quando os tamanhos dos spinners atingem a marca de 3 a 4 TB, ou menos, para dados mais importantes. Há uma boa razão para isso:dispositivos de armazenamento falhame issoacontece com uma frequência alarmante. No caso do ZFS, você também está procurando serviços de recuperação de dados muito mais caros se quiser algo além de devolver os bits brutos que ainda podem ser lidos nos pratos, e não tenho conhecimento de nenhum software de recuperação de dados que pode até mesmo lidar remotamente com pools ZFS. Se o ZFS não puder importar seu pool, a resposta mais prática geralmente é considerar como perdidos todos os dados dos quais você não fez backup.em outro lugar.
Para responder à pergunta do título, e TL;DR
O FreeNAS/ZFS me permitirá gerenciar meu armazenamento desta forma?
Num sentido estritamente técnico, sim, deveria. No entanto, eurealmentenão recomendaria nada.Você está forçando demais o envelope operacional do hardwarepara eu me sentir confortável com isso, e muito menos endossá-lo. (Observe que esta resposta seria exatamente a mesma, independentemente do sistema de arquivos sobre o qual você estava perguntando.)