Mythos RAID und die Ernüchterung

Alles was sich dreht, geht irgendwann auch mal kaputt. Eine Alltagsweisheit, die aber immer dann zum Entsetzen führt, wenn sie natürlich überraschend und zur ungünstigsten Zeit auftritt. Manchmal hat man aber auch Glück und es erwischt einen am Wochenende, so dass kein Produktionsausfall zu erwarten ist.

Ausfall, Analyse und erster Versuch

So geschehen im September 2009, als der Exchange Server nicht mehr funktionierte. Die erste Analyse war einfach: Der Server konnte noch per PING erreicht werden, aber alle Zugriffe per Netzwerkfreigabe, Eventlog aus der Ferne oder RDP auf den Server sind fehl geschlagen.

Da es ein Wochenende war und ich keine Lust hatte, die 27 Kilometer zum Server zu fahren, habe ich einfach eine Verbindung auf einen Nachbarserver aufgebaut und versucht, den Server per "Shutdown /m:servername /r" aus der Ferne zu einem Neustart zu veranlassen. Es kann ja schon mal passieren, dass sich z.B. der Netzwerkkartentreiber verabschiedet hat (Stichwort TCPChimney etc.). Natürlich ist der Befehl auch nicht an den Server gekommen und der Ping lief fröhlich weiter. Exchange natürlich nicht.

Weitere Analyse und zweiter Versuch

Weil mittlerweile schon Samstag Nacht war und Mailserver ja es einige Zeit immer wieder versuchen, habe ich einfach meinen Office Communicator Client angeschaltet und gewartet, bis ein Kollege "online" geht, der vielleicht direkt in Paderborn wohnt und am Sonntag einfach seinen Spaziergang entsprechend umdisponiert.

Und tatsächlich dauerte es nicht lange, bis sich jemand bei mir meldete, warum denn Exchange nicht ginge. (Hab ich schon geschrieben, dass sich OCS zu schätzen gelernt habe :-). Nach wenigen Minuten hatte ich dann eine "ferngesteuerte Hand" beim Exchange Server. In Verbindung mit einem Notebook und einer Webcam konnte ich nun doch noch "auf" den Bildschirm des Servers schauen. (Leider hat der Server kein autarkes Monitoring-Board). Dort war zu lesen, dass ein Shutdown angefordert worden wäre und in Minus Irgendwas Sekunden stattfinden würde. Das war dann wohl mein Shutdown des vorherigen Abends, der noch angenommen aber nicht ausgeführt worden war.

Die "remote Hand" hat dann den Server einfach ausgeschaltet, nach dem alle "geplanten" Versuche eines Shutdown oder Anmeldung nicht möglich waren. Exchange "überlebt" solche Stromausfälle eigentlich problemlos, solange der RAID-Controller seinen Cache leeren und die Festplatten die Daten schreiben können.

Der Server ist wieder gestartet um dann noch viel mehr Schrecken zu verbreiten. Die Konsole hat sich mit Meldungsfenstern über "Disk-IO-Fehler" nur so gefüllt. Anscheinend konnte der Server an vielen Stellen der Disks nicht mehr schreiben. Eine Anmeldung etc. war natürlich auch nicht möglich und eigentlich wollte ich den Server auch nicht weiter "schreiben" lassen. Es konnte ja nur schlimmer werden. Als AUS.

Schreibfehler und RAID ?

Jetzt muss ich dazu sagen, das der Server natürlich einen RAID-Controller hatte, und die Disks als RAID1 konfiguriert waren. Die beiden Festplatten waren auch beide "grün" und auch der Status des Raid-Controllers (beim Reboot) hat keine Inkonsistenzen der Daten angezeigt. Die Fehler können also nicht auf einen Ausfall der Festplatten o.ä. geschoben werden. Aber woran lag es dann ?. Es ist immer wichtig die Ursache zu erforschen, um dieses Problem dann auch zu beheben, Wenn ein Server also Daten "kaputt-.schreibt", dann gibt es immer einen Grund.

Dritter Versuch mit Reservehardware

Exchange ist wichtig und ohne Exchange kann eine Firma nicht arbeiten. Also musste ein "Opfer" gefunden werden. Und hier "lohnt" es sich dann immer ein paar Server der gleichen Serie zu betreiben. Ein Terminalserver, der zwar auch wichtig aber eben weniger wichtig ist, wurde als Spender auserkoren. Er wurde sauber beendet und der Festplatten beraubt. Die beiden Festplatten des defekten Exchange Servers wurden eingebaut und der Server gestartet.

Der RAID-Controller (Gleiches Modell aber eben andere Hardware) hat die beiden Festplatten sofort erkannt und auch als "konsistent" bezeichnet und nach wenigen Minuten war der Server, diesmal ohne Meldungsfenster über Disk-Fehler) wieder online. Die erste Anmeldung hat zwar etwas länger gedauert, da die "neue" Netzwerkkarte keine IP-Adresse hatte und die nicht mehr vorhandene Karte erst aus der Konfiguration entfernt werden musste, aber danach konnte der Server wieder bedient werden.

