Fakt oder Fiktion: Hohe Verfügbarkeit durch den Einsatz eines einzigen Speicheranbieters

Ich möchte mich bei Ihnen dafür bedanken, dass Sie heute an unserem Webinar zum Thema „Fakt oder Fiktion – Hochverfügbarkeit durch den Einsatz eines einzigen Speicheranbieters“ teilnehmen, das von DataCore präsentiert wird. Unser Referent heute ist Steve, der als Director of Solution Architecture bei DataCore tätig ist.

Steve Hunsaker: Vielen Dank, Whitney, und wir wissen alles zu schätzen, was du für uns getan hast. Wir haben uns schon sehr darauf gefreut und sind gespannt darauf, in den nächsten 45 Minuten mit [ihnen] über dieses „Fakt oder Fiktion“ zu sprechen. Ich werde die Katze gleich aus dem Sack lassen – natürlich ist es Fiktion. [Gelächter] Wir – ich kann mich noch genau daran erinnern, wie ich in meinem Rechenzentrum an einer Wand lehnte und mir meine gesamte Infrastruktur und alle meine Ressourcen ansah, wissen Sie, und da dachte ich mir: Nun, ich habe redundante Switches und redundante Router, und dennoch sind meine Daten nicht redundant, und das ist nicht besonders gut. Es ist also Fiktion, und ich hoffe, in der kurzen Zeit, die uns zur Verfügung steht, erklären zu können, warum das so ist, was DataCore macht, wie wir das bewerkstelligen, und einige unserer Funktionen und Fähigkeiten vorzustellen. Ich habe – natürlich habe ich eine PowerPoint-Präsentation, die ich durchgehen muss. [Gelächter] Aber ich habe ein Whiteboard hinter mir und eine Kamera, die umschalten wird, damit wir das gemeinsam am Whiteboard durchgehen können. Bitte lassen Sie mich wissen, wenn Sie Fragen haben; ich werde sie in Echtzeit beantworten. Und bitte denken Sie daran, dass Sie mir jederzeit eine E-Mail an Steve.Hunsaker@datacore.com senden können.

Na gut. Dann fange ich einfach mal an und komme gleich zur Sache. Da ich nicht auf ein-zu-eins-Vergleiche angewiesen bin, hielt ich es für das Beste, mit unseren deployment zu beginnen und darüber zu sprechen, was wir alles leisten können, welche Flexibilität unser Produkt bietet, was wir tun und wer wir sind – all das wird sich im Laufe der Präsentation von selbst ergeben.

Sie verfügen wahrscheinlich alle über Speicher-Arrays, und wie Sie wissen, kann es sich dabei um Fibre-Channel-, ISCSI oder NFS handeln. SANsymphony ein Blockspeicherprodukt, daher müssen wir uns wirklich auf Fibre-Channel und ISCSI konzentrieren. Beginnen wir links: Dort sehen wir ein traditionelles Speichermodell, bei dem Sie in der Regel ein Speicherarray in Ihrem Rechenzentrum haben. In den meisten Fällen – ich würde sagen in 99 Prozent der Fälle – erfordern die meisten Speicherarrays natürlich, dass Sie genau dieselbe Marke und dasselbe Modell kaufen, um Ihre Daten an einem anderen Standort bereitzustellen. Und genau deshalb lautet der Titel dieses Webinars „Fakt oder Fiktion“, denn wir vertreten die Ansicht, dass Sie das nicht tun müssen. Das mag vielleicht ein wenig altmodisch klingen, und das ist es auch, denn wir machen das schon seit 21 Jahren so. Aber wenn wir diese deployment durchgehen, werden Sie meiner Meinung nach erkennen, wie wir uns weiterentwickelt haben, wie sich die Branche weiterentwickelt hat, und das hat unsere Fähigkeit, der Branche einige ziemlich einzigartige Funktionen und Möglichkeiten anzubieten, nur noch verstärkt.

Dann gibt es noch „Converged“, bei dem ich lokalen Speicher nutzen und daraus ein SAN der Enterprise-Klasse aufbauen kann, ISCSI Fibre-Channel- oder ISCSI bereitstellt. Und dann gibt es noch „Hyper-Converged“ – dieses Schlagwort, das in letzter Zeit in aller Munde ist und das ihr wahrscheinlich schon nicht mehr hören könnt –, aber eigentlich wiederholt sich hier nur die Geschichte: Anwendungen kehren wieder auf den lokalen Speicher zurück. Und dann gibt es noch „Hybrid Converged“ – ein Konzept, das wir als neuen Ansatz vorschlagen: Dabei können nicht nur die Anwendungen zurückkehren und der Speicher auf demselben Host wie alle anderen Gäste verwaltet werden, sondern es können auch weiterhin andere physische Server vorhanden sein – etwa mit Linux, Oracle oder Unix – oder andere, wie vielleicht ein Hyper-V-Cluster oder VMware weiterer VMware , denen wir ebenfalls Festplatten zur Verfügung stellen können. Darauf werde ich später noch näher eingehen. Das sind jedoch einige deployment , über die man nachdenken sollte, während wir dies umsetzen.

