Die grundlegendste Stufe des Datenschutzes ist die Prüfsumme, die einen speziellen Fehler erkennenden Code ist, der neben den Daten gespeichert wird. Eine Beschädigung der Daten bei der Netzwerkübertragung wird mit Hilfe einer Prüfsumme und in einigen Fällen mehreren Prüfsummen erkannt.

Ein FC-Frame enthält beispielsweise eine Form der Prüfsumme, die als zyklische Redundanzprüfung (CRC, Cyclic Redundancy Check) bezeichnet wird, um sicherzustellen, dass die Nutzlast während der Übertragung nicht beschädigt ist. Der Sender sendet sowohl die Daten als auch den CRC der Daten. Der Empfänger eines FC-Frames berechnet den CRC der empfangenen Daten neu, um sicherzustellen, dass er mit dem übertragenen CRC übereinstimmt. Wenn der neu berechnete CRC nicht mit dem CRC übereinstimmt, der dem Frame zugeordnet ist, sind die Daten beschädigt und der FC-Frame wird verworfen oder abgelehnt. Eine iSCSI-I/O-Operation umfasst Prüfsummen auf TCP/IP- und Ethernet-Ebenen und kann für zusätzlichen Schutz optional auch den CRC-Schutz auf der SCSI-Schicht beinhalten. Jede Bit-Beschädigung auf dem Kabel wird von der TCP-Schicht oder IP-Schicht erkannt, was zu einer erneuten Übertragung des Pakets führt. Wie bei FC führen Fehler im SCSI CRC zu einem Verwerfen oder Zurückweisen des Vorgangs.

Mit Prüfsummen wird auch die Integrität der auf Laufwerken gespeicherten Daten überprüft. Auf Laufwerke geschriebene Datenblöcke werden mit einer Prüfsummenfunktion gespeichert, die eine unvorhersehbare Anzahl ergibt, die mit den Originaldaten verknüpft ist. Wenn Daten vom Laufwerk gelesen werden, wird die Prüfsumme neu berechnet und mit der gespeicherten Prüfsumme verglichen. Wenn sie nicht übereinstimmt, sind die Daten beschädigt und müssen von der RAID-Schicht wiederhergestellt werden.

Eine der schwierigsten Arten von Korruption ist ein verlorenes oder falsch geschaltenes Schreiben. Wenn ein Schreibvorgang bestätigt wird, muss er an der richtigen Stelle auf das Medium geschrieben werden. Datenbeschädigungen lassen sich mithilfe einer einfachen Prüfsumme, die mit den Daten gespeichert wurde, relativ einfach erkennen. Wenn der Schreibvorgang jedoch einfach verloren geht, dann könnte die vorherige Version der Daten noch existieren und die Prüfsumme wäre korrekt. Wenn der Schreibvorgang an einem falschen physischen Speicherort platziert wird, ist die zugehörige Prüfsumme erneut für die gespeicherten Daten gültig, auch wenn der Schreibvorgang andere Daten zerstört hat.

Die Lösung für diese Herausforderung ist wie folgt:

Wenn ONTAP einen Block schreibt, schließt er Daten ein, zu denen der Block gehört. Wenn ein nachfolgender Lesezugriff einen Block identifiziert, der jedoch aufgrund der Metadaten zu Standort 123 gehört, als er an Position 456 gefunden wurde, wurde der Schreibvorgang fehlgestellt.

Es ist schwieriger, einen vollständig verlorenen Schreibvorgang zu erkennen. Die Erklärung ist sehr kompliziert, aber im Wesentlichen speichert ONTAP Metadaten so, dass ein Schreibvorgang zu Updates an zwei verschiedenen Orten auf den Laufwerken führt. Wenn ein Schreibvorgang verloren geht, werden bei einem nachfolgenden Lesen der Daten und der zugehörigen Metadaten zwei unterschiedliche Versionsidentitäten angezeigt. Dies zeigt an, dass der Schreibvorgang vom Laufwerk nicht abgeschlossen wurde.

