Un NAS ZFS de 71 TiB sans panne de disque en 10 ans
(louwrentius.com)- Un NAS ZFS de 71 TiB construit avec 24 disques HGST de 4 To a été exploité pendant plus de 10 ans ; la carte mère et l’alimentation ont été remplacées, mais aucun disque n’est encore tombé en panne
- En 10 ans, le temps de fonctionnement cumulé des disques n’a atteint qu’environ 6000 heures ; le fait de ne l’allumer à distance qu’en cas de besoin a fortement réduit le coût de l’électricité
- Sur HN, certains ont estimé que la probabilité que 24 disques ne tombent pas en panne en 10 ans était plus élevée qu’on ne l’imagine, ce qui rend difficile d’attribuer cela avec certitude aux extinctions fréquentes
- ZFS a pu réimporter le pool sans problème après plusieurs changements de système d’exploitation, et aucun zpool scrub lancé quelques fois par an n’a jamais détecté d’erreur de checksum
- Le bruit, le réseau, l’UPS, les sauvegardes et le plan de remplacement ont tous été gérés comme des compromis entre énergie, coût et acceptation du risque ; à l’avenir, une capacité équivalente pourrait être obtenue avec 6 à 8 disques en RAIDZ2
Un NAS ZFS de 71 TiB qui tient depuis plus de 10 ans
- Un NAS ZFS 4U de 71 TiB composé de 24 disques de 4 To est toujours utilisé après plus de 10 ans
- Le système actuel utilise sa deuxième carte mère et sa deuxième alimentation
- Aucun disque n’est encore jamais tombé en panne
- Le temps de fonctionnement cumulé des disques HGST de 4 To est d’environ 6000 heures, soit l’équivalent d’environ 250 jours sur 10 ans
Une gestion de l’alimentation où le NAS n’est allumé qu’en cas de besoin
- Le NAS reste éteint par défaut et n’est allumé à distance qu’en cas de besoin
- La séquence d’allumage est la suivante
- un script active une multiprise connectée IoT
- une fois le démarrage du BMC (Baseboard Management Controller) terminé, le NAS lui-même est allumé via IPMI
- Wake-on-LAN aurait aussi pu être utilisé comme alternative
- Une fois l’utilisation terminée, un petit script arrête le serveur, puis coupe l’alimentation murale après quelques secondes d’attente
- Le fait d’éteindre uniquement le serveur tout en laissant la carte mère et le BMC sous tension entraînait une consommation continue d’environ 7 W, ce qui a conduit à éviter cette méthode
- Les autres services tournent sur un Raspberry Pi 4 ou sur des serveurs ayant une consommation en veille bien plus faible ; il n’était donc pas nécessaire de laisser en permanence ce gros NAS allumé
- La motivation principale était de réduire la facture d’électricité, avec l’idée que cela pourrait aussi être bénéfique pour la durée de vie des disques durs
- Sur HN toutefois, certains ont fait remarquer que la probabilité de voir 24 disques tenir 10 ans sans panne était plus élevée qu’attendu, ce qui rend difficile d’attribuer ce résultat au seul mode d’exploitation avec coupure de l’alimentation
- Le NAS précédent, équipé de 20 disques Samsung Spinpoint F1 de 1 To, avait lui aussi été exploité pendant environ 5 ans sans aucune panne de disque
Des composants qui ont posé problème avant les disques
- Les disques étaient en bon état, mais la carte mère a dû être remplacée il y a quelques années
- Les symptômes de la panne étaient l’impossibilité d’entrer dans le BIOS et des échecs de démarrage occasionnels
- Des mesures de base, comme le retrait de la pile CMOS, ont été tentées sans succès
- Une carte mère identique était disponible à un prix correct sur Ebay, ce qui a permis de la remplacer sans grande difficulté
- la nécessité d’avoir exactement la même carte venait du fait que le serveur utilisait 4 slots PCIe
- la configuration comprenait 3 HBA et 1 NIC 10 Gbit
- L’alimentation devait encaisser un démarrage simultané de tous les disques, ce qui tirait environ 600 W pendant quelques secondes
- L’alimentation était certifiée pour 750 W et, de mémoire, le rail 12 V pouvait fournir suffisamment de puissance, mais il arrivait qu’elle se mette en protection au démarrage
Exploitation de ZFS et résultats des scrub
- ZFS a fonctionné sans problème pendant des années
- Le système d’exploitation a été changé plusieurs fois, mais après chaque nouvelle installation il n’y a eu aucun problème pour réimporter le pool existant
- Si un nouveau serveur de stockage devait être construit, ZFS serait de nouveau utilisé
- Un
zpool scrubest lancé quelques fois par an- l’exécution complète d’un scrub prend environ 20 heures
- comme la consommation électrique augmente pendant un scrub, il est lancé les jours où l’électricité est moins chère avec une tarification dynamique
- Jusqu’à présent, aucun scrub n’a jamais détecté d’erreur de checksum
- Il semble que plus d’un pétaoctet de données ait été lu au total sur l’ensemble des disques, sans qu’une intervention corrective de ZFS soit nécessaire
Erreurs de disque et corruption silencieuse des données
- Les pannes de disque se divisent principalement en deux catégories
- la panne totale, où le disque n’est plus détecté du tout
- les échecs de lecture/écriture ou les secteurs défectueux
- Une troisième catégorie, la corruption silencieuse des données, est considérée comme très rare
- quand le disque transmet des données corrompues sans savoir lui-même qu’elles le sont
- ou quand la connexion SATA ne détecte pas une erreur de checksum
- Étant donné le grand nombre de vérifications de checksum à bas niveau, ce risque est jugé très faible
- La corruption silencieuse des données est un vrai risque, mais elle semble surtout préoccupante dans des environnements à grande échelle comme les datacenters plutôt que dans un cadre résidentiel
- ZFS vaut la peine d’être appris pour les utilisateurs familiers de Linux ou de FreeBSD, et sa prise en main n’est pas particulièrement difficile
Contrôle des ventilateurs pour un NAS silencieux
- Ce NAS est très silencieux pour un NAS de cette catégorie
- Le châssis contient 3 ventilateurs 12 V robustes pour refroidir les 24 baies de disques
- À leur vitesse par défaut, ils sont très bruyants, mais à bas régime ils deviennent assez silencieux tout en assurant un flux d’air suffisant dans la plupart des cas
- Cependant, à basse vitesse uniquement, la température finissait par monter lors des lectures et écritures sur les disques
- La carte mère Supermicro utilisée permettait de contrôler tous les connecteurs de ventilateurs depuis Linux
- Un script a été créé pour ajuster la vitesse des ventilateurs en fonction de la température du disque le plus chaud
- Une question a été posée sur un subreddit consacré aux mathématiques pour trouver un algorithme à la fois silencieux et efficace pour refroidir les disques, et un contrôleur PID a été recommandé
- Le code de contrôle PID a été écrit en Python, avec reprise d’exemples puis ajustement des paramètres
- Ce script a bien fonctionné pendant des années et a maintenu la température des disques sous les 40°C
- Comme le flux d’air de base était limité, un ventilateur supplémentaire a aussi été nécessaire pour refroidir les 4 cartes PCIe, dont les HBA et la carte réseau
Évolution de la configuration réseau
- Au départ, un contrôleur réseau Gigabit quad-port avec bonding réseau était utilisé
- Cette configuration permettait d’atteindre environ 450 MB/s entre plusieurs systèmes
- Comme cela nécessitait trop de câbles UTP, la configuration a ensuite été remplacée par des cartes InfiniBand bon marché
- Avec InfiniBand, le débit entre systèmes pouvait atteindre environ 700 MB/s
- Au moment du retour d’Ubuntu vers Debian, les cartes InfiniBand ont cessé de fonctionner, et la cause n’a pas pu être résolue
- Des cartes Ethernet 10 Gbit d’occasion ont ensuite été achetées et fonctionnent sans problème depuis
UPS, sauvegardes et acceptation du risque
- Pendant un temps, un gros UPS a été utilisé afin de permettre un arrêt propre en cas de coupure de courant
- Après avoir constaté que l’UPS consommait plus de 10 W en plus de la consommation du serveur, il a été retiré
- Le risque de perdre le système à cause d’un problème d’alimentation a été accepté
- Les données les plus importantes sont sauvegardées trois fois
- Une grande partie des données stockées sur le serveur n’est pas jugée assez importante pour justifier une sauvegarde
- La perte de données due à une panne de disque est gérée en s’appuyant sur le matériel de remplacement et sur ZFS
- Si cette protection ne suffit pas, la perte est acceptée : c’est dans ce cadre que le système a été exploité pendant 10 ans
Une génération suivante possible avec une configuration plus petite
- Il n’existe actuellement pas de projet de stockage précis pour la suite
- Le serveur avait été construit au départ pour éviter d’avoir à déplacer sans cesse les données faute d’espace, et il reste encore aujourd’hui largement assez de capacité disponible
- Des pièces de rechange sont disponibles, notamment carte mère, CPU, mémoire et cartes HBA, ce qui donne de bonnes chances de remettre le système en service en cas de panne
- Comme la capacité des disques durs a fortement augmenté, le châssis 24 baies pourrait un jour être remplacé par un format plus compact
- Un niveau de capacité redondante équivalent pourrait être obtenu avec 6 à 8 disques durs en RAIDZ2, soit une redondance de niveau RAID 6
- Le stockage reste considéré comme coûteux
- Une autre possibilité est que le système finisse tout simplement par tomber en panne dans les prochaines années, sans être remplacé, marquant ainsi la fin de ce hobby autour du stockage
1 commentaires
Avis de Hacker News
Je me demande s’il existe un cycle de remplacement des disques
Les 24 disques sont probablement du même modèle et du même lot, avec une usure similaire ; la plupart pourraient donc tomber en panne à peu près au même moment, et les autres pourraient lâcher aussi pendant la reconstruction à cause de la charge accrue
Le stockage fiable est délicat
Évidemment, les deux sont tombés en panne en même temps, et il a fallu passer la nuit à récupérer les données
J’ai vraiment eu de la chance :D
Mais j’ai du mal à croire que l’usure matérielle soit cohérente à ce point
Ça a bien tenu jusqu’à ce qu’un disque meure, puis qu’un deuxième suive pendant la reconstruction
Bien sûr, ce n’était pas du ZFS, il n’y avait pas de scrub régulier, les taux de panne des disques des années 2000 étaient peut-être différents, et il ne l’éteignait pas quand il ne s’en servait pas
Le point essentiel, ce sont les pannes corrélées, plus que la cause exacte. Avec les réserves habituelles : un seul échantillon, une personne au hasard sur Internet
Le passage disant que « ce NAS est très silencieux pour un NAS » s’explique par le fait qu’un ventilateur de grand rayon peut déplacer beaucoup d’air à bas régime, avec une efficacité énergétique bien meilleure
Oxide Computer a expliqué dans une présentation pourquoi ils utilisent des ventilateurs de 80 mm : parce qu’ils sont silencieux et, plus important encore, parce qu’ils consomment peu
Ils ont observé que sur d’autres serveurs, jusqu’à 25 % de l’énergie sert à alimenter les ventilateurs, contre environ 1 % chez eux
https://www.youtube.com/shorts/hTJYY_Y1H9Q
https://www.youtube.com/watch?v=4vVXClXVuzE
Si l’on met de côté les ventilateurs de 40 mm des alimentations Flex ATX presque disparues, c’est le cas, et même les 80 mm sont assez rares aujourd’hui. On voit plutôt du 120 mm ou du 140 mm
Je déteste vraiment le bruit aigu des petits ventilateurs DC à haut régime typiques des datacenters
J’espère qu’ils utilisent aussi quelque chose d’« intelligent » pour contrôler la vitesse des ventilateurs ;-)
Je suis totalement convaincu par l’idée de déplacer un plus grand volume d’air à plus basse vitesse
Je comprends que ce soit difficile dans un châssis 1U ou 2U
Mais c’est bien. Rien que la réduction du bruit des ventilateurs est impressionnante, et on se demande pourquoi personne n’avait pensé plus tôt à quelque chose qui paraît aussi simple
J’ai déjà entendu le conseil exactement inverse : laisser les disques tourner en permanence pour réduire l’usure due aux cycles d’alimentation
Je ne sais pas quoi croire, mais j’aime l’idée de laisser un NAS ZFS allumé pour qu’il puisse lancer des scrubs réguliers et vérifier les données
À titre indicatif, j’ai fait tourner un système à 4 disques pendant 10 ans, avec 2 pannes de disque sur la période, mais c’étaient des WD Green, pas des modèles enterprise
Allumer et éteindre un disque une ou deux fois par jour n’est pas la même chose que le laisser se mettre en veille toutes les 15 minutes ou moins
Les disques WD Green ne sont pas recommandés pour un NAS. À une époque, ils parquaient les têtes de lecture/écriture toutes les quelques secondes ; c’est acceptable si les accès aux données sont rares, mais sur un serveur cela peut entraîner une usure continue et provoquer une panne prématurée
Les têtes de lecture/écriture s’usent très peu tant qu’elles flottent au-dessus des plateaux. Quand on coupe l’alimentation, les têtes se posent physiquement sur une rampe ou sur la zone d’atterrissage du plateau, et les phases d’atterrissage et de décollage sont celles qui les usent le plus
Dans le pire des cas, à cause de l’adhérence statique, la tête peut être arrachée pendant le décollage
Les roulements durent aussi plus longtemps, et peuvent se gripper s’ils restent immobiles trop longtemps. Même chose pour le moteur du disque
Le courant d’appel au démarrage est aussi une contrainte électrique, même s’il est faible
Les seules raisons d’éteindre un disque dur sont l’économie d’énergie, la réduction du bruit et le transport
Cela peut entraîner plusieurs spin-up et spin-down par jour, donc cet argument est très difficile à accepter
Cela dit, je n’ai pas de preuves pour l’étayer
Dans ce cas, les laisser tourner en permanence peut améliorer leur durée de vie en évitant que les disques s’allument et s’éteignent toutes les quelques minutes
Mais dans un homelab, il est très probable que vous dépensiez bien plus en électricité que ce que vous économisez en usure des disques
J’ai quelques gros disques pour les médias familiaux, et j’aimerais les protéger avec plus de certitude que simplement « le disque n’est pas tombé en panne »
Les discussions sur les systèmes de fichiers à somme de contrôle tournent généralement autour de ZFS et BTRFS, mais je me demande si quelqu’un a déjà essayé bcachefs
Il a été intégré en upstream dans le noyau Linux et, si je comprends bien, prend en charge les checksums complets. Son auteur semble aussi prendre très au sérieux les responsabilités d’un système de fichiers
Quelqu’un l’utilise ici ?
https://bcachefs.org/
Il a fallu environ une semaine pour que tout le RAID refuse de se monter à cause d’un problème de journal. La configuration était composée de 8 HDD, 2 SSD en cache d’écriture et 2 NVMe en cache de lecture
L’auteur a répondu sur Reddit en moins d’une journée, et j’ai essayé d’appliquer son correctif. Il fallait compiler le noyau Linux et démarrer dessus, mais le problème n’a pas été résolu
Ensuite, malheureusement, je n’ai plus eu de réponse ; après avoir attendu quelques jours, j’ai tout effacé et je suis revenu à un RAID mdadm classique
Bien sûr, tout ce qui était important était sauvegardé, mais j’ai perdu une partie de données non critiques, et cela m’a rappelé que la pointe de la technologie est instable
Cela dit, le processus de configuration et les fonctionnalités étaient excellents. Rien que le fait de pouvoir ajouter des disques et les marquer comme caches de lecture/écriture était appréciable
Je réessaierai certainement dans quelques années, quand le projet aura davantage mûri
[1] https://linuxiac.com/torvalds-expresses-regret-over-merging-...
[2] https://news.ycombinator.com/item?id=41407768
Je ne voudrais pas prendre ce risque avec des données de production, mais pour un homelab ça peut aller
Il faut toutefois se demander combien de temps on est prêt à y consacrer si quelque chose se passe mal
J’utilise aussi ZFS depuis plus de 15 ans et j’ai vu toutes sortes de choses à cause de mauvais matériels, mais sur du bon matériel enterprise il a fonctionné sans accroc
Je teste une combinaison avec environ 2 TiB de SSD placés devant de gros disques durs d’environ 8 TiB, en utilisant le SSD comme cache
J’ai eu de petits problèmes sous Ubuntu avec la combinaison zsys, désormais héritée, + ZFS en racine, mais c’est une configuration courante, largement utilisée depuis des années, donc il est facile de trouver de l’aide
Je n’utiliserai probablement pas bcachefs tant qu’il n’aura pas atteint un niveau similaire d’adoption et de support communautaire
Je pense que l’environnement dans lequel les disques tournent fait une énorme différence sur leur durée de vie
Un environnement résidentiel est bien plus variable qu’un datacenter ou un bureau. Les variations de température et d’humidité sont déjà un gros défi, mais ce qui m’a surpris, c’est que même une petite quantité de poussière a un effet assez net
Il y a longtemps, je faisais tourner une grappe 8x500 Go sur un vieux serveur Dell dans un sous-sol. Les disques étaient tous des Seagate neufs, à 7200 tr/min, peut-être même des versions « enterprise »
Pendant 5 ans, un disque tombait en panne en moyenne tous les 6 mois. J’avais 2 disques de parité, je gardais un disque de rechange, et j’envoyais un RMA à chaque panne
Après un déménagement, j’ai eu une pièce dédiée au labo, et avec la même configuration je n’ai eu aucune panne pendant les 5 années suivantes. Je m’attendais à ce que le nouvel environnement soit meilleur, mais j’ai été surpris de voir à quel point un environnement plus propre et plus stable pouvait faire la différence
J’ai toujours utilisé des NAS/serveurs de fichiers dans des environnements résidentiels poussiéreux, et encore aujourd’hui on voit presque le logo Synology gris tout pelucheux, mais je n’ai jamais vu ça
Je pense qu’il y avait un problème de firmware sur cette génération
Voir ici les taux de panne annuels : https://www.backblaze.com/blog/best-hard-drive-q4-2014/
Avec les disques modernes scellés et remplis à l’hélium, même si c’était un problème au départ, ce ne devrait plus être un gros souci
À propos du passage « on accepte le risque de perdre le système à cause d’un problème d’alimentation », un autre type de panne très rare contre lequel un UPS protège est le déséquilibre électrique
Des travaux à proximité peuvent provoquer un problème électrique, ou la foudre peut frapper un poteau près de la maison, créant des pics vers le haut ou vers le bas, tous deux potentiellement destructeurs
À mon premier travail, il y a environ 10 ans, plusieurs serveurs sont morts comme ça. Mais c’est la seule fois où j’ai entendu parler d’un tel problème
D’après ce que je comprends, un UPS protège aussi contre ces pics, et c’est l’UPS qui mourra avant que le serveur ne soit endommagé
La foudre a frappé directement l’antenne TV chez mes parents, et le câble coaxial allait jusqu’à l’amplificateur/répartiteur du coffret de communication
Ensuite, je ne sais pas exactement comment, c’est passé vers un panneau de brassage réseau à proximité et ça a grillé tous les contrôleurs Ethernet filaires connectés au réseau. Y compris ceux intégrés aux ports du switch et aux AP
Dans le switch réseau, le courant a apparemment essayé de partir à la terre, au point de détruire aussi l’alimentation
La façon dont c’est passé du coaxial au Cat5 reste un peu mystérieuse. Peut-être qu’un électricien avait posé quelque part les deux câbles en parallèle, très proches l’un de l’autre
Il a fallu refaire tout le réseau, mais heureusement il n’y avait pas d’ordinateur filaire sur place. Je pense que les unités de stockage auraient eu du mal à survivre aussi
Le petit APC 850 VA à 99 $ acheté chez Office Depot ne fait pas ça. Il bascule simplement très vite du secteur vers la batterie, sans réellement nettoyer l’alimentation
Si vous pouvez vous payer un bon modèle, cela améliore vraiment la fiabilité du matériel à long terme. Une alimentation propre, c’est bien
Vu la répartition entre les équipements morts, endommagés et apparemment intacts, la paire de cuivre transportant le VDSL était très clairement le chemin principal. Le modem était connecté à tout le reste en Ethernet
La vraie solution serait probablement de convertir en fibre, de passer par une petite section de fibre optique, puis de reconvertir. L’électricité choisira plus probablement un autre chemin que le verre
Mais choisir les produits s’est révélé beaucoup plus pénible que prévu, et comme je ne suis pas quelqu’un du réseau, j’ai abandonné après avoir essayé pendant environ une heure de distinguer les produits
J’ai donc mis un pont Wi‑Fi entre le modem VDSL et le reste de l’équipement. J’espère que lors du prochain orage, ce mode de panne sera isolé
Il y avait une grappe ZFS connectée au même modem ; elle a survécu, mais je pense avoir eu de la chance
Je n’avais pas de serveur à l’époque, mais des ampoules LED tombaient en panne toutes les quelques semaines, ce qui était agaçant. C’était un vieux bâtiment des années 60, et il y avait aussi des réparations de fortune suspectes dans l’installation électrique de mon appartement
Le « secret », ce n’est pas de couper l’alimentation, c’est simplement la chance
Je fais tourner des disques HGST de 4 To en 24/7 depuis plus de 10 ans. Pas 24 exactement, mais 8, et zéro panne
Moi aussi j’ai juste de la chance, et j’ai des amis qui ont envoyé plusieurs fois les mêmes disques en RMA
Ce qui m’intrigue le plus, c’est : quelles sont les données qui nécessitent 71 To tout en pouvant rester éteintes la plupart du temps ? Un serveur de stockage de sauvegarde ?
Par exemple, les roulements peuvent se gripper à froid
Quelqu’un qui connaît correctement les statistiques pourrait sans doute estimer un taux de panne annuel d’environ 1 % et calculer la probabilité que les 24 survivent tous
Et en plus, les 20 disques du NAS précédent n’ont pas eu de panne non plus. Ça donne N=44 : à quel point faut-il être chanceux ?
C’est utilisé à domicile, et quand j’ai besoin des données, je les copie généralement en 10 Gbit vers un système bien moins gourmand, puis je rééteins ce NAS
Il y a eu des disques pour lesquels les cycles d’alimentation étaient risqués
Donc je suis d’accord avec le modèle, mais il ne faut pas supposer que c’est toujours une bonne méthode pour tout le monde. Certains SSD doivent être alimentés périodiquement
Avec le cycle d’utilisation d’un NAS, cette exigence est probablement satisfaite
C’est sans doute correct, et la facture d’électricité est clairement plus basse. Les disques avec de la graisse supplémentaire sur l’axe ont été un cas particulier d’une certaine époque
Je me demande si Backblaze dispose d’un modèle statistique sur les disques allumés/éteints et leur durée de vie. Ils sont probablement plutôt dans un espace où tout reste toujours allumé
Mais dans mon cas, je ne fais pas subir de cycles d’alimentation fréquents à ces disques. Au maximum quelques fois par mois
Je ne peux pas dire ni prouver que ce n’est pas un gros risque, mais je crois que ce n’en est pas un et j’accepte ce risque depuis plus de 15 ans
Il faut aussi se rappeler que les disques durs ont une option de mise en veille des plateaux quand ils sont inactifs. Autrement dit, les disques durs peuvent supporter de nombreux redémarrages des plateaux dans une journée
Pour sauvegarder quelques appareils Synology, il utilisait des disques durs 3,5 pouces internes avec un dock USB, et quand il remettait un disque dans le dock pour restaurer des fichiers ou faire une sauvegarde supplémentaire, j’avais l’impression qu’environ 1 fois sur 10, il ne se rallumait pas
En production, nous utilisons depuis plusieurs années une base de données PostgreSQL de plusieurs To sur ZFS, et jusqu’ici nous n’avons rencontré aucun problème, pas même de bit flip
Pour ceux que ça intéresse, j’ai documenté notre expérience ici :
https://lackofimagination.org/2022/04/our-experience-with-po...
Concernant les coupures d’alimentation intermittentes au démarrage, il faut regarder le fait que les disques tirent de la puissance sur le rail 5 V au démarrage
Des disques similaires consomment généralement jusqu’à 1,2 A. En combinant cela avec la charge maximale de 25 A sur le rail 5 V (Seasonic Platinum 860 W), il est très probable que des défaillances d’alimentation surviennent au démarrage si l’on n’utilise pas de démarrage échelonné des disques