Verfügbarkeit (Exchange und anderes)

An einigen Stellen werden Sie Überschriften erkennen, die noch nicht verlinkt sind. Ich habe noch nicht alle Seiten erstellt. Ich bitte das zu entschuldigen. Nutzen Sie doch den RSS-Feed um neue Seiten und Änderungen schnellstens zu erhalten.

Dieser Bereich fasst die verschiedenen Konzepte und Modelle zusammen, um die Verfügbarkeit von Exchange zu verbessern. Dabei ist ein Exchange "Cluster" nur ein sehr kleiner Aspekt dieser Modelle. Wer von Hochverfügbarkeit spricht, muss nicht immer einen Cluster kaufen und einsetzen. Oft fahren Sie sogar mit einem einfachen Standardserver und entsprechenden Vorkehrungen unterm Strich besser.

Konzept <> Lösung
Ich beschreibe hier teils technische Feinheiten als auch allgemeine Konzepte, Ideen, Möglichkeiten. Sie sollten kein "How-To" erwarten, da höhere Verfügbarkeiten immer individuell zu betrachten sind

Es ist offensichtlich, dass immer mehr Administratoren unruhig schlafen, wenn Sie an einen Ausfall des Exchange Servers denken.  Sie werden sehr schnell merken, dass Exchange nicht nur ein Mailserver ist, sondern sehr schnell das Herz und Rückgrat eines unternehmens werden kann. Messaging Dienste dürfen dann nicht mehr ausfallen oder Ausfälle (geplant oder ungeplant) müssen möglichst kurz gehalten werden. Also suchen Sie nach Lösungen, wie im Falle eines Fehlers die Ausfallzeit und der mögliche Schaden minimiert werden kann. Und damit landen Sie beim Thema Hochverfügbarkeit mit Exchange. Leider gibt es auch hier keine Antwort ohne das Umfeld zu können und nur durch die Installation eines Cluster wird ihr System eher komplexer und weniger Verfügbar, wenn Sie nicht das Gesamtpaket umsetzen. für die Funktion des Nachrichtensystems in einem Netzwerk sind viele Komponenten notwendig, die alle zusammen greifen und funktionieren müssen. Es ist eine Kette und der Exchange Server ist meist nicht das schwächste Glied. Fatalerweise wird ihr Exchange Server dann zum schwächsten Glied, wenn Sie ihn als Cluster installieren und nicht entsprechend vorbereitet sind. Sie werden nämlich für jede einzelne Komponente ihres gesamten Systems prüfen müssen, wie Sie diese auf eine von ihnen gewünschte Verfügbarkeit bringen.

Verfügbarkeit - mehr als nur Cluster

Ehe sie nun gleich zu den unterseiten über die verschiedenen Exchange Cluster weiter klicken, sollten Sie sich erst einmal Gedanken zum Thema "Verfügbarkeit" machen.

Exchange Bordmittel

Nachdem Sie diese Vorarbeiten erledigt haben, können Sie sich natürlich die Details zu Microsoft mit Cluster durchlesen.

Verfügbarkeit mit Storage

Die meiste Zeit geht verloren, wenn Sie eine Datenbank wiederherstellen oder einen Server installieren müssen. Ein Storage Netzwerk (Fiber Channel oder iSCSI) kann hier bei fachgerechtem Einsatz Zeit sparen.

  • SAN Replikation / Snapshots
  • SAN Backup/Restore
  • SAN Boot

Verfügbarkeit im Netzwerk

  • DNS Round Robin
    Lastverteilung und Verfügbarkeit und die Grenzen
  • Network Load Balancing
    Bis zu 32 Server in einem Verbund betreiben.
  • LoadBalancer
    Dedizierte System zur Weiterleitung von Anfragen an verfügbare Server
  • MiniSFT
    Eine alternative Möglichkeit eine IP-Adresse zu übernehmen und die Beschränkungen von NLB zu umgehen.
  • MCSC IP Failover
    Wer denkt, dass Microsoft Cluster Services nur für Storage Dienste geeignet ist, könnte sich täuschen.

Verfügbarkeit und Virtualisierung

Nicht erst seit "vMotion" von VMWare denken Leute über die Vorteile einer Virtualisierung von Servern bezüglich der Verfügbarkeit nach.

Der Einsatz von virtuellen Systemen ist allerdings nur bedingt als "Hochverfügbarkeit" anzusehen. Fällt ein VM-Hostsystem aus, können bei geeigneter Storage-Konfiguration die virtuellen Systeme auf einem anderen Host neu gestartet werden. Nützlich bei einem RZ-Ausfall. Auch geplante umschaltungen sind oft einfach möglich. Virtualisierung ist aber kein Mittel um die "Uptime" von Servern zu verbessern, wenn diese selbst gepatched, durchgestartet oder anderweitig verändert werden müssen. Eine defekte Exchange Datenbank oder Programminstallation eines Server kann keine Virtualisierung lösen. Allenfalls durch ein Rollback zu einem vorherigen Snapshot gibt es hier einen Vorteil.