Verloren gegangene und falsch verlegte Schreibvorgänge sind äußerst selten, doch steigt mit zunehmendem Laufwerksanzahl und steigenden Datenmengen der Datensätze das Risiko. Jedes Storage-System, das Datenbank-Workloads unterstützt, sollte die verlorener Schreibschutz enthalten.

Wenn ein Datenblock auf einem Laufwerk erkannt wird, dass er beschädigt ist oder das gesamte Laufwerk ausfällt und nicht verfügbar ist, müssen die Daten wiederhergestellt werden. Dies wird in ONTAP mithilfe von Paritätslaufwerken durchgeführt. Die Daten werden auf mehreren Datenlaufwerken verteilt und anschließend Paritätsdaten generiert. Diese wird getrennt von den Originaldaten gespeichert.

ONTAP verwendete ursprünglich RAID 4, das für jede Gruppe von Datenlaufwerken ein Single-Parity-Laufwerk verwendet. Das Ergebnis war, dass ein Laufwerk in der Gruppe ausfallen konnte, ohne dass es zu Datenverlust kam. Bei einem Ausfall des Paritätslaufwerks wurden keine Daten beschädigt und ein neues Paritätslaufwerk erstellt. Wenn ein einzelnes Datenlaufwerk ausfällt, können die verbleibenden Laufwerke zusammen mit dem Paritätslaufwerk verwendet werden, um die fehlenden Daten neu zu generieren.

Bei geringen Laufwerksanzahl war die statistische Wahrscheinlichkeit, dass zwei Laufwerke gleichzeitig ausfallen, vernachlässigbar. Mit wachsenden Laufwerkskapazitäten hat sich auch die Zeit entwickelt, die für die Wiederherstellung von Daten nach einem Laufwerksausfall benötigt wird. Dadurch erhöht sich das Zeitfenster, in dem ein zweiter Laufwerksausfall zum Datenverlust führen würde. Darüber hinaus erzeugt der Neuerstellungsvorgang eine Menge zusätzlicher I/O auf den verbleibenden Laufwerken. Mit zunehmendem Festplattenalter steigt auch das Risiko, dass die zusätzliche Last zu einem zweiten Laufwerksausfall führt. Selbst wenn das Risiko eines Datenverlusts mit der fortgesetzten Nutzung von RAID 4 nicht Anstieg, würden die Folgen eines Datenverlusts schwerwiegender. Je mehr Daten im Falle eines Ausfalls einer RAID-Gruppe verloren gehen würden, desto länger würde die Wiederherstellung der Daten dauern, wodurch die Unterbrechung des Geschäftsbetriebs käme.

Aus diesen Problemen entwickelte NetApp die NetApp RAID DP-Technologie, eine Variante von RAID 6. Diese Lösung umfasst zwei Paritätslaufwerke, d. h., zwei beliebige Laufwerke einer RAID-Gruppe können ohne Datenverlust ausfallen. Die Größe der Laufwerke wurde weiter vergrößert, wodurch NetApp schließlich die NetApp RAID-TEC-Technologie entwickelt hat, wodurch ein drittes Paritätslaufwerk eingeführt wird.

Einige bewährte Verfahren für historische Datenbanken empfehlen die Verwendung von RAID-10, auch als Striped Mirroring bekannt. Dies bietet weniger Datensicherheit als RAID DP, da mehrere zwei-Festplatten-Fehlerszenarien auftreten, während es in RAID DP keine gibt.

