ZFS et SAN - meilleures pratiques?

La plupart des discussions sur ZFS suggèrent que le RAID matériel soit désactivé et que ZFS devrait parler directement aux disques et gérer le RAID sur l'hôte (au lieu du contrôleur RAID).

Cela a du sens sur un ordinateur avec 2-16 ou même plus de disques locaux, mais qu'en est-il dans un environnement avec un grand SAN?

Par exemple, l'entreprise pour laquelle je travaille possède ce que je considérerais comme un SAN de taille modeste avec 2 racks complets de disques, ce qui représente quelque chose comme 400 broches. J'ai vu des étagères SAN bien plus denses que la nôtre et des déploiements SAN bien plus grands que les nôtres.

Les gens exposent-ils 100 disques directement aux gros serveurs ZFS? 300 disques? 3000 disques? Les outils de gestion SAN facilitent-ils la gestion automatisée de ce genre de choses?

FWIW J'ai de l'expérience avec jusqu'à 92 disques dans un seul pool ZFS et jusqu'à présent, cela fonctionne bien.

Mais si vous parlez vraiment de plusieurs centaines de disques, j'envisagerais de les partitionner en un petit nombre de pools disjoints (mais toujours importants). Je ne veux pas savoir combien de temps par exemple un zpool scrubs'exécute sur un pool de disques de 3000 (mais vous voulez nettoyer régulièrement). De plus, la sortie de commandes comme celle- zpool statusci serait difficile à gérer avec un si grand nombre de disques. Alors pourquoi mettre tous les œufs dans un même panier?

(Note latérale sur la déduplication : notez que bien que la déduplication puisse être contrôlée au niveau de l'ensemble de données, elle trouvera des doublons au niveau du pool. Autrement dit, vous obtiendrez probablement de moins bons résultats de déduplication si vous partitionnez comme suggéré. besoin de beaucoup plus de mémoire pour contenir les hachages de déduplication d'un seul pool géant qui pourraient ne pas convenir à ARC + L2ARC si le pool est trop grand. .)

Nous laissons nos SAN gérer le RAID. Pourquoi dépenser de l'argent sur toute cette NVRAM alimentée par batterie et ces processeurs dédiés, puis décharger le travail sur le serveur, dont les processeurs je veux faire autre chose que des sommes de contrôle RAID?

Voici un site Web que vous voudrez peut-être consulter pour prendre en compte la taille et la configuration du ou des pools pour la probabilité de perte de données.
https://blogs.oracle.com/relling/entry/zfs_copies_and_data_protection

C'est une vieille question mais c'est juste un sujet d'actualité comme il y a 7 ans!

Pour répondre à la première partie de la question, je ne sais pas ce que nous appellerions un «SAN» qui exposerait jamais les disques bruts à un serveur qui pourrait exécuter ZFS. Un SAN par définition ne présente que le stockage par blocs (LUN) ou peut-être avec quelque chose comme un Filer / FS présente un NFS ou CIFS. Il existe certains "SAN" qui exécutent ZFS en interne, mais ils sont largement abstraits - les disques ne sont jamais exposés à un serveur, mais le composant "Filer" du SAN présente des systèmes de fichiers en bloc ou réseau aux serveurs.

Un périphérique qui présente les disques bruts (via SAS ou moins probablement via FC) est un DAS. Pour exécuter ZFS, vous diriez généralement au contrôleur RAID de présenter les disques en tant que JBOD.

Cependant, devez-vous utiliser ZFS sur un LUN présenté par un SAN? Peut-être: ZFS vs par exemple EXT4, fournit quelques fonctionnalités supplémentaires telles que des scrubs qui vérifient les sommes de contrôle ou pour exécuter des instantanés. Un nettoyage ne peut probablement pas réparer automatiquement de la même manière qu'il le fait s'il fait le RAID de disque, mais il peut toujours vous alerter de la corruption, aidant à prévenir le bitrot. Les instantanés que vous pouvez créer sur, par exemple, un serveur de fichiers Linux SAMBA sont largement supérieurs à ce que vous pouvez faire avec EXT, ils peuvent même être exposés dans Windows en tant que "Versions précédentes).

Si vous ne donnez pas de données redondantes à ZFS pour travailler (par exemple, miroirs, RAID-Z), vous perdez de nombreux avantages de son utilisation. Le nombre de disques impliqués ne changera pas ce fait. Cependant, que cela soit important dépend vraiment de votre environnement. Vous devez déterminer les fonctionnalités de stockage dont vous avez besoin (une analyse potentiellement laborieuse), puis rechercher la solution la moins chère (que vous pouvez vous permettre) qui répond à vos besoins. Cela peut signifier utiliser ZFS partout avec des périphériques de stockage Oracle spécialisés (certaines personnes le font et ont de nombreux disques exposés à ZFS sans problème et utilisent des outils Oracle pour faire la gestion), cela peut signifier utiliser uniquement des produits SAN d'entreprise, ou cela peut signifier utiliser un hybride (auquel cas vous devrez probablement développer vous-même certains outils et processus pour gérer l'environnement). Don'