Hochverfügbarkeit ohne Cluster
Auf der Seite Hochverfügbarkeit haben Sie sicher schon gelesen, dass der Einsatz von Cluster erst bei Verfügbarkeitsanforderungen unter einer Stunde wirklich überlegt werden sollte, da Cluster natürlich auch mit einer höheren Komplexität und Kosten verbunden ist.
Für Firmen, die aber eine längere Ausfallzeit (z.B. wenige Stunden) tolerieren können, gibt es aber sehr viele alternative Wege, die Wiederherstellungszeit des Servers zu reduzieren.
Warnung:
Diese Seite beschreibt Gedanken für eine beschleunigte Wiederherstellung von
defekten Exchange Servern. Sie ist nicht als "How-To"-Anleitung oder gar als
Konzept für eine Exchange Hochverfügbarkeit zu verstehen.
Hier ein paar Gedanken und Konzepte:
Cold Standby
Die sicher einfachste Option ist die Vorhaltung von "Ersatzteilen" oder eines Opfers. Wer gleiche mehrere baugleiche Server hat, kann hier natürlich mit weniger Hardware die verschiedenen Defekte überbrücken. Diese Vorratshaltung ist durchaus zweckmäßig, da ein Lieferant selten innerhalb von Stunden schon Ersatzteile liefern kann. Oder der Preis für diese Leistung ist so hoch, dass der Ersatzserver in wenigen Monaten schon bezahlt ist.
Es hindert Sie ja niemand daran, diesen Ersatzserver mit einer "weniger wichtigen" Funktion zu betrauen. Er könnte als Test und Spielserver für die Administratoren dienen, indem er virtuelle Maschinen vorhält. Einige Firmen nutzen solche Server auch für sekundäre Dinge wie einen WSUS-Server. Sicher ist es notwendig, seine Server regelmäßig zu Patchen, aber ein Exchange Server sollte schnell wieder da sein, während die meisten Firmen auf einen Server für Patchmanagement gerne mal ein paar Tage verzichten können. Wenn beim Hauptserver nicht gerade der komplette Massenspeicher ersetzt werden muss, bleiben die Daten ja erhalten.
Wenn der Ersatzserver nicht nur aus einer Kiste von Bauteilen besteht, sondern funktionsfähig ist, dann kann im Desasterfall natürlich die Wiederherstellung des Server sofort beginnen. Diese Zeit geht dann schon mal nicht verloren. Der Server wird einfach mit dem gleichen Namen wieder installiert und nutzt das bestehende Computerkonto. Exchange wird dann mit der Option /DesasterRecovery (2003) oder /RecoverServer (2007) wieder installiert.
Wenn die Datenbanken des originalen Servers auf einem externen Massenspeicher oder gar im SAN lagen, dann kann man diese meist wieder an den Ersatzserver anbinden und erspart sich so das zeitaufwändige Restore der Datenbank.
Cold Standby mit SAN-Boot
Wer sowieso schon mit zentralen müssenspeichern arbeitet, sollte prüfen, ob der Rechner nicht auch direkt vom SAN booten kann. So wird der eigentliche Server nur zur Bereitstellung von CPU, Speicher und Netzwerk benötigt, während Betriebssystem, Konfiguration und Daten komplett im SAN liegen.
Der Ausfall eines Rechnerknotens ist dann weniger kritisch, wenn identische verfügbare Systeme vorhanden sind. Hier sind natürlich Blade-Systeme in ihrem Element. Ein ausgefallenes Blade kann von einem anderen Blade einfach übernommen werden. Einige Hersteller haben sogar die passende Überwachungssoftware, die bei Bedarf das defekte Blade abschalten und ein Ersatzblade online nehmen.
In Grenzen ist sogar eine geografische Verteilung in zwei Rechenzentren möglich, wenn auch das SAN dies unterstützt. Wir haben Kunden, die in der gleichen Stadt ein "kaltes" Rechenzentrum vorhalten, indem nur eine Kopie der Massenspeicher und der Bandroboter stehen. Fällt das primäre Rechenzentrum aus, dann sind die Ersatzsysteme schnell (auch aus der Ferne) eingeschaltet und arbeiten mit dem gleichen Datenbestand weiter.
Redundante Daten mit LCR und Co
Die bislang aufgeführten Wege funktionieren natürlich um so besser, je weniger Daten verloren sind. Neben der Zeit für die Lieferung der Ersatzhardware und der Installation des Betriebssystems und Exchange ist die Wiederherstellung der Datenbank der große Brocken, zumal dieser Schritt bei den meisten Lösungen erst nach Abschluss der anderen Tätigkeiten starten kann.
Das wird auch ein Grund gewesen sein, warum mit Exchange 2007 Funktionen wie LCR, CCR oder SCR hinzu gekommen sind. Erlauben diese doch die Ablage einer Datenbankkopie auf dem gleichen Server, dem anderen Cluster Knoten oder einem komplett anderen Server. Damit wird nicht nur die Zeit für eine Datenwiederherstellung minimiert, sondern auch überhaupt der Verlust von Daten reduziert. Wer mag seinem Chef nach einem Ausfall am Nachmittag (16:00) unter die Augen treten und ein Backup vom 22:00 des Vortags anbieten ?
Diese Kopien können aber auch zu alternativen Lösungen genutzt werden. Wenn ein Exchange 2007 Standard Server eine Kopie seiner Daten auf eine zweiten Festplatte ablegen kann (LCR), dann steht nirgends geschrieben, dass diese Festplatte im gleichen Gehäuse eingebaut sein muss. Dieser Datenspeicher muss auch kein SAN sein, sondern könnte eine "Netzwerkfestplatte" sein, die per iSCSI angesprochen wird. Ein UNC-Laufwerk ist nicht nutzbar.
Wichtig ist hier, dass die Daten eben als Kopie auf einem zweiten Massenspeicher an einem anderen Ort liegen. Beim Ausfall des Server kann eben wieder eine beliebige Ersatzhardware herangezogen und mit Exchange installiert werden. Die Kopie der Datenbank wird dann als primärer Massenspeicher eingebunden schon in wenigen Stunden ist ein "Notfall Exchange" wieder online.
VSS, Snaphots und Images
Gerade in Verbindung einem SAN, iSCSI und einem zentralen Storage
Snapview, VSS
Warm Standby
Ersatzserver "läuft" als eigener Server
mit ADMODIFY (http://www.msexchange.org/tutorials/Using-admodifynet-administer-recover-Exchange-2003.html) kann man HomeMTA/HomeMDB ändern. Aber MAPI-Profile neu erforderlich (oder DNS-CNAME etc.)
Dialtone Restore
Gleichnamiger Server mit leere DB restaurieren. Leute können weiter senden/Empfangen. aber keine Stellvertreter, Regeln etc. OST werden neu aufgebaut. Beste Option: MAPI Zugriff Stoppen, nur OWA Notbetrieb zulassen. Restore der Produktion in Recovery Storage Group. Dann Mailboxstore "Switchen" und mergen.
Die Bedeutung eines Archivsystems
Was viele bei der Betrachtung von Verfügbarkeit häufig übersehen ist die Bedeutung eines Archivsystems. Es kann z.B. Mails während der Zustellung schon in das Archiv kopieren (z.B. per Journal) und damit die Mails an einem zweiten Ort vorhalten und nach einem Ausfall mit Datenverlust sogar wieder einspielen.
Weitere Links
-
Clustergrundlagen
Grundlagen für den Betrieb eines Windows Clusters -
Exchangecluster
Grundlagen zur Exchange auf dem Cluster -
Standby
Alternativen fürhere Verfügbarkeiten -
MSXFAQ MiniSFT
Eine alternative Möglichkeit statt NLB - Network Load Balancing