VNx/Unity: Nicht korrigierbare Sektoren und Paritätsfehler (zu korrigierende Benutzer)

Verstehen nicht korrigierbarer Sektoren und Paritätsfehler auf einem CLARiiON-, VNx-oder Unity-Array.

Ereignisprotokollmeldungen, wie z. b. die folgenden, können auch als Wähl Häuser angezeigt werden:

VNX1-
Fehlercode: 0x953 nicht korrigierbarer Paritäts Sektor-
Fehlercode: 0x957 nicht korrigierbarer Datensektor-
Fehlercode: 0x68A nicht korrigierbarer Paritäts Sektor-
Fehlercode: 0x695 nicht korrigierbarer Datensektor-
Fehlercode: der B26-Cache des 0x840-Daten Sektors
hat CORRUPT_CRC ausgegeben. LUN = 309 ca_sync. c 0 309 2

VNX2
71688003 nicht korrigierbare Sektor-RAID-Gruppe: Position %2: %3 LBA: %4 Blöcke: %5 Fehlerinformationen: %6 zusätzliche Informationen: %7
71688008 nicht korrigierbare Sektor-RAID-Gruppe: 10 Position: 1 LBA: d180 Blöcke: 8 Fehlerinformationen: 0 zusätzliche Informationen: e [r5_rb Grippe 8224 r5_rb]
71688008 nicht korrigierbare Sektor-RAID-Gruppe: 10 Position: 1 LBA: D170 Blöcke: 8 Fehlerinformationen: 0 zusätzliche Informationen: e [r5_rb Grippe 8224 r5_rb]
71688001 Data Sector Invalidated RAID-Gruppe: 10 Position: 1 LBA: D121 Blöcke: 7 Fehlerinformationen: 0 zusätzliche Informationen: e [r5_rb Grippe 8224 r5_rb]

Nicht korrigierbare Fehler treten auf, wenn zwei verschiedene Festplatten in derselben RAID-Gruppe im gleichen Sektor Medienfehler aufweisen. 
Ein Beispiel: Wenn eine Festplatte mit Datenträgerfehlern in eine Hotspare kopiert und eine andere Festplatte in derselben RAID-Gruppe im gleichen Sektor auch Medienfehler aufweist, führt dies zu einem nicht korrigierbaren Fehler/Sektor. 

Die oben beschriebenen Ereigniscodes werden protokolliert, wenn das System nicht in der Lage ist, Datensektoren von einer Festplatte zu lesen, und nachfolgende Versuche, die Daten von einer anderen Festplatte in der RAID-Gruppe zu rekonstruieren, fehlgeschlagen. Die "nicht korrigierbaren" Meldungen geben an, welche Festplatte (n) die Sektoren nicht erfolgreich lesen konnte, und die "ungültigen" Meldungen geben an, welche Datenträgersektoren als ungültig gemeldet wurden. Diese Markierung wird durchgeführt, um sicherzustellen, dass keine ungültigen Daten an ein Hostsystem zurückgegeben werden. Versuche, von einem ungültigen Speicherort zu lesen, führen dazu, dass ein harter Fehler an einen Host zurückgegeben wird.
Versuche, in einen ungültigen Speicherort zu schreiben, werden erfolgreich abgeschlossen, und der void-Standort wird in der Regel durch "füllen" (überschreiben) und somit die nicht korrigierbaren Speicherorte wirksam behoben. Aus diesem Grund verschwinden manchmal vergangene nicht korrigierbare Fehler, nachdem ein Host diese Sektoren mit neuen guten Daten überschrieben hat.

Für VNx:
Sobald alle Hardwareprobleme behoben sind, muss der technische Support von Dell EMC eine manuelle schreibgeschützte Hintergrundüberprüfung (ROBV) durchführen, wenn sich die betroffenen internen LUN im betroffenen Pool befinden. ROBV liest und prüft die Daten für uncorrectables auf dem gesamten LUN (intern), einschließlich nicht verwendeter Speicherplatz, um festzustellen, wie viele uncorrectables-Sektoren noch vorhanden sind.
Wenn die ROBV abgeschlossen ist, muss Ihr Dell EMC Technical Support Engineer zusätzliche Schritte ausführen, einschließlich der Erfassung und Analyse von Informationen zur Speicher Zuweisungstabelle (Sat), um die jeweiligen betroffenen Benutzer LUN zu identifizieren (die internen LUNs, in denen die uncorrectables gefunden wurden, werden den Benutzer-LUNs zugeordnet).
Eine vollständige Erläuterung und die Voraussetzungen für die Ausführung einer ROBV finden Sie im Artikel 466638, VNx: Erläuterung des schreibgeschützten background Verify (ROBV) (Benutzer korrigierbar)