Es gibt auch einige historische Best Practices für Datenbanken, die darauf hinweisen, dass RAID-10 aufgrund von Performance-Bedenken den Optionen RAID-4/5/6 vorzuziehen ist. Diese Empfehlungen beziehen sich manchmal auf einen RAID-Abzug. Obwohl diese Empfehlungen in der Regel richtig sind, gelten sie nicht für die Implementierungen von RAID innerhalb von ONTAP. Die Leistungsbedenken beziehen sich auf die Paritäts-Regeneration. Bei herkömmlichen RAID-Implementierungen müssen bei der Verarbeitung der routinemäßigen, zufälligen Schreibvorgänge durch eine Datenbank mehrere Lesezugriffe auf die Festplatte durchgeführt werden, um die Paritätsdaten neu zu generieren und den Schreibvorgang abzuschließen. Der Abzug wird definiert als die zusätzlichen Lese-IOPS, die zum Ausführen von Schreibvorgängen erforderlich sind.

Bei ONTAP kommt es nicht zu RAID-Einbußen, da Schreibvorgänge in den Speicher ausgelagert werden, wo Parität erzeugt wird und dann als einzelner RAID-Stripe auf die Festplatte geschrieben wird. Zum Abschließen des Schreibvorgangs sind keine Lesevorgänge erforderlich.

Zusammengefasst bieten RAID DP und RAID-TEC im Vergleich zu RAID 10 viel mehr nutzbare Kapazität, besseren Schutz vor Festplattenausfällen und keine Performance-Einbußen.

Jedes Storage-Array für Datenbank-Workloads muss Schreibvorgänge so schnell wie möglich durchführen. Darüber hinaus muss ein Schreibvorgang vor einem Verlust durch unerwartete Ereignisse, wie z. B. einen Stromausfall, geschützt werden. Das bedeutet, dass jeder Schreibvorgang sicher an mindestens zwei Orten gespeichert werden muss.

AFF und FAS Systeme vertrauen zur Erfüllung dieser Anforderungen auf NVRAM. Der Schreibvorgang funktioniert wie folgt:

Der Schreibvorgang in dieser Phase ist aus Sicht der Applikation abgeschlossen, und die Daten sind vor Verlust geschützt, da sie an zwei verschiedenen Standorten gespeichert werden. Schließlich werden die Änderungen auf die Festplatte geschrieben, doch dieser Prozess ist aus Sicht der Applikation bandextern, da er nach dem Quittieren des Schreibvorgangs auftritt und sich somit nicht auf die Latenz auswirkt. Dieser Prozess ist wieder ähnlich wie die Datenbankprotokollierung. Eine Änderung an der Datenbank wird so schnell wie möglich in den Wiederherstellungsprotokollen aufgezeichnet und die Änderung wird dann als festgeschrieben bestätigt. Die Updates der Datendateien erfolgen viel später und haben keinen direkten Einfluss auf die Geschwindigkeit der Verarbeitung.

Bei einem Controller-Ausfall übernimmt der Partner-Controller die erforderlichen Festplatten und gibt die protokollierten Daten im NVRAM wieder, um I/O-Vorgänge, die beim Ausfall gerade ausgeführt wurden, wiederherzustellen.

Wie zuvor bereits erläutert, wird ein Schreibvorgang erst bestätigt, wenn er in lokalem NVRAM und NVRAM auf mindestens einem anderen Controller angemeldet wurde. Dieser Ansatz stellt sicher, dass ein Hardware-Ausfall oder ein Stromausfall nicht zum Verlust der aktiven I/O führen Wenn der lokale NVRAM ausfällt oder die Verbindung zum HA-Partner ausfällt, werden diese aktiven Daten nicht mehr gespiegelt.

Wenn der lokale NVRAM einen Fehler meldet, wird der Node heruntergefahren. Dieses Herunterfahren führt zu einem Failover auf einen HA-Partner-Controller. Es gehen keine Daten verloren, da der Controller den Schreibvorgang nicht bestätigt hat.

ONTAP lässt kein Failover zu, wenn die Daten nicht synchron sind, es sei denn, das Failover wird erzwungen. Durch das Erzwingen einer solchen Änderung der Bedingungen wird bestätigt, dass Daten im ursprünglichen Controller zurückgelassen werden können und dass ein Datenverlust akzeptabel ist.