Eine meiner Überzeugungen – und das ist ein berühmter Spruch von mir – lautet: DataCore verhält sich zum Speicher wie VMware zu Servern. Ich kann mich noch genau daran erinnern, wie ängstlich, nervös und sogar zögerlich ich war, als ich von einem physischen Server auf einen virtuellen Server umsteigen sollte – das mag vielleicht wie vor 15 Jahren klingen, aber ehrlich gesagt hat es etwas länger gedauert, bis die Branche und auch Sie selbst erkannt haben, dass sich Speicher ebenfalls virtualisieren lässt. Ich möchte daher auf einige der Vorteile eingehen, die mir die Servervirtualisierung gebracht hat, und auf einen der Gründe, warum ich niemals wieder zurückgehen würde. Wir würden wahrscheinlich niemals wieder zurückgehen. Wir alle schätzen es sehr, dass ich virtuell einen Server hochfahren kann, der Mobilität, Redundanz und Hochverfügbarkeit bietet – all diese Vorteile sind von großem Nutzen und echte Lebensretter, und wir würden es nicht anders haben wollen.

Und ich beobachte, dass sich bei der Speicherung dasselbe abspielt. Ich würde es wirklich nicht anders wollen. Genau diese Gründe sind auch die Gründe, warum ich meinen Speicher virtualisieren würde. Damit schaffe ich die Möglichkeit, diese virtuellen Festplatten zu verschieben – statt virtueller Maschinen –, und nun können virtuelle Festplatten ausgetauscht und verschoben werden, während der zugrunde liegende Speicher gleichzeitig ausgetauscht, aufgerüstet oder erweitert wird, und es gibt alle möglichen – wissen Sie, die Denkweise dabei ist, dass wir die Kapazität immer erhöhen müssen, die Datenmenge wächst ständig, es wird immer besseren und schnelleren Speicher geben, die Branche wird stets versuchen, die Leistung zu steigern, und wir neigen dazu, Marketingbegriffe wie die Vermeidung von Herstellerabhängigkeit zu verwenden – und das ermöglicht uns mehr Flexibilität, uns um den zugrunde liegenden Speicher zu kümmern und Ihnen gleichzeitig die Verfügbarkeit – fünf Neuner, sechs Neuner – der Speicherverfügbarkeit zu gewährleisten, während Ihr Speicher gewartet oder ausgetauscht wird, dank dessen, was wir auf den Tisch bringen.

Das ist also, kurz gesagt, und dies ist wahrscheinlich die letzte Folie, mit der wir uns ausführlich beschäftigen werden, aber ich möchte Ihnen den Aufbau dieser Folie erläutern und dabei von unten nach oben vorgehen. Auf diese Weise – und ich werde das Gleiche anschließend am Whiteboard darstellen, damit Sie anhand von Abbildungen, wenn man so will, anhand von Diagrammen sehen können, wie das Ganze funktioniert. Der Name unseres Produkts lautet also DataCore SANsymphony. Wir sind ein reines Software-Unternehmen. Wir haben zwar eine Appliance, aber im Grunde sind wir ein Softwareunternehmen, und der Name der Software lautet SANsymphony. SANsymphony die Orchestrierung verschiedener Speicher-Arrays, SANsymphony , ob es sich um NVMe handelt NVMe und wenn ich hier ein guter Referent bin, hole ich SANsymphony meinen kleinen Marker heraus –, ob es sich um NVMe Fibre Channel, ISCSI, SAS oder SATA oder die cloud handelt; lassen Sie uns das Schritt für Schritt durchgehen.