Exchange Status ermitteln

Die größte Sorge galt natürlich den Exchange Datenbanken. Wurden Sie durch diese Fehler in Mitleidenschaft gezogen ?. Der erste Stein fiel vom Herzen, als das Dateisystem ohne weitere Fehler gemounted werden konnte und die Dateien komplett da waren. Der erste Schritt war natürlich die Sperrung aller Zugriffe auf die Exchange Dienste, damit kein Prozess vielleicht schon neuen Mails in defekte Datenbanken zustellt. Leider gibt es keinen Weg einen Server beim Hochfahren den Start der Datenbanken temporär zu verbieten. Der Server geht ja erst mal davon aus, dass er schnell wieder seine Dienste bereitstellen soll. Die Datenbanken wurden auch tatsächlich gemounted. Aber schon der Vergleich zwischen OWA auf den Server und Outlook im Cached Mode offenbarte, dass "etwas" nicht stimmen konnte. Auch fanden sich im Eventlog erschreckend viele Einträge zu defekten Tabellen, Indexe etc. Die Datenbank hatte also etwas abbekommen und musste umgehend wieder offline gehen.

Um zu sehen, wie groß der Schaden ist, wurden alle Datenbanken und Transaktionsprotokolle mit ESEUTIL /MH bzw. /ML gesichtet und mit ESEUT /K die CRC-Prüfsummen der Dateien kontrolliert. Faszinierender weise haben alle Tests auf dieser Ebene keinen Fehler gemeldet. Die Blockstruktur der Datenbank war also fehlerfrei. Die Schreibzugriffe waren also doch nicht beschädigt oder haben einfach nicht mehr statt gefunden.

Ratlosigkeit

Zuerst dachte ich, dass der Ausfall des Servers indirekt damit verbunden war, dass der Massenspeicher keine Schreibaktionen mehr zugelassen hat, z.B. Treiber des RAID-Controllers oder der Controller selbst. Das würde zwar erklären, warum die ESE-Prüfsummern kein Problem haben, aber widerspricht den Fehlern beim Start auf dem Server und den logischen Fehlern in der Datenbank.

Allerdings kann ich einen physikalischen Defekt auf den Disks oder dem RAID-Controller eigentlich ausschießen, da die S.M.A.R.T-Parameter der Festplatten in Ordnung sind und auch sonst keine Events im RAID-Controller oder dem Systemmanagementboards des Servers aufgetaucht sind.

Der Weg zurück ins Grün

Dem Server kann ich so erst mal nicht weiter vertrauen. Aber zum Glück konnte ein anderer baugleicher Server ohne die Probleme die Funktion übernehmen. Nachdem nun fest stand, dass die Datenbank zwar gemountet werden kann, aber für einen weiteren Produktivbetrieb nicht "zuverlässig" genug erscheint, musste ein Restore herhalten. Zum Glück wird der Server über den Data Protection Manager sehr oft gesichert (Transaktionsprotokolle z.B. alle 15 Min), so dass auf dem Server zwar eine vollständige Datenbank von vor 4 Tagen bereit lag, aber aus dem Backup auch einige Transaktionsprotokolle restauriert werden konnten. Das Backup konnte aber die letzten Stunden aber natürlich auch nichts sichern, da der Server ja nicht mehr über das LAN erreichbar war. Aber da die Datenträger in sich ja vorhanden waren, konnten von dort auch noch ein paar Protokolldateien zusammen geführt werden.

Also wurde die Datenbank von DPM restauriert, die Transaktionsprotokolle dazu geschafft und mit ESEUTIL /cc wieder verarbeitet. Es gab zwar noch die ein oder anderen Problemchen, auf die ich nicht weiter eingehen will, aber der Server war nach einigen Stunden wieder online.

Rettet die Daten

Um den Datenverlust zu minimieren, konnte ich nun auf drei weitere Bausteine eines Exchange Betriebs zurück greifen

  • Recovery Storage Group
    Da die alte Datenbank weiterhin vorhanden war und sogar gemountet werden konnte, haben wir diese nach dem erfolgreichen Restore einfach als "recovery Storage Group" eingebunden und alle Mails der letzten drei Tage noch einmal "mergen" lassen. Zwar sind hierbei weitere Fehler aufgetaucht, aber was gelesen werden konnte, wurde auch kopiert
  • Archiv
    Mit dem Einsatz eines Archivprodukts konnten die Benutzer, die ihre Mails sehr früh archivieren lassen, natürlich auch hier ihre Elemente wieder selbst herstellen. Mit einem Journalarchiv könnten sogar alle empfangenen und gesendeten Mails wieder generiert werden.
  • Spamschutz mit Queue
    Da wir eingehende Mails nicht direkt mit Exchange empfangen, sondern mit NoSpamProxy, hilft uns dies gleich zweifach. Per Default nimmt NoSpamProxy nämlich nur dann Mails an, wenn er sie nach intern auch los wird, Es konnten also gar keine Mails zum Exchange zugestellt werden, während der Server nicht erreichbar war. Wenn wir das Queueing auch eingehend aktiviert hätten, dann könnten wir alle Mails auf dem NoSpamProxy in einem Buffer vorhalten und so auch noch mal senden.