Datenbanken sind besonders anfällig für Beschädigungen, wenn ein Failover erzwungen wird, da Datenbanken große interne Daten-Caches auf der Festplatte aufbewahren. Wenn ein erzwungenes Failover auftritt, werden zuvor bestätigte Änderungen effektiv verworfen. Der Inhalt des Storage Arrays springt effektiv zurück in die Zeit, und der Zustand des Datenbank-Cache entspricht nicht mehr dem Status der Daten auf der Festplatte.

Um Daten aus dieser Situation zu schützen, können mit ONTAP Volumes für speziellen Schutz vor NVRAM-Ausfällen konfiguriert werden. Wenn dieser Schutzmechanismus ausgelöst wird, gelangt ein Volume in den Status „NVFAIL“. Dieser Status führt zu I/O-Fehlern, die dazu führen, dass Applikationen heruntergefahren werden, sodass keine veralteten Daten verwendet werden. Daten sollten nicht verloren gehen, da alle bestätigten Schreibvorgänge auf dem Speicher-Array vorhanden sein sollten.

Als Nächstes muss ein Administrator die Hosts vollständig herunterfahren, bevor die LUNs und Volumes manuell wieder online geschaltet werden. Obwohl diese Schritte etwas Arbeit erfordern können, ist dieser Ansatz der sicherste Weg, um die Datenintegrität zu gewährleisten. Nicht alle Daten erfordern diesen Schutz. Daher kann ein NVFAIL-Verhalten auf Volume-Basis konfiguriert werden.

SyncMirror ist eine Spiegelungstechnologie, die RAID DP oder RAID-TEC verbessert, aber nicht ersetzt. Es spiegelt den Inhalt von zwei unabhängigen RAID-Gruppen. Die logische Konfiguration ist wie folgt:

Die Abbildung oben zeigt eine Beispiel-SyncMirror-Konfiguration. Es wurde ein Aggregat mit 24 Laufwerken auf dem Controller mit 12 Laufwerken aus einem an Standort A zugewiesenen Shelf und 12 Laufwerken aus einem an Standort B zugewiesenen Shelf erstellt Die Laufwerke wurden in zwei gespiegelte RAID-Gruppen gruppiert. RAID-Gruppe 0 enthält einen Plex mit 6 Laufwerken an Standort A, der auf einen Plex mit 6 Laufwerken an Standort B gespiegelt wird Ebenso enthält RAID-Gruppe 1 einen Plex mit 6 Laufwerken an Standort A, der auf einen Plex mit 6 Laufwerken an Standort B gespiegelt wird

Normalerweise wird SyncMirror für die Remote-Spiegelung bei MetroCluster Systemen verwendet, wobei eine Kopie der Daten an jedem Standort vorhanden ist. Gelegentlich wurde es verwendet, um eine zusätzliche Redundanz in einem einzigen System bereitzustellen. Insbesondere bietet sie Redundanz auf Shelf-Ebene. Ein Festplatten-Shelf enthält bereits duale Netzteile und Controller und ist im Großen und Ganzen etwas mehr als Bleche, doch in einigen Fällen ist möglicherweise der zusätzliche Schutz gewährleistet. Ein NetApp Kunde beispielsweise hat SyncMirror für eine mobile Echtzeitanalyse-Plattform für Automobiltests implementiert. Das System wurde in zwei physische Racks getrennt, die von unabhängigen USV-Systemen mit Strom versorgt wurden.

Das Thema Prüfsummen ist von besonderem Interesse für DBAs, die es gewohnt sind, Oracle RMAN Streaming Backups zu Snapshot-basierten Backups zu verwenden. Eine Funktion von RMAN besteht darin, dass es während der Backups Integritätsprüfungen durchführt. Auch wenn dieses Feature einen gewissen Wert bietet, ist der Hauptvorteil für eine Datenbank, die nicht in einem modernen Storage-Array verwendet wird. Wenn physische Laufwerke für eine Oracle-Datenbank verwendet werden, ist es fast sicher, dass eine Beschädigung irgendwann auftritt, wenn die Laufwerke altern, ein Problem, das durch Array-basierte Prüfsummen in echten Storage-Arrays behoben wird.