Ich kann NVMe eines Servers, eine Fibre-Channel-LUN aus einem anderen Array oder eine beliebige Anzahl von Fibre-Channel-LUNs, eine ISCSI , eine SAS- oder SATA-Festplatte im Gehäuse oder ein angeschlossenes JBOD sowie ein cloud nutzen und all diese Speicherprotokolle in einem einzigen, aggregierten Pool zusammenführen. Und das ist an sich schon ein interessantes Konzept. Wenn ich zum Beispiel über fünf Terabyte NVMe, eine fünf Terabyte große Fibre-Channel-LUN, eine fünf Terabyte ISCSI und ein fünf Terabyte großes SAS-JBOD-Shelf verfüge, bedeutet das, dass ich aus jedem dieser vier beitragenden Elemente einen einzigen 20-Terabyte-Pool erstellen kann. Und dann kann ich innerhalb dieses Pools damit beginnen, die Features und Funktionen zu nutzen, die wir weiter oben auf dieser Folie oder in dieser Abbildung sehen. Ich kann dann die Speicherblöcke innerhalb dieses Pools automatisch in Tiers einordnen, indem ich kleine Speicherzuweisungseinheiten – wie wir sie nennen – im Tier-Stack nach oben oder unten verschiebe, wie hier [rot] dargestellt. Dazu verwenden wir einen Algorithmus, der die Lesehäufigkeit berücksichtigt, und verschieben die Einheiten entsprechend im Tier-Stack nach oben oder unten.

Und genau deshalb würde man traditionell niemals auch nur im Traum daran denken,
eine NVMe mit einer SATA-Festplatte mit 5400 U/min zu kombinieren, aber bei uns ist das möglich, dank dieses Echtzeit-Auto-Tiering. Das geschieht in Echtzeit, nicht nach einem Zeitplan oder Ähnlichem. Aber hier ist der springende Punkt, und lassen Sie mich noch einmal auf die fiktive Antwort auf den Titel unserer heutigen Diskussion zurückkommen. Unabhängig davon, was Sie haben, kann ich diesen Pool synchron spiegeln, indem ich etwas nutze, das wir eine virtuelle Festplatte nennen. Ich richte also eine virtuelle Festplatte auf diesem Pool ein, und wenn ich nun – ich bin kein großer Fan davon, Anbieternamen zu nennen, aber wenn ich eine oder mehrere Fibre-Channel-LUNs habe – oder auch ISCSI –, und ich habe sie alle zusammengeführt, sogar mit einigen internen Festplatten, dann stellt das einen Pool dar, den ich nun auf einen anderen Pool spiegeln kann, der vielleicht aus völlig anderem Speicher besteht. Und genau das ist der springende Punkt, die Antwort und der Grund, warum wir betonen, dass der Titel reine Fiktion ist.

Es gibt also jede Menge Features und Funktionen; ich möchte hier nicht allzu viel Zeit darauf verwenden, aber Sie sollten wissen, dass wir einige ziemlich coole Features haben. Und wenn wir dann weitermachen und über unsere Zugriffsmethoden sprechen: Ich kann diese virtuellen Festplatten als Fibre-Channel, ISCSI, NFS SMB bereitstellen, und auf diese Weise können alle unsere externen Hosts den von uns bereitgestellten Speicher nutzen. Lassen Sie mich also meine Zeichnungen löschen, ein paar Folien zurückblättern und die deployment noch einmal durchgehen, um sicherzustellen, dass wir alle verstehen, in welche Richtung es geht. Wenn ich also ganz rechts beginnen und noch einmal auf das Hybridmodell eingehen darf: Was wir damit sagen – nun, da Sie vielleicht schon ein wenig besser verstehen, was wir tun –, ist, dass DataCore nicht nur als virtuelle Appliance auf beispielsweise einemhypervisor laufen kann, um alle Fibre-Channel-LUNs und alle ISCSI aus dem vorhandenen Speicher in Ihren Umgebungen einzubinden, sondern auch in der Lage ist, alle lokalen Festplatten zu nutzen, das JBOD, das an diesen Server angeschlossen ist, nutzen, all diesen Speicher zusammenführen und dann dem ESX-Cluster, auf dem ich mich befinde, sowie den virtuellen Gästen – den Maschinen, die sich auf demselben Server befinden – Speicher zur Verfügung stellen. Gleichzeitig bin ich auch in der Lage, externen Hosts eine Fibre-Channel- oderSMB bereitzustellen. Das ist also Ihr Hybridansatz.

Nun gehe ich kurz zum Whiteboard, um sicherzustellen, dass – ich habe die Kamera hier entsprechend umgestellt – und fange an, ein paar Dinge für Sie zu skizzieren und zu erklären, wie wir diesen synchronen Spiegelungsvorgang umsetzen. Sie sollten diese Darstellung hier auf meinem Whiteboard sehen können. Also, los geht’s. Ich habe also ein Array, und zwar über Fibre-Channel – denken Sie daran, dass das eine ganze Reihe von LUNs sein könnte. Ich habe ein weiteres Array, möglicherweise über ISCSI, und vielleicht habe ich noch einige lokale NVMe sowie ein JBOD daran angeschlossen – das sind die verschiedenen Speichermedien, die in meinem Zuständigkeitsbereich liegen können. Ich habe einen Host, den wir – nennen wir ihn vorerst einfach „DataCore“ – und ich möchte hier nicht zu sehr ins Detail gehen, aber das könnte ein ESX-Host sein, auf dem wir als virtuelle Maschine laufen, oder wir könnten einfach ein eigenständiger Knoten im eher traditionellen Sinne sein. Der Punkt ist jedoch, dass ich jedes dieser Elemente nehmen, sie zusammenfassen und, wie gesagt, auf eine andere Seite spiegeln kann.

