Projektinterview: Redundante Rechenzentren – Projekterfahrungen

Dr. Behrooz Moayeri ist seit 1988 bei ComConsult tätig. 1996 wurde er Prokurist bei der damaligen ComConsult Beratung und Planung GmbH und Anteilseigner. Während er sich anfangs mit Messungen und Fehlersuche beschäftigte, kam später die Konzeption und Planung von Netzen hinzu. Seit 2019 ist er Leiter der ComConsult Akademie bei der heutigen ComConsult GmbH. Daneben ist er Leiter des ComConsult Competence Centers Data Center und Cloud. Im Laufe der Jahre hat er mehrere Competence Center von ComConsult gegründet und an seine Nachfolger übergeben. Dazu zählen beispielsweise die Competence Center Tests und Analysen, IT-Sicherheit, Netze und Kollaborations- und Kommunikationslösungen. In diesem Interview berichtet Dr. Moayeri von seinen Erfahrungen aus Projekten, die er bei Kunden aus verschiedenen Branchen hinsichtlich Betriebsredundanz und Georedundanz für hochverfügbare Rechenzentren (RZ) gesammelt hat.

Behrooz, du arbeitest seit vielen Jahren in Projekten, bei denen es um die Redundanz von Rechenzentren geht. Was sind die Bestandteile und Funktionen eines Rechenzentrums, die bei der Standortredundanz abgesichert werden?

Ein wichtiger Punkt ist die Stromversorgung, die an den verschiedenen Rechenzentren möglichst unabhängig sein soll. Weiterhin müssen die Ressourcen abgesichert sein, die in einem Rechenzentrum betrieben werden. Das sind zum Beispiel Server, Speichersysteme, das Layer-2- und Layer-3-Netz, Provider-Anbindungen, Weitverkehrsanbindungen und Internetanbindungen. Doch auch Security-Komponenten wie beispielsweise Firewalls müssen voneinander unabhängig sein, damit ein Rechenzentrum auch ohne das andere Rechenzentrum lebensfähig ist und die Services und Applikationen unterstützen kann, die ein Rechenzentrum nutzt.

Welche Möglichkeiten haben Unternehmen bei der Standortwahl ihrer redundanten Rechenzentren?

Es gibt verschiedene Modelle. Das erste Modell kommt insbesondere bei Unternehmen aus der Industrie zur Anwendung, die ein größeres Areal zur Verfügung haben. Sie entscheiden sich dafür, auf ihrem Campus im Abstand von ein paar Kilometern ihre Rechenzentren zu platzieren und sie dort auf dem Gelände unabhängig voneinander zu betreiben. Beim zweiten Modell hat ein Unternehmen eines seiner Rechenzentren im eigenen Gebäude und ein weiteres Rechenzentrum betreibt es bei einem Anbieter, einer sogenannten Co-Location oder einem Housing-Anbieter. Oft ist das ein Zentrum, in dem viele Anbieter präsent sind, beispielsweise in Frankfurt am Main. Oder man entscheidet sich für andere Anbieter von Rechenzentrumsflächen, die die Anforderungen moderner Rechenzentren erfüllen. Das dritte Modell sieht vor, dass beide Rechenzentren bei Co-Locations oder externen Anbietern betrieben werden. Alle drei Modelle sind in den letzten Jahren in unseren Projekten zur Anwendung gekommen.

Erkläre bitte die Begrifflichkeiten Standortredundanz, Betriebsredundanz und Georedundanz.

Ich orientiere mich an einem Dokument des Bundesamtes für Sicherheit in der Informationstechnik (BSI) vom Herbst 2019, in dem die Begriffe erstmalig klar voneinander abgegrenzt wurden. Dieses Dokument nennt sich „Kriterien für die Standortwahl von Rechenzentren“. Ich interpretiere das Papier so, dass „Standortredundanz“ der Oberbegriff ist, der zwischen „Betriebsredundanz“ und „Georedundanz“ unterscheidet.

