Comment le cache en écriture modifie le risque de perte de données dans un NAS domestique

Le cache en écriture différée augmente le risque de perte de données sur un NAS domestique uniquement lorsqu’une écriture est reconnue avant que le stockage non volatile protégé ne l’ait sécurisée.

Une copie de fichier se termine-t-elle rapidement même si les disques continuent de travailler, ou envisagez-vous un cache SSD pour améliorer les performances des machines virtuelles et des bases de données ? La question importante n’est pas simplement de savoir si l’écriture différée est activée, mais quelle couche envoie la reconnaissance d’achèvement et ce qui survit en cas de panne de courant, du système d’exploitation, d’un contrôleur ou d’un dispositif de cache. Ce guide sépare ces domaines de défaillance pour que vous puissiez conserver l’avantage de vitesse uniquement lorsque tout le chemin d’écriture préserve la durabilité attendue par vos applications.

Que reconnaît réellement le cache en écriture différée ?

Une reconnaissance d’écriture est une promesse faite par une couche à la couche supérieure. En mode écriture immédiate, le cache ne signale pas l’achèvement tant que l’écriture n’a pas atteint le stockage de sauvegarde requis. En mode écriture différée, le cache peut signaler l’achèvement tout en conservant des données modifiées qui doivent encore être transférées vers le niveau plus lent.

Cette distinction est plus précise que de qualifier l’écriture immédiate de « sûre » et l’écriture différée de « risquée ». Un cache en écriture différée soutenu par un support non volatile protégé peut garantir une promesse de durabilité valide. Une pile en écriture immédiate peut toujours être dangereuse si un disque ou un contrôleur inférieur accuse réception des données depuis la mémoire volatile et ignore les commandes de vidage destinées à les rendre persistantes.

Les piles de stockage modernes utilisent des commandes d’ordonnancement et de durabilité plutôt que d’attendre aveuglément après chaque bloc. La couche bloc Linux documente les vidages forcés du cache et Force Unit Access comme des mécanismes permettant aux systèmes de fichiers de contrôler le cache volatile d’un appareil. L’écriture différée est donc acceptable uniquement lorsque chaque couche transmet et respecte la demande de vidage ou d’écriture synchrone de l’application.

Où les données reconnues peuvent-elles encore être perdues ?

Mémoire volatile du système ou du contrôleur

La RAM système, un cache de contrôleur RAID non protégé ou un autre tampon volatile perd son contenu modifié lorsque son alimentation disparaît. Si le client a déjà été informé qu'une écriture synchrone est terminée, le NAS ne peut pas recréer ces octets après un redémarrage. La conséquence peut être une transaction récente manquante, un enregistrement VM ou base de données endommagé, ou une incohérence au niveau de l'application.

Un plantage logiciel n'est pas identique à une coupure de courant secteur. Une alimentation sans coupure (UPS) peut maintenir l'alimentation du matériel lors d'une panne de courant, mais elle ne peut pas préserver la RAM ordinaire lors d'un panic du noyau, d'un redémarrage par watchdog, d'une défaillance de la carte mère ou d'un redémarrage dur accidentel. L'intervalle vulnérable dure jusqu'à ce que les données modifiées atteignent la couche de stockage suivante qui garantit la durabilité promise.

Cache SSD sans protection contre la perte de puissance

La mémoire flash NAND est non volatile, mais un SSD peut temporairement conserver les données utilisateur et les métadonnées de traduction flash dans une DRAM volatile. Une coupure brutale de l'alimentation de l'appareil peut donc menacer les données que l'hôte croyait avoir vidées si le SSD n'implémente pas correctement la protection attendue. La protection matérielle contre la perte de puissance fournit une réserve d'énergie pour que le contrôleur puisse terminer les travaux internes critiques ; l'explication de Kingston sur la protection contre la perte de puissance des SSD pour les données en cours et les tables de correspondance décrit cette limite au niveau de l'appareil.

Le miroir de deux SSD avec cache protège contre la défaillance d'un seul appareil, mais un miroir ne crée pas de protection contre la perte de courant à l'intérieur de chaque disque. Inversement, la protection contre la perte de puissance (PLP) sur un SSD ne fournit pas de redondance contre une défaillance du contrôleur ou du média. Un cache d'écriture de grande valeur peut nécessiter les deux, selon ce que promet le logiciel de mise en cache et la quantité de données reconnues que le propriétaire est prêt à perdre.

Cache d'écriture interne au disque

Les disques durs (HDD) et les SSD activent souvent un cache d'écriture volatile interne pour améliorer les performances. Ce n'est pas automatiquement dangereux lorsque le disque et le contrôleur traitent correctement les commandes flush et FUA. Cela devient risqué lorsqu'un pont, un contrôleur, un paramètre de firmware ou un disque signale la fin de l'opération sans respecter ces commandes.

Désactiver le cache de tous les disques n'est pas la solution par défaut car cela peut entraîner une perte de performance importante et peut être inutile avec une pile de stockage correctement configurée. Vérifiez plutôt le chemin de la commande et le comportement de protection au lieu de supposer que le paramètre de cache NAS de niveau supérieur contrôle chaque couche inférieure.

