Suche
Sprachen
<
Webcast auf Abruf
19 min

Maßnahmen zur Geschäftskontinuität für vielfältige Datensätze

Sandro Lima

Leiter Technische Geschäftsentwicklung

DataCore Software

Daten sind Ihr wichtigstes Kapital, doch jeder Datensatz erfordert ein anderes Schutzniveau. Wenn Sie in Ihrem Geschäftskontinuitätsplan alle Daten gleich behandeln, kann dies zu Risiken und finanziellen Kosten für das Unternehmen führen. Doch wie lässt sich ein flexibler Datenschutzprozess über verschiedene Speicheranbieter und -architekturen hinweg umsetzen?

Erfahren Sie, wie DataCore Sie bei dieser Herausforderung unterstützen und Ihren wichtigsten Daten den erforderlichen Schutz bieten kann.

Präsentation herunterladen

Transkript des Webcasts

Sandro Lima: Mein Name ist Sandro Lima, ich bin Leiter der Abteilung „Technical Business Development“ bei DataCore Software. Heute werden wir darüber sprechen, wie DataCore Ihnen dabei helfen kann, vielfältige Datensätze in Ihre Geschäftskontinuitätsmaßnahmen einzubinden. Wir haben hier einige interessante Inhalte vorbereitet, also lassen Sie uns gleich loslegen. In Ordnung. Es macht wohl keinen Sinn, extra zu betonen, wie wichtig kritische Daten sind, oder? Aber Tatsache ist, dass Sie nicht alle Daten gleich behandeln und ihnen in Ihren Business-Continuity- und Disaster-Recovery-Plänen die gleiche Bedeutung beimessen können. Sie müssen also die potenziellen Auswirkungen und die mit jedem Datensatz verbundenen Risiken verstehen, um für jeden einzelnen das angemessene Schutzniveau zu gewährleisten.

Und aus Sicht der Datenspeicherung ist der einzige Weg, dies zu erreichen, über ein breites Spektrum an Funktionen zu verfügen, die Ihnen diesen angemessenen Datenschutz bieten, nicht wahr? Je nach den RTO- und RPO-Anforderungen Ihrer Daten. Ich werde [unverständlich 0:01:27] näher auf jede dieser – oder einige dieser – Funktionen eingehen, aber zunächst möchte ich nur einige der Herausforderungen hervorheben, denen Sie möglicherweise gegenüberstehen, wenn Sie versuchen, diese breite Palette an Funktionen in Ihrer gesamten Speicherinfrastruktur zu implementieren.

Problem: Mehrere Speicheranbieter

Das erste und sehr häufige Problem ist also, dass mehrere Speicheranbieter im Einsatz sind. Es ist also nicht ungewöhnlich, dass ein Unternehmen zwei oder mehr verschiedene Anbieter von Speicher-Arrays hat, und dabei ist es so, dass jeder von ihnen unterschiedliche Funktionen bietet und sie meistens nicht miteinander kommunizieren. Das führt dazu, dass selbst wenn sie – beispielsweise in diesem Beispiel – dieselbe Funktion bereitstellen können, stellen Sie sich vor, Sie hätten Anbieter eins, zwei und drei, die alle beispielsweise Snapshot anbieten – und selbst dann haben sie unterschiedliche Konfigurationen und Schnittstellen, sodass Sie letztendlich drei verschiedene Prozesse erstellen und diese in Ihrem BCDR-Plan separat behandeln müssen. Das erhöht also nur die Komplexität.

Problem: Unterschiedliche Speichermodelle

Die zweite Herausforderung [die ebenfalls sehr häufig auftritt] sind also unterschiedliche Speichermodelle. Es gibt Unternehmen, die traditionelle Speicher-Arrays nutzen, die über SANs – Storage Area Network – verbunden sind; es gibt Unternehmen, die eher auf ein [konvergentes] Modell setzen und Direct Attach sowie internen Speicher nutzen; manche Unternehmen setzen auf Hyperkonvergenz oder Lösungen mit sehr geringem Platzbedarf und einfacher deployment, aber was wir in unserem Kundenstamm sehr häufig beobachten, ist ein hybrides Szenario, bei dem Unternehmen alle möglichen unterschiedlichen Modelle nutzen, einschließlich cloud bestimmte Archivierungszwecke oder zur Notfallwiederherstellung. Wenn man also verschiedene Speicheranbieter mit unterschiedlichen Speichermodellen kombiniert, wird deutlich, wie komplex es für Sie wird, all diese Funktionen in Ihrer gesamten Speicherinfrastruktur bereitzustellen.