Bei der Betriebsredundanz steht der Aspekt der synchronen Datenreplikation im Vordergrund. Das bedeutet, dass zu jedem Zeitpunkt die Daten, die in zwei sich Redundanz gebenden Rechenzentren vorgehalten werden, absolut identisch sein müssen. Das führt dazu, dass die Entfernung zwischen zwei Standorten eingeschränkt ist, denn sonst funktioniert die synchrone Replikation der Daten nicht mehr.

Bei der Georedundanz steht der Aspekt im Vordergrund, dass möglichst viele regionale Desaster und Katastrophenfälle abgedeckt werden. Das BSI hat vorgegeben, dass die Georedundanz vor allem dann erfüllt ist, wenn die beiden Rechenzentren mindestens 200 Kilometer voneinander entfernt sind, wobei ich diesen Abstand als Luftlinie verstehe. In Ausnahmefällen kann auch eine Entfernung von 100 Kilometern möglich sein, wenn technisch unabweisbare Gründe dafür sprechen. Neben dieser wesentlichen Vorgabe gibt es noch ein paar andere Bedingungen für die Georedundanz, die in dem Dokument des BSI erwähnt werden. Das betrifft zum Beispiel die Lage der Rechenzentren in Bezug auf die verschiedenen Netzabschnitte der Stromversorgung, die Erdbebenzonen und die Lage der Rechenzentren in Bezug auf sogenannte Flusssysteme und somit auf mögliches Hochwasser.

Bei der Betriebsredundanz steht der Aspekt der synchronen Datenreplikation im Vordergrund. Was sind die Vor- und Nachteile?

Bei der Betriebsredundanz werden die Daten bei jeder Transaktion sofort repliziert. Daten werden ja in Schreibvorgängen verändert. Wann immer eine Applikation beziehungsweise ein User einen Bestandteil der Daten eines Rechenzentrums verändert, wird diese Änderung unmittelbar zum anderen Rechenzentrum repliziert. Die Bestätigung der Änderung erfolgt beispielsweise in einer Datenbank erst dann, wenn die Replikation zwischen den RZ-Standorten im Hintergrund abgeschlossen und korrekt ist. Dies verlängert natürlich die Antwortzeit jeder Transaktion. Deshalb sind bei der Betriebsredundanz der Entfernung zwischen den Rechenzentren relativ enge Grenzen gesetzt. Bei den meisten Applikationen kann man von maximal 100 Kilometern Kabelstrecke ausgehen, was natürlich eine noch kürzere Distanz in der Luftlinie bedeutet.

Bei der Georedundanz kommt das Verfahren der asynchronen Replikation zum Einsatz?

Das ist korrekt. Bei der Georedundanz werden in regelmäßigen Abständen in einem bestimmten Raster von zum Beispiel fünfzehn Minuten Daten repliziert ohne Rücksicht auf die Online-Transaktionen. Das bedeutet, dass zwischen zwei Replikationen im Falle eines ungeplanten Ausfalls ein Teil der Daten beim überlebenden Rechenzentrum nicht mehr auf dem neuesten Stand ist und damit aktuelle Daten verloren gehen. Deshalb sagte ich ja eben schon, dass bei der Georedundanz der Fokus auf der Abdeckung von möglichst vielen Schadensfällen liegt und nicht auf dem Aspekt der absoluten Datentreue, also der Erhaltung sämtlicher Daten.

Welche Unternehmen entscheiden sich für das Modell Betriebsredundanz?

Es gibt Unternehmen, für die der Aspekt der Datenkonsistenz allerhöchste Priorität hat. Insbesondere gilt das für Banken und Versicherungen. Für diese Unternehmen kann Datenverlust existenzgefährdend sein. Daher entscheiden sich die meisten Unternehmen der Finanzbranche zumindest für Betriebsredundanz. Ob darüber hinaus an einem dritten Standort auch noch Georedundanz realisiert wird, ist von Unternehmen zu Unternehmen unterschiedlich.