Pourquoi un onduleur, un cache contrôleur protégé et un PLP SSD résolvent-ils des défaillances différentes ?

Un onduleur maintient l'alimentation de tout le NAS lors d'une courte coupure de courant et peut signaler au système d'exploitation de vider les données et de s'arrêter avant que sa batterie ne soit épuisée. Network UPS Tools décrit une séquence d'arrêt dans laquelle le système d'exploitation est arrêté proprement à faible batterie. Le lien de communication et la configuration de l'arrêt automatique sont aussi importants que la batterie elle-même.

Un onduleur ne couvre pas toutes les défaillances internes : il ne peut pas sauver le cache volatile d'une panne d'alimentation interne, d'un redémarrage du contrôleur, d'un crash du noyau, d'une déconnexion d'alimentation ou d'un SSD cache défaillant. Ces lacunes nécessitent une protection au niveau de la couche qui détient les données sales. Un cache contrôleur avec batterie ou mémoire flash préserve les écritures reconnues par ce contrôleur, tandis que le PLP SSD fournit une énergie locale pour protéger l'état en cours du disque et ses métadonnées internes.

La protection doit également échouer en toute sécurité. Un contrôleur doit revenir à l'écriture directe lorsque sa batterie, son condensateur ou son module de protection du cache est défaillant. Surveillez cet état et testez les alertes ; posséder le matériel ne signifie pas avoir un chemin de protection actif et récupérable.

Comment les systèmes de fichiers et les écritures synchrones modifient-ils le risque ?

Journalisation et Copy-on-Write des systèmes de fichiers

Le journalisation et le copy-on-write aident un système de fichiers à récupérer une structure cohérente après une interruption, mais ils ne peuvent pas récupérer les données utilisateur reconnues qui n'ont jamais atteint un stockage durable. Ils dépendent des couches inférieures qui respectent l'ordre d'écriture, les barrières, les vidages ou le FUA. Un système de fichiers cohérent peut encore contenir une version plus ancienne d'un fichier ou d'une transaction de base de données.

La sémantique synchrone est importante car des applications telles que les bases de données et les machines virtuelles l'utilisent. fsync, O_SYNC, ou des requêtes réseau équivalentes lorsqu’une transaction doit survivre à un crash. Les applications asynchrones peuvent accepter une fenêtre définie de perte de données récentes pour la rapidité. Forcer les charges synchrones à se comporter de manière asynchrone modifie le contrat de durabilité de l’application plutôt que de simplement optimiser un cache.

Limites du ZIL et du SLOG dans ZFS

ZFS dispose déjà d’un journal d’intention ZFS pour les opérations synchrones ; un dispositif de journal séparé, ou SLOG, déplace ce journal vers un autre appareil. Ce n’est pas un cache write-back général, il n’accélère pas les écritures asynchrones ordinaires de la même manière, et ne stocke pas de façon permanente la copie principale des données. OpenZFS recommande de considérer les dispositifs SLOG pour les charges utilisant fsync ou O_SYNC sur des pools mécaniques.

Un SLOG doit toujours fournir la latence, l’endurance, le comportement de vidage et la protection contre la perte d’alimentation requis par la charge de travail. Le miroir peut protéger contre une défaillance du dispositif de journalisation pendant l’intervalle où il contient le seul enregistrement durable des écritures synchrones reconnues. Configurer un dataset pour ignorer la sémantique synchrone demandée peut améliorer les performances, mais cela accepte explicitement la perte des transactions récentes reconnues après un crash.

Quelles charges de travail bénéficient réellement du cache write-back ?

Le write-back est le plus utile lorsque la charge entrante est en rafales, sensible à la latence, et que le stockage plus lent peut ensuite vider les données modifiées. Les exemples incluent les petites écritures aléatoires, le stockage de machines virtuelles, les transactions de bases de données, les artefacts de compilation, l’état des applications et les courtes rafales multi-clients dirigées vers un pool de disques durs.

Il ne peut pas transformer le groupe de disques sous-jacent en un stockage plus rapide de façon permanente. Une fois que les données modifiées remplissent la zone de cache autorisée, le débit soutenu diminue vers le taux auquel le pool de disques durs peut absorber les écritures. La récupération, les vérifications, les lectures et autres E/S peuvent encore réduire ce taux de vidange.

Les copies séquentielles importantes peuvent bénéficier moins que prévu, surtout lorsque le réseau est déjà plus lent que le groupe de disques. La documentation Linux bcache explique que les E/S séquentielles importantes peuvent contourner le cache car la mise en cache SSD est généralement plus utile pour les E/S aléatoires. La conception du cache dépend de l’implémentation, mais le principe de décision est transférable : mesurer la charge de travail plutôt que de supposer que chaque copie de fichier 10GbE nécessite un write-back.

Comment auditer le chemin d'écriture du NAS avant de l'activer ?

Tracez tout le chemin : application, système d'exploitation client, protocole réseau, cache de pages NAS, système de fichiers, cache logiciel, cache RAID ou HBA, firmware SSD ou HDD, et support physique. Marquez la couche qui reconnaît la complétion, la couche qui rend les données non volatiles en premier, et le statut de protection entre elles.

