Auf den ersten Blick erscheint das Konzept schlüssig: Die Verfügbarkeit des eigenen Rechenzentrums soll durch das Verteilen der Infrastruktur auf zwei Serverräume erhöht werden. Doch nicht jedes Design geht im Fehlerfall gleichermaßen gut auf und bringt das gewünschte Maß an Ausfallsicherheit. Lesen Sie in diesem Beitrag, worauf Sie beim Design Ihres räumlich aufgeteilten Rechenzentrums achten müssen.
Wer heutzutage ein Rechenzentrum plant, und sei es nur ein Serverraum in einem kleinen Unternehmen, versucht meistens, die dort untergebrachte Technik auf mehr als einen Raum zu verteilen. Vorzugsweise befinden sich diese Räumlichkeiten dann in verschiedenen Brandabschnitten oder sogar Gebäuden zum Beispiel auf einem Werksgelände. Die Idee dahinter ist, bei einem geplanten oder ungeplanten Ausfall eines Rechenzentrum-Raums die dort bereitgestellten IT-Dienste von dem anderen Raum aus aufrechterhalten zu können. Virtualisierungs- und Storage-Plattformen, Datenbanken und Anwendungen bieten dafür äußerst umfangreiche Hilfsmittel.
Doch stellen IT-Verantwortliche oft fest, dass es mit zwei RZ-Räumen, redundanter Stromversorgung, Klima und Vernetzung allein nicht getan ist. Damit sich die Schwachstellen der geplanten RZ-Redundanz nicht erst im Failover-Fall offenbaren, ist ein gutes Verständnis der eingesetzten Technologien und vor allem eine klare Definition der angestrebten Redundanz vonnöten. Die wichtigsten Merkmale, die Sie dabei berücksichtigen müssen, sind (in dieser Reihenfolge):
- Single Points of Failure,
Wer heutzutage ein Rechenzentrum plant, und sei es nur ein Serverraum in einem kleinen Unternehmen, versucht meistens, die dort untergebrachte Technik auf mehr als einen Raum zu verteilen. Vorzugsweise befinden sich diese Räumlichkeiten dann in verschiedenen Brandabschnitten oder sogar Gebäuden zum Beispiel auf einem Werksgelände. Die Idee dahinter ist, bei einem geplanten oder ungeplanten Ausfall eines Rechenzentrum-Raums die dort bereitgestellten IT-Dienste von dem anderen Raum aus aufrechterhalten zu können. Virtualisierungs- und Storage-Plattformen, Datenbanken und Anwendungen bieten dafür äußerst umfangreiche Hilfsmittel.
Doch stellen IT-Verantwortliche oft fest, dass es mit zwei RZ-Räumen, redundanter Stromversorgung, Klima und Vernetzung allein nicht getan ist. Damit sich die Schwachstellen der geplanten RZ-Redundanz nicht erst im Failover-Fall offenbaren, ist ein gutes Verständnis der eingesetzten Technologien und vor allem eine klare Definition der angestrebten Redundanz vonnöten. Die wichtigsten Merkmale, die Sie dabei berücksichtigen müssen, sind (in dieser Reihenfolge):
- Single Points of Failure,
- Failover-Verhalten der einzelnen Systeme und Dienste,
- Performance-Einschränkungen durch Wegfall von Systemen.
Das Ziel klar definieren
Bevor Sie weitreichende und im Nachhinein schwer zu korrigierende Entscheidungen für Ihr RZ-Design treffen, müssen Sie festlegen, welcher Ausfall mit welchen Einschränkungen toleriert werden soll. Die oft formulierte Idealvorstellung lautet: "Wenn eines der Gebäude komplett abbrennt, muss für den Rest der Firma alles weiterlaufen, höchstens ein wenig langsamer". Mit einer solchen Leistungszusage ist es in der Regel auch am einfachsten, ein Budget für Hochverfügbarkeit genehmigt zu bekommen. Doch was bedeutet eine derart allgemein gefasste Aussage in der praktischen Durchführung?
In der modernen IT spielt die Anbindung an das Internet und damit an die Außenwelt eine große Rolle. Für viele Dienste und Anwendungen ist der Internetzugang oft wichtiger als die Anbindung an die internen Netze und Systeme. Die Vorgabe, einen RZ-Raum ohne funktionale Einschränkungen abschalten oder verlieren zu können, bedeutet daher, dass die Internetzugänge inklusive Zuführung seitens der Provider ebenfalls auf beide Räume verteilt werden müssen. Das bringt einige Herausforderungen mit sich. Eine entsprechende Konfiguration der externen Router, die ebenfalls auf beide Räume zu verteilen sind und über entsprechende Failover-Mechanismen verfügen müssen, ist in der Regel herstellerseitig vorgesehen und schnell erledigt.
Die Leitungszuführung hingegen kann problematisch werden, insbesondere wenn die beiden RZ-Standorte in einem Gebäude dicht beieinander liegen und nur durch Brandabschnitte getrennt sind. Da kann es schon passieren, dass die Leitungsführung zum Raum A durch den Brandabschnitt mit dem Raum B verläuft und bei Problemen in diesem Bereich in Mitleidenschaft gezogen wird. Bei Serverräumen, die an unterschiedlichen Seiten eines weitläufigen Fabrikgeländes platziert sind, müssen Leitungsanbieter manchmal überzeugt werden, einen Leitungsstrang rund ums Gelände zu führen.
Viel spannender wird die Herausforderung, den Internet-Uplink auf zwei Räume zu verteilen, wenn aus dem Rechenzentrum heraus Dienste ins Internet veröffentlicht werden. Es muss also auch bei Ausfall eines der Räume sichergestellt sein, dass externe Kommunikationspartner den entsprechenden Endpunkt finden und erreichen können. Dazu gibt es zwei technische Lösungsansätze:
- Sie lassen die externen IP-Adressen Ihrer DMZ stets in einem der Räume terminieren, beim Ausfall des dortigen Routers übernimmt der Router des verbleibenden Raumes und teilt mittels Border Gateway Protocol (BGP) dem Rest der Welt mit, dass er von nun an für diese Subnetze verantwortlich ist. Diese Technik muss Ihr ISP explizit unterstützen, Sie müssen das Grenznetz also zwingend mit ihm zusammen designen und aufbauen. Wie gravierend sich Fehler im Umgang mit BGP auswirken können, zeigt der jüngste Ausfall sämtlicher Dienste des Facebook-Konzerns [1].
- Sie richten in jedem Raum eine eigene DMZ ein und routen Ihre extern veröffentlichten Dienste innerhalb Ihres eigenen Netzwerks. Um sicherzustellen, dass externe Kommunikationspartner die angebotenen Dienste auch bei Ausfall eines der Räume finden, müssen Sie entweder zu GeoDNS (zum Beispiel ClouDNS mit der "Failover and Monitoring"-Option [2]) oder zum Geo-Loadbalancing greifen. Ein Beispiel hierfür ist "Elastic Load Balancing" von AWS [3]. In beiden Fällen nutzen Sie einen Dienst aus der Public Cloud, womit Sie genau genommen nicht mehr zwei, sondern drei "Serverräume" haben.
Doch auch für Ihre internen Applikationen und Dienste müssen Sie sich auf eine jeweils passende Hochverfügbarkeits-Methodik festlegen, um keine Überraschungen im Falle eines Ausfalls oder einer geplanten Wartung zu erleben. Dabei ist es wichtig, dass Sie die folgenden Szenarien in Bezug auf Ihre konkrete Infrastruktur genau betrachten und gegeneinander gewichten (nach Wahrscheinlichkeit des Eintretens und Dauer der Wiederherstellung):
- Unkontrollierter Ausfall des RZ A oder RZ B
- Kontrollierte Abschaltung des RZ A oder RZ B
- Verlust der externen Konnektivität im RZ A oder RZ B
- Verlust der Verbindung zwischen RZ A und RZ B
Besonders das letzte Ausfallszenario birgt sowohl im Design als auch später im Betrieb viele Tücken. Es wird bei der Planung eines hochverfügbaren internen RZ jedoch oft übersehen oder nicht ausreichend beachtet.
Schließlich müssen Sie möglichst frühzeitig ein in der Verfügbarkeitsplanung häufiges Missverständnis auflösen – spätestens dann, wenn Sie Ihre RZ-Planung dem Management vorstellen. Oft ist in technischen Designs und Konzepten von "Hochverfügbarkeit" (High Availability oder HA) die Rede. Dies bedeutet jedoch nicht mehr, als dass bei Ausfall eines Systemteils das Gesamtsystem automatisch und innerhalb einer definierten Zeit die Bereitstellung des jeweiligen Diensts wiederaufnimmt.
HA sorgt für keine Zusicherung des unterbrechungsfreien Betriebs oder eine 100-prozentige Datenkonsistenz nach Wiederherstellung. Genau dies ist jedoch die Erwartungshaltung der Nichttechniker (und leider auch vieler Techniker) in Bezug auf den Begriff "HA". Die korrekte Bezeichnung für diese deutlich höhere Servicequalität ist "Fehlertoleranz" (Fault Tolerance oder FT). Fehlertolerante Designs sind in vielen Fällen möglich, jedoch meist mit deutlich höheren Kosten verbunden als die "einfache" HA.
Bild 1: Die scheinbare Einfachheit der Plattform-HA birgt viele Herausforderungen.
Die beiden Designextreme
Bei der Projektierung eines hochverfügbaren Rechenzentrums mit zwei oder mehreren Abschnitten stehen Ihnen zahlreiche Designmöglichkeiten zur Verfügung. Sie alle haben gemeinsam, dass jeder der Räume eine aktuelle Kopie aller Anwendungsdaten vorhalten muss, Sie zu jeder Zeit eine Netzwerkverbindung zu den Anwendungs- und Infrastrukturservern ermöglichen müssen und außerdem eine Datendivergenz zwischen den Räumen ("split brain") in allen vorgesehenen Szenarien zu vermeiden ist. Die beiden Designansätze, mit denen Sie Ihre Planung beginnen müssen, sind "Plattform-Hochverfügbarkeit" und "Anwendungs-Hochverfügbarkeit".
Die Plattform-Hochverfügbarkeit, die erst mit dem Fortschreiten der Servervirtualisierung möglich geworden ist, abstrahiert die Compute-, Storage- und Netzwerkleistung von ihrem jeweiligen Standort. Alle Datenspeicher, in denen sich die virtuellen Festplatten befinden, sind synchron gespiegelt – entweder mit der klassischen SAN-Spiegelung oder mit "Software-defined-Storage"-Technologien wie VMware vSAN oder Microsoft Storage Spaces Direct. Sowohl Daten- als auch Storage-Netzwerke sind zwischen den RZ-Räumen voll vermascht, sodass die eingesetzten Switching-Protokolle schnell auf Veränderungen der Netzwerktopologie reagieren und die Pakete in den "richtigen" Raum zustellen können. Sämtliche Anwendungen und Infrastrukturdienste, auf die Clients zugreifen sollen, werden auf virtuellen Maschinen oder in Containern ausgeführt. Der Hochverfügbarkeitsansatz besteht darin, dass jede virtuelle Maschine stets den aktuellen Datenunterbau hat und netzwerktechnisch unter ihrer IP-Adresse erreichbar ist – egal in welchem RZ-Abschnitt sie gerade ausgeführt wird.
Anwendungs-Hochverfügbarkeit verfolgt den gegenteiligen Ansatz: Storage-Bestände und IP-Adressen, somit auch einzelne VMs, sind dauerhaft an einen der Räume gebunden, und jeder Dienst beziehungsweise jede Anwendung nutzt die dort eingebauten Replikations- und Failover-Mechanismen. Active Directory, DNS, DHCP, doch auch Exchange, SQL, ADFS oder andere Webanwendungen verfügen über zuverlässige und gut skalierbare HA-Fähigkeiten.
Zu diesem Ansatz gibt es keine wirkliche Alternative, wenn Sie gezwungen sind, eine Anwendung auf physischen anstatt virtuellen Servern bereitzustellen. Doch auch im virtuellen Umfeld ist die anwendungseigene Hochverfügbarkeit oft die einzige, die vom jeweiligen Hersteller unterstützt wird – so ist dies beispielsweise bei Microsoft Exchange oder Skype for Business der Fall.
Beide Architekturen haben ihre Stärken und Schwächen. Sie können diese Stärken ausnutzen, wenn Sie die beiden Designansätze geschickt miteinander kombinieren. Dafür ist es wichtig, die Auswirkungen der verschiedenen HA-Architekturen genau zu kennen. Denken Sie daran, dass keines der HA-Konzepte per se den Anspruch der Integrität und Vollständigkeit der Daten erhebt und alle Aussagen sich lediglich auf die Verfügbarkeit der Dienste beziehen.
Bild 2: Bei der Anwendungs-HA muss jeder Dienst separat berücksichtigt werden.
Failover vs. Switchover
Bei der Planung hochverfügbarer Infrastrukturen wird oft der Extremfall ausführlich diskutiert: Ein ganzer RZ-Standort geht unerwartet und unkontrolliert vom Netz. Das kann durch ein katastrophales Ereignis oder menschliches Versagen erfolgen, aber auch durch einen Cyberangriff etwa auf die Stromversorgung. In diesem Fall ist das erwartete Verhalten Ihrer Server- und Netzwerklandschaft ein sogenanntes "Failover". Ein viel häufiger auftretendes Ereignis ist jedoch ein "Switchover", das heißt, ein kontrolliertes Abschalten eines RZ-Abschnitts für Baumaßnahmen oder im Rahmen behördlich vorgeschriebener Untersuchungen, falls Ihr Hochverfügbarkeitskonzept einer Auditpflicht unterliegt.
Nicht jede HA-Architektur ist für Failover und Switchover gleichermaßen geeignet. Bei der Anwendungs-HA werden Sie als Administrator versucht sein, für die meisten Anwendungen den Switchover-Vorgang administrativ "anzukündigen". Das beinhaltet das Verschieben aktiver Cluster-Instanzen, das Versetzen von einzelnen Servern in einen Wartungsmodus oder deren kontrolliertes Herunterfahren.
Obwohl dieses behutsame Vorgehen eine bessere Verfügbarkeit aller Anwendungen während und nach dem Switchover verspricht, ist diese Herangehensweise aufwendig und bei vielen Anwendungen nur denkbar, wenn Sie sie möglichst vollständig automatisieren. Im Fall der Plattform-HA müssen Sie "nur" alle virtuellen Maschinen aus dem abzuschaltenden RZ-Abschnitt verschieben und die dortigen Virtualisierungshosts in den Wartungsmodus versetzen, damit die VMs nicht automatisch zurückmigriert werden.
Bei einem ungeplanten Failover fallen alle Dienste, die im havarierten RZ-Abschnitt gelaufen sind, erst einmal aus. Im Fall der Plattform-HA werden sie durch die Hochverfügbarkeitsfunktion der Virtualisierung neu gestartet. Je nach Ressourcen kann es einige Minuten dauern, bis alle VMs wieder laufen. Die Betriebssystem- und Datenfestplatten sind in diesem Fall "doppelt-Crash-konsistent", zum einen durch das abrupte Ausschalten der VM selbst und zum anderen durch den Abbruch der Replikation der Storage-Blöcke zwischen den RZ-Abschnitten. Moderne Betriebssysteme haben inzwischen eine sehr hohe Resilienz gegenüber solchen Vorgängen entwickelt.
Datenbanken und Anwendungen können hingegen einen Schaden davontragen, wenn Sie für ihre interne Datenhaltung keine transaktionelle Integrität erzwingen. Die Hochverfügbarkeit auf Anwendungsebene leistet hier, sofern sie sauber konfiguriert ist, deutlich bessere Dienste. Für viele Anwendungen können Sie hier mit einer ausfallfreien Fortsetzung des Betriebs rechnen. Ist neben Hochverfügbarkeit auch Lastverteilung Teil Ihrer Bereitstellungsstrategie, ist vom Ausfall eines RZ-Abschnitts ohnehin nur die Hälfte der Verbindungen betroffen.
Physische Standorte planen
Die Anwendungs-Hochverfügbarkeit beinhaltet meist Konzepte, die die Bindung einer Serverinstanz an einen bestimmten RZ-Raum durch standortspezifische IP-Subnetze und davon abgeleitete Active-Directory-Standorte realisieren. So findet beispielsweise die AD-Replikation innerhalb eines Standorts stets sofort nach einer Änderung statt, zwischen den Standorten unterliegt sie einem Turnus und berücksichtigt die Qualität der Standortverbindungen. Weitere Beispiele für standortabhängiges Verhalten sind DFS (Priorisierung von Ordnerzielen) oder Exchange (Autodiscover, Mailrouting, Safety Net, Datacenter Activation Coordination).
Doch auch Loadbalancer können davon profitieren, zwischen unterschiedlichen Subnetzen für ihre "realen Server" unterscheiden zu können. Bei einer sauber konfigurierten Anwendungs-HA können die Applikationen also erkennen, dass nicht einfach nur eine beliebige Hälfte der Anwendungsserver vom Netz gegangen ist, sondern ein ganzer Standort. Auch die Authentifizierungsanforderungen an das Active Directory gehen nicht ins Leere, wenn ein anderer Standort als der eigene ausfällt, was für den flüssigeren Betrieb der AD-abhängigen Anwendungen sorgt.
Bei der Plattform-HA gibt es aus Sicht der virtualisierten Anwendungsserver nur einen Standort. In der Konfiguration der Virtualisierung und des Storage müssen die einzelnen Knoten zwar bestimmten Standorten zugewiesen werden, um die Datenreplikation und das Failover-Verhalten entsprechend der physischen Servertopologie zu lenken.
Dies geschieht meist durch Definition sogenannter Fault Domains (siehe [4] für VMware und [5] für Microsoft), die Zuweisung der Knoten zu Fault Domains ist jedoch den Administratoren vorbehalten. Falls Sie innerhalb einer hochverfügbaren Plattform Anwendungen unter Benutzung ihrer eigenen HA-Mechanismen bereitstellen, müssen Sie Vorkehrungen treffen, damit die anwendungseigene HA adäquat auf den Ausfall eines RZ-Standorts reagiert.
Der dritte Zwilling
Die meisten HA-Konzepte, ganz gleich auf welcher Ebene sie wirken, setzen auf eine Clustering-Logik, um auf Ausfälle einzelner Server zu reagieren. Die Algorithmen, nach denen jeder Server bestimmt, ob er seinen Dienst weiter verrichten oder einstellen soll, unterscheiden sich von Produkt zu Produkt. Alle Dienste, die zur Ausfallerkennung auf Microsoft-Cluster (Windows Server Failover Clustering, WSFC) setzen, bedienen sich eines auf Stimmenmehrheit basierenden Entscheidungsverfahrens.
Dieses ist in den modernen Windows-Server-Versionen mehrfach verfeinert worden, sodass Sie bei einem kontrollierten Herunterfahren alle Clusterknoten bis auf einen (und den Quorum-Zeugen) abschalten können, ohne dass das Cluster seinen Dienst einstellt. VMware hat eine andere Logik implementiert, nach der jeder Host versucht zu ermitteln, ob er andere Hosts, die Datenspeicher und bestimmte Punkte im Netzwerk erreicht. Mit vSphere 7.0U1 ist dieser Mechanismus um Cluster-Services-VMs erweitert worden, sodass jeder Cluster auch dann seine Vorgänge koordinieren kann, wenn das vCenter gerade ausgefallen oder nicht erreichbar ist.
Jeder dieser Mechanismen stellt Sie als RZ-Planer vor eigene Herausforderungen. Die auf Stimmenmehrheiten basierende Microsoft-Logik funktioniert sehr gut bei einem Ausfall einzelner Knoten. Geht jedoch ein ganzer RZ-Abschnitt gleichzeitig vom Netz, fehlt bei einer symmetrischen Verteilung der Knoten die Hälfte der Stimmen und das Überleben des Clusters hängt davon ab, ob der Quorumzeuge noch erreichbar ist.
Diese Logik hat VMware auch für vSAN Stretched Cluster übernommen – inklusive der dynamischen Stimmenzählung (geplant ab 7.0U3), sodass bei einem konsekutiven Ausfall eines RZ-Standortes und des Quorums der verbleibende Standort weiterhin den vSAN-Datastore zur Verfügung stellt. Die ausschließlich auf Erreichbarkeit beruhende Logik eines vSphere-Clusters scheitert dann, wenn die Netzwerkadressen, welche als "Beacon" eingetragen sind, vom ausgefallenen Rechenzentrum in Mitleidenschaft gezogen wurden.
Die größten Entscheidungsprobleme haben Cluster jeder Art jedoch zu bewältigen, wenn nicht einer der RZ-Standorte ausfällt, sondern lediglich die Verbindung zwischen den Standorten. Hier muss die Failover-Logik wirkungsvoll verhindern, dass ein Split Brain-Szenario entsteht, bei dem jeder Knoten der Meinung ist, dass er der legitime Überlebende eines Ausfalls ist und die Dienste weiter ausführt. In der Regel wird hier als Lösungsansatz ein dritter Standort empfohlen, der unabhängig vom übrigen Netzwerk an die produktiven RZ-Standorte angebunden ist und lediglich den Quorum-Zeugen beinhaltet.
Bei einer symmetrischen Knotenverteilung stellt Sie dieser Ansatz zunächst einmal vor ein Dilemma: Ist der Anschluss an das Quorum bei der Trennung der Querverbindung intakt, sehen beide Seiten das Quorum und sprechen sich damit die Stimmenmehrheit zu, sodass es zum Split-Brain-Phänomen kommt. Geht die Quorum-Verbindung mit der Heartbeat-Verbindung des Clusters zusammen offline, hat keine der Seiten eine Stimmenmehrheit und der gesamte Cluster geht offline.
Ein Ansatz, der hier mehr Erfolg verspricht, besteht darin, das Backend-Netzwerk des Clusters (Heartbeat und gegebenenfalls Datenreplikation) mit dessen Frontend- und Quorum-Netzwerk zusammenzulegen. Die Separation und Priorisierung des Traffics kann in diesem Fall durch VLANs und QoS erfolgen, aber der Ausfall einer Netzwerkverbindung wirkt sich auf Client- und Quorumzugriff gleichermaßen aus, sodass weder Split-Brain noch eine unerwartete Gesamtabschaltung des Clusters auftreten können.
Doch auch der strikt auf Erreichbarkeit basierende HA-Ansatz eines vSphere-Clusters bedarf beim Einsatz über RZ-Abschnitte hinweg einer sorgfältigen Behandlung. Hier wird über die Host-Isolation anhand der Zugriffe auf Datenspeicher entschieden. Bei einem klassischen, gespiegelten SAN kann es passieren, dass der Ausfall der Spiegelverbindung von den Hosts gar nicht erkannt wird. Folgt dann ein Ausfall der Querverbindung für das Managementnetzwerk, spielen die sogenannten Isolationsadressen die Rolle des Quorums – ist eine von ihnen erreichbar, gilt der Host als nicht isoliert und setzt seine Arbeit fort [6].
Auch hier gilt: Das Zusammenlegen (auf Hardware-Ebene) des Management- und des Frontend-Netzwerks kann für eine präzisere Erkennung von Ausfällen sorgen als die generelle Best-Practices-Empfehlung, diese Netzwerke voneinander zu trennen. Stellen Sie nach Möglichkeit pro RZ-Standort zwei Datenspeicher für Ihre vSphere-Cluster bereit, die nur in diesem Standort vorhanden sind und fixieren Sie den Hartbeat-Datastore auf diese. Dann wissen Ihre ESXi-Hosts genau, wenn sie isoliert sind, und können den Ausfall eines einzelnen Hosts dennoch korrekt behandeln.
Bild 3: Eine ungünstige Platzierung der Quorum-Leitung führt zu anderem Failover-Verhalten als beabsichtigt.
Das Beste aus beiden Welten
Beim Design Ihres RZ sollten Sie sich nicht zu früh darauf versteifen, einen der oben beschriebenen HA-Konzepte für alle Dienste und Anwendungen durchzusetzen. Einige Dienste (Lizenzserver, beispielsweise für RDS, oder Datenbanken, für die HA-Funktionen nicht lizenziert wurden) verfügen gar nicht über native HA-Mechanismen und würden von der Plattform-Hochverfügbarkeit immens profitieren.
Andere Anwendungen müssen vielleicht aus Gründen, die Sie nicht beeinflussen können, auf physischen Servern bereitgestellt werden, sodass Sie hier auf die Anwendungs-HA angewiesen sind. Bei allen anderen müssen Sie eine Entscheidung treffen, wobei der Hersteller-Support und das in Ihrem IT-Team vorhandene Know-how eine Rolle spielen. Diese Entscheidungen lassen sich sehr gut an Microsoft-Produkten illustrieren, deren native Hochverfügbarkeit auf "Availability Groups" basiert: Exchange und SQL.
Wenn Sie mehr als nur eine Handvoll Exchange-Postfächer hosten, ist eine Database Availability Group (DAG) praktisch Pflicht. Damit verdoppelt sich der Speicherplatz, den Sie für die Exchange-Daten bereitstellen müssen, schon auf der Anwendungsebene mindestens. Sie werden kaum davon profitieren, dass Sie ihn noch einmal verdoppeln, indem Sie die Postfachserver auf gespiegelten Datenspeichern laufen lassen.
Es kann also sinnvoll sein, die Postfachserver fest in den RZ-Abschnitten anzusiedeln und die Hochverfügbarkeit ausschließlich auf Anwendungsebene zu betreiben. Ein Hybrid-Exchange-Server für Ihre Office-365-Bereitstellung hingegen benötigt keine derartige Sonderbehandlung und lässt sich durchaus "schwebend" innerhalb einer hochverfügbaren Virtualisierungsplattform betreiben.
Eine häufige Designfrage bei der Kombination beider HA-Ansätze innerhalb einer Umgebung betrifft Domaincontroller für das Active Directory. Diese nehmen in der Regel wenig Ressourcen in Anspruch, können aber nicht unbegrenzt lange ausfallen. Hier erreichen Sie eine optimale Bereitstellung, indem Sie bestimmte IP-Subnetze zwar organisatorisch einem RZ-Standort widmen, sie jedoch technisch über die gesamte Virtualisierungsplattform spannen.
So können Domaincontroller und Systeme, die die Standort-Topologie im AD ignorieren, bei Ausfall oder Wartung eines RZ-Standorts umziehen. Systeme, die physisch an einen RZ-Standort gebunden sind, werden ihre Domaincontroller finden, auch wenn sie gerade im anderen Serverraum laufen. Sie müssen sich bei geplanter Wartung oder längerem Ausfall eines Standortes zudem nicht damit befassen, ob der aktuelle PDC Emulator oder RID Master gerade online ist.
Fazit
Bei der Planung Ihres hochverfügbaren, auf mehrere Abschnitte verteilten Rechenzentrums müssen Sie eine Balance zwischen Ausfallsicherheit, Komplexität und Betriebsfähigkeit finden. Setzen Sie sich bei der Planung mit den Eigenarten der technischen HA-Ansätze auseinander und designen Sie Ihr Rechenzentrum so, dass Sie von den technologischen Vorteilen der Plattform- und Anwendungs-Hochverfügbarkeit größtmöglich profitieren.