Also, lassen Sie uns diese beiden Knoten einmal aufbauen: Ich habe nun DataCore 1 mit seinem gesamten Speicher und DataCore 2 mit seinem gesamten Speicher. Das spielt keine Rolle – sie müssen nicht übereinstimmen – denken Sie an das fiktive Szenario – und dann kann ich Spiegelpfade verwenden, die hoffentlich redundant sind, und diese Spiegelpfade sind entweder Fibre-Channel oder ISCSI. Und ich zeichne zwei, denn natürlich können sie redundant sein; natürlich möchten wir, dass Sie das haben. Es können auch mehr sein; sie können über einen Switch, einen Fibre-Channel-Switch oder einen Ethernet-Switch geschaltet werden, oder sie können direkt von Knoten zu Knoten verbunden sein. Was sind also diese Knoten? Diese Knoten sind beliebige x86-Server. Was wir also im Grunde sagen, ist: Sie stellen einen Server Ihrer Wahl bereit – sei es von Lenovo, Super Micro, Dell, HP oder einem anderen Hersteller – und installieren DataCore auf diesem Knoten. Damit verfügen wir nun über zwei Speichercontroller, die den gesamten darunterliegenden Speicher bündeln und Spiegelungen durchführen können.

Das sind also die Pfade. Wir erstellen nun die sogenannte virtuelle Festplatte, und ich werde das gleich hier in unserer GUI zeigen. Wir haben nun eine virtuelle Festplatte, die von beiden Knoten erkannt wird. Mit anderen Worten: Wir haben nun die beiden Speichercontroller aufgeteilt. Dieser Spiegelpfad kann also eine gewisse Entfernung haben, und wir möchten, dass die Latenz auf diesen Spiegelpfaden unter fünf Millisekunden liegt. Der springende Punkt ist jedoch: Meine Daten sind nun aufgeteilt, und ich verfüge über echte Hochverfügbarkeit – Aktiv-Aktiv, von Standort B zu Standort A, oder wie auch immer. Ja, wir haben Kunden, bei denen sich beide im selben Rack, im selben Schrank und im selben Raum befinden, aber wir haben auch Kunden, bei denen sie sich in verschiedenen Räumen oder verschiedenen Gebäuden auf dem Campus befinden. Oder in verschiedenen Städten. Wir haben die Daten aufgeteilt und verfügen nun über echte Hochverfügbarkeit. Ein synchroner Spiegel ist also im Grunde – wenn man es so betrachten kann – RAID 1. Und es ist ein echter Spiegel. Was auch immer also mit dieser Festplatte passiert, wird auf beide Seiten geschrieben. Denken Sie daran, dass ich gesagt habe, dass diese Festplatte über Fibre-Channel, ISCSI usw. bereitgestellt werden kann.

Nun, wenn ich einen DSX-Cluster habe, an den ich Daten weitergeleitet habe, wird dieser in ESX als Datenspeicher angezeigt. Und dieser Datenspeicher nutzt beim Schreiben die drei NPIO-Verfahren – Round-Robin, „Most Recently Used“ (MRU) oder „Fixed Path“ – und entscheidet selbst, welchen Pfad er nimmt. Aber ESX sieht auf jeden Fall alle Pfade, die ich ihm für diesen Datenspeicher zugewiesen habe. In einer einwandfrei funktionierenden Umgebung, in der alle Pfade vorhanden sind und alles im Active-Active-Modus läuft, könnte die Datenanforderung – sagen wir mal – auf den Pfad links von DataCore 1 fallen. Nun, hier kommen wir zu den Details und werden etwas technischer, wenn es darum geht, wie wir den synchronen Spiegel aufrechterhalten. Diese Datenanforderung wird im RAM empfangen. Das ist ein entscheidender Unterschied, denn einige unserer Konkurrenzprodukte nutzen Festplatten oder eine Form von Festplattenspeicher, um ihre Schreib- und Lesevorgänge zwischenzuspeichern. Wir nutzen den Arbeitsspeicher (RAM), um Schreib- und Lesevorgänge zwischenzuspeichern. Diese Daten werden über den Spiegel – einen der Spiegelpfade – gesendet und auf der anderen Seite im RAM empfangen; anschließend senden wir eine T-10-SCSI-Bestätigung gemäß dem ANSI-Standard und senden diese [AK] im umgekehrten Prozess über den – zurück [unverständlich 0:20:10] den Spiegelpfad zurück an die ESX-VM, die sich auf der rechten Seite befindet.