Wenn ein nicht korrigierbarer Sektor in einer Benutzer LUN gefunden wird, müssen die Benutzerdaten von der Hostanwendung überprüft werden, um festzustellen, ob die Benutzerdaten beschädigt sind, oder ob der Fehler im nicht verwendeten Speicherplatz liegt. Jeder Prozess, bei dem die Daten gelesen werden, z. b. ein Backup, würde die Identifizierung und Kennzeichnung möglicher Beschädigungen befolgen.
Wenn eine Beschädigung vorliegt, können die Daten von einem guten Backup mit einer kompletten Wiederherstellung oder einer partiellen Wiederherstellung nur der betroffenen Datei (en) wiederhergestellt werden.
Wenn kein gutes Backup vorhanden ist, sollte ein anderes Mittel aus der Hostanwendung verwendet werden, um die Daten wiederherzustellen oder neu zu erstellen. 

Sollte der nicht korrigierbare Fehler in Benutzerdaten nicht gefunden werden, können die Hintergrundprozesse den Fehler möglicherweise auch in der Zukunft erkennen, wenn der Sektor durch Host-I/O nicht überschrieben wird. Dies kann zu einer falschen Einschätzung führen, dass es sich um einen neuen Fehler handelt, der zu Verzögerungen bei der Analyse und Behebung eines alten Fehlers führt, der nicht vollständig aufgelöst wurde.
In diesem Fall wird dringend empfohlen, die guten Daten in einen anderen LUN zu verschieben und die ursprünglich betroffenen LUN zu löschen.

Für Unitykönnen andere Methoden bestehen, um zu versuchen, dieses Problem zu beheben. Bitte überprüfen Sie, ob weitere Unity-spezifische Artikel sind.

Häufig gestellte Fragen:

Hat die Technik eine andere Möglichkeit, verloren gegangene Kundendaten wiederherzustellen, wenn die Daten durch eine Kunden Hostanwendung nicht überschrieben werden und eine Wiederherstellung aus dem Backup nicht funktioniert? 
Es gibt keine andere Möglichkeit, die Daten außer einem Wiederherstellungsvorgang wiederherzustellen oder die Daten aus der Anwendung neu zu erstellen.
Da die nicht korrigierbaren Daten in Wirklichkeit Daten fehlen, können Sie nicht wissen, was die Daten sein sollten, um Sie Zurückschreiben zu können.  Aus diesem Grund wird der Sektor "ungültig" und ein harter Fehler wird an den Host zurückgegeben. Es ist besser, einen harten Fehler als falsche Daten zurückzugeben. 

Ist es möglich, dass ein ungültiger Sektor die Standorte auf einer Festplatte ändert? 
Bei einer Standard LUN bleiben die ungültigen Datensektoren immer identisch.
Bei einem Pool LUN mit aktiviertem Auto-Tiering kann er verschoben werden, wenn das Slice verlagert wird.

Gibt es eine Möglichkeit, den tatsächlichen Standort eines ungültigen Sektors zu ermitteln?  
Es ist sehr schwierig, die Position eines ungültigen Sektors zu finden, da LUNs in RAID-Gruppen oder-Pools zugeordnet sind und welche Informationen in den Ereignisprotokollen zur Verfügung stehen.
Wenden Sie sich an Dell EMC Support, um weitere Unterstützung zu erhalten und die Blöcke zu identifizieren, die den ungültigen Sektor  Das Support-Team muss zuerst den nicht korrigierbaren Wiederherstellungsvorgang durchführen und dann das Problem an das Wiederherstellungsteam eskalieren. gemeldet wird. 

Wenn der ungültige Sektor anscheinend nicht die Auswirkungen auf den Bereich "Kundendaten" hat, gibt es eine Möglichkeit, ihn loszuwerden, ohne die LUN zu lösen?
Einige Erfolge wurden gemeldet, wenn temporäre Daten geschrieben wurden, um die LUN zu übertragen und dann die temporären Daten zu löschen.  Wenn in den ungültigen Bereich mit temporären Daten geschrieben wird, werden die stornierten Standorte gefüllt, wodurch der ungültige Sektor mit gültigen Daten wiederhergestellt wird. 