Für welche Unternehmen ist das Modell Georedundanz unerlässlich?

Wenn beispielsweise ein Unternehmen, das weltweit Services anbietet, keine georedundanten Rechenzentren betreibt, kann das dessen Existenz bedrohen. Nehmen wir den Betreiber einer Suchmaschine, die unbedingt – um einen hohen Umsatz konstant aufrechtzuerhalten – in möglichst vielen Regionen der Welt ständig verfügbare Dienste anbieten muss. Das ist jetzt ein Extrembeispiel. Es gibt auch andere Beispiele von öffentlichen Auftraggebern, die sich zusammenschließen, um kommunale Rechenzentren georedundant auszulegen. Historisch kann man sich das so vorstellen, dass kommunale Verwaltungen – zunächst in einer relativ kleinen Region – im Zusammenschluss Rechenzentren gegründet haben. Mit der Zeit haben diese kommunalen Rechenzentren als teilweise Betreiber von kritischen Infrastrukturen ihre Rechenzentren zusammen georedundant ausgelegt, um Ausfällen, die durch Vorfälle wie Überflutung, Überschwemmung, größere Stromausfälle und so weiter entstehen, vorzubeugen.

Gibt es Organisationen, die sich für beides entscheiden: permanente Datenkonsistenz und Absicherung gegen Großereignisse?

Es gibt Unternehmen, die sowohl Betriebsredundanz als auch Georedundanz für ihre Rechenzentren benötigen. Die Lösung dafür kann nur ein Verbund von mindestens drei Rechenzentren sein. Das heißt, zwei Rechenzentren müssen so nah beieinanderliegen, dass eine synchrone Datenreplikation möglich ist. Zusätzlich muss es noch einen dritten Standort geben, der so weit von den beiden synchronen Rechenzentren entfernt ist, dass die Bedingungen der Georedundanz erfüllt sind. Ein Beispiel ist ein Unternehmen, das zur Realisierung der Betriebsredundanz zwei Rechenzentren im Flusssystem des Rheins betreibt. Möchte das Unternehmen von einem möglichen Hochwasser des Flusssystems Rhein unabhängig sein, könnte das Unternehmen in Erwägung ziehen, einen weiteren georedundanten Standort zum Beispiel im Flusssystem Donau zu betreiben.

Das BSI macht keine Vorgaben, welches Redundanzmodell Unternehmen für ihre Rechenzentren wählen sollen.

Das ist richtig. Das BSI empfiehlt in dem eingangs erwähnten Dokument, dass jedes Unternehmen eine Risikoanalyse durchführen soll. Im Ergebnis dieser Analyse steht dann fest, ob das Kriterium der Datenkonsistenz oder das der Abdeckung möglichst vieler Schadensfälle für das Unternehmen unerlässlich ist. Wie gesagt kann es durchaus sein, dass beide Gesichtspunkte für ein Unternehmen höchste Priorität haben.

Wie läuft die Risikoanalyse ab?

Die Risikoanalyse wird zum Beispiel von meinen Kolleginnen und Kollegen aus dem ComConsult Competence Center IT-Sicherheit durchgeführt und muss korrekt und gewissenhaft umgesetzt werden. Es gibt ein Regelwerk dazu, wie man solche Risikoanalysen gestaltet. Wir analysieren die Wahrscheinlichkeit von Risiken und halten das Ausmaß der Schäden fest, wenn solche Risiken eintreten. Aus der Kombination von der Wahrscheinlichkeit der Risiken und des Ausmaßes der Schäden erfolgt eine Gewichtung der Risiken in einer Matrix. Für die Risiken, die hoch gewichtet sind, weil sie sehr wahrscheinlich sind oder größere Schäden verursachen, müssen Abhilfemaßnahmen getroffen werden. Die Risiken, die nicht so hoch gewichtet sind, können als Restrisiko übernommen werden.