Wir spiegeln also das Recht auf beide Seiten in dieser „Aktiv-Aktiv“-Weise vollständig wider. Im Falle einer Katastrophe – ganz gleich, was passiert, bei welcher Komponente auf der linken Seite – lassen Sie mich meinen roten Stift zur Hand nehmen: Unabhängig von der Art der Katastrophe und davon, welche Komponente dabei ausfällt, erkennt ESX diese Pfade möglicherweise als ausgefallen, oder auch nicht – vielleicht sind die Pfade in Ordnung, vielleicht liegt das Problem beim zugrunde liegenden Speicher; der Punkt ist, dass Sie mit dieser synchronen Spiegelung oder der echten RAID-1-Verfügbarkeit auf der anderen Seite eine weitere aktive Seite haben. Also ja, man muss hier Speicher haben und dort Speicher. Wenn man 100 Terabyte Kapazität benötigt, muss man hier 100 Terabyte haben und dort 100 Terabyte. So schaffen wir also diesen fiktiven Aspekt, dass nicht auf beiden Seiten derselbe Speicheranbieter erforderlich ist.

Ich wechsle jetzt kurz die Kamera und zeige Ihnen unsere Benutzeroberfläche. Gut. Ich wechsle nun zu unserer Benutzeroberfläche, auf die ich per Remote-Desktop zugreife, und auf diesem Bildschirm sehen Sie meine drei DataCore-Server. Ich habe eine Servergruppe mit dem Namen „Demo Lab“, die drei DataCore-Engines bzw. Server enthält. Wir support zu 64 innerhalb einer einzelnen Organisationseinheit oder Servergruppe. Dies ist SAN 1, und ich habe mir die Freiheit genommen, hier einfach meine eigene Demo-Umgebung zu erstellen – bitte haben Sie dafür Verständnis. Darin befinden sich jedoch physische Festplatten jeglicher Art, und genau das möchte ich verdeutlichen: Ich habe – vielleicht eine Fibre-Channel-LUN, vielleicht eine ISCSI oder vielleicht auch interne Festplatten im Server. Diese physischen Festplatten können zum Erstellen von Pools verwendet werden, und das ist der nächste Baustein. Ich habe also diese physischen Festplatten, und ich zeige Ihnen die Pools, denen sie tatsächlich bereits zugewiesen sind. Hier habe ich meine Pools: Disk Pool 1 und CDP. Diese Pools setzen sich aus diesen physischen Festplatten zusammen.

Nun, ich habe das tatsächlich schon ausprobiert, und ich werde mit Ihnen ein wenig ins Detail gehen und das zeigen – mir gefällt, wie flexibel und leistungsstark wir sind, und ich möchte demonstrieren, dass ich tatsächlich ein Disk-Pool-Mitglied habe, bei dem es sich um eine gespiegelte, agile LUN handelt, oder – und um eine 3PAR-LUN. Wir haben also tatsächlich die Möglichkeit, LUNs zu spiegeln, und dieses gespiegelte Paar physischer Festplatten stellt innerhalb des Festplattenpools eine eigenständige Festplatte dar, was einfach unglaublich ausfallsicher und fantastisch ist. Ich habe einen Festplattenpool, dann habe ich virtuelle Pool-Festplatten, wo ich in diesem Fall eine namens „ESXi“, die ich erstellt habe, und wie Sie auf diesem Bildschirm sehen können, verfügt sie über eine Reihe von Pfaden, die entweder aktiv und verbunden sind, und es wird angezeigt, wer die Initiatoren und die Ziele sind. Das verdeutlicht, dass DataCore SANsymphony – jener Server, den ich hinter mir eingezeichnet habe, der Server, über den wir gesprochen haben – sowohl ein gleichzeitiger Initiator als auch ein Ziel ist. Ich initiiere also Verbindungen zu Backend-Systemen und stelle deren Speicher zur Verfügung, und gleichzeitig bin ich ein Ziel für die Initiatoren in der Branche, wie ESX, Hyper-V usw., und kann ihnen Speicher bereitstellen.

