Ausfallsicherheit per Cloud

Doppelt hält besser

13. November 2019, 7:00 Uhr | Hans Berndl

Wer ein Rechenzentrum betreibt, kann aus verschiedenen Gründen dazu gezwungen sein, seine Infrastruktur doppelt zu betreiben, um zum Beispiel auch im Katastrophenfall seine Geschäfte unterbrechungsfrei fortführen zu können. Allerdings überlegen mittlerweile viele Unternehmen, aus Kosten- und Effizienzgründen auf Infrastrukturen in der Cloud zu setzen. Dabei geht es häufig auch um die Auslagerung geschäftskritischer Anwendungen. Unternehmen sollten genau hinschauen, um beim Cloud-Partner ihres Vertrauens zu landen.

Mit Blick auf den Cloud-Provider sollten Unternehmen die gleichen Ansprüche stellen, die sie in der Vergangenheit auch an ihre höchstverfügbaren und georedundanten Rechenzentren gestellt haben. Die meisten dieser Ansprüche basieren auf den verschiedenen rechtlichen Vorschriften, darunter solchen, die eine permanente Verfügbarkeit und Nachvollziehbarkeit von Finanztransaktionen vorsehen. Dazu hat das Bundesamt für Sicherheit in der Informationstechnik (BSI) schon vor langer Zeit einen Kriterienkatalog erarbeitet, der Anforderungen an Rechenzentren im Hinblick auf Standortwahl, Latenzzeiten und andere Faktoren präzisierte.

Der ursprüngliche Forderungskatalog des BSI definierte den Abstand zweier Rechenzentren als Sicherheitskriterium. Da eine Katastrophe bei zu geringer Distanz beide redundante Rechenzentren in Mitleidenschaft ziehen kann, ging das BSI von einem Minimalabstand von rund fünf Kilometern aus. Diese Entfernung errechnet sich aus dem dreifachen Evakuierungs- und Sperrradius bei Bombenfunden aus dem zweiten Weltkrieg, der rund 1.500 Meter beträgt. Denn liegen die Rechenzentren näher zusammen, befinden sie sich gegebenenfalls in der gleichen Sperrzone, was beide im Katastrophenfall unerreichbar macht.

Auch für den maximalen Abstand formulierte das BSI damals eine Empfehlung: So sollte eine Entfernung von bis zu 50 Kilometern ausreichend für den Abstand zweier Rechenzentren sein. Diese Distanz ergab sich aus der Überlegung, dass übertragungstechnische Aspekte meist schon natürliche Grenzen für die Entfernung setzen. Außerdem gingen die Autoren dieser Richtlinien davon aus, dass mit Ausnahme von massiven kriegerischen Handlungen kaum ein Schaden eine derart große Fläche betrifft.

Alte Empfehlungen über Bord geworfen

Mittlerweile haben Experten diese ursprünglichen Empfehlungen allerdings überarbeitet. Denn haben die verantwortlichen Fachkreise bislang die Wahrscheinlichkeit des gemeinsamen Ausfalls beider Rechenzentren durch lokale Ereignisse geringer eingeschätzt, hat sich diese Annahme unter den aktuellen Entwicklungen geändert. So hat das BSI im Dezember 2018 beispielsweise seine Empfehlungen für die Mindestentfernung zwischen Rechenzentren angehoben. In seiner Veröffentlichung über die "Kriterien für die Standortwahl höchstverfügbarer und georedundanter Rechenzentren" (Standort-Kriterien HV-RZ in der Version 1.0), spricht das Bundesamt heute anstelle der ursprünglichen fünf nun von 200 Kilometern.

Grund dafür ist, dass es "im Blick in die Vergangenheit nicht möglich ist, zukünftige potenziell schädliche Situationen und Ereignisse ausreichend sicher vorauszusagen". Dort, wo der Gesetzgeber oder Regulator eine Redundanz vorschreibt, kann das Unternehmen, das die Rechenzentren betreibt beziehungsweise nutzt, im Einzelfall auch deutlich geringeren Abstände einhalten - die Notwendigkeit dafür es muss allerdings schriftlich darlegen und einer Risikoanalyse unterziehen. Diese veränderten Empfehlungen schlagen sich natürlich auch auf den laufenden Betrieb von re-dundanten RZ-Strukturen nieder. So erhöht sich durch die größere Entfernung auch die Latenz, die Betreiber in Kauf nehmen müssen. Dies äußert sich nicht nur bei der synchronen Spiegelung von Datenbeständen, sondern bereits bei der Anfertigung von Backups oder Snapshots.

LL11F02b Exoscale_Screenshot Zonenauswahl_online
Der Administrator wählt bei Nutzung von Cloud-Services die gewünschte Failover-Zone per Web-Interface aus. Bild: A1 Digital

Wo ist unter diesem Aspekt eine synchrone Spiegelung der Daten sinnvoll? Hier gibt es zwei Argumente. Keine Wahl bleibt einem Unternehmen, wenn der Gesetzgeber eine Spiegelung vorschreibt. Dies trifft besonders im Umfeld von Banken, Versicherungen und Finanzdienstleistern zu, für die die Bundesanstalt für Finanzdienstleistungsaufsicht (BaFin) entsprechend strenge Regeln für den Betrieb von IT-Infrastrukturen formuliert hat.