Bis auf die Recovery Storage Group musste aber keine weitere Technik eingesetzt werden. Es ist aber gut zu wissen, was noch möglich gewesen wäre.

Besser in der Zukunft

Dieses Beispiel hat aber natürlich wieder gut aufgezeigt, dass ein RAID1 oder andere Redundanz der Disks nicht wirklich gegen solche logische Fehler oder Fehlbedienungen schützen kann. Es gibt schon Argumente, warum ein RAID zwar eine "Verfügbarkeit" im Fehlerfall einer Disk bereit stellt, aber keinen Schutz gegen Datenausfälle oder Veränderungen bietet. Selbst Schattenkopien sind nicht immer für solche Probleme gerüstet.

Insofern ist es wirklich zu prüfen, ob neben dem RAID als Absicherung der Plattform und einem Backup auch andere Optionen hier gewinnen können. Exchange 2007 bietet mit den Optionen SCR, LCR und CCR ja genug Möglichkeiten an, die Daten auf Applikationsebene zu "kopieren". Aber was ist mit all den anderen Servern und Diensten ?.

Auch ein Dateiserver hat natürlich ein RAID, damit ein schnöder Festplattendefekt, der doch ziemlich wahrscheinlich ist, keine teure Ausfallzeit und Datenverluste nach sich zieht. Aber ein tägliches Backup ist mir da auch zu wenig. Vielleicht wäre ein "ROBOBOPY" der geänderten Dateien einmal pro Stunde einfach auf eine andere Festplatte oder über das LAN eine sinnvolle Option für eine "Zweite Chance". Leider kenne ich kein Programm, welches dies "effektiver" als über das DateiÄnderungsdatum löst. Es wäre schon interessant, wenn ein Kopierprogramm z.B. über das USN-Journal der Festplatte gehen würde oder über einen Filtertreiber sogar auf Blocklevel herunter geht.

Übrigens macht z.B. DPM2007 so etwas, indem er als "Backup" einfach die geänderten Blöcke über LAN auf die Festplatte des DMP-Servers überträgt und damit mit minimaler CPU-, Disk- und Netzwerkbelastung eine Kopie auf einem anderen Server mit wenigen Stunden oder gar Minuten Verzögerung nachführt.

Für einfache Dateiserver wäre ein ROBOCOPY auf eine externe USB-Festplatte (Achtung 24h Betrieb !) oder einen NAS-Speicher durchaus eine interessante Option. Eine solche "Sicherung" wünsche ich mir natürlich auch für meinen Notebook, der zwar kein RAID hat, aber neben dem Defektrisiko einer kleinen 2,5" Festplatte in unterschiedlichen BetriebsUmgebungen. In der Hinsicht ist der "Windows Home Server" natürlich eine nette Lösung, da hier der Home Server Connector quasi immer mal wieder eine "Sicherung" des Desktops oder hier meines Notebooks auf eben den Home Server macht. Der Home Server selbst kann auch mehrere Festplatten bedienen, aber auch diese werden nicht als RAID geführt, sondern auch hier "kopiert" ein Prozess die Daten von der primären platten auf eine andere, um so eine "verzögerte Redundanz" zu erreichen. Auf die Idee, ohne RAID mit "Copy" eine Datenredundanz zu erreichen sind also schon andere gekommen.

Exchange Datenbanken haben ja die nette Eigenschaft, dass die Datenblöcke in sich eine CR-Prüfsumme haben, die mit "ESEUTIL /K" auch geprüft werden kann. Manchmal wünsche ich mir schon für NTFS auch eine solche Prüfsummenbildung und auf Block oder Dateiebene um korrupte Dateien einfacher zu erkennen. Leider ist sowas nicht Bestandteil von Windows sondern nur als Tool (z.B. http://www.md5summer.org) oder über Virenscanner umgesetzt. Alternativ kann eine Datei auch digital signiert sein, was langsam sich auch durchsetzt. Hier fehlt dann ein Programm um rekursiv dann alle signierten Dateien zu prüfen, damit ein Fehler nicht erst auffällt, wenn Windows die Datei laden will. Weit weiß denn schon, wie oft man über Word und Co flucht, wo doch tatsächlich ein unbemerkter logischer Fehler im Disk Subsystem die Ursache war. Wird mal Zeit für einen Dienste, der geänderte (kleine) Daten mit einem MD5-Hash versieht :-)

Weitere Links