Home | Comics | Gallery | wishlist | Donations | Impressum | The Book of Postfix | Postfix - Einrichtung, Betrieb und Wartung | Blog | 38.107.179.211 |

Why Exchange sucks: The ultimate experience

This is a report from a former colleague. He left the company after this incident - he warned them not to use Exchange, but of course nobody listened. Read about their suffering here:

Der *****-Krimi

Viele haben sich gefragt, was da eigentlich los ist bei ***** in Darmstadt.
Mails an die Darmstädter kommen ungelesen wieder zurück oder erreichen den
Empfänger nur mit stundenlanger Verzögerung. Immer wieder schaltet sich der
"Systemadministrator" ein und schickt eine Fehlermeldung. 

Liegt das etwa an Problemen bei der FUTZ - Umstellung in Darmstadt? (Für die
Neuen bei *****: FUTZ ist der Name des Projekts, das die Bürokommunikation
an den verschiedenen *****-Standorten vereinheitlicht). Gibt's einen
Hardwaredefekt oder einen Bug in der Software?

Tatsächlich hat eine ganze Reihe von sich gegenseitig beeinflussenden, aber
auch völlig unabhängigen Ereignissen (Murphy's Law) für die mehrfachen
Abstürze des Mail-Servers gesorgt. 

Hier die Details, protokolliert von Joe Sufferer: 

Dienstag 23. Januar (vormittags):

Der neue Darmstädter-Exchange Server fällt aus. Problem: Die Festplatten
sind vollgelaufen. Der Server konnte nicht mehr korrekt herunterfahren und
die Datenbanken, die alle Darmstädter E-Mails enthalten, wurden beschädigt.
Warum sind die Festplatten vollgelaufen?

1. Das System ist auf ein lauffähiges Backup ausgelegt. Ein tägliches Backup
archiviert sogenannte Log-Files und löscht diese danach. Da wir zur Zeit
kein Backup haben, wurden diese Log-Files nie gelöscht.

2. Die internal IT hat den Zustand zu spät bemerkt. Die Logfiles wuchsen
durch die Umstellung einiger Mitarbeiter mit großen Postfächern sehr schnell
an. (Umstellung von Altsystemen auf FUTZ).

Nach einem Backup der Datenbanken auf einen anderen Rechner haben wir mit
einem Reparaturlauf angefangen. Aufgrund der Datenmenge von 15 GB (nur
E-Mail in Darmstadt!!!) dauerte dieser Reparaturlauf bis zum nächsten
morgen. Ende des Tages: 22 Uhr.

Gleichzeitig wurde ein Support-Call bei Microsoft eröffnet, damit wir von
Anfang an optimale Unterstützung bei dieser Katastrophe haben.

Mittwoch 24. Januar:

Unser Arbeitstag beginnt um 5 Uhr morgens. Wir fahren den Exchange Server
hoch. Das meiste funktioniert normal und wir haben keinen nennenswerten
Datenverlust. Einziges Problem: Der Rechner ist extrem langsam weil er zu
100% ausgelastet ist.

Wir fassen den Entschluß, die Daten aller Mitarbeiter aus der alten evtl.
noch defekten Datenbank in eine andere Datenbank zu verschieben.

Gegen 9 Uhr morgens meldet der Exchange Server erneut einen Fehler. Wieder
sind die Datenbanken defekt und müssen repariert werden. Der Grund hierfür
ist uns zunächst unklar. Microsoft analysiert später unsere Protokolle und
vermutet einen Hardwaredefekt an dem Exchange Server. Laut Microsoft hängt
dieser zweite Crash so merkwürdig es auch klingt nicht mit dem ersten Crash
zusammen. Das Pech hat uns einfach an zwei aufeinanderfolgenden Tagen voll
erwischt.

Um die Leute wieder in einen arbeitsfähigen Zustand zu versetzen, legen wir
alle Darmstädter Kollegen erneut an und lagern ihre Daten auf den
Frankfurter Server aus. Dies geschieht gegen 15 Uhr. Seit 15 Uhr sind also
alle Darmstädter Kollegen wieder unter den normalen E-Mail Adressen
erreichbar. Allerdings können die Kollegen nur über https://pim.*****.de
arbeiten und die ,,alten" E-Mails stehen in dieser temporären Umgebung nicht
zur Verfügung.

Microsoft empfiehlt, alle Daten erneut zu sichern und den Reparaturlauf auf
den ursprünglichen Daten vom Vortag zu machen. Bis zum Abend kämpfen wir mit
dem Backup dieser Datenmengen.

Donnerstag 25. Januar:

Erneut beginnt unser Arbeitstag um 5 Uhr. Wir starten den Reparaturlauf.
Dieser ist gegen 12 Uhr beendet. Danach starten wir ein weiteres Backup der
entsprechenden Daten!

Auf Empfehlung von Microsoft und HP installieren wir einen zweiten Exchange
Server damit unsere Bemühungen nicht erneut durch einen eventuell defekten
Server zunichte gemacht werden. Gegen 17 Uhr ist der neue Server
einsatzbereit.

Mike Fixer arbeitet die gesamte Nacht durch und verschiebt nach und nach die
Daten eines jeden Mitarbeiters von dem wiederhergestellten Rechner auf den
neuen Rechner.

Freitag 26. Januar:

Wir konnten ausschlafen... D.h. wir waren erst gegen 6:30 Uhr im Büro. Mike
ist gerade mit dem Verschieben der letzten Kollegen fertig.

Alle Kollegen können wieder normal mit dem System arbeiten. Wir stellen
jedoch fest, daß auch dieser Server 100% CPU-Auslastung hat und
dementsprechend träge antwortet. Der ,,Fehler" scheint also vom alten zum
neuen System mitgewandert zu sein. Dieser Zustand wird mit Microsoft
besprochen. 

Nach Feierabend stehe ich bis ca. 3 Uhr nachts mit Microsoft in Verbindung
und sammele Informationen, Logfiles, Dumps usw. Um 3 Uhr nachts scheint der
Server noch immer stabil und das Problem wird auf Montag morgen vertagt.

Sonntag 28. Januar:

Gegen 4 Uhr nachts erweist sich unsere Einschätzung der Lage als zu
optimistisch: Ohne Vorwarnung schreibt das System ca. 20 GB an nutzlosen
Daten auf die Festplatte. Gegen 15 Uhr bemerken wir diesen Zustand durch
Anrufe bei unserer 24 Stunden Hotline.

Ich fahre am Abend in die Firma und installiere eine weitere Festplatte, so
daß der Zustand schnell behoben werden kann. Dann starte ich eine Prozedur,
um die nutzlosen Daten wieder zu entfernen und den Server wieder lauffähig
zu machen. Das dauert die ganze Nacht.

Montag 29. Januar:

Um 7 Uhr morgens beginnt der Tag...  Das System wird zunächst wieder flott
gemacht. Zwischen 8 Uhr und 18 Uhr werden eventuelle Fehlerquellen mit
Microsoft durchgesprochen. Dabei wird immer versucht, den Produktivbetrieb
nicht zu stören. Leider ist uns das nicht immer gelungen.

Um 18 Uhr: Der Durchbruch. Durch verschiedene Änderungen am System erhalten
wir einen wirklich stabilen Zustand. Das Symptom ist verschwunden, aber der
Grund wohl noch vorhanden. Und den kennen wir noch nicht... Danach: Fahrt
nach Königswinter.

23-3 Uhr: Zusammen mit Microsoft wird versucht, einen Grund für die Probleme
zu finden. Microsoft kommt um 3 Uhr zu der Erkenntnis, daß der Fehler nur
durch ein sogenanntes "Live-Debugging" auf der defekten Maschine gefunden
werden kann. Dieses wird auf den nächsten Abend vertagt, da wir erst die
entsprechenden Voraussetzungen schaffen müssen.

Dienstag 30. Januar:

Tagsüber läuft das System stabil. 

23 Uhr: Hoch lebe Amerika... Die nächste Sitzung mit Microsoft beginnt. Die
drei Musketiere Jared, Andy und Joe Sufferer verbringen sieben sehr
harte Stunden mit dem Microsoft Support in Amerika. Leider gelingt aus
verschiedenen technischen Gründen das eigentliche "Debugging" nicht. Aber es
können alle notwendigen Voraussetzungen geschaffen werden.

Mittwoch 31. Januar:

Das System läuft stabil. Wir treffen weitere Vorbereitungen für das Debugging. 

Donnerstag 1. Februar:

Tagsüber wird versucht, das Problem am Rechner pim.*****.de nachzustellen.
Leider ohne Erfolg. 

20:30 Uhr. Das Debugging am eigentlichen Problemrechner beginnt. Innerhalb
der nächsten drei Stunden kann Microsoft den Fehler im System eingrenzen. Es
scheint sich wirklich um einen Fehler im Programm zu handeln. Microsoft
bestätigt, daß es KEIN Konfigurationsfehler auf ***** Seite ist.


Aktueller Status: 

Microsoft versucht, daß gesamte Problem im eigenen Labor nachzustellen. Wenn
dies gelingt, wird der gesamte Fall an die Exchange-Entwickler in Redmond
übergeben. Falls dies nicht gelingt wird Microsoft den Fall weiter direkt
auf unseren Systemen untersuchen. Sobald der Bug gefunden wird, erhalten wir
einen HotFix für das Problem.


Zusammenfassung:

- Der erste Crash entstand durch die oben genannten zwei Gründe. 

- Der zweite Crash kam durch einen Hardwareausfall zu Stande. 

- Die Situation seit dem 26. Januar war problematisch, weil Microsoft einen
  bis dahin nicht entdeckten Fehler in ihrem System hat. Leider sind wir
  durch unglückliche Verkettungen genau in diesen Fehler hineingerannt. So
  wie es aussieht sind wir damit die ersten weltweit. Hat doch auch was...
  :-(


Was tun wir, damit uns das in Zukunft nicht erneut geschieht? 

BACKUP, BACKUP, BACKUP. Die ganzen Vorfälle haben die Entscheidungsfindung
bzgl. des Backup-Budgets beschleunigt. Wir werden so schnell wie möglich
deutschlandweit ein Backup-System für die gesamte FUTZ-Umgebung
installieren. Wenn wir im obigen Szenario ein ordentliches Backup des
betroffenen Systems gehabt hätten, wäre der Ausfall auf maximal 1/2 Tag
beschränkt gewesen.

This file was last modified 07. May 2007 by root