Nach Vorlage der Risikoanalyse entscheidet sich das Unternehmen dann zum Beispiel für Betriebsredundanz. Die in der Analyse aufgezeigten Restrisiken, die wegen der fehlenden Georedundanz verbleiben, werden vom Unternehmen übernommen. Wir haben beispielsweise ein Projekt gehabt, in dem bei unserem Kunden die Betriebsredundanz zwischen zwei Rechenzentren realisiert wurde, die zum einen so weit voneinander entfernt waren, dass Stromversorgung, Klimatisierung und viele andere Aspekte unabhängig voneinander gestaltet werden konnten und zum anderen die Rechenzentren so nah beieinanderlagen, dass eine Datenreplikation möglich war. Damit befassten sich dann in diesem Projekt die Kolleginnen und Kollegen vom Competence Center Infrastrukturen.

Mit welchen Konsequenzen muss ein Unternehmen rechnen, wenn es seine Rechenzentren nicht redundant betreibt?

Wir hatten einmal ein Projekt, bei dem bei einem größeren Rechenzentrum das Problem darin bestand, dass die Services, die die Rechenzentren nutzten, ohne Rücksicht auf die Redundanz der Rechenzentren positioniert wurden. Alle Domain-Controller des Active Directory waren aufgrund der fehlenden Kommunikation zwischen den zuständigen Abteilungen nur in einem der Rechenzentren betrieben worden. Und dieses Rechenzentrum ist aufgrund eines technischen Fehlers bei einem der beteiligten Systeme ausgefallen. Folglich waren auch alle Domain-Controller des Unternehmens ausgefallen, und es funktionierten sämtliche Remote-Einwahlen und vieles andere nicht mehr. Das Unternehmen war also weitgehend arbeitsunfähig. Deshalb muss man sowohl die Ressourcen als auch die Dienste, die diese Ressourcen nutzen, im Zuge eines Projektes gesamtheitlich betrachten und Abläufe vorsehen, die diese allumfassende Betrachtungsweise sicherstellen.

Bei einem Projekt mit einem öffentlichen Auftraggeber war die Frage, ob die synchrone oder asynchrone Replikation für seine Rechenzentren die richtige Lösung ist. Wie war die Situation?

Der Kunde hatte hohe Anforderungen an den physikalischen Schutz seiner beiden Rechenzentren. Die Anforderungen an die Sicherheit und den personell abgesicherten Schutz der Rechenzentren waren so hoch, dass die Standorte im Prinzip schon festgelegt werden mussten. Die Organisation hat hier die relativ ungewöhnliche Vorgehensweise gewählt, dass Applikation für Applikation geprüft wurde, ob eine synchrone Replikation möglich ist. Wo das nicht möglich war, hat man sich für asynchrone Replikation entschieden.

Der RZ-Standort einer Bank befand sich in einem Gebäudekomplex des Bürostandortes, der geräumt werden musste. Wie verlief das Projekt?

In dem Bestandsrechenzentrum, das sich in einem Bürogebäude befand, entsprachen Energieeffizienz und in dem Zusammenhang die Kühlung, der physikalische Schutz und andere Aspekte nicht mehr dem Stand der Technik. Also musste dieses Rechenzentrum entweder vollständig renoviert oder geräumt werden. Der Kunde hatte sich für die Räumung entschieden. Eine solche Räumung geht nicht über Nacht. Es wurden zwei Rechenzentren bei einem Co-Location-Anbieter gemietet. In einer Übergangszeit mussten drei Rechenzentren betrieben werden. Teilweise wurden Ressourcen wie Server, Storage-Systeme und Netzkomponenten in den neuen Rechenzentren neu beschafft und installiert. Doch einige der Ressourcen, die im alten Rechenzentrum betrieben wurden, waren noch nicht so alt, dass das Ende ihres Lebenszyklus absehbar gewesen wäre. Also mussten diese Ressourcen verlagert werden. Wir haben dafür die Umzugsplanung übernommen und dabei die aus dem alten Rechenzentrum zu verlagernden Ressourcen inventarisiert und die Vorgehensweise und den Ablauf für den Umzug am Wochenende geplant und festgelegt.