Sur les systèmes Linux avec des périphériques ATA ou SCSI directement visibles, smartctl -g wcache /dev/sdX peut interroger un paramètre de cache d'écriture volatile pris en charge. La requête de cache d'écriture smartctl montre également pourquoi le cache du disque est séparé du cache SSD au niveau NAS ; les périphériques derrière des contrôleurs RAID peuvent nécessiter l'utilitaire de gestion du contrôleur. Limitez l'inspection à une simple interrogation à moins de bien comprendre la pile, puis enregistrez la politique du contrôleur, la santé de la protection du cache, le PLP SSD, la redondance du cache, les propriétés de synchronisation du système de fichiers, l'autonomie de l'UPS, la livraison des notifications et les seuils d'arrêt.

sudo smartctl -g wcache /dev/sdX
sudo smartctl -x /dev/sdX
sudo hdparm -W /dev/sdX

Testez le chemin d'arrêt sans couper l'alimentation d'un pool de production actif. Utilisez le test pris en charge par le logiciel UPS ou un événement simulé, vérifiez que le NAS le reçoit, et confirmez que les services s'arrêtent et que les systèmes de fichiers se démontent avant la date limite de la batterie configurée. Effectuez un benchmark avec des données représentatives plus grandes que la RAM et le cache afin qu'une brève rafale en mémoire ne soit pas confondue avec une performance de stockage durable.

Quand faut-il activer, restreindre ou désactiver le cache en écriture différée ?

Activez l'écriture différée lorsque les mesures montrent un avantage significatif de la charge de travail et que le cache peut honnêtement satisfaire les vidages requis malgré les pannes que vous êtes prêt à tolérer. Pour les données synchrones importantes, cela signifie normalement un support de cache protégé, un comportement de vidage vérifié, une surveillance de la santé, une endurance suffisante, un chemin de récupération testé et une alimentation sans coupure (UPS) communicante comme couche de défense supplémentaire.

Limitez le write-back aux ensembles de données sélectionnés lorsque seules les machines virtuelles, bases de données ou états d’application bénéficient d’une latence réduite ; un domaine de risque plus restreint est plus facile à valider et à récupérer. Gardez les médias en masse, les sauvegardes froides et les transferts séquentiels longs sur un chemin plus simple lorsqu’ils n’en tirent pas avantage. Utilisez le cache write-through ou en lecture seule lorsque le gain n’est pas mesuré, que le cache présente un point de défaillance non protégé, que l’arrêt UPS n’est pas testé, que la protection du contrôleur est défaillante ou que la perte d’écritures reconnues est inacceptable.

Ne considérez pas la redondance du cache comme une sauvegarde. Les snapshots, la réplication et les copies hors ligne ou hors site protègent contre différents modes de défaillance, y compris la suppression, les malwares, les erreurs d’opérateur et la perte du pool. La protection du cache réduit la probabilité de rompre une promesse d’écriture récente ; elle ne remplace pas les copies récupérables des données.

FAQ

Un onduleur rend-il le cache write-back complètement sûr ?

Non. Un onduleur communicant réduit le risque lié à une coupure de courant externe et donne au NAS le temps de vider le cache et de s’arrêter, mais il ne couvre pas une défaillance de l’alimentation, un panic du noyau, un reset du contrôleur, une défaillance du périphérique de cache, un câble interne déconnecté ou une configuration d’arrêt défaillante. Il doit compléter la protection au niveau des périphériques et du contrôleur.

Un cache d’écriture SSD en miroir suffit-il sans protection contre la perte de puissance ?

Pas nécessairement. Le mirroring protège contre la défaillance d’un SSD, mais les deux disques peuvent perdre leur état interne volatile lors du même événement de coupure de courant. Si la couche de cache dépend de la durabilité des vidages, vérifiez que chaque SSD répond à cette exigence ; utilisez des preuves spécifiques au modèle de PLP plutôt que de supposer que la NAND seule suffit.

Le cache en lecture seule est-il plus sûr que le cache write-back ?

Oui, en ce qui concerne la perte de cache sale. Un cache en lecture seule stocke des copies remplaçables des données déjà présentes dans le pool de stockage, donc le perdre ne devrait pas entraîner la perte des écritures reconnues. Il peut toujours ajouter de la complexité ou échouer, mais il ne crée pas le même intervalle où le cache détient la seule copie actuelle.

Conclusion finale

Le cache write-back n'a pas un niveau de risque universel. Il modifie le risque des données sur un NAS domestique selon l'endroit où la complétion est reconnue, si ce cache est réellement non volatile, si les vidages atteignent chaque couche inférieure, et quelles défaillances le système de protection peut supporter.

Cartographiez le chemin d'écriture, vérifiez l'arrêt de l'onduleur (UPS), la protection du contrôleur, le PLP du SSD, la redondance du cache, les paramètres du disque et la sémantique du système de fichiers, puis évaluez la charge de travail réelle. Activez le write-back uniquement lorsque le gain mesuré justifie la fenêtre de défaillance restante ; sinon, utilisez un cache write-through ou en lecture seule et conservez le modèle de durabilité plus simple.