Je cherche à créer un pool ZFS plus large (150 To +), et j'aimerais entendre les expériences des gens sur les scénarios de perte de données en raison d'un matériel défaillant, en particulier, en distinguant les cas où seules certaines données sont perdues par rapport à l'ensemble du système de fichiers ( s'il y a même une telle distinction dans ZFS).
Par exemple: disons qu'un vdev est perdu en raison d'une panne comme une panne de boîtier de disque externe ou une défaillance de la carte contrôleur. D'après ce que j'ai lu, le pool devrait passer en mode défectueux, mais si le vdev est renvoyé, le pool devrait récupérer? ou pas? ou si le vdev est partiellement endommagé, perd-on tout le pool, certains fichiers, etc.?
Que se passe-t-il si un appareil ZIL tombe en panne? Ou juste l'un des nombreux ZIL?
Vraiment toutes les anecdotes ou scénarios hypothétiques appuyés par des connaissances techniques approfondies sont appréciés!
Merci!
Mise à jour:
Nous faisons cela à bas prix, car nous sommes une petite entreprise (9 personnes environ), mais nous générons une bonne quantité de données d'imagerie.
Les données sont pour la plupart de petits fichiers, à mon avis, environ 500 000 fichiers par To.
Les données sont importantes mais pas ultra-critiques. Nous prévoyons d'utiliser le pool ZFS pour mettre en miroir un tableau de données «en direct» de 48 To (utilisé pendant environ 3 ans) et d'utiliser le reste du stockage pour les données «archivées».
Le pool sera partagé à l'aide de NFS.
Le rack est censé être sur une ligne de générateur de secours de bâtiment, et nous avons deux onduleurs APC capables d'alimenter le rack à pleine charge pendant environ 5 minutes.
la source
Réponses:
Concevez de la bonne façon et vous minimiserez les risques de perte de données de ZFS. Vous n'avez cependant pas expliqué ce que vous stockez sur la piscine. Dans mes applications, il sert principalement des VMDK VMWare et exporte des zvols via iSCSI. 150 To n'est pas un montant insignifiant, donc je m'appuierais sur un professionnel pour des conseils de mise à l'échelle.
Je n'ai jamais perdu de données avec ZFS.
Je l' ai connu tout le reste:
Mais à travers tout cela, il n'y a jamais eu de perte appréciable de données. Juste des temps d'arrêt. Pour les VMDK VMWare assis au-dessus de ce stockage, un fsck ou un redémarrage était souvent nécessaire après un événement, mais pas pire que tout autre crash du serveur.
En ce qui concerne la perte d'un périphérique ZIL, cela dépend de la conception, de ce que vous stockez et de vos modèles d'E / S et d'écriture. Les appareils ZIL que j'utilise sont relativement petits (4 Go-8 Go) et fonctionnent comme un cache d'écriture. Certaines personnes reflètent leurs appareils ZIL. L'utilisation des périphériques SSD STEC haut de gamme rend la mise en miroir peu coûteuse. J'utilise plutôt des cartes PCIe DDRDrive uniques . Planifiez la protection de la batterie / de l'onduleur et utilisez des cartes SSD ou PCIe avec une sauvegarde de super-condensateur (similaire aux implémentations de contrôleur RAID BBWC et FBWC ).
La plupart de mon expérience a été du côté de Solaris / OpenSolaris et NexentaStor . Je sais que les gens utilisent ZFS sur FreeBSD, mais je ne sais pas jusqu'où se trouvent les versions de zpool et d'autres fonctionnalités. Pour les déploiements de stockage purs, je recommanderais de suivre la route Nexentastor (et de parler à un partenaire expérimenté ), car il s'agit d'un système d'exploitation spécialement conçu et il y a plus de déploiements critiques fonctionnant sur des dérivés Solaris que FreeBSD.
la source
design the right waylien est rompu maintenant.J'ai accidentellement remplacé les deux ZIL sur la dernière version d'OpenSolaris, ce qui a entraîné la perte irrévocable de l'ensemble du pool. (Vraiment une mauvaise erreur de ma part! Je ne comprenais pas que perdre le ZIL signifierait perdre le pool. Heureusement récupéré de la sauvegarde avec un temps d'arrêt.)
Cependant, depuis la version 151a (je ne sais pas ce que signifie la version ZPool), ce problème a été corrigé. Et, je peux témoigner que cela fonctionne.
En dehors de cela, j'ai perdu des données ZERO sur un serveur de 20 To - y compris en raison de plusieurs autres cas d'erreur utilisateur, de multiples pannes de courant, d'une mauvaise gestion du disque, de mauvaises configurations, de nombreux disques en panne, etc. Même si la gestion et les interfaces de configuration sur Solaris changent fréquemment et de façon exaspérante de version en version et présentent un objectif de compétences toujours changeant, c'est toujours la meilleure option pour ZFS.
Non seulement je n'ai pas perdu de données sur ZFS (après ma terrible erreur), mais cela me protège constamment. Je ne subis plus de corruption de données - ce qui me tourmente depuis 20 ans sur un certain nombre de serveurs et de postes de travail, avec ce que je fais. Une corruption de données silencieuse (ou tout simplement "assez silencieuse") m'a tué de nombreuses fois, lorsque les données quittent la rotation de sauvegarde, mais sont en fait devenues corrompues sur le disque. Ou d'autres scénarios où les sauvegardes ont sauvegardé les versions corrompues. Cela a été un problème beaucoup plus important que de simplement perdre des données de manière considérable, ce qui est presque toujours sauvegardé de toute façon. Pour cette raison, j'adore ZFS et je ne comprends pas pourquoi la somme de contrôle et la guérison automatique ne sont pas des fonctionnalités standard des systèmes de fichiers depuis une décennie. (Certes, les systèmes de vie ou de mort ont généralement d'autres moyens d'assurer l'intégrité,
Parole de sagesse, si vous ne voulez pas descendre dans l'enfer ACL, n'utilisez pas le serveur CIFS intégré à ZFS. Utilisez Samba. (Vous avez dit que vous utilisez NFS cependant.)
Je ne suis pas d'accord avec l'argument SAS vs SATA, au moins la suggestion que SAS est toujours préféré à SATA, pour ZFS. Je ne sais pas si ce commentaire faisait référence à la vitesse de rotation du plateau, à la fiabilité présumée, à la vitesse de l'interface ou à un autre attribut. (Ou peut-être simplement "ils coûtent plus cher et ne sont généralement pas utilisés par les consommateurs, donc ils sont supérieurs". Une étude récente publiée par l'industrie (toujours dans l'actualité, je suis sûr), a révélé que SATA survit en fait à SAS en moyenne, au moins avec la taille importante de l'échantillon de l'enquête. (Cela m'a choqué, c'est sûr.) Je ne me souviens pas s'il s'agissait de versions "d'entreprise" de SATA ou de consommateurs, ou à quelle vitesse - mais d'après mon expérience considérable, les modèles d'entreprise et de consommation échouent en même temps. taux statistiquement significatifs. (Il y a le problème des disques grand public qui prennent trop de temps pour expirer en cas d'échec, ce qui est certainement important dans l'entreprise - mais cela ne m'a pas mordu, et je pense qu'il est plus pertinent pour les contrôleurs matériels qui pourraient prendre la totalité volume hors ligne dans de tels cas. Mais ce n'est pas un problème SAS vs SATA, et ZFS ne m'a jamais laissé tomber. À la suite de cette expérience, j'utilise maintenant un mélange de 1/3 disques SATA d'entreprise et 2/3 de disques SATA grand public .) De plus, je n'ai vu aucune performance significative atteinte avec ce mélange de SATA, lorsqu'il est correctement configuré (par exemple une bande de miroirs à trois voies), mais là encore, j'ai une faible demande d'IOPS, donc en fonction de la taille de votre boutique et cas d'utilisation typiques, YMMV. J'ai certainement remarqué que la taille du cache intégré par disque importe plus pour les problèmes de latence que la vitesse de rotation du plateau, dans mes cas d'utilisation.
En d'autres termes, c'est une enveloppe avec plusieurs paramètres: coût, débit, IOPS, type de données, nombre d'utilisateurs, bande passante administrative et cas d'utilisation courants. Dire que SAS est toujours la bonne solution, c'est ignorer un large univers de permutations de ces facteurs.
Mais de toute façon, ZFS est absolument génial.
la source