Welche Besonderheiten gibt es bei Versicherungsunternehmen?

Eine wichtige Besonderheit bei Versicherungsunternehmen ist, dass sie Verträge haben, die Jahrzehnte zurückliegen und den damaligen gesetzlichen Vorschriften entsprechen. Deshalb ist für Versicherungen typisch, dass sie Applikationen verwenden, die vor vielen Jahren nach den damals gültigen Gesetzesvorgaben entwickelt und geschrieben worden sind und weiter betrieben werden müssen. Viele dieser Applikationen wurden auf der Basis der damaligen Systeme entwickelt, zum Beispiel Großrechner beziehungsweise Mainframes, und unter Anwendung von Entwicklungsumgebungen und Programmiersprachen wie Cobol, die man heute neu nicht mehr einsetzt. Viele Versicherungsunternehmen, die ich kenne, nutzen noch solche Programme und Großrechner. Bei den Banken ist das ähnlich, wobei sich die Banken weitgehend zusammengeschlossen haben und solche Großrechner nutzen, die in Verbundrechenzentren betrieben werden. Die Versicherungen sind teilweise außerhalb solcher Verbundsysteme und sind Unternehmen, die eigenständig arbeiten und deshalb ihre Großrechner selber betreiben müssen. Die besondere Schwierigkeit bei den Versicherungsunternehmen ist, dass manchmal die Expertise nicht mehr da ist, weil die Mitarbeiter, die sich noch mit Mainframes und den Applikationen darauf ausgekannt haben, in Rente gegangen sind. Hinzu kommt, dass die Versicherungen, die Großrechner betreiben, lieber auf Nummer sicher gehen und diese, auch wenn sie standortredundant ausgelegt werden, nicht so weit voneinander platzieren, wie es eigentlich hinsichtlich der Abdeckung der Schadensfälle geboten wäre.

Dienstleister ohne große Gelände verlagern zunehmend ganze RZs in redundante Co-Locations. Warum?

Wenn man zwei Rechenzentren im selben Gebäude betreiben muss, weil man kein großes Gelände hat, können diese keinesfalls die Anforderungen von Betriebsredundanz und auch Georedundanz erfüllen. Das Gebäude hat zum Beispiel eine bestimmte Anbindung an Providernetze und Stromnetze, es hat keine sehr große Netzersatzanlage für Strom wie Dieselaggregate und es muss hin und wieder saniert werden. Viele solcher Unternehmen ohne große Gelände sind in gefragten und teuren Gegenden wie in Zentren von Großstädten ansässig, wo die wirtschaftlichste Nutzung einer Gebäudefläche nicht unbedingt ein Rechenzentrum ist. Deshalb werden solche Rechenzentren in vielen Projekten durch Flächen, die bei Co-Location-Anbietern außerhalb oder am Rande der Städte platziert werden, abgelöst.

Warum müssen Projekte zur RZ-Standortredundanz interdisziplinär sein?

Diejenigen Personen, die technische Entscheidungen vorbereiten und Vorlagen für technische Entscheidungen ausarbeiten, müssen in Projekten zur RZ-Standortredundanz einen Überblick über ganz verschiedene Aspekte haben. Dazu zählen beispielsweise Server-Cluster, Storage-Cluster, Cluster von Sicherheitskomponenten, Gestaltung von Layer-2- und Layer-3-Netzen und die Anbindung an Provider-Netze. Diese Expertise bekommt man nur, wenn man in Projekten, die sich mit diesen Themen befassen, jahrelang tätig gewesen ist. Daher ist RZ-Standortredundanz ein typischer Fall einer Aufgabenstellung für Experten, die einen Gesamtüberblick über alle diese Faktoren gewonnen und praktische Erfahrung diesbezüglich gesammelt haben.