Das zweite Argument ist die Abwägung der Kosten. Denn eine permanente Datenspiegelung ist nicht nur grundsätzlich bereits ein teures Unterfangen. Da bei jeder Transaktion gleichzeitig eine Spiegeltransaktion stattfindet, verdoppelt sich zudem der Aufwand. Zusätzlich verlängert sich die Transaktion, da sie aus zwei anstelle nur eines Schritts besteht. Dies kann je Transaktion zu einer Wartezeit führen, die beispielsweise gerade bei der Interaktion mit Kunden eines Internet-Shops nicht mehr innerhalb einer tolerierbaren Zeitspanne liegt. So muss man Ressourcen hinzufügen, um auch in einem solchen Fall hohe Performance zu gewährleisten. Dem wiederum stehen möglicherweise kalkulatorische Verluste für einen Zeitraum gegenüber, an dem das System nicht verfügbar ist. Übersteigt der für den Katastrophenfall errechnete Verlust die Kosten für die Spiegelung, ist aus Gründen der Risikominimierung eine ständige Synchronisation die bessere Wahl.

Kosteneffiziente Alternative

Eine Alternative zum kontinuierlichen Parallelbetrieb ist die Sicherung des Datenbestands in engen Zeitabschnitten. Hier kann der RZ-Betreiber per Delta-Sicherung lediglich den veränderten Datenstand seiner zwei Datenbestände in einem kompletten und daher komprimierbaren Backup-Lauf abgleichen. Granular steuern kann das Unternehmen seinen Informationsabgleich über die Wahl der Zeitabschnitte, in denen die Sicherung erfolgt, sowie über die Priorisierung der verschiedenen Bereiche, wie oft wo ein Backup stattfindet. Natürlich sind stets auch Mischformen zwischen einem zyklischen Backup und einer Spiegelung einiger ausgewählter Bereiche möglich.

Dazu bietet sich CDP (Continuous Data Protection) an, auch als Contiuous Backup oder Real-Time Backup bekannt. Dieses Verfahren stellt eine inkrementelle Datensicherung dar. Im Gegensatz zum herkömmlichen Backup, das man zu einem spezifischen Zeitpunkt anlegt, ist hier eine Rücksicherung unabhängig von einem bestimmten Zeitpunkt möglich. Das System erkennt automatisch, welche Daten verändert wurden, und stellt diese wieder her. Aufgrund dieser Flexibilität kommt CDP insbesondere beim Online-Backup zum Zuge. Eine Mindestbandbreite ist allerdings auch hier Voraussetzung.

Attraktivität der Cloud

Da ein solcher redundanter Betrieb einem Unternehmen einiges an Administrationsaufwand abverlangt, sollte man einen externen Dienstleister hinzuziehen. Cloud-Dienstleister eignen sich hier perfekt als Partner für den Betrieb der RZ-Infrastruktur. Allerdings sollten Unternehmen bei der Wahl ihrer Cloud-Provider großen Wert darauf legen, dass der Anbieter über verschiedene Standorte verfügt und seine Rechenzentren eine für den Krisenfall ausreichende Entfernung aufweisen. Da eine permanente Spiegelung im Regelfall ein hohes Maß an Traffic verursacht, kann dies die Kosten für die Spiegelung je nach Cloud-Anbieter bedeutend in die Höhe treiben.

IT-Organisationen müssen sich darüber hinaus Gedanken machen, wie sie die dauerhafte Spiegelung ihrer Datenbanken technisch bestmöglich umsetzen. Für gewöhnlich liefern IaaS-Anbieter (Infrastructure as a Service) lediglich das technische Fundament, die Realisierung der Spiegelung nehmen die Nutzer selbst vor. Dies ist dem Umstand geschuldet, dass beim Ausfall des Rechenzentrums die jeweilige Applikation des Nutzers in der Lage sein muss, kurzfristig mit einer anderen IP-Adresse - also einem anderen Rechenzentrum - zu interagieren.

Dieser Schritt kann jedoch nur auf dem Applikations-Layer erfolgen - dem Cloud-Provider sind dabei die Hände gebunden. Der Anwender sollte daher auf jeden Fall darauf achten, dass bereits bei der Anwendungsentwicklung der zu synchronisierenden Kernanwendung eine Schnittstelle für eine weitere Applikation implementiert wurde. Die einzige Aufgabe dieser Applikation ist es, stetig zu prüfen, ob das primär genutzte Rechenzentrum erreichbar ist. Dies kann mittels eines einfachen Pings erfolgen, der in regelmäßigen Intervallen erfolgt - die Zeitabstände kann man individuell wählen, abhängig davon, welche Folgen ein Ausfall nach sich ziehen würde.

Ist das Rechenzentrum nicht erreichbar, muss die Kernanwendung folglich in der Lage sein, automatisiert und ohne Zutun eines Administrators auf die Fallback-Infrastruktur - eine Fallback-Zone im Sinne einer Multi-Zoning-Architektur - zu wechseln, um den Failover möglichst reibungslos zu gewährleisten.

Hans Berndl ist Senior Product Owner Exoscale bei A1 Digital, www.a1.digital.


Lesen Sie mehr zum Thema


Jetzt kostenfreie Newsletter bestellen!

Weitere Artikel zu Lacie

Weitere Artikel zu saperion AG

Matchmaker+