BBWC: Theoretisch eine gute Idee, aber hat man jemals Ihre Daten gespeichert?

Ich kenne die Aufgaben eines BBWC (Battery-Backed Write Cache) und habe sie bereits bei guten USV-Systemen auf meinen Servern verwendet. Es gibt offensichtliche Fehler, für die es keinen Schutz bietet. Ich bin gespannt, ob es in der Praxis tatsächlich einen echten Nutzen bringt.

(NB Ich suche speziell nach Antworten von Leuten, die BBWC haben und Abstürze / Ausfälle hatten und ob die BBWC zur Genesung beigetragen hat oder nicht.)

Aktualisieren

Nach den Rückmeldungen hier bin ich zunehmend skeptisch, ob eine BBWC einen Mehrwert bringt.

Um Vertrauen in die Datenintegrität zu haben, MUSS das Dateisystem wissen, wann Daten nichtflüchtig gespeichert wurden (nicht unbedingt die Festplatte - ein Punkt, auf den ich noch zurückkommen werde). Es ist erwähnenswert, dass viele Festplatten lügen, wenn Daten auf die Festplatte übertragen wurden ( http://brad.livejournal.com/2116715.html ). Es scheint zwar vernünftig anzunehmen, dass das Deaktivieren des Festplattencaches die Festplatten ehrlicher macht, es gibt jedoch auch keine Garantie dafür, dass dies der Fall ist.

Aufgrund der typischerweise großen Puffer in einer BBWC kann es für eine Barriere erforderlich sein, wesentlich mehr Daten auf die Festplatte zu schreiben, was zu Verzögerungen beim Schreiben führt. Der allgemeine Ratschlag lautet, Barrieren zu deaktivieren, wenn ein nichtflüchtiger Rückschreibcache verwendet wird (und On-Volatile-Write-Back-Cache zu deaktivieren). Festplatten-Caching). Dies scheint jedoch die Integrität des Schreibvorgangs zu untergraben - nur weil mehr Daten in einem nichtflüchtigen Speicher aufbewahrt werden, bedeutet dies nicht, dass diese konsistenter sind. In der Tat scheint es ohne Abgrenzung zwischen logischen Transaktionen weniger Möglichkeiten zu geben, für Konsistenz zu sorgen als sonst.

Wenn die BBWC Barrieren an dem Punkt erkennt, an dem die Daten in ihren nichtflüchtigen Speicher gelangen (anstatt auf die Festplatte übertragen zu werden), scheint dies die Datenintegritätsanforderungen ohne Leistungseinbußen zu erfüllen - was bedeutet, dass Barrieren weiterhin aktiviert sein sollten. Da diese Geräte jedoch im Allgemeinen ein Verhalten aufweisen, das mit dem Löschen der Daten auf das physische Gerät (bei Barrieren erheblich langsamer) und dem weit verbreiteten Hinweis zum Deaktivieren von Barrieren vereinbar ist, können sie sich nicht auf diese Weise verhalten. WARUM NICHT?

Wenn die E / A im Betriebssystem als eine Reihe von Streams modelliert sind, besteht ein gewisser Spielraum, um die Blockierungswirkung einer Schreibsperre zu minimieren, wenn der Schreibcache vom Betriebssystem verwaltet wird - da auf dieser Ebene nur die logische Transaktion (ein einzelner Stream) ) muss begangen werden. Andererseits müsste eine BBWC, die nicht weiß, aus welchen Datenbits die Transaktion besteht, ihren gesamten Cache auf die Festplatte übertragen. Ob der Kernel / das Dateisystem dies tatsächlich in die Praxis umsetzt, würde viel mehr Aufwand erfordern, als ich derzeit investieren möchte.

Eine Kombination von Datenträgern, die über die festgestellten Vorgänge und den plötzlichen Stromausfall Aufschluss geben, führt zweifellos zu Korruption. Bei einem Journalling- oder Protokolldateisystem, das nach einem Ausfall keine vollständige Überprüfung durchführt, ist es unwahrscheinlich, dass die Korruption entdeckt wird, geschweige denn ein Versuch, es zu reparieren.

In Bezug auf die Ausfallarten treten meines Erachtens die meisten plötzlichen Stromausfälle aufgrund eines Stromausfalls auf (der durch eine USV und ein verwaltetes Herunterfahren leicht gemildert werden kann). Leute, die das falsche Kabel aus dem Rack ziehen, implizieren eine schlechte Hygiene des Rechenzentrums (Etikettierung und Kabelmanagement). Es gibt einige Arten von plötzlichen Stromausfällen, die nicht durch eine USV verhindert werden. Ein Ausfall des Netzteils oder des VRM einer BBWC mit Barrieren würde im Falle eines Ausfalls die Datenintegrität gewährleisten. Wie häufig sind solche Ereignisse jedoch? Sehr selten, gemessen an den fehlenden Antworten.

Das Verschieben der Fehlertoleranz im Stack ist mit Sicherheit deutlich teurer als bei einer BBWC. Die Implementierung eines Servers als Cluster bietet jedoch viele weitere Vorteile für die Leistung und Verfügbarkeit.

Eine alternative Möglichkeit, die Auswirkungen eines plötzlichen Stromausfalls abzuschwächen, besteht in der Implementierung eines SAN - AoE. Dies ist ein praktischer Ansatz (ich sehe den Punkt in iSCSI nicht wirklich), aber es entstehen wiederum höhere Kosten.

Sicher. Ich habe einen batteriegepufferten Cache (BBWC) und später einen flashgepufferten Schreib-Cache (FBWC) zum Schutz von Daten während des Flugs nach Abstürzen und plötzlichem Stromausfall.

