NAS ZFS de 71 TiB sem falhas de drive por 10 anos
(louwrentius.com)- Um NAS ZFS de 71 TiB montado com 24 drives HGST de 4 TB operou por mais de 10 anos; a placa-mãe e a fonte de alimentação foram substituídas, mas ainda não houve falha de drive
- Em 10 anos, o tempo acumulado de funcionamento dos drives ficou em cerca de 6000 horas; ligá-lo remotamente apenas quando necessário reduziu bastante o custo de energia
- No HN, houve comentários de que a probabilidade de 24 drives passarem 10 anos sem falhas é maior do que parece, então é difícil afirmar que isso aconteceu por causa da prática de mantê-lo desligado com frequência
- O ZFS voltou a importar o pool sem problemas mesmo após mudanças de sistema operacional, e em vários zpool scrub executados ao longo dos anos nunca foi encontrado um erro de checksum
- Ruído, rede, UPS, backup e plano de substituição foram todos administrados como compromissos entre energia, custo e tolerância a risco; no futuro, a mesma capacidade também poderia ser obtida com RAIDZ2 usando 6 a 8 drives
NAS ZFS de 71 TiB resistindo há mais de 10 anos
- Um NAS ZFS 4U de 71 TiB composto por 24 drives de 4 TB continua em uso há mais de 10 anos
- O sistema atual está em sua segunda placa-mãe e segunda fonte de alimentação
- Ainda não houve nenhuma falha de drive
- O tempo acumulado de funcionamento dos drives HGST de 4 TB é de cerca de 6000 horas, o equivalente a aproximadamente 250 dias de operação ao longo de 10 anos
Operação de energia: ligar só quando necessário
- O NAS normalmente fica desligado e só é ligado remotamente quando necessário
- O fluxo para ligar é o seguinte
- Um script liga uma régua de energia IoT
- Quando o BMC (Baseboard Management Controller) termina de inicializar, o próprio NAS é ligado via IPMI
- Como alternativa, também seria possível usar Wake-on-LAN
- Quando o uso termina, um pequeno script desliga o servidor e, alguns segundos depois, corta a energia da tomada
- Deixar apenas o servidor desligado, mantendo a placa-mãe e o BMC energizados, consumiria cerca de 7W continuamente, então essa abordagem foi evitada
- Como outros serviços rodam em um Raspberry Pi 4 ou em servidores com consumo em espera muito menor, não houve necessidade de manter esse NAS grande ligado o tempo todo
- A principal motivação foi economizar na conta de luz, e a avaliação é que isso também parece beneficiar a vida útil dos discos rígidos
- Ainda assim, no HN houve opiniões de que a chance de 24 drives ficarem 10 anos sem falhas é maior do que o esperado, então é difícil atribuir esse resultado com certeza à estratégia de desligar a energia
- O NAS anterior também operou por cerca de 5 anos com 20 drives Samsung Spinpoint F1 de 1 TB, sem falhas de drive
Componentes que deram problema antes dos drives
- Os drives permaneceram intactos, mas a placa-mãe precisou ser substituída há alguns anos
- Os sintomas eram impossibilidade de entrar na BIOS e falhas ocasionais na inicialização
- Medidas básicas, como remover a bateria CMOS, foram tentadas, mas não resolveram
- Como a mesma placa-mãe estava à venda no Ebay por um preço razoável, a troca foi feita sem grande dificuldade
- O motivo para precisar da mesma placa era que o servidor usava 4 slots PCIe
- A configuração era de 3 HBAs e 1 NIC de 10 Gbit
- A fonte de alimentação enfrentava a condição de todos os drives girarem ao mesmo tempo no boot, puxando cerca de 600W por alguns segundos
- A fonte era classificada em 750W e, pelo que o autor se lembra, a linha de 12V também fornecia potência suficiente, mas às vezes ela desarmava na inicialização
Operação do ZFS e resultados do scrub
- O ZFS funcionou sem problemas por anos
- O sistema operacional foi trocado várias vezes, mas não houve dificuldade para reimportar o pool existente após instalar um novo SO
- Se fosse montar um novo servidor de armazenamento, a ideia seria usar ZFS novamente
- O
zpool scrubé executado algumas vezes por ano- Concluir um scrub leva cerca de 20 horas
- Como o consumo de energia aumenta durante o scrub, ele é executado em dias em que a eletricidade está mais barata em um plano tarifário dinâmico
- Até agora, nenhum erro de checksum foi encontrado durante os scrubs
- Provavelmente já foram lidos mais de 1 petabyte de dados somando todos os drives, mas nunca houve situação em que o ZFS precisasse intervir para recuperação
Erros de drive e corrupção silenciosa de dados
- Falhas de drive normalmente se dividem em dois tipos
- Falha total, em que o drive simplesmente deixa de ser detectado
- Falhas de leitura ou escrita e setores defeituosos
- Um terceiro tipo, a corrupção silenciosa de dados, é considerado muito raro
- Quando o disco não percebe que entregou dados corrompidos
- Quando a conexão SATA não detecta erros de checksum
- Como há muitas verificações de checksum em níveis baixos, esse risco é visto como muito pequeno
- A corrupção silenciosa de dados é um risco real, mas é considerada mais preocupante em ambientes de grande escala, como datacenters, do que em um ambiente residencial
- O ZFS vale a pena para quem já está acostumado com Linux ou FreeBSD, e não é tão difícil de aprender
Controle de ventoinhas para um NAS silencioso
- Para um NAS, este sistema é bastante silencioso
- O chassi inclui 3 ventoinhas de 12V robustas para resfriar as 24 baias de drive
- Na velocidade padrão, elas fazem muito barulho, mas em RPM baixo são relativamente silenciosas e fornecem fluxo de ar suficiente na maioria das situações
- Só com baixa rotação, porém, a temperatura dos drives acabava subindo durante leituras e gravações
- A placa-mãe Supermicro usada permitia controlar todos os headers de ventoinha no Linux
- Foi criado um script que ajusta a velocidade das ventoinhas de acordo com a temperatura do drive mais quente
- Em um subreddit de matemática, foi perguntado qual algoritmo serviria para manter silêncio e ainda resfriar os drives, e a recomendação foi um controlador PID
- O código do controle PID foi escrito em Python, usando código de exemplo e ajustando os parâmetros
- Esse script funcionou bem por anos e manteve a temperatura dos drives abaixo de 40°C
- Como o fluxo de ar básico era baixo, também foram necessárias ventoinhas extras para resfriar as 4 placas PCIe, como HBAs e a placa de rede
Mudanças na configuração de rede
- No início, era usado um controlador de rede gigabit de quatro portas com network bonding
- Com essa configuração, foi obtida uma taxa de transferência de cerca de 450MB/s entre vários sistemas
- Como eram necessários cabos UTP demais, depois a configuração foi trocada por placas Infiniband baratas
- Com Infiniband, era possível chegar a cerca de 700MB/s entre sistemas
- Ao decidir voltar do Ubuntu para o Debian, as placas Infiniband deixaram de funcionar e a causa não foi resolvida
- Depois disso, foram compradas placas usadas de Ethernet 10 Gbit, que continuam funcionando sem problemas até hoje
UPS, backup e tolerância a risco
- Durante um período, foi usado um grande UPS para permitir desligamento adequado em caso de falta de energia
- Ao constatar que o UPS consumia mais de 10W adicionais além do uso de energia do servidor, ele foi removido
- Optou-se por aceitar o risco de perder o sistema por problemas de energia
- Os dados mais importantes têm três backups
- Muitos dos dados armazenados no servidor não são considerados importantes o bastante para justificar backup
- A perda de dados por falha de drive é tratada contando com hardware de substituição e com o ZFS
- Se essa proteção não for suficiente, a perda é aceita; o sistema foi operado assim por 10 anos
Próxima geração possível com uma configuração menor
- No momento, não há um plano específico para armazenamento futuro
- O motivo para montar esse servidor no início foi não querer continuar movendo dados por falta de espaço, e ainda hoje sobra bastante capacidade
- Há placa-mãe, CPU, memória e placas HBA de reserva, o que aumenta bastante a chance de ressuscitar o sistema em caso de falha
- Como a capacidade dos discos rígidos aumentou muito, talvez algum dia o chassi de 24 baias seja trocado por um formato menor
- O mesmo nível de armazenamento redundante poderia ser obtido com 6 a 8 discos rígidos e RAIDZ2, isto é, redundância equivalente a RAID 6
- O armazenamento ainda é visto como caro
- Outra possibilidade é que, nos próximos anos, o sistema finalmente quebre e não seja substituído, encerrando o hobby de armazenamento
1 comentários
Comentários do Hacker News
Fico me perguntando se existe um ciclo de substituição dos drives
Como os 24 drives provavelmente são do mesmo modelo e do mesmo lote, e devem ter desgaste parecido, a maioria pode falhar em momentos semelhantes, e os restantes também podem falhar junto por causa do aumento de carga durante a reconstrução
Armazenamento confiável é complicado
Claro que os dois falharam ao mesmo tempo, e tivemos que passar a noite fazendo a recuperação
Foi uma sorte absurda :D
Mas não acho que desgaste de hardware seja tão consistente assim
Ele aguentou bem até um drive morrer e, durante a reconstrução, um segundo morrer junto
Claro, não era ZFS, não havia scrub regular, as taxas de falha dos drives dos anos 2000 talvez fossem diferentes, e ele também não desligava quando não estava usando
O ponto principal é a falha correlacionada, mais do que a causa exata. Com as ressalvas de sempre: amostra de 1, uma pessoa aleatória na internet
A parte de “este NAS é muito silencioso para um NAS” se deve ao fato de ventoinhas de raio grande conseguirem mover muito ar mesmo em baixa RPM, além de serem muito mais eficientes energeticamente
A Oxide Computer explicou em uma apresentação por que usa ventoinhas de 80 mm: porque são silenciosas e, mais importante, consomem pouca energia
Eles observaram que, em outros servidores, até 25% da energia é usada para acionar as ventoinhas, enquanto nos deles é cerca de 1%
https://www.youtube.com/shorts/hTJYY_Y1H9Q
https://www.youtube.com/watch?v=4vVXClXVuzE
Tirando as ventoinhas de 40 mm das fontes Flex ATX, hoje quase desaparecidas; mesmo 80 mm anda bem raro hoje em dia. Normalmente vejo muito 120 mm ou 140 mm
Eu realmente detesto o ruído agudo típico de ventoinhas DC pequenas de alta RPM
Espero que também usem algum método “inteligente” para controlar a velocidade das ventoinhas ;-)
Estou totalmente convencido da ideia de mover mais fluxo de ar em velocidade mais baixa
Entendo que isso seja difícil em chassis 1U ou 2U
Ainda assim, é bom. Só a redução de ruído das ventoinhas já é impressionante, e fico me perguntando por que ninguém pensou antes em algo que parece tão simples
Já ouvi o conselho exatamente oposto, de que os drives devem ficar girando continuamente para reduzir o desgaste causado por ciclos de energia
Não sei no que acreditar, mas gosto do fato de poder deixar o NAS ZFS ligado para rodar scrubs regularmente e verificar os dados
Para referência, rodei um sistema com 4 drives por 10 anos e tive 2 falhas de drive nesse período, mas eram WD Green, não de classe enterprise
Ligar e desligar o drive uma ou duas vezes por dia é diferente de fazer spin-down a cada 15 minutos ou menos
Drives WD Green não são recomendados para NAS. No passado, eles estacionavam as cabeças de leitura/gravação a cada poucos segundos; isso pode ser aceitável quando o acesso a dados é raro, mas em servidores gera desgaste contínuo e pode levar a falha prematura
As cabeças de leitura/gravação quase não sofrem desgaste enquanto estão flutuando sobre os pratos. Quando a energia é desligada, a cabeça pousa fisicamente em um suporte ou em uma zona de pouso do prato, e o pouso e a decolagem são o que mais desgasta a cabeça
No pior caso, por causa do atrito estático, a cabeça pode ser arrancada durante a decolagem
Os rolamentos também duram mais, e podem travar se ficarem parados por tempo demais. O mesmo vale para o motor do drive
A corrente de partida ao ligar também é um estresse elétrico, por menor que seja
Os únicos motivos para desligar discos rígidos são economizar energia, reduzir ruído e transporte
Isso pode gerar vários spin-ups e spin-downs por dia, então esse argumento é bem difícil de aceitar
Dito isso, não tenho evidências para sustentá-lo
Se for esse o caso, manter os discos girando para evitar que liguem e desliguem a cada poucos minutos pode ajudar a aumentar a vida útil
Mas, se for um homelab, é bem provável que você esteja gastando muito mais na conta de luz do que economizando no custo de manutenção dos discos
Tenho alguns drives grandes para mídia da família e gostaria de protegê-los com mais confiança do que apenas “o drive não falhou”
Discussões sobre sistemas de arquivos com checksums geralmente giram em torno de ZFS e BTRFS, mas fico curioso se alguém já usou bcachefs
Ele foi upstreamed no kernel Linux e, pelo que sei, oferece suporte a checksums completos. O autor também parece levar a sério a responsabilidade do sistema de arquivos
Tem alguém aqui usando?
https://bcachefs.org/
Levou cerca de 1 semana até o RAID inteiro deixar de montar por um problema no journal. A configuração era 8 HDDs, 2 SSDs como cache de escrita e 2 NVMes como cache de leitura
O autor respondeu no Reddit em menos de um dia, e tentei aplicar o patch dele. Tive que compilar o kernel Linux e inicializar com ele, mas o problema não foi resolvido
Depois disso, infelizmente não houve mais resposta, então esperei alguns dias, apaguei tudo e voltei para um RAID mdadm comum
O importante, claro, estava todo em backup, mas perdi alguns dados sem importância, e isso me fez lembrar de novo que o estado da arte é instável
Ainda assim, o processo de configuração e os recursos eram excelentes. Só o fato de poder adicionar discos e marcá-los como cache de leitura/escrita já era ótimo
Com certeza pretendo tentar de novo depois de mais alguns anos de maturação
[1] https://linuxiac.com/torvalds-expresses-regret-over-merging-...
[2] https://news.ycombinator.com/item?id=41407768
Eu não gostaria de assumir esse risco com dados de produção, mas para um homelab pode ser aceitável
Só que é preciso se perguntar quanto tempo você está disposto a gastar quando algo der errado
Também uso ZFS há mais de 15 anos e já vi muita coisa por causa de hardware ruim, mas em bom hardware empresarial ele funcionou sem falhas
Estou testando uma combinação com um SSD de cerca de 2 TiB na frente de um HD grande de cerca de 8 TiB, usando o SSD como cache
Tive pequenos problemas no Ubuntu com a combinação zsys, que agora é legado, + ZFS na raiz, mas é uma configuração comum, usada amplamente há anos, então é fácil encontrar suporte
Provavelmente não usarei bcachefs até que ele tenha um nível parecido de adoção e suporte da comunidade
Acho que o ambiente em que os drives ficam funcionando faz uma diferença enorme na vida útil
Ambientes residenciais são muito mais variáveis do que datacenters ou escritórios. Variações de temperatura e umidade já são grandes desafios, mas o que me surpreendeu foi que até pequenas quantidades de poeira têm um efeito bastante perceptível
Há muito tempo, eu rodava um array 8x500G em um servidor Dell antigo no porão. Os drives eram todos Seagate novos, 7200 RPM, talvez até a versão “enterprise”
Durante 5 anos, em média, um drive falhava a cada 6 meses. Eu mantinha 2 drives de paridade, guardava um drive reserva e enviava para RMA sempre que algum falhava
Depois de me mudar, passei a ter uma sala dedicada para o laboratório e, com a mesma configuração, não tive nenhuma falha nos 5 anos seguintes. Eu esperava que o novo ambiente fosse melhor, mas foi surpreendente ver o quanto um ambiente mais limpo e estável podia melhorar as coisas
Sempre mantive NAS/servidores de arquivos em ambientes residenciais empoeirados, e ainda hoje dá para ver o logo cinza felpudo da Synology, mas nunca vi algo assim acontecer
Acho que aquela geração tinha um problema de firmware
Veja a taxa anual de falhas aqui: https://www.backblaze.com/blog/best-hard-drive-q4-2014/
Nos drives atuais selados e preenchidos com hélio, mesmo que isso tenha sido um problema antes, provavelmente já não é grande coisa
Sobre a parte de “aceitar o risco de perder o sistema por problemas de energia”, outra falha extremamente rara que um UPS ajuda a evitar é o desequilíbrio elétrico
Se houver algum problema elétrico durante uma obra nas proximidades, ou se um raio atingir um poste perto de casa, podem ocorrer picos para cima ou para baixo, e ambos podem ser destrutivos
No meu primeiro emprego, cerca de 10 anos atrás, vários servidores morreram desse jeito. Mas aquela foi a única vez em que ouvi falar desse tipo de problema
Pelo que entendo, um UPS também protege contra esses picos, e o UPS morreria antes que o servidor fosse danificado
Um raio atingiu diretamente a antena de TV da casa dos meus pais, que estava ligada por cabo coaxial até o amplificador/divisor da caixa de telecomunicações
Depois disso, de algum modo, passou para o painel de patch de rede próximo e queimou todos os controladores Ethernet cabeados conectados à rede. Incluindo as portas do switch e os embutidos nos APs
No switch de rede, parece que a corrente tentou ir para o terra e acabou destruindo até a fonte de alimentação
Como ela passou do coaxial para o Cat5 ainda é um pouco misterioso. Talvez o eletricista tenha passado algum trecho em paralelo, bem próximo, em algum lugar
Tivemos que refazer a rede inteira, mas felizmente não havia computadores cabeados no local. Acho que os dispositivos de armazenamento também teriam tido dificuldade para sobreviver
Um APC de 850VA de US$ 99 comprado na Office Depot não faz isso. Ele apenas alterna muito rapidamente da rede elétrica para a bateria; não faz uma filtragem real da energia
Se puder comprar um produto bom, ele realmente aumenta a confiabilidade do hardware no longo prazo. Energia limpa é uma coisa boa
Pela distribuição entre equipamentos mortos, danificados e aparentemente intactos, o fio de cobre que carregava o VDSL foi um caminho muito direto. O modem estava conectado por Ethernet a todos os outros equipamentos
A solução correta provavelmente seria converter para óptico, passar por um pequeno trecho de fibra e depois converter de volta. A eletricidade provavelmente escolheria outro caminho em vez do vidro
Mas escolher os produtos acabou sendo muito mais trabalhoso do que eu esperava e, como não sou da área de redes, desisti depois de tentar diferenciar os produtos por cerca de uma hora
Então coloquei uma ponte Wi‑Fi entre o modem VDSL e o restante dos equipamentos. Espero que, na próxima tempestade, esse modo de falha fique isolado
Havia um array ZFS conectado ao mesmo modem, e ele sobreviveu, mas acho que foi sorte
Na época eu não tinha servidor, mas era irritante ver lâmpadas LED queimando a cada poucas semanas. Era um prédio antigo dos anos 60, e a instalação elétrica do nosso apartamento também tinha alguns reparos improvisados suspeitos
O “segredo” não é desligar a energia; é simplesmente sorte
Tenho discos HGST de 4 TB rodando 24/7 há mais de 10 anos. Não são exatamente 24 unidades, são 8, mas houve 0 falhas
Eu também só tive sorte, e tenho conhecidos que enviaram vários RMAs com os mesmos discos
O que mais me intriga é: que tipo de dado exige 71 TB, se ele pode ficar desligado a maior parte do tempo? É um servidor de armazenamento de backup?
Por exemplo, rolamentos podem travar quando estão frios
Alguém que entenda bem de estatística poderia calcular a probabilidade de todos os 24 sobreviverem assumindo uma taxa anual de falha de algo como 1%
Além disso, os 20 discos do NAS anterior também não tiveram falhas. Então N=44; quanta sorte seria necessária?
É usado em ambiente residencial e, quando preciso dos dados, normalmente copio por 10 Gbit para um sistema de consumo bem menor e depois desligo esse NAS de novo
Havia discos para os quais ciclos de energia eram arriscados
Então concordo com o modelo, mas não se deve presumir que isso seja sempre um bom método para todos. Alguns SSDs precisam receber energia periodicamente
Pelo ciclo de uso do NAS, provavelmente esse requisito é atendido
Provavelmente está tudo bem, e a conta de luz certamente fica mais barata. Discos com graxa extra no eixo foram um caso peculiar de certa época
Fico curioso se a Backblaze tem um modelo estatístico sobre ligar/desligar discos e vida útil. Eles provavelmente atuam em um espaço de problema em que tudo fica sempre ligado
Mas, no meu caso, não faço ciclos de energia nesses discos com frequência. No máximo algumas vezes por mês
Não posso dizer nem provar que não é um grande risco, mas acredito que não seja e venho aceitando esse risco há mais de 15 anos
Também é preciso lembrar que discos rígidos têm a opção de reduzir a rotação em idle. Ou seja, HDDs conseguem lidar com muitos spin-ups por dia
Ele usava HDs internos de 3,5 polegadas e um dock USB para fazer backup de alguns equipamentos Synology, e quando recolocava um disco no dock para restaurar arquivos ou fazer backups adicionais, parecia que em cerca de 1 de cada 10 vezes ele não ligava de novo
Em produção, uso há anos um banco de dados PostgreSQL de vários TB sobre ZFS e até agora não tive nenhum problema, incluindo bit flips
Para quem tiver interesse, documentei a experiência aqui:
https://lackofimagination.org/2022/04/our-experience-with-po...
Sobre quedas de energia intermitentes durante a inicialização, vale observar que os discos puxam energia do trilho de 5 V na partida
Discos semelhantes costumam consumir até 1,2 A. Somando isso ao fato de que a carga máxima do trilho de 5 V é 25 A (Seasonic Platinum 860W), é provável que ocorram falhas de alimentação durante o boot quando não se usa staggered spinup