Aber damit ist es noch nicht getan. Selbst wenn Sie also einen gut durchdachten und gründlich getesteten BCDR-Plan erstellen, ändert sich Ihre Umgebung ständig. Während der gesamten Lebensdauer Ihres Rechenzentrums finden also technologische Erneuerungen statt, nicht wahr? Sie beziehen also neue Anbieter, neue Architekturen und neue Technologien ein. Sie müssen sich mit Fusionen und Übernahmen auseinandersetzen, und dann müssen Sie – plötzlich – andere Anbieter, Architekturen, [Personal-]Abläufe und alles andere integrieren und einbinden. Es kann zu Veränderungen im Rechenzentrum kommen, sei es durch einen physischen Umzug oder eine Erweiterung. Vielleicht möchte Ihr Unternehmen cloud für die Replikation und die Notfallwiederherstellung nutzen. Und diese Liste lässt sich endlos fortsetzen, nicht wahr? Der Punkt ist also: Die Dinge ändern sich ständig, und Ihr BCDR-Plan muss flexibel genug sein, um diesen Veränderungen im Laufe der Zeit Rechnung zu tragen.

Lösung: DataCore

In Ordnung. In diesem Szenario haben Sie also verschiedene Anbieter, unterschiedliche – verschiedene Anbieter, unterschiedliche Speichermodelle und eine sich ständig verändernde Umgebung. Wie können Sie also dennoch unser Ziel erreichen, diese breite Palette an Funktionen konsistent über Ihre gesamte Speicherinfrastruktur hinweg verfügbar zu haben? Wir bei DataCore sind der Überzeugung, dass alles damit beginnt, über eine einzige Plattform ein sehr umfassendes Angebot an [fortschrittlichen] Diensten bereitzustellen. Und genau das bietet DataCore, nicht wahr? Wir verfügen über synchrone Spiegelung, synchrone Replikation, kontinuierlichen Datenschutz – worüber wir gleich noch sprechen werden –, snapshots viele weitere dieser für Unternehmen entwickelten Datendienste, die sich auf sehr einheitliche Weise in Ihrer gesamten Speicherinfrastruktur bereitstellen lassen. Und mit dieser Plattform können Sie jede Art von Speicher integrieren und einbinden – Direct-Connect, SAN –, wie Sie unten sehen können: Wir haben ISCSI, Fibre Channel, NVME, direkt angeschlossene Speicher sowie cloud, richtig?

Und ganz oben, wo [Sie] die Endnutzer sehen, können wir diesen Speicher für verschiedene Host-Typen bereitstellen – von Finanzdienstleistungen über Hypervisoren bis hin zu virtuellen Maschinen und Containern. Das ist also der erste Schritt: diese breite Palette an Datendiensten über eine einzige Plattform verfügbar zu machen. Ein zweiter Schritt, der genauso wichtig ist wie der erste, ist das deployment , und genau hier ermöglicht die „Software-Defined“-Architektur, dass DataCore wirklich in jedem Modell eingesetzt werden kann. Wir können DataCore also als Speichercontroller für Primär- und Sekundärspeicher in einem hyperkonvergenten Szenario einsetzen; Sie können es in der cloud oder an einem Disaster-Recovery-Standort installieren – es spielt also keine Rolle, welches Modell Sie heute haben oder in Zukunft planen: Wir können jeden Anbieter unterstützen, den Sie derzeit oder in Zukunft nutzen, und Sie können dies mit DataCore umsetzen.

Und nun sehen wir ein Bild davon, was ich [gezeichnet] habe: Im Grunde genommen geht es darum, über Ihr gesamtes Rechenzentrum hinweg über ein einheitliches Angebot an [umfassenden] Diensten zu verfügen. Sie können sich nun wahrscheinlich vorstellen, wie dies Ihre Prozesse sowie die Gestaltung Ihrer Pläne zur Geschäftskontinuität und zur Notfallwiederherstellung vereinfachen kann.

Funktionen von DataCore

Also, als Nächstes wollen wir doch mal etwas ausführlicher auf einige dieser Funktionen eingehen, oder? Die erste betrifft den Umgang mit Daten – das ist ja besonders wichtig, oder? Wir sprechen hier von einer RTO im Bereich von Mikrosekunden bis Millisekunden und einer RPO von Null. Das bedeutet also, dass keinerlei Datenverlust auftreten darf und der Datenzugriff unterbrechungsfrei gewährleistet ist. Für solche Situationen sind synchrones Mirroring und [unverständlich 0:08:36] also [entscheidend], richtig? Um noch ein wenig näher darauf einzugehen: Synchrones Mirroring ermöglicht es Ihnen, zwei Kopien der Daten auf zwei Knoten zu haben, die als Einheit fungieren. Sobald also einer nicht mehr verfügbar ist, ist der zweite [bereit], die Primärrolle zu übernehmen, wodurch jegliche Datenunterbrechung vermieden wird. Und das System stellt sicher, dass diese Daten jederzeit synchronisiert bleiben.

