Cloud-Infrastruktur: Wann ist ein duales Rechenzentrum für Enterprise Anwendungen nötig?


In diesem Blogbeitrag erklären wir die wichtigsten Anforderungen an Business Continuity für Enterprise Clouds.

Für systemrelevante Organisationen wie Krankenhäuser oder Banken sowie deren Lieferanten gelten besondere Kriterien für den unterbrechungsfreien Betrieb: Sie müssen sehr schnell wieder einsatzbereit sein. In diesem Blogbeitrag geben wir Antworten auf die wichtigsten Fragen zum Thema Business Continuity für Cloud-Systeme und -Services für systemrelevante Organisationen.

Es ist heute üblich, dass sich Unternehmen darüber Gedanken machen, was es bedeutet, wenn IT- und Cloud-Dienste ausfallen und wie lange es dauert, bis die Systeme wieder einsatzbereit sind. Bei den Szenarien, die dabei entworfen werden, handelt es sich oft um unwahrscheinliche Ereignisse, wie etwa einen Flugzeugabsturz auf ein Rechenzentrum, der zu einem erheblichen Ausfall der Cloud-Dienste führen würde.

Je nach Geschäft und Organisation und dem betroffenen Service kann es durchaus akzeptabel sein, den Service erst innerhalb von bis zu einer Woche wiederherzustellen. In vielen Fällen können sich Organisationen aber selbst im Katastrophenfall keine langen Ausfallzeiten leisten und müssen so planen, dass ihre Dienste innerhalb von Stunden wieder laufen. In diesen Fällen bietet ein duales Rechenzentrum der Organisation eine schnelle Recovery-Lösung. 

Doch ab wann ist so eine Infrastruktur tatsächlich nötig? In diesem Blogbeitrag werfen wir einen Blick auf die wichtigsten Anforderungen an Business Continuity für Enterprise Clouds:

  1. Wie stellt man sicher, dass die Computing-Lösung z. B. mehr als 99,9 % der Zeit verfügbar ist?
  2. Wie schützt man sich vor Datenverlusten, z.B. wenn ein Speichermedium oder ein Server defekt ist?
  3. Wie können ungewollt gelöschte Daten wiederhergestellt werden?
  4. Wie kann ein kompletter Server wiederhergestellt werden?
  5. Wie können die geltenden KPIs (RPO / RTO) eingehalten werden?
  6. Wie kann der unterbrechungsfreie Betrieb innerhalb eines angemessenen Zeitraums sichergestellt werden, z. B. wenn ein Server ausfällt oder es einen Stromausfall gibt?
  7. Wie kann die Geschäftskontinuität im Falle einer grösseren Katastrophe sichergestellt werden, die ein ganzes Rechenzentrum betrifft (z. B. Überschwemmung, Feuer, Flugzeugabsturz)

In diesem Blog-Beitrag werden wir Antworten auf diese Fragen geben.

Wie Safe Swiss Cloud den unterbrechungsfreien Betrieb von geschäftskritischen Anwendungen sicherstellt.

Wie stellt man sicher, dass die Computing-Lösung zu mehr als 99,9 % der Zeit verfügbar ist?

Technisch gesehen ist Redundanz auf jeder möglichen Ebene die ideale Lösung. Das Ziel ist es sicherzustellen, dass Hardwaredefekte nicht zu einem Ausfall führen. Wenn Server beispielsweise über zwei unabhängige Netzteile verfügen, die unabhängig voneinander mit Strom versorgt werden, dann überlebt das System auch einen Defekt im Netzteil des Servers oder einen Ausfall in einer der Stromversorgungsleitungen. Das Gleiche gilt für Storage (siehe nächster Abschnitt), Netzwerk (Switches, Routers usw.), Internetverbindungen, Kühlung und viele weitere Komponenten.

Im Falle einer Enterprise Cloud Lösung, die von einem Anbieter wie Safe Swiss Cloud gehostet wird, kann ein Service Level Agreement (SLA) für die Verfügbarkeit für den benötigten Prozentsatz der Zeit (zum Beispiel größer als 99,9 %) abgeschlossen werden.

Wie schützt man sich vor Datenverlusten, z.B. wenn ein Speichermedium oder ein Server defekt ist?

Kann bei einem Defekt einer Speicherkomponente wie einer SSD oder eines Speicherservers das System ohne Unterbrechung weiterarbeiten? Die Lösung ist ein redundanter Speichercluster, z.B. mit Redundanz auf der Ebene der SSDs und auf der Ebene der Speicherserver. Wenn einige SSDs einen Defekt haben, läuft die Verarbeitung ohne Unterbrechung weiter, da die Daten von anderen Stellen im Cluster abgerufen werden. Gleiches gilt, wenn ein ganzer Speicherserver mit mehreren SSDs nicht verfügbar wäre.