Und das alles ergibt sich aus der Natur der Server-Ports. Ich habe daher tatsächlich versucht, hier in meinem eigenen Labor eine Art Best-Practice-Lösung aufzubauen, bei der ich zwei Front-End-Pfade und zwei Spiegelpfade habe. Und wie ich euch bereits gesagt habe, schummle ich ein bisschen, weil ich zu Hause nicht über all diesen Speicherplatz im Back-End verfüge. [Gelächter] Aber ihr hättet zwei Back-End-Pfade, wenn ihr über Back-End-Speicher verfügen würdet.

Um ganz offen zu sein und Ihnen zu zeigen, wie das funktioniert: Das sind alles ISCSI, daher präsentiere ich hier 229,1, 91,1, und ich zeige Ihnen, woher ich lese, damit Sie sehen können – das ist die IP-Adresse und der IQN, von denen wir sprechen. Ich werde das jetzt löschen und meinen Zeiger wieder auf den Pfeil umstellen. Nun haben wir zwei Front-End-Pfade, zwei Spiegel, und das alles über ISCSI. Wenn ich es Ihnen auf der Seite des physischen Adapters zeige, können Sie sehen, dass ich tatsächlich – und ich mache das gerne, da ich ein bisschen zwanghaft bin –, aber ich habe die – Microsoft hat es immer noch nicht hinbekommen, die IP-Adresse hier als eine der Spalten einzufügen, und falls jemand weiß, wie das geht, lassen Sie es mich wissen. Aber ich benenne sie einfach mit ihrer IP-Adresse und ihrem Namen, damit ich den Überblick über alle behalten kann. Tatsächlich habe ich, wie viele, sechs – sechs [Nicks], die alle IP-basiert sind, und ich habe sie nach ihren Rollen und ihrer Funktionalität benannt. Das zeigt euch also die technischen Details, wie das alles abläuft und wie wir das hinbekommen.

Diese Spiegelungsports übertragen also lediglich die DataCore-spezifischen Rechte über diese Verbindung an den oder die anderen DataCore-Knoten, um diesen RAID-1-Ansatz, also die synchrone Spiegelung, zu gewährleisten, sodass die Daten auch dann noch verfügbar wären, sollte einer dieser Knoten ausfallen. Auf einer virtuellen Festplatte stehen mir dann zahlreiche Funktionen und Möglichkeiten zur Verfügung, wie wir Ihnen bereits anhand der Tabelle gezeigt haben, in der der Großteil meines Funktionsumfangs genau hier bei der virtuellen Festplatte zu finden ist. Ich kann also weitere virtuelle Festplatten erstellen – sie aufteilen und aus dem Dienst nehmen. Da es sich um ein gespiegeltes Paar handelt, kann ich sie aufteilen oder trennen und so zwei einzelne Einheiten daraus machen. Ich kann den Speicher austauschen und verschieben, ein Speicherprofil einrichten, und in der Branche verwenden wir gerne Begriffe wie „pin“ – ich möchte diese Festplatte an eine SSD „pinnen“ oder vielleicht auch umgekehrt – ich weiß, dass auf diese Festplatte eigentlich nie wirklich zugegriffen wird, also möchte ich sie in die unteren Archivierungsebenen verschieben.

Ich kann CDP aktivieren – eine fantastische Funktion, die es mir ermöglicht, ein Journal zu führen und auf eine bestimmte Sekunde zurückzusetzen. Innerhalb eines bestimmten Zeitraums, der von anderen Elementen in Ihrer Infrastruktur abhängt – ich kann ja nicht einfach, wissen Sie, sagen, wie viele Tage das bei Ihnen sein werden, aber nehmen wir mal an, es sind 14 Tage – Sie haben die Möglichkeit, auf eine bestimmte Sekunde zurückzusetzen, genau wie bei einer Transaktionsprotokoll-Wiederherstellung. Es ist genau dasselbe Prinzip: Wir haben ein Journal, das alle Transaktionen protokolliert. Ich kann snapshots und einen snapshot erstellen; ich kann ihn während der Spiegelung replizieren und anschließend asynchron an einen entfernten Ort replizieren, wissen Sie, an einen weit entfernten Ort. Vielleicht Azure, Google, AWS oder Mr. Frosts Garage, ich weiß es nicht. Aber der Punkt ist: Wir können ihn während der Spiegelung an einen dritten Standort replizieren und Ihnen so ein gewisses Maß an Notfallwiederherstellung (DR) bieten.