Kann ein Kunde nur ein CHKDSK oder fsck ausführen, um die Integrität der Daten im Dateisystem zu überprüfen, wenn nicht korrigierbare Fehler von "Read Only background verify" gemeldet werden? 
Bei Problemen mit nicht korrigierbaren Sektoren sollten die Kundendaten geprüft werden, um festzustellen, ob eine Dateibeschädigung vorliegt. Um dies zu tun, führen Sie eine Art von Anwendung oder Programm aus, die alle genutzten Sektoren im LUN Speicherplatz liest. Die häufigste Art von Methode ist ein komplettes Backup der Daten. Es ist nicht ratsam, einfach ein fsck (Unix) oder Chkdsk (Windows) auszuführen, da diese Dienstprogramme nur den Metadatenbereich der Dateien überprüfen. Wenn die nicht korrigierbaren Sektoren nicht im Metadatenbereich vorhanden sind, hat der Kunde den Eindruck, dass die Daten in Ordnung sind, wenn es tatsächlich nicht der Fall ist.

Weitere FAQ:

Warum muss die Datenkomprimierung deaktiviert werden?
Die Datenkomprimierung ist eine Funktion, die die Daten auf einer Festplatte analysiert und Algorithmen anwendet, die die Größe der repetitiven Sequenzen von Bits reduzieren, die in einigen Dateitypen inhärent sind. Während des Komprimierungsvorgangs für eine RAID-Gruppe LUN migriert und komprimiert die LUN Daten in eine Thin-LUN in einem Pool. Das LUN wird zu einer komprimierten schlanken LUN. Komprimierungs Vorgänge für Pool-LUNs (Thick und Thin) erfolgen in dem Pool, in dem sich die zu komprimierenden LUN befindet. Wann immer Daten komprimiert werden, erfolgt eine Datenverschiebung im Speicherpool, die uns nicht hilft, die korrekte MLU zu identifizieren, die aufgrund von Uncorrectables oder unerwarteter Kohärenz betroffen ist. Die Funktion muss angehalten werden.

Warum ist es erforderlich, das Auto-Tiering zu deaktivieren?
Die Auto-Tiering-Funktion migriert Daten zwischen Storage Tiers oder anderen Speichermedien (EFD, FC & SATA). Der Zweck von Tiered Storage ist es, die am häufigsten aufgerufenen oder wichtigsten Daten auf schnellen, leistungsfähigen (kostspieligeren) Laufwerken aufzubewahren und die weniger häufig abgerufenen und weniger wichtigen Daten auf Low-Performance-Laufwerke (weniger kostspielig) zu verschieben. Ähnlich wie bei der Datenkomprimierung gibt es auch bei der automatischen Tiering eine Datenverschiebung, die uns bei der Identifizierung des Sektors der MLU, die aufgrund von Uncorrectables oder unerwarteter Kohärenz betroffen sind, nicht hilft, wenn er nicht deaktiviert ist. Die Verlagerung muss also gestoppt werden und der Zeitplan muss deaktiviert werden.

Warum muss fast Cache deaktiviert werden?
Der fast Cache muss nur deaktiviert werden, wenn der nicht korrigierbare Sektor-Fehler in fast Cache gemeldet wird

. Warum ist es erforderlich, ROBV auf der gesamten RAID-Gruppe (RG) und nicht auf dem bestimmten LUN auszuführen?
Sie müssen ROBV auf der gesamten RG ausführen, um bestimmte andere Kunden-LUNs in derselben RG nicht zu beeinträchtigen.

Warum ist es erforderlich, ROBV auf dem Pool und nicht nur auf der RAID-Gruppe auszuführen?
Sie müssen ROBV auf einem gesamten Speicher Pool ausführen, wenn ein Auto-Tiering-Plan seit dem Zeitpunkt, an dem ein nicht korrigierbarer Bericht gemeldet wurde und der ROBV geplant ist, gestartet wird.  Dies ist erforderlich, da Datenslices die nicht korrigierbaren Daten in einen anderen Sektor verschieben können, wenn diese Datenscheibe in eine andere Schicht verschoben wird.
 
Warum ist es erforderlich, Informationen zur Sat-Speicher Zuweisungstabelle zu sammeln?
Die Sat-Informationen beim Ausführen der Tools, die von Dell EMC Support verwendet werden, bestimmen die Kunden LUN/MLU, in denen der nicht korrigierbare Sektor liegt.  Dies zeigt außerdem an, ob sich das Problem im Datenspeicherplatz oder im Metadatenbereich des Kunden LUN.