Ein redundantes, geclustertes Speichersystem stellt sicher, dass …

  • keine Daten verloren gehen.
  • die Datenverarbeitung nicht unterbrochen wird.

Redundante, geclusterte Speichersysteme leisten dies, indem sie Daten mehrfach in einem Speichersystem speichern, so dass bei einem Defekt eines Teils des Speichersystems die Daten immer noch von einem anderen Teil des Systems zur Verfügung gestellt werden können und zwar ohne Betriebsunterbruch.

Wie können ungewollt gelöschte Daten wiederhergestellt werden?

Ein duales Rechenzentrumssystem allein schützt nicht vor gelöschten Daten: Die duale Datenlösung repliziert alles von einem Rechenzentrum zum anderen, einschließlich Löschungen oder möglicher anderer Datenprobleme, die z. B. aus Softwarefehlern resultieren.

Regelmäßige Backups der Daten sind notwendig, um allfällige Datenlöschungen oder Datenkorruption (z.B. als Konsequenz von Software Updates) beheben zu können. Alles, was von Benutzern unbeabsichtigt gelöscht wurde, kann aus den regelmässigen Backups wiederhergestellt werden. Backups müssen mindestens täglich auf einem unabhängigen Speichermedium erstellt werden. 

Ein zusätzliches Ziel eines Backups ist es, eine vollständige Wiederherstellung eines Servers zu ermöglichen, wenn der Server nicht mehr wie erwartet funktioniert, z. B. als Folge eines Software-Upgrades. 

Die Backup-Systeme der Safe Swiss Cloud etwa schreiben die Backup-Daten standardmässig in ein anderes Rechenzentrum als das, in dem der Computing-Workload läuft.

Wie kann ein kompletter Server wiederhergestellt werden?

Um der Gefahr vorzubeugen, dass ein Server nicht wie erwartet funktioniert, zum Beispiel nach einem Software-Upgrade, ermöglicht Safe Swiss Cloud den Kunden, einen „Snapshot“ des Servers zu erstellen. Wenn die Ergebnisse des Server-Upgrades nicht wie erwartet funktionieren, kann der Server mit ein paar Klicks sehr schnell aus dem Snapshot wiederhergestellt werden. 

Es ist wichtig, dass Snapshots einen zeit- und datenkonsistenten „Schnappschuss“ des gesamten Speichers auf einem Server darstellen – dies ist etwas, das von Backups allein nicht geliefert werden kann.

Wie können die geltenden KPIs (RPO / RTO) eingehalten werden?

Was ist die RPO (Return Point Objective)? Die RPO ist eine in Zeiteinheiten ausgedrückte Zahl, die besagt, dass man in der Lage ist den Zustand wiederherzustellen, in dem sich die Daten mindestens die RPO-Zeitspanne vor dem Auftreten eines Vorfalls befanden. Sie gibt an, dass im Falle eines ungünstigen Ereignisses nicht mehr als die im RPO-Zeitraum gesammelten Daten verloren gehen können.

Was ist die RTO (Return Time Objective)? Die RTO ist eine Zahl, welche die maximale Zeitspanne ausdrückt, die für die Wiederherstellung benötigt wird.

Im Allgemeinen wird dies durch eine Kombination aus regelmäßigen Backups und in einigen Fällen durch Snapshots erreicht. Bestimmte Anwendungen benötigen möglicherweise spezielle Verfahren, z. B. für die Wiederherstellung von Datenbanken. Wiederherstellungstests, insbesondere der größten Systeme, sind erforderlich, um realistische Schätzungen des RTO zu erhalten.

Wie kann die Geschäftskontinuität innerhalb einer angemessenen Zeitspanne sichergestellt werden, z. B. wenn ein Server ausfällt oder es einen Stromausfall gibt?

Die Lösung dafür ist einmal mehr ausreichende Redundanz, zumindest innerhalb desselben Rechenzentrums. Fällt ein Server aus, muss die Rechenleistung auf einen anderen Server übertragen werden. 

Im Falle eines Stromausfalls sollte der Server über eine redundante Stromversorgung verfügen, die automatisch übernimmt. 

Darüber hinaus sollten Rechenzentren über unterbrechungsfreie Stromversorgungen (USV) verfügen, die Spannungsschwankungen ausgleichen oder im Falle einer größeren Katastrophe dem Rechenzentrum Zeit geben, ihre Dieselgeneratoren zu starten, die in der Lage sein sollten, wochenlang unabhängig Strom zu liefern.

Wie kann die Business Continuity / Disaster Recovery im Falle einer grösseren Katastrophe, die das Hauptrechenzentrum betrifft (z. B. Überschwemmung, Flugzeugabsturz etc.), sichergestellt werden?