Ich kann diese gruppieren und an verschiedene Hosts verteilen, und das werde ich Ihnen jetzt zeigen. Diese virtuelle ESX-Festplatte enthält also einige Informationen, und ich werde das hier kurz hervorheben. Sie sehen, dass sie auf dem neuesten Stand ist, sie ist grün – ich hole mal meinen Textmarker heraus – ich habe einen grünen „Up-to-date“-Status auf SAN 1, ich habe einen grünen „Up-to-date“-Status auf SAN 2, und ich habe tatsächlich einen „Up-to-date“-Status auf SAN 3, und ihr seht, dass der Host-Zugriff deaktiviert ist, denn wenn wir eine Drei-Wege-Spiegelung durchführen – was für alle unter euch gilt, die geschäftskritische Anwendungen betreiben und eine Verfügbarkeit von sieben oder acht Neunen benötigen, kein Scherz –, können wir ein Drei-Wege-RAID über diese verschiedenen Speicherpools hinweg einrichten und eure Daten wirklich hochverfügbar machen. Wir betreiben jedoch kein Aktiv-Aktiv-System auf allen drei, sondern ein Aktiv-Aktiv-Passiv-System. Wenn also einer dieser Speicher ausfällt, wird der dritte aktiv. Lassen Sie mich meine Skizzen löschen und zum nächsten Punkt übergehen, den ich Ihnen zeigen wollte.

Also, hier auf meiner Registerkarte „Einstellungen“ möchte ich besonders darauf achten, denn das ist meine SCSI-Geräte-ID, meine NAA, und ihr seht, dass AF29 meine – also die letzten vier Ziffern sind. Lasst mich mich bei meinem ESX-Server anmelden und euch einfach zeigen, wie das aussieht, und dass ich mir das nicht nur ausdenke, und ich führe euch hier Schritt für Schritt durch den Vorgang. Wenn ich mich nur an mein Passwort erinnern kann. Oh nein. Und ihr seht, dass ich etwas Speicherplatz habe – wo wir gerade dabei sind: Erinnert ihr euch, als ich euch erzählt habe, dass wir ISCSI all diese Pfade haben? Lasst mich mal meinen Marker herausholen – hier sind alle Front-End-Ports. Der Grund, warum wir sechs haben, ist, dass ich zwei Front-End-Ports von jedem der drei DataCore-Hosts habe. Mit dieser Dreifach-Spiegelung erkennt ESX sie alle [angeschlossen]; es ist in der Lage, vier dieser sechs oder eigentlich sogar alle sechs zu nutzen – DataCore handelt den Host-Zugriff zwar nicht aus, aber alle sechs [werden weitergeleitet], also habe ich vollständige Redundanz aufgebaut, und so ISCSI eingerichtet. Und dann sehen Sie auf dem Speicher selbst, dass die NAA-Nummer AF29 lautet, genau wie ich es Ihnen auf der DataCore-Konsole gezeigt habe – AF29.

Das ist also die Vorgehensweise bei physischen Festplatten – nur zur kurzen Wiederholung: Physische Festplatten, egal ob Fibre-Channel-, ISCSI, direkt angeschlossene oder interne Festplatten, werden in unserer Umgebung zu physischen Festplatten. Anschließend kann ich beliebige Kombinationen dieser physischen Festplatten zu Pools zusammenfassen. Sobald ich einen Pool habe, kann ich darauf virtuelle Festplatten erstellen, die eine unglaubliche Vielzahl an Funktionen bieten. Ich bin über Server-Ports, über Fibre-Channel oder ISCSI meinen Spiegeln, meinem Frontend und meinem Backend verbunden, und meine Konfiguration ist vollständig redundant und stabil; anschließend spiegele ich diese auf andere Knoten innerhalb dieser Servergruppe.

[Lassen Sie mich] noch einmal zu meiner PowerPoint-Präsentation zurückkehren und dann ganz kurz zusammenfassen: Wir vertreten die Ansicht, dass Sie nicht an einen Anbieter gebunden sein sollten und dass Sie sich im Jahr 2019 frei fühlen sollten, verschiedene Speicherlösungen zu nutzen. Eines der wichtigsten Verkaufsargumente und ein wichtiger Aspekt, den es zu bedenken gilt: Wir hatten einen Kunden, der ausschließlich Speicherlösungen desselben Anbieters einsetzte. Als dieser Anbieter ein Firmware-Upgrade durchführte, führte der Kunde das Upgrade ebenfalls durch – und legte dabei alle seine Arrays lahm, weil das Upgrade fehlschlug. Und deshalb – wenn es in Ihrem Unternehmen darum geht, dass Ihre Daten geschäftskritisch und hochverfügbar sind, ist es tatsächlich ratsam, verschiedene Speicherlösungen in Ihrer Umgebung zu haben, damit Sie in einem solchen Szenario nicht das gesamte System lahmlegen.

