Fangen wir bei der Festplatte selbst an.
SMART -> „Self Monitoring, Analysis and Reporting Technology“. Schön, also wissen wir wann die Platte ausfällt. Google sagt hierzu folgendes: „Bei 36% der defekten Festplatten hatte SMART keine Warnung erzeugt„. Gut, wissen wir also schon mal, dass eine Festplatte in 64% aller Fälle einen Fehler auch meldet bevor sie ausfällt.
MTBF -> „Mean Time Between Failures“. Also die mittlere Zeit wann ein Fehler auftreten sollte. Was sagt das Internet dazu: „Leider kalkuliert jeder Hersteller die MTBF anders. IBM ging von täglich 11 Stunden bei 25 °C aus, Seagate rechnete mit täglich 9 Stunden bei 40 °C.“. Nein, wir nutzen Festplatten immer bei 25 Grad und niemals über 9 Stunden und wir kennen jeden einzelne Platten besser als der Hersteller.
AFR -> „Annualized Failure Rate“, die jährliche Ausfallrate. Internet: „Der Wert sollte deutlich unter einem Prozent liegen. Wird dieser Wert in den Datenblättern nicht angegeben, ist er vermutlich deutlich schlechter.“. Moment, wir haben weniger als 100 Festplatten im Einsatz oder keine der Platten wird länger als ein Jahr genutzt.
POH -> „Power-On-Hours“. Bei Serverplatten sollte dies 8760 Stunden oder 24/7 bedeuten. Na wenigstens darauf achten wir zumindest im Server Umfeld.
CRC -> „Cyclic Redundancy Check“. Wikipedia: „Das CRC-Verfahren ist nur für die Erkennung von zufälligen Fehlern ausgelegt. Es ist nicht geeignet, die Integrität der Daten zu bestätigen. Das heißt, es ist verhältnismäßig leicht, durch beabsichtigte Modifikation einen Datenstrom zu erzeugen, der den gleichen CRC-Wert wie eine gegebene Nachricht hat. Wenn eine solche Sicherheit gefordert ist, müssen kryptografische Hash-Funktionen wie beispielsweise SHA zum Einsatz kommen.“
Plattenoberfläche: Information zur Formatierung im Internet: „Es wird geschätzt, dass jede Festplatte ein Drittel ihrer nominellen Kapazität als „heimliche Reserve“ zurückhält, um kleine Schäden reparieren zu können. Diese Schäden entstehen vor allem durch leichte Kopfaufsetzer.“ Aha, leichte Schäden 33% na gut.
Platte Zusammenfassung. 33% Platz nur für entstehende Sektor-Fehler … wir sind nicht mehr bei Kilo- oder Megabyte. Wir reden heute wohl von mehreren Millionen nicht reparablen und kommenden Sektor-Fehlern. Wir vertrauen auf CRC und wissen dass es nicht korrekt funktioniert. Wir betreiben Festplatten nicht bei 25 Grad und dies mehr als 9 Stunden pro Tag. Wir wissen, dass im Optimalfall nur eine Festplatte von 100 defekt ist. Dafür vertrauen wir S.M.A.R.T was in 36% der Fälle versagt, aber ein Hardware-RAID -> „Redundant Array of Independent Disks“ soll uns bei diesen bekannten Problemen helfen, welch ein Wundersystem!
Nehmen wir einfach das, was uns heute jeder Speicheranbieter generell anbietet, also ein RAID5. RAID größer RAID0 bedeutet lediglich, dass ein Plattenausfall abgefangen werden kann. RAID bedeutet also kein Backup, keine Datenkonsistenz oder viel mehr Sicherheit, ganz im Gegenteil. Ein Hardware-RAID verhindert sogar die Prüfbarkeit der einzelnen Platten auf Konsistenz.
Hardware-RAID bedeutet aber auch, dass man an seine Daten nur dann wieder heran kommt, wenn der identische RAID Controller vorhanden ist, dass BIOS des Controllers muss mindestens der gleichen Version entspricht. Zudem müssen alle Platten in der genau gleichen Reihenfolge gesteckt sein und ein Großteil der Einstellungen im Controller muss bekannt sein. Wer weiß das schon oder schreibt sich dies auf? Portabilität und Flexibilität Fehlanzeige! Dabei reden wir gerade mal um eine RAID-Gruppe in einem einzelnen Gehäuse.
Das nächste Problem ist, dass die RAID-Gruppen jeweils verkettet werden (RAID0) auch innerhalb eines Gehäuse. Fällt nur eine RAID-Gruppe aus, so sind alle Daten verloren. Leider muss damit jedes Dateisystem leben, auch ZFS. Übrigens zeigt dies auch, dass über größeren RAID-Gruppen eine Softwareebene sein muss, die diese RAID-Gruppen verbindet!
Was macht ZFS hier aber anders? ZFS ist Volume Manager und Dateisystem in einem. Jede Information wird mit Prüfsumme getrennt auf die jeweiligen Einzelplatten geschrieben. Ein Test der Daten und sogar eine Reparatur der Daten ist so online möglich. Das obige Problem mit den RAID Gruppen lässt sich z.B. so umgehen, in dem man nicht nur RAID Gruppen spiegelt, sondern man kann die RAID Gruppe in sich selbst aufzuteilen z.B. weiterer Kontroller oder in Zukunft sogar andere Brandabschnitte durch Festplatten die über IP erreichbar sind (aktuelle Entwicklung).
Beispiel: Zwei RAID Gruppen A und B bestehen aus jeweils 3 Einzelplatten 1,2,3 sowie AS und BS als Spare-Platten.
RAID5: Erste Gruppe (A1,A2,A3 – AS) und (B1,B2,B3 – BS) bilden ein RAID50 über einen Kontroller.
ZFS: Die A Platten hängen am ersten und die B Platten am zweiten Kontroller.
ZFS baut daraus z.B. (A1,B1) und (A2,B2) und (A3,B3) über beide Kontroller als RAID10. RAID10 ist hier gewählt um die Unterschiede deutlicher zu machen.
Bei dem RAID 5 darf nur eine Platte je Gruppe ausfallen. Eine Verteilung der RAID-Gruppen über Controller-Grenzen hinweg geht aus Hardware-Gründen nicht.
Bei dem ZFS RAID10 darf pro RAID-Gruppe eine Platte ausfallen oder es kann ein ganzer Controller ausfallen und das System läuft weiter. Mir ist hierzu kein Hardware-RAID ohne Software bekannt, die dies kann. Letzteres wäre noch schlimmer, da wir dann noch die Treiberebene über dem RAID zusätzlich sichern müssten, mit gleichzeitiger kompletter Abhängigkeit des Kontroller- und/oder System Hersteller, um das RAID wieder zu aktivieren.
Noch einen Unterschied gibt es im Zusammenhang der Spare Platten. Spareplatten müssen bei dem RAID zumindest am gleichen Kontroller angemeldet ggf. sogar der gleichen RAID Gruppe zugeordnet sein.
Bei ZFS können AS und BS sogar der jeweils anderen RAID Gruppe bei Ausfall zugeordnet werden, AS könnte so also auch Ersatzplatte für B1, B2 oder B3 sein.
Eine weitere Besonderheit ist, das ZFS Funktionen wie S.M.A.R.T nicht benötigt. Bei jeder Platte läuft ein Fehlerzähler mit. Ist diese Fehleranzahl zu hoch, passiert etwas, was kein RAID Kontroller in dieser Form kann. Die Spareplatte wird in die defekte RAID-Gruppe eingebunden. Also A1,B1,AS es ist quasi ein Spiegel über drei Platten. ZFS kann für die Korrektur selbst von der ausfallenden Platte sofern möglich noch korrekte Informationen erkennen und lesen, um so die Performance für das Recovery zu verbessern. Erst wenn das Recovery beendet oder die defekte Platte komplett ausgefallen ist, wir die defekte Platte aus der RAID Gruppe entfernt. Eine ähnliche Funktion kann man dazu nutzen, wenn man z.B. online in ein anderes Shelf mit größeren Platten migrieren möchte, ohne eine Downtime zu haben. Dies ist sogar zwischen Unterschiedlichen Anschlusstechniken (IDE, SATA, SAS, FC, IB, IP) usw. möglich, weil es ein Software RAID ist. Alle RAID Platten bleiben portabel und haben einen internen Index. ZFS ist es egal, ob die ZFS Partition als DUMP (Binär Abzug) oder alle anderen Anschlusstechniken (s.o.) zur Verfügung gestellt wird.
Zudem ist ZFS einfach in der Handhabe. ZFS braucht nur die zwei Befehle „zfs“ und „zpool“. Um obiges RAID 10 aufzusetzen braucht es nur folgenden Befehl:
„zpool create DATEN mirror A1 B1 mirror A2 B2 mirror A3 B3 spare AS BS“
Der ZFS Pool ist in Sekunden durch COW -> Copy On Write verfügbar, da keine Formatierung benötigt wird. Das Formatieren eines RAID Systems kann Stunden oder sogar Tage benötigen. Eine FSC Eternus benötigte bei 16 Platten ca. 7,5 Stunden bei 300GB/15K Platten. Wir sprechen heute aber von Terabyte Platten.
Bis hier hin ist noch nicht über Snapshots, Datenkompression, Deduplikation oder Clonig, Mirroring gesprochen worden. All dies kann ein RAID nur über Zusatz… nun man kann es sich denken Software … nicht Hardware!
Aber die guten und leider ewig teuren Freunde EMC, Netapp, HP und weitere, werden uns dies immer und immer wieder anders verpackt verkaufen. Keiner dieser Hersteller hat eine solche durchgehende Datenintegrität. Wie auch? RAID in Hardware als Unterbau bedeutet schlicht, es geht definitiv nicht! EMC nutzt eine 32 Bit CRC Prüfsumme und Netapp eine 16Bit CRC Prüfsumme. Hier von Netapp ein eigener nie genannter Test: „Eine aktuelle wissenschaftliche Studie von 1,5 Millionen Festplatten in der NetApp Datenbank hat über einen 32 Monats-Zeitraum festgestellt, dass 8,5% der SATA-Festplatten eine schleichende Korruption entwickeln. Einige Festplatten-Arrays führten einen Hintergrundprozess aus, der die Daten und RAID-Parität Übereinstimmung überprüfte, um diese Art von Fehler festzustellen. Allerdings ergab die Studie außerdem, dass 13% der Fehler durch den Hintergrundüberprüfungsprozess verpasst wurden.“
Die Prüfsumme einer einzelnen Festplatte liegt bei 8 Bit. Übrigens bemerkt? Jede 12te Platte ist defekt und 13% aller Fehler werden selbst mit Zusatzsoftware in ONTAB nicht erkannt. Kein Problem, wer braucht schon mehr als 12 Platten im Rechenzentrum? Man braucht ja auch nicht mehr als 640KB Speicher …
Der bei ZFS genutzte Krypto-Code ist 256Bit groß und ist gegenüber der CRC beim Marktführer EMC mit (32Bit) nur 26.959.000.000.000.000.000.000.000.000.000.000.000.000.000.000.000.000.000.000.000.000.000 mal besser.
Oder
26.959 Milliarden Miliarden Millarden Milliarden Milliarden Milliarden Milliarden mal besser.
Die Netapp CRC ist noch 65536 mal schlechter als die von EMC. In beiden Fällen EMC und Netapp sprechen wir ausschließlich von Prüfsummen und Fehlererkennung auf Blockebene, nicht aber richtiger Fehlerbehebung, wie auch? Die Prüfsumme im ZFS geht neben den Daten auch über die Metadaten bzw. Verzeichnisstrukturen.
Es gibt dann noch die Möglichkeit bei ZFS für Paranoide Sicherheitsfanatiker, eine zusätzliche Blockprüfung einzuschalten und die Daten selbst n-fach auf jeweils eine Platte schreiben zu lassen, sowie jede Schreiboperation generell synchron durchführen zu lassen. Der Einstiegspunkt ins Dateisystem ist zudem 5 fach abgesichert pro Platte!
Warum ist es nur so wichtig ein gutes Dateisystem wie ZFS zu haben?
OK, kommen wir zu den Kosten:
Wir bezahlen für eine Netapp 3220 mit 96TB Brutto 95.200 Euro. Ein Nexenta ZFS Storage kostet mit 60TB Brutto 15.696 Euro. Eine Netapp kostet also 992 Euro pro Terabyte, bei Nexenta 262 Euro pro Terabyte. Für Nexenta bezahlen wir einen Software-Aufpreis von weniger als 150 Euro je Terabyte.
Wie sieht also eine Firmenumgebung mit Netapp und Comvault (Datensicherung) in Summe aus: Anschaffung 160.000 Euro FAS 3240 Cluster, Anschaffung FAS 3220 Backup 95.200 Euro, Comvault Simpana für aktuell 52TB netto Speicherplatz 357.000 Euro. Gesamtwert: 612.200Euro für Netto ca. 60TB nutzbarem Speicher mit Backup ohne Band Hardware. Bei 20% Wartungskosten pro Jahr sind dies schlappe 122.440 Euro. Netapp möchte so viel Wartung, dass der Kunde lieber ein neues Netapp System kauft, als das System in Wartung weiter laufen zu lassen. Bitte dran denken, viel Geld für kaum vorhandene Datenintegrität!
Wenn man nur Nexenta nutzen würde, könnte man für 612.200 Euro 2.300 Terabyte ZFS Speicher kaufen. Selbst mit den 255.200 Euro der jetzigen kompletten Netapp Lösungen ohne Backup könnten wir 974 Terabyte ZFS Speicher bezahlen. Dabei sind in diesem Preis noch die Nexenta Lizenzen eingerechnet. ZFS selbst ist als OpenZFS kostenfrei und man kann sich vieles selbst erstellen und in diesem Fall nochmal ein drittel mehr Speicher kaufen. OpenZFS ist in den freien Solaris Varianten sowie FreeBSD integriert. In Linux und Mac OS X kann es nachträglich installiert werden.
Stellt man sich nicht mal die Frage, wozu der ganze Aufwand für 52TB wenn man zwischen 974TB und 2300TB haben könnte? Bei aktuell 0,2% Datenänderung pro Tag und 15% Zusätzlicher Daten pro Jahr, würden selbst 974TB für 14 Jahre in der Rücksicherung reichen. Dabei ist die Datenkompression LZ4 nicht berücksichtigt und auch nicht die Blockdifferenzierung der Snapshots in der Offline Kopie.
Man könnte ein LiveSystem, OfflineSystem und Backupsystem realisieren, dazu bräuchte man nicht mal mehr Bänder und wäre wesentlich günstiger. Das LiveSystem würde sich auf das OfflineSystem spiegeln und das Backupsystem würde nur am Wochenende aktiv.
Jetzt sollte es endlich Klick gemacht haben! Danke!