| Anhang | Größe |
|---|---|
 Blog_Silent Data Corruption_Disks_Teil1..pdf | 176.63 KB |
Starnberg, 11. Mai 2012 – Silent Data Corruption oder: "Lassen sich auch große Mengen an Daten (in der Cloud) fehlerfrei speichern ?"
Zum Hintergrund: Die Betreiber von Enterprise-Disk-Storage - Cloud-Anbieter wie die interne IT - verlassen sich zu 100 Prozent und implizit auf die Datenintegrität Ihrer Systeme, wenn wichtige Anwendungsdaten gespeichert bzw. archiviert werden. Storage-Arrays verfügen hierzu über mehrere Ebenen von Integritäts-Prüfungen, sowohl Controller- als auch Diskseitig. Trotzdem konnten einige Untersuchungen (siehe Quellen am Textende) die Entstehung von "schleichender Datenbeschädigung" bei großen Speicherumgebungen beobachten (HPC-Umfeld). Die Fehlerraten sind zwar laut diesen Analysen bei (silent-)data corruption auf dem Papier nicht hoch (2% latente Sektoren-Fehler-Rate bei Enterprise Disks innerhalb von 2 Jahren; 19% im selben Zeitraum bei Nearline-Storage-Systemen und Fehlerraten durch stille Datenkorruption von 0.06% bei Enterprise Disks (0.6% bei Nearline), ebenfalls im Zeitraum von zwei Jahren), weisen aber auf ein Phänomen hin, das im Zusammenhang mit der raschen Zunahme von unstrukturierten Daten und Cloud-Archivlösungen (auf Festplattenbasis) aus Anbietersicht beachtet werden sollte.
Nicht unproblematisch ist eben der Trend zu mehr Daten, der zwangsläufig zu einem sehr ausgeprägten Kostenbewusstsein auf der Einkaufsseite führt (dies gilt natürlich analog auch für Cloud Storage); nicht nur auf Grund steigender Storage-Verwaltungskosten bzw. Aufwendungen für Sicherungsverfahren etc. Und eines ist sicher: Die Anzahl an ausgelieferten Festplatten wird in den nächsten Jahren nicht abnehmen.
Zitat „…Storage demand growth right now is over 50% in the cloud, in other businesses its 25%. Overall call it 40%. Areal density growth is right now under 25%. So you’regoing to say, well, wait a second. If this is growing at 40, and this is growing at 25, how are you going to fill that gap. The only way we can do it is more heads and disks... “ Interview, Zitatauszug: Seagate CEO Steve Luczo, March 2012, Quelle Forbes.com, US.
In diesem Blogbeitrag (der in Kürze fertiggestellte Teil 2 wird sich mit der Problematik bei Filesystemen beschäftigen) versuche ich deshalb, die Problematik der sog. stillen Datenkorruption aufzuzeigen und verweise in diesem Zusammenhang ausdrücklich auf einige wissenschaftlich angelegte Untersuchungen, welche die Phänomene ausführlich analysiert haben (University of Wisconsin-Madison, CERN, N. Bairavasundaram etc. - siehe auch Quellenangaben am Textende).
1. Silent Data Corruption und Parity Pollution - Um was geht es?
Das Verschwinden von Bits ist zwar ein seltenes Phänomen, kann aber über die Zeit dazu führen, dass Informationen unbemerkt verloren gehen. Im Prinzip werden beim Schreiben der Daten Bits geändert und können beim Lesen nicht korrekt wiedergegeben werden. Storage- und Filesysteme sollten eigentlich das fehlerhafte Schreiben erkennen, den Fehler melden und dann beheben. Bei der schleichenden Datenkorruption können jedoch die geänderten Bits nicht erkannt werden; indirekt wird damit das Schreiben von fehlerhaften Daten unfreiwillig unterstützt. Bei stark steigenden Datenmengen, sprich Anzahl Festplatten steigt statistisch gesehen damit auch die Gefahr, Daten zu verlieren. Ohne permanente Backups und der Möglichkeit, Silent Data Corruption beim fehlerhaften Schreiben zu erkennen, werden diese Fehler erst erkannt, wenn Daten bereits verloren sind.
2. Welche Arten von Datenkorruption sind möglich, welche Auswirkungen existieren und wie können Fehler identifiziert bzw. korrigiert werden? (Quelle: An Analysis of Data Corruption in the Storage Stack):
> http://static.usenix.org/events/fast08/tech/full_papers
/bairavasundaram/bairavasundaram_html/main.html
Fehlerquelle: Checksum mismatch:
Auswirkung: Bit-level corruption; misdirected oder torn write
Erkennung: RAID block checksum beim Disk-Read
Fehlerquelle: Identity discrepancy:
Auswirkung: Lost or misdirected write
Erkennung: File system-level block identity bei File Reads
Fehlerquelle: Parity inconsistency:
Auswirkung: Memory corruption; lost write, bad parity calculation
Erkennung: RAID parity mismatch
Lösung: Data Scrubbing.
Ein möglicher Entstehungsgrund von Silent Data Corruption ist Hardwareseitig auf die zum Teil sehr große Anzahl von unterschiedlichsten Controllern, Speicher, Chipsätze etc. - im Nearline-Bereich aus Kostengründen auch gerne kombiniert mit preiswerten Disks wie z.B. SATA Desktop-Varianten - zurückzuführen. Dazu kommt: Alle Daten müssen eine lange Folge von Geräten durchlaufen, was die Fehleranfälligkeit erhöht. Data Corruption kann dabei entstehen durch:
- Controller Versagen, während die Daten gerade im Cache sind
- Ein längerer Stromausfall mit kritischen Daten im Cache
- Plötzlicher Controller-Fehler während des Schreibvorgangs
- Fehler beim Lesen von Daten von Disk
Weitere Quellen für Probleme können sein: Bootstorms, Softwarefragmente in der Registry oder das Überschreiben von Treibern, statt diese zu löschen. Architekturseitig ist der Weg dieser Daten deshalb durch die Umsetzung verschiedener ECCs (Error Correction Code) und CRCs (Cyclic Redundancy Check) begleitet:
Der Speicher korrigiert einzelne Bitfehler
- Cache ist ECC-protected
- PCIe und SATA-Anschlüsse haben CRC implementiert
- Der Festplatten-Cache arbeitet mit ECC und das Schreiben auf die Festplatte ist durch ECC-Mechanismen abgesichert.
- CRC wird implementiert, um bis zu 32 Byte-Fehler (pro 256 Bytes) zu korrigieren. Die Daten sind dann meist fünf Mal gecheckt, bevor sie die eigentliche Festplatte erreichen.
Enterprise-SCSI-Laufwerke (Fibre Channel-, SAS Drives), wie sie bei Disk-Arrays von allen führenden Anbieter verwendet werden, arbeiten normalerweise mit 520-Byte-Sektoren-Größe: Für jeden Block stehen 32KB zur Verfügung und es existieren 64 Sektoren. Jeder Sektor besitzt 512 Bytes an Daten und zusätzlich 8 Bytes für DIF (Data Integrity Field) Prüfsummen sowie für weitere herstellerspezifische Verwendungen. Bei ATA-Laufwerke passen in der Regel 65 Sektoren in einen 32KB-Block. Diese Sektoren sind 512 Byte groß und werden ausschließlich für die Datenspeicherung verwendet. Es gibt jedoch in der Regel hier keine vergleichbaren Prüfsummen (checksum). Quelle: Siehe hierzu auch die Ergebnisse der CERN-Studie in der Anlage.
- Desktop disk: 10^-14 (1 bit in ~11.3 TiB)
- Enterprise disk: 10^-15 (1 bit in ~113 TiB)
Aus Gründen der Länge dieses Beitrags finden Sie den kompletten Text inkl. aller Quellenangaben und Links als PDF Download (184 KB, siehe Anlage unten)
Das Erkennung und die Wiederherstellung von korrupter Daten ist wie gesehen kein triviales Problem und Dateisysteme können nicht immer zweifelsfrei erkennen, ob ein Festplattenfehler aufgetreten ist. Viele Filesysteme verwenden eine proprietäre Form von Disk(block-)-checksums, allerdings arbeitet die Mehrzahl heute noch auf Basis von HDD-ECC - Überprüfungen, um Fehler zu melden.
Zwei der neueren Filesysteme, die selbst eigene Software-Prüfsummen verwenden um eventuell beschädigte Daten zu identifizieren, sind Sun Oracle ZFS und Google GFS. Mehr dazu in einem separaten Blog.
Quellenangaben:
[1] Bairavasundaram et al. “An Analysis of Latent Sector Errors in Disk Drives.” Proceedings of the International Conference on Measurement and Modeling of Computer Systems (SIGMETRICS'07). June 2007.
“An Analysis of Data Corruption in the Storage Stack.” Proceedings of the 6th USENIX conference on File and Storage Technologies (FAST'08). February 2008
[2] Jiang et al. “Are Disks the Dominant Contributor for Storage Failures?” Proceedings of the 6th USENIX conference on File and Storage Technologies (FAST'08). February 2008
Krioukov et al. “Parity Lost and Parity Regained.” Proceedings of the 6th USENIX conference on File and Storage Technologies (FAST'08). February 2008
[3] Panzer-Steindel. “Data Integrity.” Internal CERN/IT study. 8. April 2007.