Es handelt sich also um Fiktion. Und wir verfügen über diese deployment – es gibt wirklich kein deployment , das wir nicht umsetzen können. Ich kann lokale Festplatten oder externe Arrays nutzen und sie nach oben und unten, von links nach rechts oder von einer Seite zur anderen bereitstellen – das spielt keine Rolle. Wir sind Speichervirtualisierung vom Feinsten, und wir haben definitiv daraus gelernt – wir würden niemals wieder zu physischen Servern zurückkehren. Und ich persönlich werde ehrlich gesagt niemals wieder zu einem physischen Speicherarray zurückkehren. Wir kennen die Vorteile für beide Seiten; wir verfügen über einen vollständigen Funktionsumfang der Enterprise-Klasse; wir haben die Speicherprotokolle von Grund auf bis hin zu den Endnutzern erklärt; es müssen keine speziellen Agenten oder Ähnliches auf den [Bare-Metal]-Hosts oder Hypervisoren installiert werden, da wir eine SCSI-Blockfestplatte nach Industriestandard bereitstellen.

Und zu guter Letzt zeigt der obere Teil dieser Folie ein typisches Bild eines Arrays, bei dem ich zwei Controller habe, die sich beide im selben Blechgehäuse befinden. Und wie dieser rote Bereich hier verdeutlicht, kann ich diese Controller natürlich nicht voneinander trennen. Ich wäre nicht bei Verstand, wenn ich versuchen würde, sie auseinanderzunehmen. Dennoch bezeichnen sich diese Speichercontroller selbst als HA. Ich weiß nicht, ob ich das so bezeichnen würde. Ich würde es als [fehlertolerant] bezeichnen, da man ja zweifellos zwei Controller hat. Aber diese beiden Controller nutzen dieselbe gemeinsame Backplane mit Festplatten, sodass der Single Point of Failure auf dieser Festplattenebene liegt – und ja, es könnte sich um ein RAID-System handeln, aber es befindet sich dennoch alles an einem Ort. Wenn Sie also das genaue Gegenteil davon wollen und diese Controller räumlich vollständig voneinander trennen und sie zumindest in verschiedenen Räumen unterbringen möchten, ist DataCore die richtige Lösung für Sie.

Und natürlich ist es ziemlich anregend und – zum Nachdenken anregend – und flexibel, darüber nachzudenken: Wenn neue Speichersysteme auf den Markt kommen und ich mehr Kapazität benötige, kann ich Komponenten an einen Server anschließen, ein JBOD auslagern oder ein weiteres Array anschaffen. Wir schreiben Ihnen nicht vor, wie Sie vorgehen sollen – und welchen Speicher Sie kaufen sollen, aber Sie sollten verstehen, dass wir Ihnen die Software zur Verfügung stellen, die es Ihnen ermöglicht, diese geschäftlichen Entscheidungen zu treffen und sich eine Menge Geld beim Kauf von Speicher zu sparen, auf dem keine Software vorinstalliert ist. Denn seien wir ehrlich: Die meisten Speicher-Arrays in unserer Branche stellen gar keinen Speicher her – es sind einfach Softwareunternehmen wie wir, die ihre Software mit der Hardware, auf der sie basieren, miteinander verbunden haben. Möglicherweise bieten sie nur wenige Speicherdienste an; achten Sie also auf die Flexibilität in diesem Bereich. Und wenn Sie über Hochverfügbarkeit an zwei verschiedenen Standorten verfügen, gibt es keinen Single Point of Failure; Sie haben dieses RAID 1, bei dem – falls eine Seite ausfällt – nicht alles verloren ist, da ich die Daten auf der anderen Seite weiterhin zur Verfügung habe.

Wir nähern uns hier dem Ende. Ich bin wahrscheinlich noch etwas zu früh dran, aber ich möchte mich bei euch für eure Teilnahme bedanken und Whitney fragen, ob – ich habe keine Fragen gesehen. Whitney, hast du irgendwelche Fragen aus dem Publikum gesehen?

Whitney: Wir hatten zwar einige Fragen zur Kontaktaufnahme mit Ihnen, zur Nachverfolgung und zu DataCore, die habe ich aber im Fragefeld beantwortet. Aber konkrete Fragen zu technischen Aspekten, die ich nicht beantworten kann? Nein.

Hunsaker: Okay. Also, alle, die noch zugeschaltet sind, und alle, die sich das später ansehen werden: Zögert bitte nicht, mich zu kontaktieren. Meine E-Mail-Adresse lautet Steve.Hunsaker@datacore.com. Ich freue mich immer darauf, mich auszutauschen, zu diskutieren und gemeinsam kreative Ansätze zum Thema Speicher zu entwickeln – insbesondere dazu, wie ihr das in eurem Umfeld umsetzt – und voneinander zu lernen.