"virtual machine snapshots aren't application aware, and using them can have unintended and unexpected consequences für a server application that maintains state data, such as Exchange. As a result, making virtual machine snapshots of an Exchange guest virtual machine isn't supported."
Quelle: http://technet.microsoft.com/en-us/library/aa996719.aspx

Insofern spielt Virtualisierung natürlich eine Rolle aber darf nicht losgelöst als Lösung betrachtet werden.

  • VMs zwischen Hosts "verschieben"
    vMotion und andere Techniken erlauben es heute sehr einfach einen Gast quasi ohne Unterbrechung auf einen anderen Host zu verlagern um damit die Hostsysteme selbst lastfrei zu schalten. Hardwareerweiterungen oder Änderungen von Hosts sind damit sehr einfach möglich, um noch mehr VMs darauf zu betreiben oder den bestehenden VMs mehr Ressourcen zu geben. eine "Downtime" gibt es eigentlich nicht. Allerdings sollten Sie diese Technik nicht mit NLB oder MS Cluster kombinieren.
  • VMs nach Hostausfall starten
    Fällt bei einem klassischen Server die Hardware aus, dann ist der eigentlich Server meist mehrere Stunden weg. Hardware bei Virtualisierung ist der Host. Die Gäste sind unabhängig und wenn die dazu gehörigen virtuellen Disks nicht im Host selbst sondern in einem SAN liegen, kann die gleiche VM relativ schnell auf einem anderen Host wieder gestartet werden. Die Ausfallzeit bewegt sich im Minutenbereich.
  • VM nach RZ-Ausfall neu starten
    Analog zum Host-Ausfall kann man so auch ganze RZs gegen Ausfälle absichern. Hier ist es aber erforderlich, dass der Storage ebenfalls redundant vorliegt (z.B.: NetApp Metrocluster, EMC Mirroring o.ä.)
  • VMs per Template bereit stellen
    Eine wichtige und elegante Funktion ist natürlich das "Template". Wer mal einen Server braucht, kann ihn per Virtualisierung in der Regeln in wenigen Minuten "bereit" stellen und auch wieder entfernen. Das ist natürlich schon eine Flexibilität
  • Snapshot und undo
    Wenn sie dran denken, dann können Sie vor größeren Updates und Patches ja auch einfach mal einen "Snapshot" machen und damit bei einem Fehler wieder auf den alten Stand zurück. Beachten Sie aber, dass sich dies meist nur auf das Betriebssystem bezieht aber nicht immer sinnvoll auf Applikationen angewendet werden kann. Snapshots auf DCs sind hingegen verboten und bringen die AD-Replikation ziemlich sicher aus dem Tritt, wenn diese vorher nicht angehalten wurde. Ein Snapshot auf einem Exchange Server hilft natürlich auch nichts, wenn an der Konfiguration im Active Directory etwas geändert wird. Ein gelöschtes Postfach wird nicht wieder lebendig, wenn Sie den Server auf einen vorherigen Stand zurück setzen.

Es gibt also schon viele Argumente für ein Einsatz von virtuellen Umgebungen und bestimmte Fehlerszenarien verlieren durch Virtualisierung auch ihren Schrecken oder lassen sich leichter Handhaben. Aber gerade im Bereich "geplante Downtime" hilft dies nur bedingt weiter.

Sonstige Verfügbarkeitsstrategien

Neben den offiziellen Wegen eines Microsoft Clusters können Sie durchaus mit alternativen Ansätzen arbeiten:

  • Redundanz durch mehrere Systeme
  • Server schnell aufsetzen mit RIS/WDS
    Sie sprechen über die Reduzierung ihrer Downtime nach einem Serververlust aber brauchen 1-2 Stunden um ihren Server erst einmal zu installieren
  • Verfügbarkeit ohne Cluster
  • Virtualisierung für Hochverfügbarkeit
    Virtuelle System können schnell auf anderen Hosts online geschaltet werden.
  • Virtualisierung als Desaster Option
    Physikalische Systeme können in virtuellen Servern als schnelle Ersatzoption gesichert werden.
  • Backup und Recovery Server
    Ersatzserver bzw. aktive Exchange Server übernehmen bestehende Datenbanken
  • Datenmanagement mit HSM/Archiv / Recovery mit Journalmailbox
    Weniger Datenmenge reduziert die Downtime durch Restore und den Datenverlust
  • Postfachaufteilung
    Aufteilung von Inhalten reduziert die Datenmenge des primären Servers = weniger Wiederherstellung, kürzeres SLA
  • Schattenserver
    Stellen Sie sic vor, die betreiben neben dem produktiven System ein zweites System für den Notfall. So könnte dies aussehen
  • VSSCopy + Recover Server
  • Mailbox Replication (Cemaphore’s MailShadow )
  • Geografische Cluster
  • Standbyserver
    Physical Hardware Failover (Doubletake, NSI)
    Database Replication (Nearbpoint Backup mimosa Systems http://www.mimosasystems.com
  • Network Load Balancing
  • MiniSFT
    Eine alternative Möglichkeit statt NLB
  • Quickstart
    RIS/WDS als Notfallwerkzeug zur Serverwiederherstellung.