Mit einem echten Storage-Array wird die Datenintegrität durch die Verwendung von Prüfsummen auf mehreren Ebenen gesichert. Wenn Daten in einem IP-basierten Netzwerk beschädigt sind, weist die TCP-Schicht (Transmission Control Protocol) die Paketdaten zurück und fordert eine erneute Übertragung an. Das FC-Protokoll umfasst Prüfsummen sowie eingekapselte SCSI-Daten. Nachdem es sich auf dem Array befindet, verfügt ONTAP über RAID- und Prüfsummenschutz. Es kann zu einer Beschädigung kommen, aber wie in den meisten Enterprise-Arrays wird sie erkannt und korrigiert. In der Regel fällt ein ganzes Laufwerk aus, was zu einer RAID-Neuerstellung führt, und die Datenbankintegrität bleibt davon unberührt. Es ist immer noch möglich, dass einzelne Bytes auf einem Laufwerk durch kosmische Strahlung oder fehlerhafte Blitzzellen beschädigt werden. In diesem Fall würde die Paritätsprüfung fehlschlagen, das Laufwerk würde ausfallen und eine RAID-Wiederherstellung würde beginnen. Auch hier bleibt die Datenintegrität erhalten. Die letzte Verteidigungslinie ist die Verwendung von Prüfsummen. Wenn zum Beispiel ein katastrophaler Firmware-Fehler auf einem Laufwerk Daten in einer Weise beschädigt, die irgendwie nicht durch eine RAID-Paritätsprüfung erkannt wurde, würde die Prüfsumme nicht übereinstimmen und ONTAP würde die Übertragung eines beschädigten Blocks verhindern, bevor die Oracle Datenbank den Block empfangen konnte.

Die Architektur der Oracle-Datendatei- und des Wiederherstellungsprotokolls wurde auch für höchste Datenintegrität entwickelt, selbst unter extremen Bedingungen. Auf der einfachsten Ebene enthalten Oracle-Blöcke Prüfsumme und grundlegende logische Prüfungen mit fast jedem I/O Wenn Oracle nicht abgestürzt ist oder einen Tablespace offline genommen hat, sind die Daten intakt. Der Grad der Datenintegritätsprüfung ist einstellbar und Oracle kann auch zur Bestätigung von Schreibvorgängen konfiguriert werden. Dadurch können fast alle Crash- und Ausfallszenarien wiederhergestellt werden. Im äußerst seltenen Fall einer nicht wiederherstellbaren Situation wird eine Beschädigung umgehend erkannt.

Die meisten NetApp-Kunden, die Oracle-Datenbanken einsetzen, beenden die Nutzung von RMAN und anderen Backup-Produkten nach der Migration zu Snapshot-basierten Backups. Es gibt nach wie vor Optionen, mit RMAN Recovery auf Blockebene mit SnapCenter durchgeführt werden kann. Allerdings werden RMAN, NetBackup und andere Produkte täglich nur gelegentlich verwendet, um monatliche oder vierteljährliche Archivkopien zu erstellen.

Einige Kunden wählen zu laufen dbv Regelmäßige Integritätsprüfungen der vorhandenen Datenbanken durchführen. NetApp rät von dieser Vorgehensweise ab, da dadurch unnötige I/O-Last erzeugt werden. Wie oben erwähnt, wenn die Datenbank zuvor keine Probleme hatte, die Chance von dbv Das Erkennen eines Problems ist nahezu gleich null, und dieses Dienstprogramm erzeugt eine sehr hohe sequenzielle I/O-Last auf dem Netzwerk und dem Speichersystem. Es sei denn, es gibt Grund zu der Annahme, dass Korruption vorhanden ist, wie die Offenlegung eines bekannten Oracle-Fehlers, gibt es keinen Grund, ausgeführt zu werden dbv.