Auf HP ProLiant Servern lautet die typische Meldung:

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

Was bedeutet, " Hey, es gibt Daten im Schreibcache, die den Neustart / Stromausfall überstanden haben !! Ich werde sie jetzt zurück auf die Festplatte schreiben !! "

Ein interessanter Fall war mein Post-Mortem eines Systems, das während eines Tornados an Strom verlor. Die Array-Sequenz lautete:

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

Der POST-Fehler 1793 ist eindeutig. - Während das System verwendet wurde, wurde die Stromversorgung unterbrochen, während sich Daten im Speicher des Array-Beschleunigers befanden. Da es sich jedoch um einen Tornado handelte, wurde die Stromversorgung nicht innerhalb von vier Tagen wiederhergestellt, sodass die Akkus des Arrays erschöpft waren und die darin enthaltenen Daten verloren gingen. Der Server hatte zwei RAID-Controller. Die andere Steuerung hatte eine FBWC-Einheit, die viel länger hält als eine Batterie. Das Laufwerk wurde ordnungsgemäß wiederhergestellt. Auf dem Array, auf dem sich der leere Akku befindet, ist eine Datenbeschädigung aufgetreten.

Trotz einer langen Batterielaufzeit in der Einrichtung war es nach vier Tagen ohne Strom und unter gefährlichen Bedingungen für niemanden möglich, die Server sicher herunterzufahren.

Ja, hatte diesen Fall.

Server "ohne UPS" in einem Rechenzentrum (wobei das Rechenzentrum eine UPS hat). PDU-Fehler - System ist schwer abgestürzt. Kein Datenverlust.

Und das ist es im Grunde. Das Gute an einem BBWC ist, dass es sich in der Maschine befindet. Haben Sie eine USV - glauben Sie mir, manchmal macht jemand etwas Dummes (wie das Ziehen des falschen Kabels). Eine USV ist extern. Oh, DIESES Kabel;)

Ich habe 2 Fälle gehabt, in denen batteriegepufferter Cache in HW-RAID-Controllern vollständig fehlgeschlagen ist (in 2 verschiedenen Unternehmen).

BBC vertraut auf die nicht überraschende Idee, dass Batterie funktioniert. Der Haken ist, dass irgendwann die Batterie des Controllers ausfällt und was verheerend ist, dass es in vielen HW-RAID-Controllern stillschweigend ausfällt . Wir dachten, wir hätten einen Cache, der gegen Stromausfall geschützt ist, aber wir taten es nicht.

Bei einem Stromausfall war der RAID-Array-Datenverlust so groß, dass alle Festplatteninhalte nicht wiederherstellbar waren. Alles war verloren. In einem Fall handelte es sich um eine Maschine, die ausschließlich zum Testen vorgesehen war.

Danach sagte ich "Nie wieder", wechselte zu softwarebasierter Festplattenspiegelung (mdadm) in Linux + journalbasiertem fs, das eine gute Ausfallsicherheit gegen Stromausfall (ext4) aufweist und nie zurückblickte. Zugegeben, ich habe es auf Servern verwendet, die keine extrem hohe E / A-Auslastung aufwiesen.

Dies scheint eine zweite Antwort auf die Frage zu erfordern ...

Ich hatte gerade einen eigenständigen VMware ESXi-Host, der ein Laufwerk in einem RAID 5-Array verloren hat. Das verschlechterte Array beeinträchtigte die Leistung auf VM- und Anwendungsebene.

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)

Die IT-Mitarbeiter dieser Firma wussten nicht, dass ein Laufwerk ausgefallen ist, und setzten den Server hart zurück ( um alles zu verbessern? ).

Der interessante Effekt dieser Vorgehensweise für ein kompromittiertes Array mit ausgelasteten virtuellen Maschinen, auf denen Folgendes ausgeführt wird:

Details zum Cache-Status: Auf dem aktuellen Array-Controller waren beim letzten Zurücksetzen oder Einschalten gültige Daten im batterie- / kondensatorgestützten Schreibcache gespeichert. Dies weist darauf hin, dass das System möglicherweise nicht ordnungsgemäß heruntergefahren wurde. Der Array-Controller hat diese Daten automatisch auf die Laufwerke geschrieben oder versucht, sie zu schreiben. Diese Meldung wird bis zum nächsten Zurücksetzen oder Aus- und Einschalten des Array-Controllers weiterhin angezeigt.

Obwohl das System plötzlich gestoppt wurde, wurden die Daten während des Fluges von der BBWC geschützt. Die virtuellen Maschinen wurden alle ordnungsgemäß wiederhergestellt, und das System ist jetzt in gutem Zustand.

Sie speichern nicht nur Ihre Daten, sondern sind auch für andere Zwecke gut. Sie sind auch gut im Puffern von Schreibvorgängen (im Cache), um die Leistung des E / A-Subsystems zu verbessern, indem die Warteschlange für Schreibvorgänge auf der Festplatte niedrig gehalten wird. Dies ist besonders wichtig für Server, auf denen die interaktive Leistung im Vordergrund steht, z. B. Citrix XenApp oder Windows Terminal Services.

Dies ist für einen Webserver oder einen Dateiserver weniger wichtig. Möglicherweise bemerken Sie eine kleine Verzögerung nicht oder sind sie gar nicht gewöhnt. Wenn Sie jedoch in einer Office-Anwendung auf ein Symbol klicken, erwarten Sie Reaktionszeiten. Und Ihr CEO auch.