Transkript des Webcasts
Danielle: Guten Morgen und guten Nachmittag, liebe Teilnehmer. Vielen Dank, dass Sie heute bei uns sind. Mein Name ist Danielle Brown. Ich bin Marketingmanagerin hier bei DataCore Software und werde heute als Moderatorin fungieren. Wir heißen Sie herzlich willkommen zum heutigen Webinar mit dem Titel „Wie man hyperkonvergente Systeme in bestehende SANs integriert“. Bevor wir jedoch mit der heutigen Präsentation beginnen, möchte ich noch kurz einige organisatorische Hinweise geben.
Diese Präsentation wird aufgezeichnet und steht anschließend auf Abruf zur Verfügung. Nach Abschluss dieses Webinars erhalten Sie eine E-Mail von BrightTALK mit einem Link zum Abruf. Und zu guter Letzt: Sie können gerne während der gesamten Veranstaltung Fragen eingeben – diese werden wir am Ende ebenfalls beantworten. Damit möchte ich nun beginnen und unseren heutigen Referenten vorstellen: Augie Gonzalez, Leiter des Produktmarketings bei DataCore Software. Augie?
Augie: Danke, Danielle. Ich möchte nun einige Punkte durchgehen, die für euch vermutlich ganz oben auf der Tagesordnung stehen. Zunächst geht es darum, zu verstehen, ob hyperkonvergente Systeme für euch geeignet sind, und euch dazu einige Tipps zu geben. Ich glaube, dass manche Leute das in manchen Fällen für eine ausgemachte Sache halten. Ich möchte euch hier einige der Rahmenbedingungen und Überlegungen dazu erläutern. Wo passt Hyperkonvergenz eigentlich am besten? Denn es gibt Bereiche, die als eher ungewöhnlich gelten.
Außerdem möchte ich auf einige besondere Aspekte eingehen, die zu beachten sind, wenn Ihre Anwendungen tendenziell E/A-intensiv sind. Denn während Allzweckanwendungen sehr gut funktionieren, erfordern E/A-intensive Anwendungen etwas mehr Planung und möglicherweise andere Entscheidungen. Dazu werden wir eine Fallstudie aus dem Notfalldienst durchgehen – von einem unserer Kunden, der einen 911-Notrufdienst betreibt. Ich denke, das wird einige der Konzepte, die wir hier besprechen, verdeutlichen; im Anschluss werde ich Ihnen noch ein paar weitere Informationen dazu geben, wie Sie Ressourcen nutzen können, die bereits vor Ort vorhanden sind, für die Sie bereits viel Geld bezahlt haben und die Sie optimal einsetzen möchten.
Und schließen wir die Diskussion mit einigen konkreten Schritten und Anleitungen ab, die Ihnen den Übergang von dem möglicherweise dreistufigen SAN, das Sie derzeit nutzen, zu einer hyperkonvergenten Umgebung erleichtern sollen. Betrachten wir nun den grundlegenden Vergleich: Sowohl die dreistufigen SANs – auf der linken Seite als externer Speicher bezeichnet, bei denen Server über ein iSCSI Fibre-Channel-Netzwerk mit einem Array verbunden sind – als auch die hyperkonvergenten Systeme, bei denen Server mit Anwendungen in einem Cluster betrieben werden, verfolgen alle dasselbe Ziel: nämlich einer Reihe von Anwendungen gemeinsam genutzten Speicher bereitzustellen, damit diese auf den gemeinsamen Kapazitätspool zugreifen können, und in einigen Fällen auch Funktionen wie die Live-Migration von Anwendungen und virtuellen Maschinen zu ermöglichen – einschließlich der Verlagerung von Containern von einem physischen Server auf einen anderen ohne Unterbrechung.
In diesen Diagrammen werden Sie sehen, dass ich eine Art aquablaues Rechteck verwende, um darzustellen, wo Software zum Einsatz kommt. Auf der linken Seite sehen wir sie also auf dem Array als Front-End-Controller. Im Falle einer hyperkonvergenten Lösung, bei der interner Speicher in den Servern genutzt wird, wäre dies eine Softwarekomponente, die entweder auf einer VM oder direkt auf dem hypervisor läuft.
DataCore bietet beides an, daher haben wir kein bestimmtes „Pferd im Rennen“, bei dem wir uns Gedanken darüber machen müssten, es in die eine oder andere Richtung zu lenken. Ich werde jedoch einige der Unterschiede erläutern, warum wir das eine gegenüber dem anderen empfehlen könnten. Es gibt ganz klare Unterschiede hinsichtlich dessen, was Sie erreichen möchten. Wenn Sie über ein zentralisiertes SAN verfügen, besteht die wichtigste Aufgabe darin, die Server zu entlasten und die Speicherkapazität in einem Bereich zu bündeln, der einfach zu verwalten ist, und über eine iSCSI Fibre-Channel-Verbindung Netzwerkzugriff darauf bereitzustellen.
Es ist auch interessant, die Zuständigkeiten beispielsweise des Speicheradministrators, der für diese zentralen Ressourcen zuständig ist, abzugrenzen. Vergleichen Sie das mit einem hyperkonvergenten System. Was wir dort erreichen wollen, ist Folgendes: Alle diese Server verfügen über überschüssige Kapazitäten in Bezug auf Rechenleistung, E/A und möglicherweise auch Speicher. Lassen Sie uns also all diese Ressourcen bündeln, sie voll ausschöpfen und, wo immer möglich, sicherstellen, dass die Anwendungen auf lokale Festplatten zugreifen können, ohne das Netzwerk durchlaufen zu müssen.
Gleichzeitig haben wir eine verbesserte Möglichkeit, die Isolation von „alt“ zu erhöhen, indem wir den Speicher auf mehr Knoten verteilen. Ein Teil des Kompromisses dabei ist, dass wir auch Rollen zusammenlegen. Aus administrativer Sicht muss also die Person, die sich um die Server kümmert, auch die Verantwortung für den Speicher übernehmen.
Und ich werde gleich auf einige der gesellschaftspolitischen Faktoren eingehen. Und hier ist ein Teil dieser Sichtweise. Wenn Sie also dieses zentrale SAN neu zeichnen und es in etwa so darstellen, betonen Sie bitte die Tatsache, dass der Speicher auf der linken Seite vollständig konzentriert ist – es handelt sich um einen zentralisierten Pool, der möglicherweise aus mehreren Arrays oder Speichergeräten besteht. Aber sie sind irgendwie – es gibt etwas, das sie umgibt und sie wie einen zentralen Pool erscheinen lässt. Und dann die Rechenelemente, auf denen die Anwendung läuft – diese würden sich einfach über die jeweilige Fabric, mit der wir es zu tun haben, damit verbinden.
Das meinen wir also mit einer klaren Rollentrennung. Im zweiten Fall ist die Situation unklar, da jeder dieser Knoten potenziell sowohl Ressourcen in Form von Kapazität bereitstellen kann als auch gleichzeitig Speicherplatz, Netzwerkbandbreite und Rechenzyklen verbraucht. Man muss also bedenken, dass man als Speicheranbieter – nehmen wir an, man befindet sich hier auf dem linken Knoten – Kapazität für seine Nachbarn auf der rechten Seite bereitstellt.
Wenn man keine besonderen Vorsichtsmaßnahmen trifft, kann es tatsächlich passieren, dass man unbewusst die Servicequalität für seine Nachbarn beeinträchtigt. Einfach weil man sich gewissermaßen nur mit seinem eigenständigen Server beschäftigt und nicht bemerkt hat, welche Auswirkungen dies auf die benachbarten Nutzer hat. Ein sehr wichtiger Punkt. Im anderen Fall denkt man immer daran: Es ist sozusagen meine Aufgabe, Speicherplatz für die breitere Masse bereitzustellen, und ich möchte sicherstellen, dass dem nichts im Wege steht. Das ist bei hyperkonvergenten Systemen etwas schwieriger zu erreichen.
Die allgemeine Philosophie hier lautet also, Ressourcen manchmal überdimensioniert bereitzustellen, einfach um ein wenig mehr Spielraum zu haben und dadurch einen etwas größeren Fan-Out zu erzielen. Was den sozialen Bereich angeht – das sind einige der Aspekte, die die Ausrichtung der dafür verantwortlichen Personen leiten, und es ist schon interessant, denn ich beobachte das häufig: Ich spreche mit Kunden auf beiden Seiten des Zauns, sogar innerhalb desselben Unternehmens, die unterschiedliche Rollen einnehmen.
Die meisten Speicheradministratoren, mit denen ich gesprochen habe – und viele von Ihnen sind heute vielleicht im Publikum –, haben folgende Einstellung: „Ich bin so etwas wie ein Spezialeinheitssoldat, ich muss mich darum kümmern, die gesamte Kapazität zu kontrollieren, und mein oberstes Ziel ist es, meinen Kunden ein Höchstmaß an Service zu bieten, indem ich diese Ressourcen zentralisiere und sicherstelle, dass hier niemals etwas ausfällt und dass die Reaktionszeiten und der Durchsatz den Erwartungen aller entsprechen.“
Und ich muss dieses zentrale SAN bei Bedarf mit Daten versorgen, um sicherzustellen, dass ich die Hardware aktualisieren kann, damit sie auf dem neuesten Stand und leistungsfähig ist, und um alles zu vermeiden, was nach einem Ausfall riecht, der katastrophale Auswirkungen auf alle meine Kunden haben könnte. Der für Hyperkonvergenz zuständige Mitarbeiter ist in der Regel jemand, der bereits die Verantwortung für die Virtualisierungsadministration übernommen hat – egal, ob man vSphere-, Hyper-V- oder KDM-Administrator ist, man ist meist für dieses breitere Spektrum an Anforderungen zuständig; man kümmert sich also um die Rechenleistung und um den Lastausgleich zwischen verschiedenen Servern.
Der Fokus liegt viel stärker auf der Anwendung. Und man verwaltet das Ganze tatsächlich eher aus der Perspektive des Hosts als aus der Perspektive des Speichers. Entscheidend ist auch, dass man möglicherweise schon recht an die Selbstbereitstellung gewöhnt ist – also daran, sich selbst Kapazität zuzuweisen und aus diesem Pool zu schöpfen. Man sieht also, dass es zwei unterschiedliche Sichtweisen gibt. Und wer diesen Wechsel von einer der beiden Seiten aus vollzieht, muss seine Denkweise möglicherweise ein wenig umstellen.
Auch bei den Anbietern, mit denen Sie zusammenarbeiten, haben Sie unterschiedliche Vorlieben, je nachdem, ob Sie die Sache aus der Perspektive eines zentralen SAN oder aus der Perspektive der Server betrachten. Die Unternehmen, mit denen Sie bisher zusammengearbeitet und von denen Sie Geräte gekauft haben, können also ganz unterschiedlich sein, und das spiegelt sich möglicherweise in Ihren Auswahlkriterien wider. Hyperkonvergente Lösungen üben eine große Anziehungskraft aus. Das ist schon seit – ich würde sagen – etwa drei Jahren so. Was als Erstes wirklich auffällt, ist, dass Hyperkonvergenz – schon rein optisch, wenn man alles in einem Paket sieht – sehr, sehr einfach wirkt. Es geht dabei eigentlich nur um eine Art von Hardware, nämlich Server.
Ich habe es also nicht mit drei einzelnen Komponenten zu tun, denn die Rechenleistung, der Speicher und das Netzwerk wurden alle in diesem einen Paket zusammengefasst und konsolidiert. Ich glaube, es wird oft behauptet, dass dies kostengünstiger sei – „günstiger“ wäre wohl das passende Wort –, da man davon ausgeht, dass bei Standarddiensten kostengünstigere Geräte zum Einsatz kommen können als bei großen proprietären Speicher-Arrays, die eine Menge zusätzlicher Hardware und anderer Komponenten mit sich bringen.
Und wenn man sich einige der dort gezeigten Diagramme ansieht, könnte man zu dem Schluss kommen, dass hyperkonvergente Lösungen auch schneller sein müssen. Denn es entstehen keine Verzögerungen durch die Übertragung über ein Netzwerk zum Speicher, da sich der Speicher lokal auf dem Rechner befindet. Wir werden all diese Punkte also ein wenig genauer unter die Lupe nehmen. Dabei möchte ich Ihnen eine kleine Warnung mit auf den Weg geben. Viele der Produkte, die wir da draußen sehen, sind zwar als hyperkonvergente Lösungen vermarktet und richten sich an große Unternehmen für umfangreiche Anwendungen, wurden aber tatsächlich für relativ kleine und allgemeine Anwendungsszenarien konzipiert.
Bei geringer Auslastung funktionieren sie wirklich gut, insbesondere wenn sich die Aufgaben leicht aufteilen lassen – etwa bei verteilten Anwendungen, bei denen man sagen kann: „Nun, ich kann entweder zwei Instanzen auf zwei Knoten ausführen oder vier Instanzen auf vier Knoten, und so lässt sich das gut handhaben.“ Etwas chaotisch wird es erst bei monolithischen Anwendungen. Viele der sogenannten „Systems of Records“ sind zum Beispiel sehr ressourcenintensiv, belasten die E/A stark und sind so linear aufgebaut, dass sie sich nicht auf mehrere Knoten aufteilen lassen – genau da geraten sie aus der Bahn, und es kann zu Problemen kommen, wenn man versucht, sie dort unterzubringen.
Das ist also eine Entscheidung, die Sie bei Ihrer Bewertung – bei der Prüfung möglicher Lösungswege für Ihr Problem – sofort treffen müssen. Wir stellen unter anderem fest, dass die Hardware zwar durchaus in der Lage ist, sehr hohe Leistungsanforderungen zu erfüllen, der dafür eingesetzte Software-Stack jedoch tatsächlich zu einem Engpass wird. Es entsteht also ein serverseitiger Engpass, der diese träge Leistung verursacht, die man beim Betrachten des Netzwerkdiagramms nicht erwarten würde.
Und da die hyperkonvergenten Systeme im Hinblick auf Benutzerfreundlichkeit so konzipiert sind, werden Sie in vielen Fällen feststellen, dass Sie nicht eingreifen können, um Anpassungen vorzunehmen. Es heißt im Grunde: Das sind die Standardeinstellungen, und damit arbeiten wir. Und das kann zu einem Phänomen führen, das wir in der Echtzeitbranche als „nicht deterministisches Verhalten“ bezeichnen. Es kommt zu gewissen Schwankungen, da das System versucht, eine Art Zeitmultiplexing durchzuführen. Dabei haben wir in den letzten Jahren, in denen wir uns damit beschäftigt und andere Angebote untersucht haben, eine sehr wichtige Erkenntnis gewonnen: Bei vielen dieser Lösungen wird von all den Kernen, die auf diesen Servern vorhanden sind, effektiv nur ein einziger Kern eines einzelnen Servers für die Verarbeitung der E/A-Vorgänge genutzt.
Und genau das kann der wichtigste Grund für ein träges Verhalten sein. Und wie ich bereits gesagt habe: Eine der Dinge, auf die Sie achten müssen, ist, dass Sie – ohne es zu wissen – diesen Wettbewerb um Ressourcen verursachen könnten, weil Sie einen oder zwei der Knoten aus Ihrem Komplex von drei oder fünf überlastet haben. Und genau von diesen Knoten beziehen alle ihre Kapazität.
Und das ist nicht gerade offensichtlich. Vor allem, wenn man es gewohnt ist, ausschließlich aus der Serverperspektive zu arbeiten. Was können wir nun dagegen tun? Nun, das Design, das DataCore für hyperkonvergente Systeme entwickelt hat, ist sehr, sehr einfach und äußerst leistungsstark. Denn die Art von Anwendungen, für die wir diese Systeme entwickeln sollten, erfordert die geringste Latenz – also die schnellste Reaktion – sowie ein sehr attraktives Preis-Leistungs-Verhältnis, d. h. den Preis, den man pro IOP zahlt.
Tatsächlich wurden einige dieser Systeme vom Storage Performance Council umfassend getestet, um zu prüfen, wie sie im direkten Vergleich mit anderen Systemen abschneiden. Das Beispiel, das ich Ihnen hier zeige, ist ein wirklich einfaches, aber hinsichtlich seiner Leistungsfähigkeit äußerst leistungsstarkes System. Es handelt sich lediglich um ein kleines System mit zwei Knoten, das den Weltrekord für hyperkonvergente E/A-Leistung im SPC-1-IOPs-Test aufgestellt hat; dabei handelt es sich um besonders anspruchsvolle transaktionsorientierte Workloads, wie sie typischerweise in OLTP-Umgebungen vorkommen.
Und IOPs werden manchmal etwas überbewertet. Was den meisten Menschen wirklich wichtig ist, ist, wie viel nützliche Arbeit man damit erledigen kann – und zwar zu einem angemessenen Preis. Und genau diese beiden Kennzahlen, insbesondere in Bezug auf die Latenz, sind der Schlüssel zu diesen Zahlen. Es war also nicht nur die schnellste hyperkonvergente Lösung, die hier gezeigt wurde, sondern sie bot auch die schnellste Reaktionszeit – unter einer Millisekunde. Die Reaktionszeit betrug 220 Mikrosekunden bei 10 SPC-IOPs pro Rechenzentrum. Wir bezeichnen das als unübertroffene Wirtschaftlichkeit.
Das ist ein Branchenstandard. Wenn Sie die SPC-Website besuchen, werden Sie feststellen, dass einige der größten und führenden Speicheranbieter ihre Lösungen dort veröffentlicht haben, und Sie können sehen, wie DataCore im Vergleich zu ihnen abschneidet – selbst bei diesen äußerst kostengünstigen Konfigurationen. Ich sollte noch erwähnen: Wie auf dem Bild zu sehen ist, verkauft DataCore ausschließlich Software. Deshalb arbeiten wir mit Hardware-Anbietern wie Lenovo oder Dell zusammen. Sie wählen den Server-Anbieter aus, und wir stellen das Ganze zusammen – unsere autorisierten Partner übernehmen dabei die Verantwortung, das Paket für Sie zusammenzustellen.
Und in vielen Fällen nutzen wir die bereits vorhandene Hardware voll aus – das ist hier der entscheidende Punkt: Sie haben bereits viel Geld dafür ausgegeben; also lassen Sie uns sie einfach nutzen. Ein Teil unserer Kompetenzen und das, was uns auszeichnet, ist die Fähigkeit, alle Kerne dieser Server zu nutzen und die E/A-Vorgänge parallel zu verarbeiten, während andere dies auf einen einzigen Thread beschränken.
Wir bieten weitere Webinare an, in denen wir ein wenig über parallele E/A sprechen. Dort können Sie sehen, wie Sie dadurch mehr Arbeit in kürzerer Zeit erledigen können und wie weniger Maschinen für die Arbeit ausreichen. Viele. Das sind wesentliche Merkmale und Unterscheidungsmerkmale des DataCore-Angebots. Lassen Sie uns das nun etwas konkreter für Sie veranschaulichen. Dazu möchte ich auf eine Fallstudie zurückgreifen, die mit einem 911-Notrufdienst durchgeführt wurde. Es handelt sich um einen Dienst. Es handelt sich um eine staatliche Behörde in Oregon. Glücklicherweise sind wir alle damit ziemlich vertraut und müssen nicht regelmäßig den Notruf 911 wählen. Aber Sie können sich vorstellen, wie lebenswichtig es ist, einen Anruf zu tätigen und sicherzustellen, dass diese Systeme die Informationen schnell weiterleiten, damit die Disponenten und die Ersthelfer stets über die aktuellsten Informationen verfügen.
Also, falls – ich werde, glaube ich, auf der nächsten Folie einen Link einfügen, der euch etwas mehr Details dazu liefert. Das Problem bei ihnen war jedoch, dass diese Callcenter-Zentrale feststellte, dass ihre Abfragen und Eingaben an den SQL-Server-Backend-Server – der das Herzstück ihrer Umgebung bildet – einfach nicht schnell genug beantwortet wurden, um die Einhaltung der von ihnen festgelegten Service Level Agreements zu gewährleisten, die eine ausreichend schnelle Rückmeldung an die Menschen am anderen Ende der Leitung ermöglichen sollten.
Und sie hatten mit sehr hohen Latenzzeiten zu kämpfen. Sie nutzten herkömmliche Speichergeräte, die auf einer erhöhten Plattform standen. Außerdem hatten sie ganz konkrete Ziele hinsichtlich der Verfügbarkeit und des Datenverlusts. Wie Sie hier sehen können, konnten sie diese Ziele nicht erreichen. Sie waren dazu nicht in der Lage und hatten zweifellos ein Problem; als sie die Situation aus finanzieller Sicht betrachteten und überlegten, wie sie diese Probleme beheben könnten, stellten sie fest, dass jede ihnen angebotene Alternative – sei es eine hyperkonvergente Lösung oder der gleichzeitige Einsatz weiterer Arrays – umfangreiche Komplettmodernisierungen erforderte, für die viel neues Geld aufgewendet werden musste.
Und das ließ sich einfach nicht rechtfertigen. Nun haben sie diese Schlussfolgerung durchgespielt und sich schließlich für DataCore entschieden, um ihre Anforderungen zu erfüllen. Hier ist eine kurze Übersicht, um Ihnen eine Vorstellung vom Ablauf zu vermitteln, wie Sie es sich vielleicht vorstellen können. Ich habe mir gerade erst gestern Abend eine dieser Sendungen angesehen, sie heißt „911“. Ich weiß nicht, ich würde sie nicht unbedingt empfehlen. Aber sie vermittelt einem einen Eindruck davon, was hinter den Kulissen vor sich geht. Und was es – ein Teil des Problems hier ist, dass sowohl der Text, der bezüglich der Geschehnisse am Notfallort eingegeben wird, als auch die Audioaufzeichnungen – all diese Informationen weitergegeben werden müssen und Situationsbewusstsein erforderlich ist, um die Ersthelfer zu informieren, seien es Polizeikräfte oder Feuerwehrleute; all diese Leute müssen sehr schnell Bescheid wissen – die meisten ihrer SLAs liegen innerhalb von 90 Sekunden.
Sie müssen alle Informationen verarbeiten und diese an jemanden weiterleiten, der Maßnahmen ergreifen kann, um Leben zu retten oder in manchen Fällen zu verhindern, dass ein Polizeibeamter auf eine Person zugeht, die eine Bedrohung für ihn darstellen könnte. Und das ist ihnen möglicherweise gar nicht bewusst. Um das zu schaffen, ist natürlich die schnellstmögliche Leistung in Bezug auf die Latenz erforderlich – weniger in Bezug auf den Durchsatz, denn der Durchsatz ist zwar interessant, aber hier nicht der wichtigste Maßstab.
Nachdem das hyperkonvergente System von DataCore implementiert worden war, verschwanden diese Latenzen, die beim Betrieb des SQL-Servers zuvor über 200 Millisekunden betragen hatten. Ich glaube, es war der Name des Herrn, der dies angesprochen hat – sie verschwanden einfach vollständig, sodass die Disponenten, als dies geschah und die neue Funktion eingeführt wurde, im Grunde sagten: „Es sieht so aus, als hätte jemand einen Schalter umgelegt und das Ganze superschnell gemacht.“ Erreicht wurde dies durch die Umstellung auf ein hyperkonvergentes System von DataCore. Ein weiterer bemerkenswerter Effekt war, dass sie zuvor Probleme bei der Einrichtung ihres Notfall-Standorts hatten. Falls es an ihrem Hauptstandort, von dem aus sie diese Anrufe bearbeiten, zu einem Ausfall oder umfangreichen Wartungsarbeiten gekommen wäre, hätten sie zu einem anderen Standort fahren müssen – und wären möglicherweise mehrere Minuten lang nicht erreichbar gewesen, sodass Notrufe im Grunde ins Leere gelaufen wären.
Das kann niemand beantworten. Nachdem wir mit DataCore einen Stretch-Cluster zwischen diesen beiden Standorten eingerichtet hatten, die etwa zwei Meilen voneinander entfernt liegen, konnten die Disponenten während der Wartungszeiten nicht einmal bemerken, wann der Dienst auf den DR-Standort umgeschaltet und wieder zurückgeschaltet wurde. So nahtlos verlief die Reaktion. Das vermittelt Ihnen, denke ich, einen Eindruck davon, wie zügig DataCore diese E/A-Anfragen bearbeitet.
Aber es war auch wichtig und machbar, weil es letztendlich kostengünstiger war. Zusammenfassend lässt sich also sagen, dass sie durch die Umstellung auf dieses hyperkonvergente System ihre Infrastruktur um über 60 Prozent reduziert hatten; sie hatten die Anzahl der Hosts – der physischen Hosts, die sie zum Betrieb benötigten – verringert, da sie all das auf weniger Server zusammenfassten, die doppelte Aufgaben übernahmen, und sie sparten zudem eine ganze Menge bei ihrer SQL Server-Lizenz, da sie weniger Instanzen davon benötigten.
Das ist zwar nichts, woran man normalerweise denkt, wenn man so etwas umsetzt, aber es ist ein wichtiger finanzieller Nebeneffekt einer richtig umgesetzten Hyperkonvergenz. Ein Teil dessen, worüber sie sprechen werden – und worüber auch viele Kunden von hyperkonvergenten Lösungen sprechen –, ist in einer zweiten Gesprächsrunde nicht nur die Leistung, die geringe Latenz und die hohe Verfügbarkeit, sondern auch die Funktionen, die sie nutzen können, um die Wiederherstellung zu verbessern und das Backup sowie die Wiederherstellung von Windows zu minimieren; normalerweise hätten sie dafür separate Backup-Produkte benötigt, die für sie eine gewisse Verzögerung und Unsicherheit mit sich gebracht hätten.
Wir bieten unter anderem Lösungen wie die kontinuierliche Datensicherung (Continuous Data Protection, CDP) an, die vielen von ihnen dabei geholfen hat, Ransomware zu bekämpfen. Das ist heutzutage kein unwesentlicher Faktor. Das Thema sorgt derzeit für viele Schlagzeilen. CDP ist im Grunde eine Methode, die – ähnlich wie ein DVR – den Strom von Ein- und Ausgabevorgängen (IOs) auf kritischen Volumes aufzeichnet und es Ihnen ermöglicht, in der Zeit zurückzugehen, den Zustand vor dem Ransomware-Angriff wiederherzustellen und die Daten von dort wiederherzustellen.
Sie können also den Leuten, die Ihr System kapern, sagen: Tut mir leid, das ist völlig irrelevant. Denn wir können uns davon vollständig erholen. Nachdem das nun gesagt ist, lassen Sie uns ein wenig über die Konfiguration im Allgemeinen sprechen. Eine der Möglichkeiten, die Ihnen das hyperkonvergente System von DataCore bietet, ist die Skalierung ganz nach Bedarf. Sie können problemlos mit einem System beginnen, das anfangs vielleicht nur aus zwei Knoten bestand, und dieses vor Ort erweitern – und zwar nicht nur mit ähnlichen Systemen, sondern Sie können möglicherweise sogar Server nutzen, die Sie bereits vor Ort haben, und diese in dieser Rolle wieder in Betrieb nehmen. Sie müssen also nicht identisch sein.
Und das ist eine Regel, die viele andere Wettbewerber in diesem Bereich durchsetzen: Sie zwingen Sie dazu, in jedem dieser Knoten entsprechende Maschinen zu haben, und das schränkt Sie ein. Der zweite Punkt, auf den ich Ihre Aufmerksamkeit lenken möchte, ist, dass einige dieser Knoten speicherintensiv sein können – das heißt, sie stellen große Speicherkapazitäten bereit; andere sind vielleicht ausschließlich für die Rechenleistung zuständig. Sie können diese Kombinationen natürlich ganz nach Belieben zusammenstellen, und aus meiner Sicht in Bezug auf Lizenzierung und Preisgestaltung spielt die Anzahl der Knoten tatsächlich keine Rolle, da alles kapazitätsbasiert ist.
Wenn man sich die Art und Weise ansieht, wie die DataCore-Software bereitgestellt wird, ist dies recht ungewöhnlich und stellt ein weiteres Alleinstellungsmerkmal dar. In den Diagrammen, die ich hier zeige, ist überall dort, wo Sie diese beiden aquafarbenen Pfeile horizontal sehen, eine Instanz der DataCore-Software im Einsatz. Viele unserer Kunden, die in den vergangenen Jahren zentrale SANs betrieben haben, haben diese genutzt, um Speicher-Arrays von Drittanbietern – sei es Dell, EMC, Hitachi, IBM oder andere – zu bündeln und zu virtualisieren.
Und wir fungieren dabei als Caching-Schicht und Hochverfügbarkeitsschicht, die diese gesammelten Ressourcen bündelt und den Anschein erweckt, als stammten sie potenziell vom selben Hersteller. Dieselbe Software kann auch dann eingesetzt werden – und die gleichen Lizenzen gelten auch dann –, wenn die Nutzungsdauer dieser Speichergeräte endet und man sie durch direkt angeschlossene Speicher ersetzt; es gibt lokalen Speicher auf den Servern, auf denen DataCore läuft, und das ist das zweite Bild, das Sie hier von links sehen.
Das wird also sofort deutlich – das ist die erste Stufe der Konsolidierung. Und irgendwann gelangt man zu einem Szenario, in dem man hyperkonvergiert ist, wenn man Schritt für Schritt vorgeht: Alles passt nahtlos und übersichtlich in die Server hinein, wobei die Anwendungen, der Speicher und alle Netzwerke miteinander kombiniert sind. Auf das vierte Bild werde ich gleich noch eingehen, aber es handelt sich um eine Mischung aus all dem. Ich werde das noch ein wenig im Unklaren lassen.
Wenn Sie nun in der Praxis mit einem hyperkonvergenten System arbeiten, fragen Sie sich vielleicht, wie das alles funktioniert – insbesondere im Hinblick auf die Bereitstellung. Als vSphere-Administrator wird Ihnen das sehr, sehr vertraut vorkommen. Wir nutzen eine Funktion namens VVOLs. VVOLs bedeutet im Grunde, dass Sie einen Katalog der Ihnen zur Verfügung stehenden Ressourcen sehen, die Sie bereitstellen können – sei es Hochleistungsspeicher, Midrange-Speicher oder Sekundärspeicher für große Archive. Diese wählen Sie einfach bei der Erstellung Ihrer VMs aus und geben sie an, genau wie bei jedem anderen Datenspeicher, und DataCore erfüllt diese Anforderungen basierend auf den von Ihnen angeforderten Festplattentypen und der Servicequalität.
Sobald ein System eingerichtet ist, müssen Sie sich also nicht mehr darum kümmern, welche „Magie“ DataCore hinter den Kulissen vollbringt; es sieht einfach aus wie die Ihnen vertraute Bereitstellung und Konfiguration von vSphere-Virtual-Machines, das Zuweisen von Festplatten, das Hinzufügen weiterer Festplatten und all das. Und all dies ist richtlinienbasierter Speicher. Manchmal werden Begriffe wie „Gold“, „Silber“ und „Bronze“ verwendet, um die verschiedenen Service-Levels und Verfügbarkeitsanforderungen zu bezeichnen.
Wenn Sie aus der Microsoft Hyper-V-Welt kommen und ein Fan von Microsoft System Center Virtual Machine Manager sind, gilt das Gleiche auch dort. Sie würden die Ihnen vertraute Benutzeroberfläche zur Bereitstellung dieser virtuellen Maschinen nutzen und sehen, dass Ihnen diese Speicherpools zur Verfügung stehen, auf die Sie zugreifen und die Sie Ihrer virtuellen Maschine zuordnen können.
Die Idee dahinter ist also, Ihnen die Feinheiten der Speicherverwaltung zu verbergen, damit Sie einfach den gewünschten Kapazitätsbedarf decken und die Verfügbarkeits- und Leistungsanforderungen erfüllen können, die Ihre Nutzer an Sie stellen. In der Praxis stellen wir fest, dass dieselbe Software auf vielfältige Weise eingesetzt wird. Dieses Bild veranschaulicht daher nur einen Teil der Vielfalt, auf die Sie bei der Anwendung stoßen könnten. Im Mittelpunkt steht ein bisher dreistufiges SAN, in dem DataCore eingesetzt wird, um diese unterschiedlichen Arrays zu bündeln.
In der linken oberen Ecke ist ein Fall dargestellt, bei dem derselbe Software-Stack nun als hyperkonvergenter Cluster für Tier-1-Anwendungen konfiguriert wurde, die höchste Leistung und geringste Latenz erfordern, aber im Grunde genommen vom Rest Systems abgeschottet sind. Beachten Sie hier, dass an den DR-Standorten dieselbe Software verwendet werden kann, um die Art und Weise zu vereinheitlichen oder zu standardisieren, wie Verbindungen vom Primärstandort zum DR-Standort oder vom Primärstandort zu den Außenstellen und Zweigstellen hergestellt werden.
Und all das lässt sich zentral verwalten. Tatsächlich können sich die Eigenschaften dieser Standorte – was einst vielleicht eine Zweigstelle war – zu einem DR-Standort entwickeln, und man muss das System lediglich neu einrichten und konfigurieren, sodass das Element oben rechts im Laufe der Zeit zunehmend dem darunter liegenden ähnelt, da sich die Definition und die Anforderungen für diese Zweigstelle erweitert haben. Und das alles ohne einen kompletten Umbau.
Das lag einfach daran, dass wir damit begonnen haben, zusätzliche Ressourcen zu konfigurieren und dem System den Zugriff auf diese Ressourcen zu ermöglichen – und damit hat sich die Rolle geändert. Das Gleiche gilt, wenn Sie eine Notfallwiederherstellung in die Cloud durchführen möchten. Nehmen wir an, Sie möchten eine Kopie von Ihrer lokalen Umgebung in Azure oder AWS übertragen. In diesem Fall würden Sie beispielsweise über ein oder mehrere hyperkonvergente Systeme vor Ort verfügen, die Daten an Kopien der DataCore-Software replizieren, die sich in dieser öffentlichen Cloud befinden.
Es würde fast so aussehen, als befände man sich in einem Colocation-Rechenzentrum oder einfach in einer weiteren Niederlassung. Der einzige Unterschied besteht darin, wie diese Kapazität verwaltet wird. Es gibt eine Reihe von Vorteilen, die ich hier hervorheben möchte. Letztendlich gibt es nur wenige Aspekte, die wirklich einen Unterschied ausmachen und die bei der Bewertung unseres Produkts besonders hervorstechen. Dabei geht es vor allem um die Reaktionsgeschwindigkeit des Systems und das Preis-Leistungs-Verhältnis, aber auch um die Flexibilität. Anstatt Ihnen also etwas aufzuzwingen und Ihnen die Hände zu binden – etwa mit der Aussage: „Ihre hyperkonvergente Lösung muss so aussehen, weil sie so definiert wurde“ –, geben wir Ihnen die Möglichkeit, das System anzupassen und Änderungen daran vorzunehmen, damit es zu Ihrer bestehenden Infrastruktur passt und Sie diese Ressourcen nutzen können, anstatt sie einfach wegzuwerfen, nur weil die Architektur dies erzwingt.
Und hier ist nun der Umstieg, den ich jedem von Ihnen empfehlen würde, insbesondere wenn Sie von einem dreistufigen SAN kommen. Er ist ziemlich unkompliziert und erfolgt auf Eigeninitiative. Der erste Schritt besteht darin, dass man sich sagt: „Okay, wenn ich die Kontrolle über meine vorhandene Vielfalt übernehmen möchte, würde ich als Erstes die DataCore-Software zwischen meinem aktuellen Host und den physischen Servern oder Bare-Metal-Servern installieren, um diese Arrays zu bündeln.“ Sobald wir der Meinung sind, dass diese Arrays ihren finanziellen Wert überschritten haben, und wir sie durch internen Speicher ersetzen, bleibt das Betriebsverhalten unverändert. Die Leistung kann in manchen Fällen sogar die im Test gezeigte Leistung übertreffen – das, was Sie auf der linken Seite sehen –, da einige dieser Arrays tatsächlich schon etwas in die Jahre gekommen sind; ich denke, so könnte man es beschreiben.
Und sie sind schlichtweg nicht in der Lage, die Geschwindigkeiten zu liefern, die Solid-State-Discs und flash – flash – direkt auf diesen Servern bieten können. Im zweiten Schritt dieses Übergangs bekommt man dann einen Eindruck davon, was passiert, wenn diese Server eine Doppelbelastung bewältigen müssen. Sie dienen nicht nur als Speicher, sondern übernehmen sowohl die Speicher- als auch die Rechenlast der Anwendungen.
Das ist also die dritte Abbildung. Und an dieser Stelle könnte man sagen: „Hey, ich möchte ein paar Knoten auf diese Weise einrichten. Mal sehen, wie das funktioniert. Kann ich die geforderte Servicequalität gewährleisten? Fühle ich mich wohl dabei, die Umgebung auf diese Weise zu betreiben? Und wenn ja, dann ist alles gut.“ Sie sind am Ziel und wenden dann dieses Vorgehen gewissermaßen auf die Rest Knoten an. Möglicherweise stellen Sie auch fest, dass es einige Ausreißer gibt. Vielleicht haben Sie einige Bare-Metal-Maschinen, die niemals Teil Ihrer hyperkonvergenten Infrastruktur sein werden. Ganz einfach: Niemand wird sich die Zeit nehmen, diese Anwendung zu virtualisieren und in einen Cluster zu integrieren.
Und mit einer Hybridlösung auf dieser Basis können Sie Kapazität besser bereitstellen und nutzen. Das heißt, ich nehme mein hyperkonvergentes System, das normalerweise nur die Anforderungen des privaten Clusters erfüllt, und stelle entweder Fibre-Channel- oder I-Scuzzy-Verbindungen zu diesen externen Hosts her, die ausschließlich Kapazitätsverbraucher sind. Sie tragen nicht zum Speicherpool bei.
Auch sie profitieren von der hohen Verfügbarkeit und den niedrigen Kosten. Vor diesem Hintergrund möchte ich Sie nun einladen, sich die Folien anzusehen. Vereinbaren Sie eine live demo uns. Über den Link, den ich Ihnen hier zur Verfügung stelle, können Sie einen Termin vereinbaren. Einer unserer Lösungsberater wird sich dann mit Ihnen in Verbindung setzen und Sie durch den Prozess führen, damit Sie sehen können, wie unkompliziert das Ganze ist und wie es sich auf Ihre Umgebung und die für Sie geltenden Governance-Regeln anwenden lässt. Anschließend stehen wir Ihnen für Fragen zur Verfügung.
Danielle: Wie ich sehe, haben wir hier ein paar Fragen, Augie. Die erste wäre: Wie sieht die Preisgestaltung für deine Software aus?
Augie: Okay. Ja. Die Preisgestaltung für die Software ist sehr übersichtlich. Sie ist nutzungsabhängig, d. h., es kommt darauf an, wie viel Kapazität Sie verwalten; das heißt, wie viel Kapazität Sie verwalten und wie viel Kapazität uns zur Verfügung steht, um das hyperkonvergente System oder das dreistufige SAN zu bedienen – das gilt für beides gleichermaßen. Und wir haben drei Modelle. Im Grunde ist eines davon das Top-Run-Premium-Modell, das alle Extras für höchste Leistung bietet – sozusagen das, was ich als „erste Wahl“ bezeichne.
Ich biete auch ein Premium-Geschäftsmodell an. Außerdem gibt es das Economy-Modell, das eigentlich für den groß angelegten Sekundärspeicher gedacht ist. Bitte wenden Sie sich an einen unserer Anbieter von Mehrwertlösungen, um sich über das Komplettpaket zu informieren.
Danielle: Super, danke. Und dann noch eine letzte Frage, bevor wir zum Ende kommen: Kann ich Ihre Software in der Cloud nutzen?
Augie: Ja, darauf bin ich ganz kurz eingegangen. Ich bin nicht allzu sehr ins Detail gegangen. Wir beobachten also zunehmend eine Kombination, eigentlich einedeployment DataCore, bei der man am Anfang steht und der Schwerpunkt zunächst vor allem darauf liegt, die Geschäftsabläufe vor Ort zu regeln – und anstatt irgendwo anders einen Remote-Standort einzurichten, der physische Infrastruktur erfordert, nutzt man Cloud , öffentliche Cloud , um diese zweite oder dritte Kopie der Daten zu erstellen und so im Falle einer größeren Katastrophe darauf zurückgreifen zu können – oder vielmehr, um die Folgen einer solchen Katastrophe von vornherein zu vermeiden.
Die Software ist also genau dasselbe Paket. Sie installieren sie einfach auf einer Instanz, auf einer virtuellen Maschine oder auf mehreren virtuellen Maschinen – sei es auf AWS, Google Cloud oder was auch immer.
Danielle: Okay, ich glaube, wir – ich sehe, dass noch ein paar Fragen hereinkommen. Falls jemand weitere Fragen hat, kann er uns gerne auch eine E-Mail schicken – die entsprechenden Informationen finden Sie auf unserer Website. Sie können sich an einen Solutions Architect wenden, der Ihre weiteren Fragen in einem persönlicheren Rahmen beantworten wird.
Damit möchte ich nun zum Abschluss kommen und noch kurz erwähnen, bevor Sie gehen: Wir möchten Ihnen unbedingt mitteilen, dass wir Ihnen eine PDF-Version dieser Präsentation zur Verfügung stellen werden, die Sie in der E-Mail mit dem On-Demand-Link finden werden. BrightTALK wird Ihnen ebenfalls eine E-Mail senden. Und zu guter Letzt: Wir sind stets auf der Suche nach Möglichkeiten, uns zu verbessern. Vergessen Sie also nicht, sich dieses Webinar noch einmal anzusehen, bevor Sie gehen. Und damit wünsche ich Ihnen allen einen schönen Tag. Vielen Dank.