In diesem Fall ist eine duale Rechenzentrumslösung erforderlich. Typischerweise ist dies eine Anforderung für „systemrelevante“ Infrastruktur wie Krankenhäuser oder Banken. Diese Art von Kunden werden von ihren Aufsichtsbehörden aufgefordert, sicherzustellen, dass sie alle erforderlichen Schritte unternommen haben, um zu gewährleisten, dass ihre Rechenkapazitäten nach einem Ausfall aufgrund eines Katastrophenereignisses wie einer Naturkatastrophe (z. B. Überschwemmung), einer von Menschen verursachten Katastrophe (Flugzeugabsturz in ein Rechenzentrum) oder etwas Unvorhergesehenem innerhalb einer kurzen Zeit (der RTO) wieder betriebsbereit sind.

Als erster Schritt ist die Erkennung eines Katastrophenereignisses, das sich in der Regel in Form eines ausgefallenen Rechenzentrums manifestiert. Sobald ein Katastrophenereignis erkannt wurde, müssen Schritte unternommen werden, um sicherzustellen, dass die Datenverarbeitung in einem anderen Rechenzentrum fortgesetzt werden kann. 

Die wichtigen Überlegungen für einen Kunden, der eine Lösung mit zwei Rechenzentren plant, sind: 

  • Wie erfolgt die Synchronisierung der Daten mit einem Standby-Rechenzentrum? Wird diese durch das Cloud-System durchgeführt oder muss der Kunde die Synchronisation selbst einrichten? Geschieht dies synchron oder asynchron?
  • Wird das Ereignis manuell oder automatisch erkannt?
  • Erfolgt die Umschaltung auf das Standby-Rechenzentrum automatisch?

Die Vorteile einer Lösung mit automatischem Failover:

Safe Swiss Cloud betreibt eine Lösung mit zwei Rechenzentren, die Daten zwischen den Rechenzentren in Echtzeit synchronisiert: Wann immer ein Programm etwas in den Speicher schreibt, wird es synchron in beide Rechenzentren geschrieben. Ein Ausfall im primären Rechenzentrum wird vom Cloud-System automatisch erkannt und fährt alle Server des Kunden im Standby-Rechenzentrum automatisch hoch. 

Der große Vorteil dieser Lösung ist, dass die Server im neuen Rechenzentrum exakt die gleichen internen und externen IP-Adressen behalten, so dass keine manuellen Eingriffe in Form von Änderungen der DNS-Adressen oder anderer Konfigurationen notwendig sind. 

Fazit: 

Ein hohes Mass an Redundanz in einem einzigen Rechenzentrum ist ausreichend, um die Geschäftskontinuität für die meisten Computing-Workloads sicherzustellen. Dies bietet ausreichenden Schutz vor einem Defekt eines Computing-Servers, eines Storage-Servers, eines Speichermediums, von Stromversorgungen, Netzwerk-Switches, Routern und Internetverbindungen.

Für systemrelevante Unternehmen und Organisationen, die kurze Wiederherstellungszeiten garantieren müssen, ist eine duale Rechenzentrumslösung erforderlich, um eine Notfallwiederherstellung innerhalb kürzester Zeit zu gewährleisten und sicherzustellen, dass sie die Anforderungen ihrer Aufsichtsbehörden erfüllen. 

Dual Data Center Cloud

Zwei Rechenzentren garantieren höchste Verfügbarkeit für geschäftskritische Applikationen

Über den Autor

Prodosh Banerjee

Prodosh Banerjee

CEO | Geschäftsführer

Prodosh hat in den Bereichen Softwareentwicklung und IT-Betrieb für Unternehmen wie UBS, SWX Swiss Stock Exchange (jetzt SIX), Grapha Informatik, IBM Software Laboratories und Telekurs (jetzt SIX) in verschiedenen Rollen gearbeitet: Führungskraft, Projektmanager, Programmierer, Betriebsleiter.

Seine Ausbildung umfasst einen Master of Systems/Informatik (M.S.) sowie einen Bachelor of Science (B.Sc.) in Physik.

Sein Schwerpunkt lag auf Innovationen in der IT, um deren Anwendungsbereich von der Erfüllung interner Unternehmensanforderungen auf mehr digitale Interaktionen mit Kunden und Lieferanten zu erweitern. Seine Mission ist es, den Kunden die Vorteile der Informationstechnologie und Digitalisierung einfach nutzbar, schnell und zuverlässig zur Verfügung zu stellen.

Weitere Interessen: Jazz & Kunst

Auf LinkedIn verbinden

KONTAKT »

Schreiben Sie einen Kommentar

Diese Website verwendet Akismet, um Spam zu reduzieren. Erfahre mehr darüber, wie deine Kommentardaten verarbeitet werden.

Hinweis:
Sie können beim Kommentieren folgende HTML Tags und Attribute verwenden: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>