Transkript des Webcasts
Ich glaube, das Publikum wird das sehr aktuell finden. Das ist normalerweise so – hier unten in Südflorida auf jeden Fall. Um diese Jahreszeit fangen wir an, uns mehr Gedanken über das Wetter zu machen. Auch wenn viele von Ihnen sicher schon einmal weiter nördlich oder an anderen Orten der nördlichen Hemisphäre waren, scheint das Wetter hier doch eine etwas größere Rolle in unseren Überlegungen zu spielen. Die folgenden Ratschläge sollen Ihnen also im Wesentlichen dabei helfen, Ihre Geschäftskontinuitätspläne aufrechtzuerhalten, indem Sie sich an jene unvermeidlichen, aber unvorhergesehenen Wendungen der Ereignisse anpassen, die mit Sicherheit für Unruhe sorgen werden.
Dies setzt voraus, dass wir eine wirklich objektive Selbsteinschätzung der Risiken vornehmen, insbesondere jener Risiken, die Kettenreaktionen auslösen, da diese in der Regel einen großen Einfluss darauf haben, wie gut man seine Sicherheitsvorkehrungen ausbauen kann. Viele dieser Risiken haben Folgen, die durchaus vermeidbar sind.
Wir sind also hier, um Ihnen einige unserer Erfahrungen aus mehreren Jahrzehnten in diesem Bereich weiterzugeben und Ihnen einige taktische Optionen aufzuzeigen, mit denen Sie auf die bevorstehenden Umbrüche reagieren können.
Als Erstes möchte ich Ihnen daher bei einem kurzen Test helfen. Bei diesem Test geht es im Wesentlichen darum, herauszufinden, inwieweit Ihre Strategie zur Geschäftskontinuität und Notfallwiederherstellung beeinträchtigt würde, wenn Sie im Laufe des nächsten Jahres oder so eine wesentliche Änderung vornehmen würden.
Die Zusammensetzung Ihrer Speichersysteme, die Anbieter, also die Hersteller dieser Systeme, oder vielleicht die Topologie – das heißt, vielleicht erwägen Sie gerade den Umstieg von einem klassischen 3-Tier-SAN auf ein hyperkonvergentes System. Betrachten Sie dies also vor dem Hintergrund Ihrer derzeitigen Vorgehensweise in Bezug auf Geschäftskontinuität und Notfallwiederherstellung und prüfen Sie auch, wie sich die Wetterbedingungen auf die von Ihnen getroffenen Entscheidungen auswirken könnten.
Vor allem das Wetter hat sich in letzter Zeit ziemlich regelmäßig verändert und viele von uns überrascht. Ich glaube, selbst die Wettervorhersager schütteln ein wenig den Kopf darüber, was hier gerade vor sich geht. Aber es ist absolut wahr – ganz gleich, worin man die Ursachen sieht –, dass die Intensität und die Häufigkeit dieser wechselhaften Wetterlagen deutlich zugenommen haben.
Und Gebiete, von denen man früher wirklich gedacht hätte: „Wow, wir sind wirklich – bei uns gibt es so seltsame Stürme und ungewöhnliche Wetterphänomene überhaupt nicht“, werden plötzlich von schweren Schäden heimgesucht: Hurrikane, Überschwemmungen, Tornados und andere Naturkatastrophen.
Das rückt das Thema also in den Vordergrund, und es ist einfach eine dieser Sachen – aber abgesehen davon, wirklich abgesehen von höherer Gewalt und all dem anderen, was uns beschäftigt, möchte ich mich wirklich auf eher alltägliche und selbstverschuldete Probleme konzentrieren, die ihr berücksichtigen solltet.
Nun, ich vermute, dass einige von euch bereits auf der Suche nach neuer Ausrüstung sind. Ihr habt mich dazu gebracht, eine Hardware-Erneuerung auf euren Servern und in euren Speichersystemen durchzuführen, und während ihr euch die Möglichkeiten auf dem Markt anschaut, ziehen euch bestimmte Dinge in ihren Bann. Man nennt das das „Shiny-Object-Syndrom“.
Man muss sich vor Augen führen, wie attraktiv eine brandneue Funktion sein könnte. Nun möchte ich das aus folgender Perspektive betrachten: Wenn Sie diese Änderung vornehmen, wenn Sie diese neue Ausrüstung einführen – wie würde sich das auf Ihren Ansatz zur Geschäftskontinuität auswirken und welche Schwierigkeiten würde dieser Übergang konkret mit sich bringen?
Das sind genau die Punkte, über die wir sprechen möchten – vor allem, wenn Sie ein Jahr in die Zukunft blicken, selbstkritisch zurückblicken, Ihre Handlungen betrachten und sich fragen: „Wow, habe ich da gute Entscheidungen getroffen?“ Haben Sie damals gute Entscheidungen getroffen oder war das kurzsichtig? Und genau darauf möchten wir Sie vorbereiten, damit Sie solche Situationen vorhersehen können und in einem Jahr tatsächlich zufrieden mit diesen Entscheidungen sind.
Warum ist uns das überhaupt wichtig? Weil solche Maßnahmen oft erhebliche Störungen verursachen. Einige der zukunftsorientierten Modernisierungsschritte, die Sie möglicherweise unternehmen, können versteckte Folgen haben, und diese Folgen hängen oft eng mit der Art und Weise zusammen, wie Sie derzeit Daten an den Notfallwiederherstellungsstandort replizieren. Vielleicht auch damit, wie Sie snapshots Ihre Backups erstellen und wie Sie das Failover von einem Standort zum anderen durchführen.
Auf diesem Bild sehen wir also das primäre Rechenzentrum, das eine Art – sagen wir – synchroner Replikation zum DR-Standort nutzt. Wie würden Sie das heute angehen, und inwiefern würde sich das ändern, wenn Sie einen Teil der Hardware austauschen würden, die diese Replikation übernimmt? Und wie würde sich dadurch die Vorgehensweise beim Fallback und bei der Wiederherstellung auf der primären Seite ändern?
Denn dies sind fest verankerte Abläufe in Ihren BCDR-Plänen, und sie können durch jede Entscheidung, die Sie in Zukunft treffen, erheblich beeinträchtigt werden. Was wir also wirklich erreichen wollen, ist, zu verhindern, dass Sie in eine Situation geraten, in der Sie sagen: „Wow, damit habe ich nicht gerechnet. Ich hatte eine beiläufige Entscheidung getroffen, die isoliert betrachtet richtig erschien und mir damals als die richtige Wahl vorkam, aber ich hatte nicht bedacht, welche Auswirkungen das nachgelagert haben könnte.“ Wir möchten Sie also in die Lage versetzen, damit umzugehen und all das genau zu verstehen.
Für unsere erste Umfrage möchte ich mir zunächst einmal einen kurzen Überblick verschaffen. Wie viele verschiedene Tools setzt Ihre Organisation derzeit ein, um kritische Daten an einem DR-Standort zu schützen?
So können wir einschätzen, ob Sie vielleicht gar keinen DR-Standort haben, ob Sie einen oder zwei Standorte betreiben – also nur ein paar – oder ob Sie eine Handvoll verschiedener Lösungen nutzen, um für verschiedene Teile Ihrer kritischen Daten eine zusätzliche Kopie an einem anderen Ort zu erstellen, von der Sie die Daten wiederherstellen können, falls dem primären Rechenzentrum etwas zustoßen sollte.
Also, lassen Sie mich mal einen Blick auf die eingehenden Stimmen werfen. Als Erstes fällt mir auf, dass es gerade erst losgeht. Ich warte mal kurz ab. Später werde ich noch eine zweite Umfrage durchführen, die ebenfalls damit zusammenhängt. Das hilft mir dabei, den Rest Gesprächs zu strukturieren, damit ich weiß, in welche Richtung ich es lenken soll.
Wie wir also derzeit feststellen, verfügt etwa ein Drittel von Ihnen noch nicht einmal über einen DR-Standort. Wow, das ist an sich schon etwas verwunderlich, aber aus budgetärer Sicht muss man verstehen, dass dies für Sie derzeit vielleicht noch nicht realisierbar ist. Wir hoffen daher, Ihnen einige Anregungen geben zu können, wie Sie dieses Problem angehen können.
Etwa ein weiteres Drittel gibt an, nur ein einziges Tool zu nutzen. Etwa 28 % geben an, etwa ein Tool zu nutzen. Derzeit geben etwa 14 % an, zwei Tools zu nutzen, und ein Viertel von Ihnen arbeitet überraschenderweise mit mehreren Tools.
Das bedeutet also, dass Sie alle Hände voll zu tun haben, um herauszufinden, wie Sie diese verschiedenen Elemente Ihres Notfallwiederherstellungsplans aufeinander abstimmen können, da sie im Grunde genommen möglicherweise voneinander isoliert sind. Aber es gibt eine gute Lösung, die Ihnen dabei hilft.
Also, machen wir weiter. Als Erstes möchte ich in diesem Zusammenhang darauf hinweisen, dass einige von Ihnen vielleicht gerade deshalb so vorgehen, wie Sie es tun, weil Sie Funktionen nutzen, die beispielsweise in Ihrem SAN integriert sind – Ihrem Storage Area Network-Array. Dieses Gerät, dieser intelligente Speichercontroller, übernimmt für Sie einen Teil der Datensicherung und der Replikationsdienste.
Wenn also einige von Ihnen mit „zwei“ oder „mehrere“ geantwortet haben, könnte der Grund dafür sein, dass Sie möglicherweise zwei verschiedene Speichermodelle in Ihrem SAN hatten. Und jedes dieser Modelle nutzt eine andere Replikationstechnik. Letztendlich geht es darum, Daten an den DR-Standort zu kopieren, aber dafür werden möglicherweise unterschiedliche Protokolle oder eigene, proprietäre Mechanismen verwendet.
Das allein führt also schon zu einigen Schwierigkeiten. Der zweite Punkt ist, dass diese Kapazitäten – da sie sich im Array befinden – isoliert sind und nicht gemeinsam genutzt werden können. Man muss also bewusst entscheiden, welche Daten an welcher Stelle abgelegt werden sollen und welche an einer anderen. Im Laufe der Zeit, wenn sich der Wert dieser Daten ändert, muss man diese Entscheidungen möglicherweise ein wenig anpassen.
Vor diesem Hintergrund bietet Ihnen DataCore in diesem Fall in erster Linie eine Möglichkeit, diese Datensicherungsdienste zu konsolidieren. Dadurch entsteht eine gewisse Einheitlichkeit. Anstatt uns beispielsweise auf die Funktionen eines bestimmten Arrays oder Speichergeräts zu verlassen, heben wir im Grunde die Ebene an, auf der diese Funktionen ausgeführt werden. So profitiert jeder Speicher, den Sie in die Infrastruktur einbinden – sowohl aktuelle als auch zukünftige Speicherlösungen – von denselben Betriebsabläufen.
Sie können eine infrastrukturweite BCDR durchführen, ohne sich um eine bestimmte Marke oder ein bestimmtes Modell kümmern zu müssen. Das ist der Kern dessen, worauf wir näher eingehen möchten. Und das erreichen wir durch ein Kontinuum von Schutzmaßnahmen. Das heißt, eine Reihe von Funktionen, die das gesamte Spektrum der Strategien abdecken, die Sie zum Schutz Ihrer Informationen einsetzen werden.
Im Extremfall oder bei kritischen Daten, die ein RPO von Null und ein RTO von Null erfordern, kommt eine synchrone Spiegelung zum Einsatz. Diese synchrone Spiegelung kann sowohl auf lokaler Ebene erfolgen, d. h. in einem Abstand von nur wenigen a Fuß zueinander, wo zwei Kopien vorhanden sind. In diesen Kontexten geht es jedoch eher um Stretched-Cluster und Metro-Cluster, und ich werde Ihnen dazu einige Beispiele zeigen. Ein weiterer wichtiger Aspekt dieser Funktion ist die Möglichkeit, automatisch auf die andere Kopie umzuschalten, sollte es beim Primärserver zu einem Ausfall kommen.
Diese arbeiten also in einer sogenannten Aktiv-Aktiv-Konfiguration, sodass es niemals zu einer Unterbrechung des Datenzugriffs kommt und auch kein Datenverlust auftritt, selbst wenn die Hälfte Ihrer Speicherinfrastruktur vollständig ausfallen sollte.
Außerdem werden einige Aspekte der dreifachen Ausfallsicherheit angesprochen, wenn man noch einen Schritt weiter gehen möchte. Und dann gibt es noch eine zweite Gruppe, die ich in diesen Bereich eingeordnet habe und die sich auf regionale Ausfälle bezieht: Ich habe also einen ganzen Ballungsraum, der von Erdbeben, Überschwemmungen und anderen schwerwiegenden Gefahren betroffen sein könnte.
Und genau hier advanced site recovery Maßnahmen wie asynchrone Replikation und advanced site recovery , bei denen man versucht, die zweite Kopie an einen weit entfernten Standort zu verlagern und diese zeitnah wiederherstellen zu können. Und dann gibt es noch einige – und übrigens, in diesem Fall sind Sie – im Grunde gibt es einige Kompromisse. Und diese Kompromisse haben damit zu tun, dass man sich eher mit einem absturzkonsistenten Image befasst als mit einem RPO von Null oder einem RTO von Null. Möglicherweise müssen Sie einige Dinge wiederherstellen, und es wird zu kleinen Störungen im Betrieb kommen.
Und dann gibt es noch weitere Maßnahmen wie Continuous Data Protection (CDP) und snapshots, die Ihnen im Grunde einen bestimmten Zeitpunkt – einen genau bekannten Zeitpunkt – liefern. Für einige von Ihnen ist CDP vielleicht noch neu. Es handelt sich dabei um eine Art DVR (Digital Video Recorder), mit dem Sie eine Aufzeichnung aller kritischen I/O-Daten erstellen können, die Sie zeitlich zurückspulen können.
Nehmen wir also einmal an, Sie wären Opfer einer Ransomware-Attacke geworden. Sie könnten die Zeit für Ihre Daten quasi zurückdrehen, direkt zu dem Zeitpunkt springen, an dem der Angriff stattfand, und den Zustand vor der Verschlüsselung wiederherstellen. So können Sie den Leuten, die versuchen, Lösegeld von Ihnen zu erpressen, gewissermaßen den Stinkefinger zeigen. Das sind also interessante Möglichkeiten, die es zu verfolgen gilt.
Das bedeutet, dass ich – oder auch Sie – denselben BCDR-Prozess aufrechterhalten kann, während Sie die Hardware erneuern. Wir wissen, dass die Erneuerung der Hardware und in manchen Fällen auch der Firmware sowie aller anderen Komponenten trotz aller Best Practices eine recht heikle Angelegenheit sein kann.
Im Grunde genommen bedeutet das also: Wir haben im Laufe der Jahre Mechanismen entwickelt, die es Ihnen ermöglichen, alte Geräte auszutauschen und durch neue zu ersetzen – was die Speicherkonfiguration betrifft –, und zwar hinter den Kulissen, an einem Arbeitstag und während der normalen Betriebszeiten, ohne dass es zu Ausfallzeiten kommt. Und all das ist möglich, selbst wenn Sie sich für einen anderen Hersteller oder ein anderes Produktmodell entscheiden, das mit dem vorherigen nicht kompatibel war.
Die Migration der Daten vom alten zum neuen System erfolgt also im Hintergrund, ohne den Betrieb zu stören. Sie können dies so oft oder so selten durchführen, wie es Ihr Unternehmen erfordert, aber der entscheidende Punkt ist, dass Ihre Betriebsabläufe unverändert bleiben, auch wenn Sie einen anderen Speicherort für Ihre Daten wählen. Das ist also einfach der Abschluss dieser Animation.
Das stimmt zwar auch, aber – manche von uns denken sich: „Na gut, aber ich betreibe keine SANs, oder besser gesagt: SANs gehören zwar gewissermaßen zu dem, was ich bisher betrieben habe, aber ich fange gerade an, mich mit Dingen wie hyperkonvergenten Systemen zu beschäftigen und frage mich, wie mir das bei der Umstellung helfen könnte.“
Das Schöne an dem, was DataCore tut – nämlich die Ebene, auf der diese Datensicherungsdienste bereitgestellt werden, nach oben zu verlagern –, ist wiederum, dass die Topologie keine Rolle spielt. Bei einigen unserer Kunden werden Sie daher feststellen, dass diese ihre ersten, schrittweisen Schritte in Richtung HCI unternehmen, indem sie hyperkonvergente Lösungen an ihrem Disaster-Recovery-Standort oder sogar am anderen Ende ihrer Metro-Cluster einsetzen. Einerseits haben sie also eine Umgebung mit klassischen externen SAN-Arrays aufgebaut. Andererseits spiegeln sie diese Daten jedoch auf eine neue Infrastruktur, die lediglich aus einfachen Servern mit internem Speicher besteht und auf der die DataCore-Software läuft – und die gleichzeitig als Host für die virtuellen Maschinen dient, für die ein Failover erfolgen soll.
Aus visueller Sicht, also optisch, ist das ein sehr drastischer Unterschied, doch aus betrieblicher Sicht sehen sie identisch aus. Es gelten dieselben Failover- und Wiederherstellungsverfahren, als hätten wir an beiden Enden identische Systeme.
Nun gibt es einige konkrete Punkte, die Sie vermeiden sollten. Ich werde sie hier als „No-Gos“ bezeichnen, aber im Grunde lautet die Botschaft: „Angesichts dessen, was Sie jetzt wissen, sollten Sie es um jeden Preis vermeiden, sich bei Ihrer Datensicherung auf ein Hardware-Array zu verlassen.“ Denn dadurch werden Sie in bestimmte Verhaltensmuster gezwängt, die später zu erheblichen Problemen führen werden.
Das untergräbt also im Grunde genommen – jedes Mal, wenn man das tut, untergräbt man den Nutzen und kann diese Box-Grenze nicht überschreiten, und mit Box-Grenze meine ich die physische Hardware, auf der das läuft. Außerdem verkürzt man damit tendenziell vorzeitig die Lebensdauer dieser Geräte, denn wenn neue Geräte zum Einsatz kommen, die nicht dieselbe Replikationstechnik verwenden, steht man im Grunde vor der Wahl oder gerät in die Situation: „Oh, ich muss das auf zwei oder drei verschiedene Arten hinbekommen“, und das ist auf lange Sicht nicht zu bewältigen.
Das zweite Tabu ist die Wahl einer DR-Strategie, die spezifisch auf die jeweilige Topologie ausgerichtet ist. Das heißt also entweder: „Nun, ich mache das immer so und gehe davon aus, dass ich immer ein SAN als Grundlage habe.“ Oder: „Ich gehe davon aus, dass es sich ausschließlich um eine hyperkonvergente Lösung handelt.“ Beides kann, wie wir sagen, gleichermaßen kurzsichtig sein. Diese Ansätze bieten Ihnen nicht die Möglichkeit, die Rolle des Speichers klar von der der Rechenleistung zu trennen, und Sie können in Bezug auf die Servicequalität von so vielen Variablen beeinflusst werden. Sich also gewissermaßen von diesen Einschränkungen zu befreien, ist der Kern unserer Botschaft.
Ich möchte ein gutes Beispiel für einen Kunden nennen, der dies umgesetzt hat – und zwar schon sehr früh. Das Unternehmen ist bereits seit über neun Jahren auf diesem Gebiet tätig. Es handelt sich um das Maimonides Medical Center. Dort werden kritisch kranke Patienten im Raum New York versorgt, und das Zentrum kann sich natürlich keinerlei geplante oder ungeplante Ausfallzeiten leisten.
Sie haben also eine vollständige Umstellung vorgenommen – früher befand sich das gesamte Rechenzentrum an einem einzigen Standort im Krankenhaus. Dann haben sie es in zwei Active-Active-Standorte aufgeteilt, von denen sich einer im Hauptkrankenhaus und der andere in der einige Häuserblocks entfernten MIS-Einrichtung befindet.
Dabei wurden stets zwei aktive Kopien aufrechterhalten – die Daten befanden sich, wie wir es beschreiben, an zwei Orten –, sodass bei Wartungsarbeiten oder einem Ausfall an einem der Standorte die anderen nahtlos die Aufgaben übernehmen konnten. Das funktioniert nun schon seit fast einem Jahrzehnt ohne jegliche speicherbedingte Ausfallzeiten. Mittlerweile dürfte es wohl schon ein Jahrzehnt sein.
Und es handelt sich um eine beachtliche Konfiguration von einem Petabyte. Es gibt eine große Gemeinschaft aus Klinikern, medizinischem Personal und Ärzten, die darauf angewiesen sind und eine ganze Reihe unterschiedlicher Anwendungen nutzen. Und im Grunde genommen sagen sie, dass sie so ihren Betrieb aufrechterhalten. Einige Beispiele dafür sind visuell etwas anschaulich dargestellt; ich denke, wenn Sie eher auf der technischen Seite – also im Netzwerkbereich – zu Hause sind, werden Sie das zweite Bild zu schätzen wissen.
Dies betrifft einen Kunden, der verschiedene Generationen von Dell-Geräten einsetzt. Am Hauptstandort im Westen wird Compellent betrieben, und als Metro-Cluster kommt EqualLogic zum Einsatz. Da diese beiden Systeme jedoch normalerweise nicht miteinander kommunizieren können – und dies tatsächlich auch nicht tun –, verfügt keines von beiden über die gleichen Funktionen. DataCore sorgt also dafür, dass die Nutzung dieser Systeme optimiert wird, und standardisiert die Tools, mit denen Kopien zwischen den Systemen erstellt werden – unabhängig davon, welche Hardware jeweils im Hintergrund zum Einsatz kommt.
Sie haben sich nun einmal dafür entschieden, und wenn das nächste 3par – oder etwas anderes, das sie hier einbinden möchten – ins Spiel kommt, ob sie nun zu HP wechseln oder bei Dell bleiben wollen, wären das Entscheidungen, die sie jederzeit treffen könnten, da dies für ihren Arbeitsablauf nicht relevant ist. Es ist lediglich der Ort, an dem die Daten am Ende des Tages gespeichert werden und von dem aus sie abgerufen werden.
Dadurch erhalten Sie auch einen etwas besseren Überblick über einige der redundanten Pfade, die Sie nutzen würden. Wenn Sie also Bedenken hinsichtlich eines einzelnen Ausfallpunkts haben – sei es in Bezug auf die Kabelstruktur bei den Verbindungen zwischen den Standorten oder bei den Verbindungen zu den Switches –, müssen Sie dies sorgfältig durchdenken. Und genau das gehört zu den Best Practices, die Ihnen unsere autorisierten Partner bieten können.
Hier ist eine weitere Konfiguration. Auch diese stammt aus dem Gesundheitswesen, wo man in der Regel besonders viel Wert auf den Schutz der Daten legt. In diesem Fall betreibt dieses Krankenhaus bzw. dieses medizinische Zentrum drei Standorte. Die beiden Standorte in Manhattan (rechts im Bild) sind die Hauptrechenzentren. Und dann gibt es noch den Ausweichstandort: Dieser befindet sich in Secaucus, New Jersey.
Das war eine sehr wichtige Entscheidung, die sie getroffen haben, denn als der Supersturm Sandy hier wütete und den Großraum Manhattan überflutete sowie zu massiven Stromausfällen führte – neben all den anderen Ereignissen, die hier gerade stattfanden –, konnten diese Standorte auf der rechten Seite auf den höher gelegenen Standort, das Rechenzentrum in Secaucus, umschalten, das glücklicherweise trocken und in sicherer Höhe lag.
Für uns Bootsfahrer ist das zwar keine gute Sache, aber für Rechenzentren ist es zweifellos eine wirklich gute Situation, und dadurch konnte ihr Betrieb aufrechterhalten werden. Dadurch blieben ihre kritischen Datendienste in Betrieb. Natürlich mussten sie dafür eine Menge anderer Dinge umorganisieren, aber aus IT-Sicht waren sie gut geschützt.
Und sobald der Betrieb in diesen Einrichtungen in Manhattan wiederhergestellt war, konnten sie einfach den Schalter umlegen und tatsächlich dorthin zurückkehren. In diesem Fall stützen sich die beiden also auf einen gemeinsamen Standort, sie tun beide dasselbe. Sie führen beides durch: die synchrone Spiegelung auf diesen Standort und ihre wechselseitige Verbindung.
In einigen Fällen – und das kommt tatsächlich immer häufiger vor – stelle ich fest, dass eine dritte Kopie erforderlich ist. Und der Grund für diese dritte Kopie ist interessant. Es gibt zwei Möglichkeiten, wie dies umgesetzt werden könnte – und ich spreche hier speziell von einer dritten Kopie in der Nähe –, die zudem synchron gespiegelt wird.
In diesem Fall geht es also darum, dass, wenn eines ausfällt – auf diesem Bild habe ich die westlichen Knoten, den mittleren im Osten und die dritte Kopie auf dem nördlichen Knoten –, einige davon in einer Campus-Umgebung, innerhalb desselben Ballungsraums. Wenn wir eines dieser Systeme für einen bestimmten Zeitraum außer Betrieb nehmen müssen – wegen vorbeugender Wartung, eines Upgrades oder aus anderen Gründen –, passiert Folgendes: Wenn Sie nur zwei dieser Systeme haben, kann es je nach deren Dimensionierung vorkommen, dass der westliche Knoten, der sich ausschließlich auf den östlichen Knoten zur Übernahme verlässt, etwas träge reagiert, wenn dieser nicht ausreichend dimensioniert ist, um die zusätzliche Last zu bewältigen.
Und an diesem Punkt hat man im Grunde genommen diese eine Einheit, die – man ist da irgendwie etwas anfälliger, denn wenn dieses „Baby“ im Rahmen eines sich ausbreitenden Ausfalls ausfallen würde, wäre das ebenfalls ein Ausfall. Um also eine hochverfügbare Umgebung aufrechtzuerhalten, selbst wenn man einen dieser Knoten außer Betrieb genommen hat, hat man diese dreifache Ausfallsicherheit genutzt.
Und das gibt einem gewissermaßen die Gewissheit: „Hey, ja, das kann ich verkraften. Ich bin bereit, die vorbeugende Wartung häufiger durchzuführen, da ich weiß, dass ich durch die beiden anderen Knoten immer abgesichert bin, und ich weiß, dass meine Nutzer keine – wir werden keine Leistungseinbußen hinnehmen müssen, während ich diese Umstellung vornehme.“ Ein wirklich guter Ansatz, um sicherzustellen, dass alles so läuft, wie man es erwartet.
Ich wollte euch auch ein paar Einblicke in die Abläufe hinter den Kulissen aus der Perspektive der Verwaltungskonsole geben. Und das ist die Sichtweise, die man hat, wenn man die Verantwortung für das gesamte System trägt.
Von hier aus steuern wir die stattfindende Replikation und können feststellen, welche Systeme möglicherweise wegen Wartungsarbeiten außer Betrieb genommen wurden. Wir können das aktuelle Leistungsverhalten beobachten und dies geräte- und anbieterunabhängig sowie topologieunabhängig analysieren.
Wir haben einen 360-Grad-Überblick über unsere Datenschutzstrategie, ohne uns mit den spezifischen Feinheiten einzelner Modelle oder Marken auseinandersetzen zu müssen. Das ist der wirklich wichtige Aspekt dabei. Wir haben diese Vorgehensweise einmal gelernt und wenden sie auch weiterhin an, selbst wenn sich die Rahmenbedingungen ändern.
Das Ergebnis sieht letztendlich so aus: Wenn Sie Ihre eigene Infrastruktur ausbauen und beginnen, sich von den bisherigen „Silos“ mit unterschiedlichen Topologien zu lösen, um eine einheitliche Methode zur Standardisierung dieser BCDR-Verfahren zu schaffen – und zwar trotz der vielfältigen Elemente, aus denen sich diese verschiedenen Bereiche zusammensetzen.
Im Mittelpunkt dieses Bildes möchte ich Ihre Aufmerksamkeit auf etwas lenken, das beispielsweise Ihr Datenspeichersystem sein könnte, auf dem Ihre wichtigsten Tier-1-Anwendungen laufen. Möglicherweise kommen hier klassische, große externe SANs zum Einsatz, die sowohl Bare-Metal-Maschinen als auch virtualisierte Maschinen versorgen. Zunehmend sehe ich mittlerweile auch Container im Entwicklungsbereich, und all diese wären dann eigentliche Clients, die Speicherplatz aus diesen externen Speicherbereichen beziehen.
In diesem Fall fungiert DataCore als Ausgleichsebene, also als Speichervirtualisierungsebene, die diese externen Speicher-Arrays zusammenfasst und sie als einheitliche Ansicht des Pfades darstellt.
Auf der linken Seite haben Sie vielleicht auch bestimmte Bereiche ausgewählt – sagen wir mal VDI, also die virtuelle Desktop-Infrastruktur –, in denen Sie testen möchten, wie diese hyperkonvergenten Cluster aussehen. Und vielleicht haben Sie diese Entscheidung getroffen; wir verwenden dort weiterhin dieselbe DataCore-Software, um unsere BCDR-Maßnahmen zu unterstützen.
Das Gleiche gilt für unseren Sekundärspeicher: Was Sie am DR-Standort sowie in den Remote-Offices und Zweigstellen sehen, ist eine ähnliche oder sogar dieselbe Softwarefunktion, allerdings mit leicht unterschiedlichen Topologien. Die ROBO-Standorte würden eher wie ein hyperkonvergenter Cluster aussehen, während der DR-Standort in diesem Fall etwas leistungsfähiger sein musste. Es sieht eher wie eine konvergierte Infrastruktur aus, bei der es zwar immer noch eine Trennung zwischen dem externen Speicher, auf dem die Nutzer ihre Daten speichern, und dem darunter liegenden Speicher des Anbieters gibt, wir uns dabei aber nicht auf große Arrays verlassen, um dies zu realisieren.
Wir haben im Grunde genommen bereits die lokale Speicherung eingerichtet und diese Ressourcen – oder einfach externe Einschübe – gebündelt, aber wir benötigen dort keine intelligenten Controller mehr, da diese Funktion von den DataCore-Funktionen übernommen wird, was ich Ihnen später anhand einer Grafik zeigen werde.
Im Wesentlichen sagen wir also, dass die Software Ihnen die Wahl zwischen verschiedenen topologieunabhängigen Implementierungsmöglichkeiten bietet, die sich im Laufe der Zeit ändern können. Vielleicht haben Sie ganz links angefangen, wo Sie das Speicherarray bündeln und virtualisieren, und dann reduzieren Sie das Ganze gewissermaßen, wenn diese Arrays ausfallen oder ihre Nutzungsdauer abgelaufen ist. Sie ersetzen sie dann durch reinen internen Speicher in diesen Servern – x86-Servern –, die als Speichercontroller fungieren.
Und dann, in der dritten Phase Ihrer Umstellung, können Sie die virtuellen Maschinen und die Workloads tatsächlich direkt auf eben diese Server verlagern. Möglicherweise müssen Sie diese zu diesem Zeitpunkt aufrüsten, aber Sie können auf jeden Fall reibungslos von links nach rechts übergehen, wobei Ihr Ziel darin besteht, die Komplexität Ihrer Infrastruktur zu reduzieren und gleichzeitig die gleichen Vorgehensweisen beizubehalten.
Und dann kommst du vielleicht später darauf zurück und sagst: „Wow, das war doch keine so gute Idee. Eigentlich wollte ich meinen Host von meinem Speicher trennen und sozusagen eine Art Hybrid schaffen.“
Um dies zu ermöglichen, bieten wir die Software im Wesentlichen in drei Editionen an. Da ist zum einen die Enterprise-Klasse mit dem umfassendsten, reichhaltigsten Funktionsumfang, dann haben wir die ST-Edition als Mittelklasse-Variante sowie eine Edition, die auf die großen sekundären Speicheranwendungen abzielt, die es hier in der benachbarten Community gibt – große Dateiserver und Ähnliches –, bei denen Sie nicht denselben Preis pro Terabyte ausgeben möchten wie für Ihre kritischsten Workloads. Also – jede dieser Lizenzen kann eingesetzt werden; es handelt sich dabei um Softwarelizenzen, die Sie auf einem x86-Server ausführen, und sie lassen sich alle in jeder dieser Topologien einsetzen.
Hier ist ein Überblick über den gesamten Stack. In diesem Gespräch haben wir uns bisher auf den Bereich der Datensicherungsdienste konzentriert. Dazu gehören beispielsweise synchrone Spiegelung, Replikation, snapshots CDP. Es gibt jedoch noch eine Reihe weiterer Dienste, die Sie von einer Speicherinfrastruktur erwarten und benötigen – sei es im Zusammenhang mit der Bereitstellung, der Erstellung von Diagrammen und Warnmeldungen oder dem Verständnis Ihrer zukünftigen Kapazitätsanforderungen aus analytischer Sicht sowie möglicherweise Anpassungen Ihrer Servicequalität.
All dies ist also ein wesentlicher Bestandteil dessen, was der Software-Stack bietet, und es spielt keine Rolle, wie Sie darauf zugreifen. Ganz gleich, ob Sie über fibre channel iSCSI arbeiten iSCSI welches Speicherprotokoll Sie im Backend verwenden. Möglicherweise nutzen Sie NVMe Ihre Anforderungen an besonders hohe Geschwindigkeit und geringe Latenz und schließen einige dieserflash direkt an diese DataCore-Server an. Oder Sie nutzen direkt angeschlossene Festplatten oder haben sogar einen Teil dieser Kapazität in der cloud. Es kommt nicht darauf an, wofür Sie sich entschieden haben – Sie weisen diesen verschiedenen Knoten einfach bestimmte Aufgaben zu, je nachdem, welche Workloads Sie von ihnen erwarten.
Vor diesem Hintergrund möchte ich eine zweite Umfrage durchführen. Nachdem Sie nun einen Überblick darüber gewonnen haben, worauf wir hinauswollen, würde ich sehr gerne erfahren, welche der folgenden Änderungen an Ihrer Datenspeicherinfrastruktur – wenn Sie jetzt eine Einschätzung abgeben müssten – Ihre BCDR-Strategie am stärksten beeinträchtigen würde.
Angenommen, (A) man würde Ihnen plötzlich mitteilen: „Hey, in den nächsten sechs Monaten werden wir – wir sind davon überzeugt, dass wir unseren DR-Standort in die cloud verlagern müssen. In einigen Fällen, insbesondere bei denjenigen unter Ihnen, die bisher noch keinen DR-Standort hatten, werden wir einen DR-Standort in der cloud einrichten.“ Wie würde sich das auf Sie auswirken?
Oder denken Sie vielleicht darüber nach, Ihr bestehendes SAN um ein flash zu erweitern? Überlegen Sie sich, ob sich die von Ihnen verwendeten Replikationsverfahren dadurch grundlegend ändern würden. Ich meine das nicht nur theoretisch, sondern ganz konkret. Wie würde sich Ihr BCDR-Plan ändern? Und wenn Sie plötzlich auf ein hyperkonvergentes System umsteigen würden – vielleicht sogar parallel zu Ihrem aktuellen Speichersystem –, würde das dann ganz, ganz anders funktionieren? Ich vermute, das wäre der Fall, daher würde ich gerne Ihre Meinung dazu hören.
Also, Carlos, ich kann die Ergebnisse der zweiten Umfrage nicht sehen. Ich weiß nicht, ob du sie sehen kannst.
Carlos Nieves: Ich kann die Ergebnisse sehen, Augie, und derzeit haben sich etwa 68 % der Teilnehmer für die Option „Verlagern Sie Ihren DR-Standort in cloud entschieden. Etwa 10 % haben „Ergänzenflash Ihr bestehendes SANflash . Der Rest hat sich für Rest Sie ein hyperkonvergentes System zusätzlich zu oder anstelle Ihres aktuellen Speichers ein“ Rest .
Augie Gonzalez: Okay, was ich mir also von euch wünsche – wenn ihr heute hier fertig seid und nach Hause geht –, ist, dass ihr euch selbst einmal Gedanken darüber macht: Wie folgenschwer ist es eigentlich, dass ich diesen Schritt gehen muss? Welche Auswirkungen hat das auf die Abläufe, die Schulungen und die Prüfungen, die ich im Rahmen meines BCDR-Plans durchführen muss, und wie kann ich verhindern, dass dies zu einer katastrophalen Veränderung meiner Sicherheitsvorkehrungen führt? Übrigens, vielen Dank für diese Anregungen.
DataCore steht Ihnen also zur Seite. Das Unternehmen unterstützt Sie in verschiedenen Bereichen. Im Rahmen des heutigen Webcasts konzentrieren wir uns zwar vor allem auf Geschäftskontinuität und Notfallwiederherstellung, doch eigentlich ist jeder Zeitpunkt, an dem Sie über eine Speichererweiterung oder -erneuerung nachdenken, ein guter Anlass, um zu überdenken, wie Sie bei der Sicherung Ihrer Daten an einem anderen Ort vorgehen möchten.
Wir sind zudem eng eingebunden in Organisationen, die Konsolidierungsmaßnahmen vorantreiben, um die Vielfalt der Hardware einzudämmen, diese Ressourcen tatsächlich zu bündeln und einheitlich zu verwalten. Dabei können wir Ihnen helfen – ebenso wie am Netzwerkrand, ganz gleich, ob Sie Remote-Büros oder Zweigstellen betreiben, die das Hauptrechenzentrum ergänzen, und versuchen, eine wechselseitige Vereinbarung zwischen den Notfallwiederherstellungsstandorten (DR) zu schaffen, indem Sie entweder das Hauptrechenzentrum als DR-Standort oder diese ROBO-Standorte nutzen.
Oder am Rand müssen Sie einen Teil dieser Daten zurücksenden. Dabei kommen dieselben Techniken zum Einsatz, sodass wir Ihnen in dieser Hinsicht sehr gut zur Seite stehen können. Insbesondere für Sie als Einzelpersonen gibt es mehrere Aufgaben, bei denen wir Ihnen helfen können.
Wenn es also Ihre Aufgabe ist, die Betriebskontinuität sicherzustellen, können wir Sie dabei unterstützen – selbst wenn die Hardware in die Jahre kommt und durch neue Geräte ersetzt wird. Und ich denke, das wäre wahrscheinlich die oberste Priorität. Zu den Werkzeugen, die wir dafür anbieten, gehört die Möglichkeit, die Daten im Hintergrund zu migrieren. Wenn also diese Geräte ausgetauscht werden, können wir diesen Wechsel vornehmen, die alten Geräte außer Betrieb nehmen, die Daten auf die neuen übertragen – und niemand muss davon erfahren, dass dieser Vorgang stattgefunden hat.
Sogar bis zu dem Punkt, an dem diese Ausrüstung an einem anderen Ort als dem ursprünglich vorgesehenen auftaucht – nicht nur der Lieferant und das Modell, sondern auch der Standort haben sich geändert. Und all dies muss geschehen, während Sie mögliche Fehlerquellen und Ausfälle umgehen; so kann es zwar tatsächlich zu schwerwiegenden Ausfällen im Rahmen Ihres Szenarios kommen – beispielsweise in einem Gebäude auf dem Campus –, doch die Systeme laufen natürlich weiter.
Es gibt auch einige zusätzliche Vorteile, nämlich die Möglichkeit, Kapazitäten über Geräte hinweg zu bündeln, die andernfalls als isolierte Einheiten betrachtet würden. Anstatt also zu sagen: „Nun, ich habe diese isolierte Speicherinsel und habe ganz bewusst entschieden, welche Anwendungen ich darauf nutze“, kann ich die mir zur Verfügung stehenden Ressourcen – egal wie unterschiedlich sie auch sein mögen – tatsächlich bündeln und aggregieren und sie als einen Ressourcenpool behandeln, aus dem ich je nach Spitzen- und Durchschnittswerten meines Verbrauchs schöpfen kann.
Und schließlich geht es um die Fähigkeit, die Verbraucher tatsächlich zu authentifizieren. Dabei wird ermittelt, wer den Service mit hoher Priorität verdient, wen wir als unredliche Verbraucher ausschließen wollen und wer den Service mit mittlerer Priorität erhält. All dies ist Teil der hier vorhandenen intelligenten Funktionen.
Wenn es eine Sache gibt, die ich Ihnen mit auf den Weg geben möchte, dann ist es diese: Lassen Sie nicht zu, dass diese versteckten Abhängigkeiten Ihren BCDR-Plan gefährden. Ob es nun um den Standort, die Topologie oder Lieferanten geht – behalten Sie das im Auge. Behalten Sie im Auge, welche Auswirkungen ein etwaiger Wechsel für Sie haben könnte.
Und aus unserer Sicht, basierend auf den Rückmeldungen, die wir von unseren Kunden erhalten haben: Einige davon – zum Beispiel die Stadt Carmel – haben einen wirklich guten Webcast veröffentlicht. Dort wird DataCore bereits seit 2010 eingesetzt. Das sind also – wie lange? Neun Jahre? Und das ganz ohne Ausfallzeiten, obwohl in dieser Zeit natürlich alle möglichen Änderungen vorgenommen wurden.
Betrachten Sie uns also als einen unabhängigen Softwareanbieter, der in einzigartiger Weise in der Lage ist, Ihre sorgfältig ausgearbeitete BCDR-Strategie zu bewahren und Ihnen gleichzeitig die Möglichkeit zu geben, Modernisierungen vorzunehmen und Ihrem Unternehmen Geld zurückzugewinnen – denn Sie müssen keine Komponenten entsorgen, die plötzlich ausgemustert und ersetzt wurden.
Und falls Sie einige dieser Informationen schnell an einige Ihrer Kollegen weitergeben möchten, die vielleicht nicht bereit sind, sich den gesamten Webcast von etwa 45 Minuten anzusehen, den wir hier durchführen, dann geben Sie ihnen doch einen kurzen Überblick über diese Maßnahmen.
Dort finden Sie verschiedene Ressourcen, darunter auch einige zweiminütige Videos, die Ihnen einen genauen Eindruck davon vermitteln, worüber wir sprechen, und veranschaulichen, was wir unter diesen kaskadierenden Abhängigkeiten verstehen. Ich kann Ihnen daher nur wärmstens empfehlen, sich diese anzusehen.
Und damit möchten wir nun, glaube ich, unsere Fragen durchgehen und schauen, was wir hier so haben. Lass mich das kurz durchgehen, Carlose – entschuldige bitte.
Die erste Frage lautet also: „Funktioniert es gut mit Office 365?“ Das ist eine interessante Frage. Office 365 ist eine gehostete Software, und daher gibt es hinter den Kulissen bereits eine Infrastruktur, die sich darum kümmert.
Dafür wären Sie auf den SaaS-Anbieter angewiesen, und das liegt im Allgemeinen außerhalb Ihrer Kontrolle, wenn Sie die gehostete Version nutzen. Sollten Sie die lokale Version auf eigenen Servern betreiben, wäre das natürlich sehr hilfreich.
Das ist die zweite Frage, die lautet: „Gibt es besondere Speicheranforderungen für die Nutzung Ihrer Software?“ Ich verstehe das so: „Gibt es besondere Kompatibilitätsaspekte, die für uns von Bedeutung sind und die uns möglicherweise daran hindern könnten?“ Und nein, die Software geht grundsätzlich davon aus, dass sie mit Speichermedien kommunizieren kann – mit Standardspeichermedien unter Verwendung der bekannten Protokolle, sei es SAS, SATA oder NVMe. Sie werden alle nativ unterstützt – bei den meisten handelt es sich im Grunde genommen um das SCSI-Protokoll, das zur Datenübertragung verwendet wird.
Wir betrachten den Host, den Speicher und die herkömmliche Art und Weise, wie diese Verbindung zustande kommt. Das ist vollständig kompatibel, sodass wir dafür keine besonderen Qualifikationen benötigen.
Da ist noch eine weitere Frage: „Wie wird die Software berechnet?“ Darauf bin ich bereits kurz eingegangen. Im Grunde geht es um die Kapazität. Es kommt darauf an, wie viel Kapazität DataCore zur Verfügung stellt. Wie viel nutzbare Kapazität steht uns zur Verfügung? Auf dieser Grundlage berechnen wir einen Preis pro Terabyte.
Je größer das Volumen ist, das Sie uns anvertrauen, desto niedriger ist der Preis pro Terabyte. Die drei Editionen, die ich Ihnen zuvor gezeigt habe – EN, ST und LS – unterscheiden sich lediglich in ihrem Funktionsumfang. In einigen Fällen sind alle Funktionen integriert, in anderen gibt es einen maßgeschneiderten Funktionsumfang, der sich für den Mittelstand eignet und für Anwendungen, bei denen die Leistung keine so große Rolle spielt – das ist die LS-Edition. Das war’s auch schon.
Ich sehe keine weiteren Fragen. Wir haben hier noch ein paar Minuten Zeit, falls Sie möchten, und dann übergebe ich das Wort an Carlos.