Dieses Diagramm veranschaulicht also, wie das funktioniert – ganz einfach: Wir haben zwei Knoten und drei [Hosts] oben. Stellen Sie sich vor, es werden zwei Datenträger bereitgestellt: VD 1 beispielsweise auf der linken Seite wird primär von Knoten 1 bereitgestellt, wobei Knoten 2 als sekundärer Knoten fungiert. Beide sind also aktiv und synchronisiert. Wenn Knoten 1 also ausfällt, kann Knoten 2 die Aufgabe übernehmen, und auf dem Host ist keine Unterbrechung beim Datenzugriff zu erkennen. Ein weiteres Beispiel für synchrones Mirroring sind sogenannte „Stretched“- oder [Meta]-Cluster. Im Grunde genommen befinden sich diese beiden Knoten nicht am selben Ort, sondern mehrere Meilen voneinander entfernt an unterschiedlichen Standorten. Solange Sie also über eine Verbindung mit geringer Latenz verfügen, die beide Knoten verbindet, können Sie alle Vorteile der synchronen Spiegelung nutzen: keinen Datenverlust, keine Unterbrechung des Datenzugriffs, aber mit zusätzlicher Redundanz. Denn da sich die Knoten an getrennten Standorten befinden, verfügen Sie über unabhängige [unverständlich 0:10:25] Ressourcen und unabhängige Aufrufe – also die Vorteile der synchronen Spiegelung mit zusätzlicher Redundanz. Das wäre also ein zweites Szenario. Synchrones Mirroring mit automatischem [Fillover] wäre also ideal für Ihre am häufigsten genutzten Daten, die jederzeit verfügbar sein müssen und bei denen keinerlei Datenverlust akzeptabel ist.

Ein drittes Beispiel wäre eine dritte Kopie Ihrer Daten. In diesem Fall haben Sie also Ihre beiden Knoten in einer HA-Konfiguration, und dann können Sie eine dritte Kopie der Daten haben, die sich jedoch in einer Standby-Konfiguration befindet, richtig? Das ist sehr praktisch, wenn Sie beispielsweise einen Knoten für Wartungsarbeiten außer Betrieb nehmen müssen, Ihre Daten aber so kritisch sind, dass Sie den HA-Zugriff darauf nicht verlieren dürfen. In diesem Fall können Sie also beispielsweise Knoten eins für Wartungsarbeiten außer Betrieb nehmen und Knoten drei manuell hochfahren, wodurch dieser dann ein HA-Paar für Knoten zwei bildet. Wenn Knoten eins wieder verfügbar ist, erfolgt einfach ein Fallback auf Knoten eins, und alles läuft wieder normal. Das gibt Ihnen die Flexibilität, solche Wartungsfenster zu nutzen, ohne die Hochverfügbarkeit Ihrer Daten zu beeinträchtigen.

Okay, machen wir weiter. Das zweite Modell ist also, wenn Ihre RTOs im Bereich von Sekunden bis Minuten liegen, Sie aber strenge RPOs haben – in diesem Fall ist eine [asynchrone] Replikation gut geeignet. Um das noch etwas näher zu erklären: Bei der synchronen Replikation überträgt die Primärfestplatte alle Änderungen über das Netzwerk an einen entfernten Standort, richtig? Dieses Bild hier veranschaulicht das häufigste Szenario für die synchrone Replikation, nämlich den Aufbau von DR-Standorten. Wie Sie links sehen, gibt es zwei Knoten in einer HA-Konfiguration, also mit synchroner Spiegelung zwischen ihnen – HA – und alle Änderungen werden asynchron an den DR-Standort repliziert. Und wann immer etwas mit dem primären Rechenzentrum passiert, können Sie die zweite Kopie am DR-Standort hochfahren und von dort aus die Wiederherstellung durchführen. Ein weiteres, ebenfalls sehr häufiges Beispiel für den Einsatz von Replikation ist die Nutzung als sekundärer Speicher. Manchmal möchte man eine separate Kopie seiner Daten haben, diese aber nicht auf dem schnellen und teuren Primärspeicher ablegen. In diesem Fall kann man die asynchrone Replikation nutzen, um im Grunde alle diese Änderungen auf einen sekundären, langsameren, aber kostengünstigeren Speicher zu übertragen.

