BBWC: en théorie une bonne idée mais en a-t-on déjà enregistré vos données?

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é.

Sûr. J'ai eu un cache sauvegardé par batterie (BBWC) et plus tard un cache d'écriture sauvegardé par flash (FBWC) protège les données en vol après les plantages et les coupures de courant soudaines.

Sur les serveurs HP ProLiant, le message typique est:

POST Error: 1792-Drive Array Reports Valid Data Found in Array Accelerator

Ce qui signifie, " Hé, il y a des données dans le cache d'écriture qui ont survécu au redémarrage / à la perte de puissance !! Je vais les réécrire sur le disque maintenant !! "

Un cas intéressant était mon post-mortem d'un système qui a perdu de la puissance pendant une tornade , la séquence du tableau était:

POST Error: 1793-Drive Array - Array Accelerator Battery Depleted - Data Loss
POST Error: 1779-Drive Array Controller Detects Replacement Drives
POST Error: 1792-Drive Array Reports Valid Data Found in Array Accelerator

L'erreur 1793 POST est unique. - Pendant que le système était en cours d'utilisation, l'alimentation a été interrompue alors que les données se trouvaient dans la mémoire de l'accélérateur RAID. Cependant, en raison du fait qu'il s'agissait d'une tornade, l'alimentation n'a pas été rétablie dans les quatre jours, de sorte que les batteries de la baie ont été épuisées et les données à l'intérieur ont été perdues. Le serveur avait deux contrôleurs RAID. L'autre contrôleur avait une unité FBWC, qui dure beaucoup plus longtemps qu'une batterie. Ce lecteur a récupéré correctement. Une corruption de données s'est produite sur la baie, soutenue par la batterie vide.

Malgré l'abondance de la batterie dans l'installation, quatre jours sans alimentation et dans des conditions dangereuses, il a été impossible pour quiconque d'arrêter les serveurs en toute sécurité.

Oui, avait ce cas.

Serveur "sans UPS" dans un centre de données (le centre de données ayant un UPS). Échec de la PDU - le système est tombé en panne. Aucune perte de données.

Et c'est tout. La bonne chose à propos d'un BBWC est qu'il est dans la machine. Ayez un UPS - croyez-moi, parfois quelqu'un fait quelque chose de stupide (comme tirer le mauvais câble). Un onduleur est externe. Oh, ce câble;)

J'ai eu 2 cas où le cache sauvegardé par batterie dans les contrôleurs RAID HW a échoué complètement (dans 2 sociétés distinctes).

La BBC s'appuie sur l'idée sans surprise que la batterie fonctionne. Le hic, c'est qu'à un moment donné, la batterie du contrôleur échoue et ce qui est dévastateur, c'est que dans de nombreux contrôleurs de raid HW, il échoue silencieusement . Nous pensions avoir un cache protégé contre les coupures de courant, mais nous ne l'avons pas fait.

En cas de perte d'alimentation, la perte de données de la matrice RAID était si importante que tout le contenu du disque était rendu irrécupérable. Tout était perdu. L'un des cas impliquait une machine entièrement dédiée aux tests, mais quand même.

Après cela, j'ai dit "plus jamais", je suis passé à la mise en miroir de disques basée sur logiciel (mdadm) dans Linux + fs basé sur le journal qui a une résilience décente contre la perte de puissance (ext4) et n'a jamais regardé en arrière. Certes, je l'ai utilisé sur des serveurs qui n'avaient pas une utilisation IO extrêmement élevée.

Cela semble nécessiter une deuxième réponse à la question ...

Je viens de faire perdre à un hôte autonome VMware ESXi un disque dans une matrice RAID 5. La baie dégradée a eu un impact sur les performances au niveau de la machine virtuelle et de l'application.

Smart Array P410i in Slot 0 (Embedded)    (sn: 5001438011138950)

   array A (SAS, Unused Space: 0  MB)

      logicaldrive 1 (1.6 TB, RAID 5, Recovering, 42% complete)

      physicaldrive 1I:1:1 (port 1I:box 1:bay 1, SAS, 300 GB, OK)
      physicaldrive 1I:1:2 (port 1I:box 1:bay 2, SAS, 300 GB, Rebuilding)
      physicaldrive 1I:1:3 (port 1I:box 1:bay 3, SAS, 300 GB, OK)
      physicaldrive 1I:1:4 (port 1I:box 1:bay 4, SAS, 300 GB, OK)
      physicaldrive 2I:1:5 (port 2I:box 1:bay 5, SAS, 300 GB, OK)
      physicaldrive 2I:1:6 (port 2I:box 1:bay 6, SAS, 300 GB, OK)
      physicaldrive 2I:1:7 (port 2I:box 1:bay 7, SAS, 300 GB, OK)
      physicaldrive 2I:1:8 (port 2I:box 1:bay 8, SAS, 300 GB, OK, spare)

Le responsable informatique de cette entreprise ne savait pas qu'un disque était tombé en panne et avait réinitialisé le serveur ( pour le rendre encore meilleur? ).

L'effet intéressant de le faire sur une baie compromise avec des machines virtuelles occupées exécutées au sommet était le suivant:

Détails de l'état du cache: le contrôleur de baie actuel avait des données valides stockées dans son cache d'écriture soutenu par la batterie / le condensateur lors de sa dernière réinitialisation ou de sa mise sous tension. Cela indique que le système n'a peut-être pas été arrêté correctement. Le contrôleur RAID a automatiquement écrit ou tenté d'écrire ces données sur les disques. Ce message continuera à s'afficher jusqu'à la prochaine réinitialisation ou redémarrage du contrôleur RAID.

Ainsi, même si le système a été interrompu brusquement, les données en vol ont été protégées par le BBWC. Les machines virtuelles ont toutes récupéré correctement et le système est maintenant en bon état.

En plus de "sauvegarder vos données", ils sont bons pour d'autres choses. Ils sont également bons pour mettre en mémoire tampon les écritures (dans le cache) afin d'améliorer les performances du sous-système d'E / S en gardant la file d'attente d'écriture sur disque faible. Ceci est particulièrement important pour les serveurs où les performances interactives sont primordiales - par exemple, Citrix XenApp ou Windows Terminal Services.

Ceci est moins important pour un serveur Web ou un serveur de fichiers. Vous pourriez ne pas remarquer ou même être habitué à un petit décalage. Cependant, lorsque vous cliquez sur une icône dans une application Office, vous vous attendez à une réactivité. Et votre PDG aussi.