Je connais bien ce qu'un BBWC (cache d'écriture avec batterie) est destiné à faire - et les ai déjà utilisés sur mes serveurs, même avec un bon onduleur. Il y a évidemment des défaillances pour lesquelles il ne fournit pas de protection. Je suis curieux de savoir si cela offre réellement un réel avantage dans la pratique.
(NB, je recherche spécifiquement des réponses de personnes qui ont une BBWC et qui ont eu des plantages / échecs et si la BBWC a aidé à la récupération ou non)
Mise à jour
Après les commentaires ici, je suis de plus en plus sceptique quant à savoir si un BBWC ajoute une valeur.
Pour avoir une confiance en l'intégrité des données, le système de fichiers DOIT savoir quand les données ont été validées dans un stockage non volatile (pas nécessairement le disque - un point sur lequel je reviendrai). Il convient de noter que de nombreux disques reposent sur le moment où les données ont été validées sur le disque ( http://brad.livejournal.com/2116715.html ). Bien qu'il semble raisonnable de supposer que la désactivation du cache sur disque pourrait rendre les disques plus honnêtes, il n'y a toujours aucune garantie que ce soit le cas non plus.
En raison des tampons généralement volumineux dans un BBWC, une barrière peut nécessiter beaucoup plus de données à enregistrer sur le disque, entraînant ainsi des retards sur les écritures: le conseil général est de désactiver les barrières lors de l'utilisation d'un cache de réécriture non volatile (et de désactiver mise en cache disque). Cependant, cela semble compromettre l'intégrité de l'opération d'écriture - ce n'est pas parce que davantage de données sont conservées dans un stockage non volatil qu'elles seront plus cohérentes. En effet, sans démarcation entre les transactions logiques, il semble qu'il y ait moins de possibilités d'assurer la cohérence qu'autrement.
Si le BBWC devait reconnaître les barrières au moment où les données entrent dans leur stockage non volatile (plutôt que d'être engagé sur le disque), il semblerait qu'il satisfasse à l'exigence d'intégrité des données sans pénalité de performance - ce qui implique que les barrières devraient toujours être activées. Cependant, étant donné que ces appareils présentent généralement un comportement compatible avec le vidage des données vers l'appareil physique (nettement plus lent avec des barrières) et les conseils répandus pour désactiver les barrières, ils ne peuvent donc pas se comporter de cette façon. POURQUOI PAS?
Si les E / S dans le système d'exploitation sont modélisées comme une série de flux, il est possible de minimiser l'effet de blocage d'une barrière d'écriture lorsque la mise en cache d'écriture est gérée par le système d'exploitation - car à ce niveau, seule la transaction logique (un seul flux) ) doit être engagé. D'un autre côté, un BBWC n'ayant aucune connaissance des bits de données qui composent la transaction devrait valider l'intégralité de son cache sur le disque. Que le noyau / système de fichiers implémente réellement cela dans la pratique nécessiterait beaucoup plus d'efforts que je ne souhaite investir pour le moment.
Une combinaison de disques informant les fibs de ce qui a été commis et d'une coupure de courant soudaine conduit sans aucun doute à la corruption - et avec un système de fichiers journalisé ou structuré qui ne fait pas un fsck complet après une panne, il est peu probable que la corruption soit détectée et encore moins une tentative de réparation.
En termes de modes de défaillance, d'après mon expérience, la plupart des coupures de courant soudaines se produisent en raison d'une perte d'alimentation secteur (facilement atténuée avec un onduleur et un arrêt géré). Les personnes qui sortent le mauvais câble du rack impliquent une mauvaise hygiène du centre de données (étiquetage et gestion des câbles). Il existe certains types d'événements de perte de puissance soudaine qui ne sont pas empêchés par un onduleur - une défaillance de l'alimentation ou du VRM, un BBWC avec des barrières fournirait l'intégrité des données en cas de défaillance ici, mais quelle est la fréquence de tels événements? Très rare à en juger par le manque de réponses ici.
Il est certain que déplacer la tolérance aux pannes plus haut dans la pile est beaucoup plus cher qu'un BBWC - cependant, la mise en œuvre d'un serveur en tant que cluster présente de nombreux autres avantages en termes de performances et de disponibilité.
Une autre façon d'atténuer l'impact d'une perte de puissance soudaine serait d'implémenter un SAN - AoE en fait une proposition pratique (je ne vois pas vraiment l'intérêt de l'iSCSI) mais encore une fois, il y a un coût plus élevé.
