ZFS - la destruction de zvol ou d'un ensemble de données dédupliqués bloque le serveur. Comment récupérer?

J'utilise Nexentastor sur un serveur de stockage secondaire fonctionnant sur un HP ProLiant DL180 G6 avec 12 disques SAS Midline (7200 tr / min). Le système a un processeur E5620 et 8 Go de RAM. Il n'y a pas de périphérique ZIL ou L2ARC.

La semaine dernière, j'ai créé un zvol clairsemé de 750 Go avec déduplication et compression activées pour partager via iSCSI vers un hôte VMWare ESX. J'ai ensuite créé une image de serveur de fichiers Windows 2008 et copié ~ 300 Go de données utilisateur sur la machine virtuelle. Une fois satisfait du système, j'ai déplacé la machine virtuelle vers un magasin NFS sur le même pool.

Une fois opérationnel avec mes machines virtuelles sur la banque de données NFS, j'ai décidé de supprimer le zvol original de 750 Go. Cela a bloqué le système. L'accès à l'interface Web Nexenta et au NMC a été interrompu. J'ai finalement pu arriver à un shell brut. La plupart des opérations du système d'exploitation allaient bien, mais le système était suspendu à la zfs destroy -r vol1/filesystemcommande. Laid. J'ai trouvé les deux entrées de bugzilla OpenSolaris suivantes et je comprends maintenant que la machine sera maçonnée pendant une période de temps inconnue. Cela fait 14 heures, j'ai donc besoin d'un plan pour pouvoir retrouver l'accès au serveur.

http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=6924390

et

http://bugs.opensolaris.org/bugdatabase/view_bug.do;jsessionid=593704962bcbe0743d82aa339988?bug_id=6924824

À l'avenir, je suivrai probablement les conseils donnés dans l'une des solutions de contournement de Buzilla:

Workaround
    Do not use dedupe, and do not attempt to destroy zvols that had dedupe enabled.

Mise à jour: j'ai dû forcer le système à s'éteindre. Au redémarrage, le système s'arrête Importing zfs filesystems. C'est ainsi depuis 2 heures maintenant.

Cela a été résolu. Leur clé est que les volumes dédupliqués doivent avoir le drapeau de déduplication désactivé avant la suppression. Cela doit être fait au niveau du pool ainsi qu'au niveau zvol ou système de fichiers. Sinon, la suppression est essentiellement en cours de déduplication. Le processus prend du temps car la table de déduplication ZFS est référencée. Dans ce cas, la RAM aide. J'ai temporairement ajouté 16 gigaoctets de RAM supplémentaires au système et remis le serveur en ligne. Le zpool importé complètement dans les 4 heures.

La morale est probablement que la déduplication n'est pas super polie et que la RAM est essentielle à ses performances. Je suggère 24 Go ou plus, selon l'environnement. Sinon, laissez la déduplication ZFS désactivée. Ce n'est certainement pas raisonnable pour les utilisateurs à domicile ou les petits systèmes.

En tant qu'utilisateur de longue date des appliances Sun / Oracle ZFS 7000, je peux vous dire sans aucun doute que la déduplication n'est pas raffinée. Ne confondez jamais vente et livraison! Les vendeurs vous diront "Oh, c'est réglé". Dans la vraie vie - ma vraie vie - je peux vous dire que 24 Go ne suffisent pas pour gérer les «tables DDT». C'est-à-dire, l'index principal qui stocke la table de déduplication. Cette table doit résider dans la mémoire système afin que chaque E / S soit interceptée en vol afin de déterminer si elle doit être écrite sur le disque ou non. Plus votre pool de stockage est grand, plus les changements de données sont importants, plus cette table est grande et plus la mémoire système est importante. Cette mémoire se fait au détriment de l'ARC (cache) et parfois du système d'exploitation lui-même - c'est pourquoi vous rencontrez des blocages, car certaines commandes se produisent au premier plan, certaines en arrière-plan. Il semble que la suppression du pool se produise au premier plan, sauf indication contraire de la CLI. Les assistants graphiques ne le feront pas.

Même une suppression en masse de données NFS dans un partage défini sur un volume dédupliqué réduira de moitié votre système si vous n'avez pas assez de mémoire pour traiter les «écritures» dans ZFS en lui disant de supprimer les données.

Dans l'ensemble, à moins que vous ne maximisiez votre mémoire et même dans ce cas, trouvez un moyen de réserver de la mémoire pour le système d'exploitation en restreignant ARC et DDT (et je ne pense pas que vous pouvez restreindre DDT par nature, c'est juste un index lié exactement à votre E / S) - alors vous êtes arrosé lors de suppressions importantes ou de zvol / pools destory.