Okay, machen wir weiter. Unser dritter Fall ist, wenn Sie RTOs zwischen Minuten und Stunden bis hin zu Tagen haben, richtig? Und in diesem Fall sind snapshots Backups gang und gäbe. Ein Sonderfall ist jedoch, wenn Sie zwar weiterhin diese nicht allzu strengen RTOs wünschen, aber sehr strenge RPOs haben – und in diesem Fall kann CDP – das steht für „Continuous Data Protection“ (kontinuierlicher Datenschutz) – eine wirklich gute Lösung sein. Lassen Sie mich also etwas näher auf CDP eingehen. Mit CDP können Sie alle Änderungen, die auf Ihren Festplatten stattfinden, kontinuierlich aufzeichnen und protokollieren. Eine gängige Analogie, die wir hierfür verwenden, ist ein DVR – also ein digitaler Videorekorder. Stellen Sie sich vor, Sie zeichnen alles live auf, was gerade passiert, und können zu jedem beliebigen Zeitpunkt zurückspulen und an dieser Stelle ein Abbild erstellen.

Ein sehr interessantes Beispiel – das leider immer häufiger vorkommt – ist der Schutz vor Ransomware. Stellen Sie sich Folgendes vor: Mit CDP können Sie diese kritischen Festplatten schützen, und im Falle eines Ransomware-Angriffs können Sie im Grunde auf die exakte Sekunde vor dem Vorfall zurückspulen und von dort aus eine Wiederherstellung durchführen. So haben Sie praktisch keinen Datenverlust und können sehr schnell wieder einsatzbereit sein. Eine weitere Vorgehensweise, die wir bei Kunden beobachten, besteht darin, nicht nur ein Image für die Wiederherstellung zu erstellen, sondern im Laufe der Zeit auch weitere Images anzulegen – im Wesentlichen für forensische Untersuchungen und Analysen, also um zu ermitteln, wie es überhaupt zu der Infektion gekommen ist. Das ist jedoch nicht der einzige Anwendungsfall für CDP. Wir bieten beispielsweise auch Schutz vor versehentlichem Löschen von Dateien.

Na gut. Und das Letzte sind snapshots. Also, snapshots sind sehr verbreitet, jeder kennt snapshots – damit können Sie einen bestimmten Zeitpunkt, also ein Abbild Ihrer Festplatte, festhalten. Es gibt jedoch einige zusätzliche Vorteile, wenn Sie snapshots DataCore erstellen. Der erste Vorteil ist, dass dies auf Speicherebene erfolgt. Sie können zwar auch snapshots Host-Ebene erstellen, aber das hängt von der [gesamten Software] ab und beansprucht Ressourcen des Hosts, nicht wahr? Wenn wir das hingegen auf der Speicherebene durchführen, geschieht dies für den Host völlig transparent. Das ist also der erste Vorteil. Der zweite Vorteil ist, dass DataCore Ihnen die Möglichkeit bietet, [differenzielle] snapshots zu erstellen. Das sind sehr ressourcenschonende snapshots Sie erstellen können. Wenn Sie also snapshots häufig snapshots erstellen möchten, snapshots diese differentiellen snapshots eine gute Option.

Und drittens: Wenn Sie einen vollständigen snapshot oder eine vollständige Kopie bzw. ein Image der Festplatte erstellen möchten, ist auch das möglich, und DataCore bietet Ihnen die Möglichkeit, diesen snapshot einem beliebigen anderen Speichermedium zu speichern. Sie müssen also beispielsweise, wenn Sie einen snapshot besonders häufig genutzten Daten erstellen, diesen nicht auf diesem schnellen und teuren Speichermedium ablegen und dort Ressourcen beanspruchen. Sie können ihn also auf einen anderen Speicher verschieben, der auch von einem anderen Anbieter stammen kann, und die snapshots speichern.

Das war’s also für heute. Wenn Sie mehr erfahren möchten, finden Sie auf unserer Website eine Seite zum Thema Geschäftskontinuität mit zahlreichen Ressourcen. Außerdem möchte ich betonen, dass es neben den [wenigen] Funktionen, die wir heute behandelt haben, noch viel mehr gibt, insbesondere im Bereich Leistung und Effizienz. Besuchen Sie also [unsere] DataCore-Website und suchen Sie nach diesem Link – dort finden Sie Erläuterungen und Details zu allen Funktionen von DataCore.

Vollständiges Transkript lesen

Der beste Start für ein Software-defined Data Center der nächsten Generation