Comme le dit la question.
Supposons que je veuille avoir l'équivalent d'un "bouton d'urgence" scripté pour mon pool FreeNAS - quelque chose sur lequel je peux cliquer pour exécuter à partir d'une interface graphique ou exécuter dans la console/SSH, qui ferme très rapidement tout ce qui pourrait être lu ou écrit dessus, démonte le système de fichiers et, idéalement, met au repos les disques ou les partitions qu'il utilise.
Je ne me soucie pas des erreurs survenant sur d'autres logiciels ou connexions à distance en faisant cela, ou en annulant prématurément tout long transfert de fichiers, je veux juste qu'il déconnecte le pool de la manière la plus rapide qui soit compatible avec le maintien de sa cohérence et éventuellement en lui donnant quelques secondes pour que toutes les écritures en attente se terminent et que le pool soit dans un état cohérent à des fins de données.
Les options suggérées par les commandes ZFS ne semblent pas prometteuses :zpool offline ne fonctionne que sur des appareils individuels, il peut donc y avoir une condition de concurrence si l'écriture se produit alors que les disques sont retirés un par un ; zpool export nécessite l'option -f si elle est utilisée et porte un avertissement indiquant que -f peut également perdre des données. On pourrait vérifier tous les file descriptors ouverts utiliser le pool ou ses appareils (des milliers ou des centaines de milliers d'entre eux ?) et forcer manuellement la fermeture de chacun, mais cela pourrait entraîner des conditions de concurrence car cela n'empêche pas la création de nouveaux fd en même temps. Je ne devrais pas non plus supposer que toute l'activité ZFS est médiatisée par une liste de démons de service de fichiers distants auxquels envoyer des signaux de sortie, car certaines activités de fichiers sont susceptibles d'être locales (cron/CLI/sessions détachées).
Donc, en regardant comment mettre hors ligne au mieux un pool entier en toute sécurité et rapidement, cela ressemble à umount pourrait être mon meilleur pari - cela fonctionne au niveau du système de fichiers et peut mettre hors ligne un système de fichiers entier rapidement et en tant qu'unité monolithique, après quoi zpool export on dirait qu'il serait alors en mesure de terminer et de mettre au repos toute activité interne de manière sûre sans le -f option, en gardant les données elles-mêmes dans un état cohérent garanti. S'il y a une activité de disque brut en cours (réargenture ou nettoyage), je suppose que cela reprendra ou redémarrera lorsque le pool sera remis en ligne plus tard.
Mais même umount ne semble pas le faire complètement, car il pourrait y avoir iSCSI zvol cibles en cours d'utilisation. Les données contenues dans celles-ci ne peuvent pas être cohérentes, car le serveur ne connaît pas sa structure, de sorte que les initiateurs distants devront réparer les données du mieux qu'ils peuvent lorsqu'ils se reconnecteront. Cela me convient, mais je ne sais pas si une sorte de commande pour forcer l'arrêt ou la mise hors ligne des cibles est nécessaire ou la meilleure pratique. (Remarque :forcer l'arrêt des connexions a les mêmes problèmes que la fermeture de fd individuels.)
Je suis conscient qu'il y aura forcément une sorte de perte de données ou de problème si le pool est brusquement expulsé de l'état RW lorsque des écritures se produisent. Mais tant qu'il ne perd pas de cohérence (au niveau du pool ZFS et du système de fichiers), tout va bien - tous les fichiers/cibles iSCSI en cours d'utilisation mis à jour devront tenter leur chance sur les fichiers/blocs se trouvant dans un ZFS-cohérent mais état de données non valide en raison de la mise hors ligne à mi-chemin de l'écriture des données. C'est inévitable et ce n'est pas un problème pour la question.
Alors, quelles étapes dois-je réellement suivre pour mettre hors ligne une piscine en cours d'utilisation aussi rapidement que possible, conformément à la sécurité et à la cohérence garanties de la piscine ? et manuellement umount un système de fichiers ZFS en cours d'utilisation (dans le cadre d'une solution) est-il sûr ou comporte-t-il un risque d'endommagement des données ?
Mise à jour : Mentionner ici au cas où quelqu'un d'autre trouverait cela utile. La réponse acceptée indique que export -f peut avoir des problèmes avec zvols (iSCSI, etc.). Sur la base de cet indice, j'ai trouvé que le gestionnaire iSCSI utilisé par FreeNAS peut forcer la déconnexion/terminer les sessions, et a d'autres sous-commandes utiles qui pourraient être émises à l'avance - voir man ctladm . Quelle que soit l'utilisation de vos zvols, il y aura probablement une commande pour mettre fin aux sessions sur eux.)
Réponse acceptée :
Avis de non-responsabilité :je n'ai pas beaucoup de liens et de références pour sauvegarder tout ce qui suit à portée de main pour le moment, et je ne l'ai pas testé de manière approfondie. Ceci n'est qu'un résumé de ce que j'ai lu au cours des cinq à sept dernières années sur ZFS et son fonctionnement, ainsi que quelques tests propres limités (non coordonnés, mais principalement des redémarrages aléatoires).
De plus, tout ce qui suit est dit sans tenir compte des événements catastrophiques (le serveur brûle complètement), des bogues logiciels (bogues dans ZFS et le système d'exploitation principal ainsi que des contrôleurs matériels) et de la malveillance active (administrateur voyou, erreurs d'administration). Dans tous ces cas, vous devez toujours disposer de sauvegardes régulières et restaurables !
Données au repos/cohérence sur disque
Je ne me soucie pas des erreurs survenant sur d'autres logiciels ou connexions à distance en faisant cela, ou en annulant prématurément tout long transfert de fichiers, je veux juste qu'il déconnecte le pool de la manière la plus rapide qui soit compatible avec le maintien de sa cohérence et éventuellement en lui donnant quelques secondes pour que toutes les écritures en attente se terminent et que le pool soit dans un état cohérent à des fins de données.
Tout d'abord, la bonne nouvelle :comme ZFS utilise des transactions CoW et atomiques, vos données déjà existantes seront en sécurité même en cas de coupure de courant soudaine. Cela inclut la disposition du pool et les métadonnées. Comme les anciennes données ne sont jamais déplacées avant que les nouvelles données ne soient complètement écrites (en fait, elles ne sont jamais déplacées du tout, juste réallouées), ces données ne peuvent en aucun cas être en danger si l'écriture est soudainement interrompue.
En relation:Grep - pourquoi les crochets dans le modèle grep suppriment-ils le processus grep des résultats ps?De plus, les sommes de contrôle (arbres de hachage Merkle) aident à certifier que rien de mal ne s'est produit pendant le redémarrage, ce que vous pouvez vérifier en nettoyant le pool. Si vous avez des vdevs redondants, ZFS corrigera automatiquement toutes les erreurs qu'il trouve à partir d'une bonne copie connue. Si certains blocs avaient été corrompus de quelque manière que ce soit (par exemple par un contrôleur de disque malveillant qui n'écrit pas mais dit qu'il le fait), leurs sommes de contrôle ne correspondraient pas à celles des autres vdevs et des erreurs s'afficheraient.
Données en vol/modes d'écriture et perte des n dernières secondes
Écritures synchronisées et asynchrones
Normalement, ZFS collecte plusieurs transactions pour accélérer les écritures coûteuses sur les disques rotatifs - le positionnement de la tête d'écriture du disque dur prend beaucoup plus de temps que l'écriture réelle, vous voudrez donc mettre en file d'attente autant que possible, puis l'écrire en séquentiel (plus rapide !) commande (rappelez-vous, nous avons CoW, cela fonctionne assez naturellement ici).
L'inconvénient est que plus vous collectez longtemps, plus vos applications devront attendre un message "écriture réussie" - ce qui signifie que votre système se verrouillera pendant plusieurs secondes, ce qui est inacceptable. Pire encore, vous perdrez toutes les données qui doivent être écrites sur le disque mais qui n'ont pas encore été écrites en cas de panne de courant. Si vos applications ne peuvent pas faire face à cela, une corruption de la couche application peut se produire.
Pour lutter contre cela, le ZIL (journal d'intention ZFS) a été ajouté. Toutes les transactions de synchronisation sont collectées dans ce journal (qui est stocké par défaut sur le disque du pool lent, mais peut être stocké sur des SSD en miroir plus rapides, qui sont nommés périphériques SLOG) et après leur stockage, « écriture réussie » est renvoyé au application qui peut poursuivre ses tâches (plus de longs verrous). De plus, toutes les transactions asynchrones sont effectuées sans le ZIL, elles peuvent donc être plus rapides - à condition que l'application appelle les opérations d'écriture correctes pour ses données (sync vs async).
Propriétés ZFS
Passons maintenant à la partie la plus intéressante :qu'advient-il de vos écrits ? Là, nous devons discerner le mode de fonctionnement du système de fichiers (il s'agit d'une propriété ZFS et peut être définie individuellement pour chaque système de fichiers). Les trois modes possibles sont (d'après les pages de manuel) :
sync=standard
This is the default option. Synchronous file system transactions
(fsync, O_DSYNC, O_SYNC, etc) are written out (to the intent log)
and then secondly all devices written are flushed to ensure
the data is stable (not cached by device controllers).
sync=always
For the ultra-cautious, every file system transaction is
written and flushed to stable storage by a system call return.
This obviously has a big performance penalty.
sync=disabled
Synchronous requests are disabled. File system transactions
only commit to stable storage on the next DMU transaction group
commit which can be many seconds. This option gives the
highest performance. However, it is very dangerous as ZFS
is ignoring the synchronous transaction demands of
applications such as databases or NFS.
Setting sync=disabled on the currently active root or /var
file system may result in out-of-spec behavior, application data
loss and increased vulnerability to replay attacks.
This option does *NOT* affect ZFS on-disk consistency.
Administrators should only use this when these risks are understood.
Vous remarquerez que même si disabled est choisi, la disposition de votre pool/cohérence interne n'est pas affectée - vous perdrez simplement vos 5 dernières secondes de données et ceci peut placer vos fichiers dans un état incorrect (par exemple, parce que vous avez une machine virtuelle au-dessus qui attend des écritures de synchronisation, mais vous n'avez fourni qu'un zvol asynchrone comme magasin de données de sauvegarde).
D'un autre côté, si vous ne voulez pas perdre rien du tout , définissez tous vos systèmes de fichiers sur always et passer à des SSD hautes performances, au moins pour l'appareil SLOG (ou subir les temps d'attente).
standard est un compromis et le plus flexible - l'application elle-même décide du mode d'écriture dont elle a besoin. Si vos applications sont mauvaises, vous pouvez subir une perte de données. S'ils se comportent bien, vous obtiendrez les meilleures performances possibles avec une ligne de base de sécurité donnée.
Exportation/importation de pool :
À partir de la documentation sur zpool export :
La commande tente de démonter tous les systèmes de fichiers montés dans le pool avant de continuer. Si l'un des systèmes de fichiers ne parvient pas à se démonter, vous pouvez le démonter de force à l'aide de l'option -f.
Si les périphériques ne sont pas disponibles au moment de l'exportation, les périphériques ne peuvent pas être identifiés comme correctement exportés. Si l'un de ces appareils est ensuite connecté à un système sans aucun des appareils en état de marche, il apparaît comme "potentiellement actif".
Si des volumes ZFS sont en cours d'utilisation dans le pool, le pool ne peut pas être exporté, même avec l'option -f. Pour exporter un pool avec un volume ZFS, assurez-vous d'abord que tous les consommateurs du volume ne sont plus actifs.
Cela signifie à peu près trois choses :
-fforce le pool à être exporté en démontant de force tous les systèmes de fichiers, même s'ils sont actifs (sans tenir compte des verrous ou des applications qui y écrivent)- Cela ne fonctionne pas avec
zvols - Vous ne devez pas diviser les pools et les utiliser sur différents systèmes (attention aux situations de basculement)
Résumé :
- Si tout ce qui vous intéresse est la cohérence sur disque, vous pouvez utiliser
export -fou un arrêt complet - Si vous vous souciez de toutes les données, utilisez
sync=alwayset SSD rapides - En ce qui concerne iSCSI/NFS en tant que magasins de données pour les VM, cet aperçu peut également être utile (extrait :utilisez NFS ou désactivez le cache d'écriture différée iSCSI sur l'hôte invité/VM ; mettez la VM au repos avant de prendre un instantané ZFS, ZFS ira bien de toute façon, mais la VM invitée ne sera cohérente qu'en cas de plantage)
En réponse aux questions de suivi des commentaires (questions laissées de côté pour lesquelles je n'ai pas de réponses utiles) :
(1) "bonne nouvelle/COW" - et si les blocs de niveau supérieur étaient sur le point d'être mis à jour - trouvera-t-il toujours un bloc de niveau supérieur utilisable (même s'il pointe vers des versions légèrement anciennes de l'arborescence des métadonnées) ? À quel point cela peut-il devenir grave ?
Le pire des cas serait que l'uberblock (celui au sommet de tous les autres) soit endommagé sur tous les appareils redondants. Comme il n'y a pas de bloc au-dessus, vous ne pouvez pas le reconstruire par le haut, il existe donc plusieurs copies de chaque uberblock (IIRC c'était environ 3 ou 4), donc une peut être perdue et une copie de remplacement est toujours là.
(2) Je connais les TXG et j'utilise ESXi. En utilisant APC UPS + bon PSU/hw + P3700 NVMe ZIL, c'est donc une puissance décente + ZIL rapide. Mais il est peu probable que les écritures actuelles soient toutes synchronisées et, comme vous le dites, sync=always est lent. Mais votre réponse soulève une pensée, je pourrais faire des tests de performance. J'utilise dedup (économie 4x, ça vaut le coup), donc write=slow de toute façon (doit rechercher DDT). La raison étant sync=toujours n'affecte que l'écriture qui est de toute façon lente en raison du DDT. Mais le réglage sync=toujours force ZIL, ZIL est très rapide et cela rend les longs TXG sûrs, ce qui peut signifier que l'accès au disque est plus efficace. Ou cela pourrait tuer la latence. Aucune idée laquelle ! Il faudrait peut-être essayer !
Je n'ai aucune expérience réelle avec la déduplication, donc je ne peux rien dire d'utile ici, sauf que vous avez déjà fait de bons choix en matière de matériel (faible latence, IOPS en écriture aléatoire élevée de 64k, interface NVMe). Cela ne pourrait être plus rapide que si vous investissiez dans un lecteur RAM permanent très coûteux (ZeusRAM et al.).
(6) Par "cohérence sur disque", vous voulez dire que ZFS est heureux et que le pool est cohérent ? Pas inquiet si certains fichiers/répertoires. se retrouver avec un contenu invalide ou non déplacé/supprimé est le pool disparaît soudainement, ou le système de fichiers tel que NTFWS/VMFS sur un zvol est corrompu en interne (c'est-à-dire qu'en tant que zvol ZFS c'est bien mais du point de vue du client il a besoin de fsck/chkdsk), pool fourni est sûr/cohérent tel que ZFS le voit
Oui. Essentiellement "ma piscine n'est pas foutue, yay!" dans une configuration multi-utilisateurs - même si un utilisateur a des problèmes avec ses fichiers, les autres n'en souffrent pas.
(7) Par "collision cohérente", voulez-vous dire ce que je veux dire (je pense que vous le faites) - que ZFS ira bien, le pool pour autant que ZFS le voit ira bien, mais les données du client distant peuvent être mutilées à partir de ce client perspective de la même manière que si le client avait rencontré une panne d'E/S disque soudaine et que des écritures avaient été perdues ? ==le pool ira bien, le client peut avoir des données perdues/incohérentes et peut avoir besoin d'aide pour récupérer, comme pour toute autre panne d'E/S de disque ou plantage du système ?
Oui, essentiellement une mise hors tension matérielle de la machine virtuelle au lieu d'un arrêt propre et PUIS de prendre un instantané - si vous l'allumez par la suite, fsck ou similaire en fonction du système de fichiers s'exécutera et il peut se plaindre d'un arrêt incorrect. Cela contraste avec les instantanés ESXi, qui reprennent à l'instant précis comme si de rien n'était, mais ils nécessitent une interaction avec le système invité (ajouts d'invités installés) et incluent la mémoire virtuelle de la machine virtuelle.
Vous pouvez combiner les deux à votre avantage :prenez d'abord un instantané ESXi, puis un instantané ZFS du magasin de données (ESXi stocke ses instantanés à côté de la VM). Supprimez ensuite votre instantané ESXi, mais conservez celui de ZFS (prend beaucoup moins d'espace en raison des copies au niveau des blocs). Lors de la restauration, restaurez d'abord votre instantané ZFS, puis revenez à votre instantané ESXi (enregistré) et vous reprendrez là où vous vous étiez arrêté. napp-it (excellent système de gestion ZFS avec interface Web) a ce concept intégré (au moins pour les datastores NFS, je n'ai pas vérifié iSCSI mais je suppose que c'est similaire).