Transkript des Webcasts
David: Hallo und herzlich willkommen zur heutigen Veranstaltung: „Hyperkonvergente Infrastruktur 101“. Gesponsert von DataCore und präsentiert von ActualTech Media. Mein Name ist David Davis, und ich werde heute als Moderator durch die Veranstaltung führen. Ich möchte mich bei allen bedanken, die sich trotz ihres vollen Terminkalenders die Zeit genommen haben, heute an unserer Veranstaltung teilzunehmen. Wir haben heute ein großartiges Programm für Sie vorbereitet. Für diejenigen unter Ihnen, die sich vielleicht noch relativ neu oder sogar ganz neu mit hyperkonvergenter Infrastruktur beschäftigen, wird dies meiner Meinung nach eine wirklich großartige Veranstaltung sein. Wir haben heute einen erfahrenen Referenten zu Gast: Herrn Steven Hunt von DataCore. Er ist schon seit langer Zeit in der Branche tätig. Ich kenne Steve tatsächlich schon sehr lange und habe seine Präsentation gesehen. Er hält einen großartigen Vortrag mit einer Demo, in dem es ausschließlich um hyperkonvergente Infrastrukturen geht.
Also noch einmal vielen Dank, dass Sie heute bei unserer Veranstaltung dabei sind. Bevor wir loslegen, gibt es ein paar Dinge, die Sie über die heutige Veranstaltung zum Thema hyperkonvergente Infrastruktur wissen sollten. Zunächst einmal verlosen wir heute im Rahmen der Live-Veranstaltung einen Hauptpreis an einen glücklichen Teilnehmer. Dabei handelt es sich um eine Amazon-Geschenkkarte im Wert von 300 Dollar, und wir werden den Gewinner dieser Geschenkkarte am Ende der Veranstaltung bekannt geben. Falls Sie Fragen zu den Teilnahmebedingungen dieser Verlosung haben, finden Sie in Ihrer Konsole unter dem Reiter „Handouts“ einen Link. Dort gibt es einen Link zu den Teilnahmebedingungen von ActualTech Media. Nun weiter zu den Fragen. Wie Sie wissen, handelt es sich hierbei um eine Einführungsveranstaltung; daher möchten wir, dass diese Veranstaltung einen hohen Lernwert hat. Wir freuen uns über Ihre Fragen.
Steve und ich werden so gut wie jede eingehende Frage beantworten. Wir werden unser Bestes tun, um auf jede einzelne Frage einzugehen. Zögert also nicht, den Reiter „Fragen und Antworten“ dort ausgiebig zu nutzen. Alle Fragen, die ihr zum Thema HCI habt – jetzt ist der richtige Zeitpunkt, um Antworten darauf zu erhalten. Außerdem legen wir Wert auf den sozialen Aspekt: Wir möchten, dass dies eine gesellige Veranstaltung wird. Der Hashtag dafür lautet #HCI101, und die heutige Veranstaltung wird von DataCore gesponsert und von ActualTech Media organisiert. Ihr könnt die Veranstaltung also gerne bewerben und in den sozialen Medien erwähnen. Unten auf dem Bildschirm befindet sich ein Twitter-Symbol, über das ihr den Hashtag verfolgen und auch selbst über die Veranstaltung twittern könnt.
Außerdem sollten Sie wissen, dass wir für diese Veranstaltung einige spezielle Ressourcen vorbereitet haben. Diese finden Sie auf der Registerkarte „Handouts“ auf der linken Seite Ihres Bildschirms, genau dort. Ich kann diese Registerkarte „Handouts“ sogar für Sie hervorheben und ein wenig verschieben; schauen Sie sich das also unbedingt an. Wir haben einige großartige Materialien von DataCore zum Thema hyperkonvergente Infrastruktur. Ich möchte darauf hinweisen, dass die Oberfläche, die Sie hier sehen, einer Windows-Oberfläche ähnelt, auf der Sie die Fenster auf dem Bildschirm – das Folienfenster sowie das Fenster für Fragen und Antworten bzw. Handouts – per Drag & Drop verschieben, in der Größe anpassen oder neu anordnen können. Ich empfehle Ihnen also, dies zu tun. Wenn ihr das Folienfenster maximieren möchtet, könnt ihr das ganz einfach tun, indem ihr auf die Maximieren-Schaltfläche oben im Folienfenster klickt. Ich empfehle euch, das zu tun, denn Steve hat einige großartige Architekturdiagramme, Demos und Ähnliches für uns vorbereitet.
Kommen wir nun zu den Referenten des heutigen Tages: Wie bereits erwähnt, ist Herr Steve Hunt unser Hauptreferent. Er ist Leiter des Produktmanagements bei DataCore Software, und ich bin Ihr Moderator. Mein Name ist David Davis. Ich bin Partner bei ActualTech Media, zehnfacher VMware , VM-zertifizierter Fachmann und CCIE und seit langer Zeit in der Branche tätig – als Referent, Blogger und Autor. Und ich kann Ihnen versichern, dass wir eine großartige Veranstaltung auf dem Programm haben. Ich werde Steve im Laufe seiner Präsentation und Demo viele Fragen stellen. Außerdem haben wir auf der Landingpage zu dieser Veranstaltung zahlreiche Fragen aus dem Publikum gesammelt. Ich werde einige dieser Fragen stellen und natürlich auch Ihre Live-Fragen, sobald sie eingehen.
Die Themen der heutigen Veranstaltung – sozusagen das allgemeine Inhaltsverzeichnis der Veranstaltung. Zunächst werden wir darüber sprechen, was HCI eigentlich ist. Was ist eine hyperkonvergente Infrastruktur? Wie kann sie Ihnen helfen? Was sind die Vorteile und Anwendungsfälle von HCI? Anschließend live demo Ihnen in einer live demo , wie Sie eine hyperkonvergente Infrastruktur verwalten können. Und natürlich wird es am Ende der Veranstaltung eine ausführliche Frage-und-Antwort-Runde geben. Damit ist es nun an der Zeit, das Wort an unseren heutigen Referenten, Herrn Steve Hunt von DataCore, zu übergeben. Steve, sind Sie bei uns?
Steven: Ja, das bin ich. Kannst du mich gut hören?
David: Ja, das geht. Danke, dass du dabei bist. Leg los.
Steven: Ausgezeichnet. Vielen Dank für die Einladung. Also gut. Wie David bereits erwähnt hat, kennen wir uns wahrscheinlich schon seit geraumer Zeit – das geht zurück bis in die Zeit, als ich noch als Systemberater tätig war und er die gesamte IT-Umgebung eines Unternehmens aus der Gegend um Dallas verwaltete. Es ist also toll, diese Präsentation gemeinsam mit ihm zu halten. An diejenigen unter Ihnen, die gerade erst dazustoßen: Einige von Ihnen wissen vielleicht bereits, was Hyperkonvergenz ist. Manche von Ihnen sind vielleicht schon ein wenig damit vertraut. Andere versuchen vielleicht noch herauszufinden, was das genau ist; hoffentlich kann ich einige dieser Fragen beantworten und Ihnen dann zeigen, wie DataCore Ihnen dabei helfen kann, dies in die Praxis umzusetzen. Unser Fokus liegt wirklich auf einer unternehmensgerechten hyperkonvergenten Lösung, um sicherzustellen, dass Sie die Vorteile einer hyperkonvergenten Umgebung nutzen und Ihre Workloads effektiv skalieren und bereitstellen können.
Was versteht man also unter „hyperkonvergent“? Das ist eine großartige Frage für diejenigen unter Ihnen, die sich noch einen Einblick in dieses Thema verschaffen möchten. Im Kern geht es um die Fähigkeit, Speicher, Anwendungen und Netzwerk – also alles, was Sie benötigen, um Anwendungen für Ihr Unternehmen bereitzustellen – in einer einzigen Box zu vereinen. Und wenn Sie dann skalieren oder Hochverfügbarkeit gewährleisten möchten, benötigen Sie natürlich die Möglichkeit, zusätzliche Knoten anzuschließen; aber im Kern geht es darum, all das in einer einzigen Box unterzubringen und so ein lineares, vorhersehbares Skalierungsmodell zu ermöglichen. Wenn Sie dann wieder skalieren, kommt, wie bereits erwähnt, die Hochverfügbarkeit ins Spiel.
Da David gerade erwähnt hat, dass dies eine Live-Session ist: Eine Frage, die gerade gestellt wurde, lautet: Wie würden Sie die Lösung mit Nutanix vergleichen? Das ist eine wirklich gute Frage. Ein Aspekt von DataCore ist, dass wir gewissermaßen aus dem Bereich der sogenannten Speichervirtualisierung hervorgegangen sind. Das Unternehmen gibt es tatsächlich schon eine ganze Weile. Es gab verschiedene Varianten und Funktionen. Das deployment , das wir ermöglichen, ist das hyperkonvergente Modell; allerdings handelt es sich dabei eher um ein „Bring Your Own Hardware“- und „Bring Your Own hypervisor . Das ermöglicht es Ihnen, diese Komponenten nach eigenem Ermessen zusammenzustellen und bereitzustellen. Wie das funktioniert – ich werde es gleich hier zeigen – und wie wir dies ermöglichen: Sie nehmen beispielsweise einen x86-Server von einem Anbieter Ihrer Wahl. Darauf würden Sie Ihren hypervisor vSphere oder Hyper-V installieren – die wir support –, und dann würden Sie sozusagen unsere Controller-Ebene auf diesem Server installieren. Anschließend stellen Sie den lokalen Speicher dieses Servers dem hypervisor Nutzung bereit.
Was die Leute mittlerweile auch zunehmend erkennen, ist: „Hey, ich habe da diesen cloud , der mir gewisse Möglichkeiten bietet. Wie kann ich den dort einbinden?“ Auch dabei helfen wir natürlich. Es gibt noch andere Möglichkeiten, dies zu bewerkstelligen; aber im Grunde geht es darum, eine Verbindung zu dieser cloud herzustellen und diese dann beispielsweise zu nutzen, um Backups Ihrer Datensätze in der cloud die Notfallwiederherstellung zu erstellen. Das beschreibt im Grunde genommen, was Hyperkonvergenz ausmacht. Es gibt noch einige andere Aspekte, die ich kurz hervorheben möchte, bei denen DataCore hilft – das ist zwar etwas anders, trägt aber dazu bei, dieses hyperkonvergente Modell wirklich für Unternehmensanforderungen zu vervollständigen. Und das betrifft das, was wir „Hyperconverged Plus“ oder „Beyond Hyperconverged“ nennen.
Was bedeutet das nun konkret? Mit unserer Lösung ermöglichen wir unter anderem die Anbindung von gemeinsam genutztem Speicher im Backend an dieses hyperkonvergente Modell, sodass Sie diesen als zusätzlichen Speicherpool für den gesamten Cluster nutzen können. Warum sollten wir das tun? Nun, die Realität sieht so aus, dass viele von uns bereits in bestehende gemeinsam genutzte Speicherarchitekturen investiert haben, die wir natürlich weiterhin nutzen können müssen; und es wäre großartig, wenn wir diese in das hyperkonvergente Modell einbinden könnten. Diese Möglichkeit bieten wir also tatsächlich an. Sie können also diesen gemeinsam genutzten Speicher nehmen, ihn den Hypervisoren in Ihren hyperkonvergenten Knoten zur Verfügung stellen und diesen Speicher dann nutzen, sodass Sie Ihren Speicher unabhängig von der HCI oder dem hyperkonvergenten Knoten skalieren können. Ein weiterer Punkt —
David: Also, Steve, du hast erwähnt –
Steven: Ja, nur zu.
David: — Du hast davon gesprochen, Kapazität und Rechenleistung unabhängig voneinander zu skalieren. Warum ist das wichtig?
Steven: Viele Unternehmen stellen also fest, wenn sie beginnen, Workloads in ein HCI-Modell zu integrieren, dass sie nicht immer einen vollständigen, zu 100 Prozent gleichmäßigen oder parallel linearen Skalierbarkeitsbedarf von der Rechen- zur Speicherseite haben. Vielleicht trifft das nicht so sehr zu, wenn man nur eine einzige Workload hat und das die einzige ist, die man bereitstellt, aber in der Realität fangen viele Leute, sobald sie eine hyperkonvergente Lösung in ihre Umgebung einführen, an, weitere Workloads hinzuzufügen, und erkennen dabei Unterschiede hinsichtlich der tatsächlichen Skalierbarkeit. Manchmal muss man aus Sicht der Rechenressourcen möglicherweise eher auf der CPU- und Speicherseite skalieren; manchmal geht einem jedoch einfach die Kapazität aus.
Die Möglichkeit, die Kapazitätskomponente eigenständig zu skalieren, ist also etwas, womit viele Anwender bei den meisten HCI-Lösungen große Schwierigkeiten haben; und das ist wiederum etwas, das aus unserem Hintergrund resultiert. Bei unserer Technologie geht es im Wesentlichen darum, die Speicherebene zu abstrahieren und sicherzustellen, dass Speicher in jedem Szenario bereitgestellt werden kann. Wir ermöglichen es Ihnen, entweder A) Ihre bereits vorhandene Shared-Storage-Plattform zu nutzen oder B) einfach einen zusätzlichen x86-Server mit lokalen Festplatten in diese Gesamtkonfiguration einzubinden.
David: Man könnte also eine Anwendung mit einem riesigen Datensatz haben, die enorm viel Speicherplatz benötigt, oder eine Anwendung, die einfach nur viele Analysen durchführt und eigentlich gar keinen Speicherplatz benötigt.
Steven: Genau, genau. Und je mehr Unternehmen das HCI-Modell einsetzen, desto mehr erkennen sie, dass sie immer mehr Workloads darauf verlagern können – und genau dann stellt man sich irgendwann die Frage: „Okay, muss ich nun in der Lage sein, meine Speicher- und Rechenkapazitäten unabhängig voneinander zu skalieren?“ Man wird feststellen, dass dies tatsächlich ein sehr häufiges Szenario ist.
David: Ja, das kann ich mir gut vorstellen. Und noch eine Frage, bevor ich dich wieder an die Arbeit lasse: Auf der vorherigen Folie – und eigentlich auch auf dieser hier – sind drei verschiedene Knoten in der hyperkonvergenten Infrastruktur zu sehen. Ist das die Mindestanforderung für den Betrieb mit DataCore und Hyperkonvergenz?
Steven: Das ist eine tolle Frage. Man braucht also eigentlich nur einen Knoten, um ein hyperkonvergentes System nutzen zu können, aber wenn man Hochverfügbarkeit gewährleisten möchte, benötigt man mindestens zwei Knoten. Und genau das unterscheidet uns von vielen unserer Mitbewerber: Bei diesen wird für Hochverfügbarkeit oft eine Anforderung von drei Knoten gestellt. In Wirklichkeit benötigen wir jedoch nur zwei Knoten, um Hochverfügbarkeit zu gewährleisten.
David: Sehr gut. Das bietet dir viel Flexibilität, vor allem für, na ja, KMUs oder, na ja, Edge-Standorte. Das ist also sehr interessant. Okay. Danke, Steve.
Steven: Auf jeden Fall, und das ist einer der Gründe, warum wir dieses Modell unbedingt ermöglichen wollten: Denn in der Realität gilt: Wenn man ein kleineres Unternehmen ist oder über Remote-Standorte verfügt, die keinen nennenswerten Bedarf an riesigen Speicher-, Kapazitäts- oder Rechenressourcen haben, dann sollte man ja auch genau das nutzen können, was man tatsächlich benötigt. In der Praxis gilt jedoch: Wenn man Hochverfügbarkeit will, sind mindestens zwei Knoten erforderlich; daher wollten wir diesem Konzept folgen und diese Hochverfügbarkeit mit möglichst geringen Mindestanforderungen ermöglichen. Mit zwei Knoten ist das also möglich. Dann gibt es noch ein weiteres Modell, über das wir gerne sprechen. Wir haben bereits über die hyperkonvergente Lösung gesprochen.
Wir haben über „Hyperconverged Plus“ gesprochen, bei dem ich zusätzlichen Speicher anschließen kann; und auch hier bündeln wir diesen über die gesamte Speicherebene hinweg. Es geht also nicht darum, dass man einfach nur unabhängige Speichereinheiten verwaltet. Man hat tatsächlich mehrere Festplattensätze, die man zusammenfassen und übergreifend nutzen kann, und ich werde gleich noch näher darauf eingehen, was wir damit alles machen können; aber dann gibt es noch dieses andere Konzept der „Hybrid-Converged“-Lösung. Das ist wiederum etwas, das noch nicht sehr viele Anbieter tatsächlich umsetzen, aber wir hören viel darüber. Erinnern Sie sich daran, dass ich erwähnt habe, dass Nutzer den Speicher möglicherweise separat skalieren müssen; in der Realität kann es aber auch sein, dass sie die Rechenleistung separat skalieren müssen oder einfach andere Anwendungs-Workloads auf Bare-Metal-Servern haben, für die sie eine Anbindung bereitstellen möchten – und genau das können wir ermöglichen.
Wir werden also zu einem [iSCSI]-Ziel in seiner einfachsten Form, und dann können alle anderen Hypervisoren, die keine hybriden konvergenten Systeme sind, oder auch reine Bare-Metal-Windows- und Linux-Server, die Sie verbinden und auf den gemeinsam genutzten Pool zugreifen lassen möchten, dies tun. Wir ermöglichen also auch diese Funktion; und auch hier geht es wieder darum, eine einzige Steuerungsebene für die Speicherebene bereitzustellen und sicherzustellen, dass alle diese Anwendungs-Workloads darauf zugreifen können. Es unterstützt also wiederum Bare-Metal-Systeme oder hypervisor stellt sicher, dass Sie das HCI-Modell nutzen können, bei dem die Rechenleistung in den Speicher integriert ist. Sie können zusätzlichen Speicher hinzufügen, sei es ein gemeinsam genutzter Speicherspeicher wie ein SAN oder – wenn Sie möchten – einfach einen x86-Server mit einer ganzen Reihe von Festplatten einrichten, unsere Software darauf installieren und diesen in einen reinen Speicherknoten verwandeln. Und auch hier gilt: Wenn Sie weitere Hosts anschließen möchten, seien es zusätzliche Hypervisoren oder weitere Bare-Metal-Systeme, können Sie dies tun und haben dann wiederum Zugriff auf diesen aggregierten Speicherpool.
David: Also, Steve, nehmen wir mal an, ich hätte ein in die Jahre gekommenes Storage Area Network (SAN) oder ein NAS – so etwas in der Art –, auf dem ich diese virtuellen Servermaschinen betreibe, und vielleicht auch einige physische Hosts, die an dieses SAN angeschlossen sind. Könnte diese hyperkonvergente Infrastruktur, wie du sie hier mit DataCore beschreibst, dieses bestehende SAN, das vielleicht bald gewartet werden muss, tatsächlich ersetzen oder ablösen?
Steven: Auf jeden Fall, und das ist einer der Punkte, den viele unserer Kunden als großen Mehrwert schätzen: die Möglichkeit, diese ältere Hardware weiter zu nutzen, die sie sonst beim Übergang zum hyperkonvergenten Modell vielleicht nicht mehr einsetzen könnten oder die einfach unabhängig von Rest der Hyperkonvergenz bleibt. Das ist eine Menge wirklich guter, nützlicher Speicherplatz, und wir möchten diesen in die Lösung einbinden, um sicherzustellen, dass Sie Ihre bisherigen Hardware-Investitionen so weit wie möglich maximieren können. Deshalb konzentrieren wir uns wirklich darauf, das sogenannte hybrid-konvergente Modell zu ermöglichen, das sicherstellt, dass Sie nicht nur Zugriff auf den von Ihnen erstellten HCI-Pool haben, sondern auch die Flexibilität genießen, alle anderen Speicherinvestitionen zu nutzen, die Sie in der Vergangenheit getätigt haben oder in Zukunft tätigen möchten.
David: Sehr gut. Sehr gut. Eine weitere Frage, die hier eingegangen ist, betrifft – wie du weißt – die Tatsache, dass dies, wie du erwähnt hast, auf Standardhardware läuft. Kann man in manchen Fällen vorhandene Hardware nutzen, um dies einzurichten, oder gibt es eine Art Hardware-Kompatibilitätsliste für DataCore?
Steven: Das ist eine tolle Frage. Wir führen zwar eine Kompatibilitätsliste, aber in der Praxis hängt diese ziemlich stark davon ab, welches Betriebssystem Sie verwenden und wie dessen Hardware-Kompatibilitätsliste aussieht. Solange Sie also den Speicher unserer Plattform zur Verfügung stellen können, die auf einem Windows-Server läuft. Manche Leute finden das vielleicht verrückt, aber in Wirklichkeit sind wir eben eine Softwarekomponente, die auf den Windows-Servern läuft und dies dann ermöglicht. Sie können also Zugriff auf oder von dieser Festplatte oder diesem Speicherarray im Backend gewähren – solange die Kompatibilität für die Verbindung gegeben ist, sollten wir damit arbeiten können.
David: Sehr schön.
Steven: Also, wie ich bereits erwähnt habe, haben wir eigentlich als Lösung für die Speichervirtualisierung angefangen und dann nach und nach all diese anderen Anwendungsfälle ermöglicht; und tatsächlich stellen wir all diese Funktionen für Unternehmensspeicherdienste, über die unsere Plattform verfügt, für all diese verschiedenen Anwendungsfälle bereit. Wir verfügen also über integrierte Funktionen für die synchrone Spiegelung. Wenn Sie eine Disaster-Recovery-Lösung an einem sekundären Standort benötigen, bieten wir integrierte asynchrone Replikation. Wir verfügen über integrierte snapshot Backup-Funktionen; und besonders vorteilhaft ist, dass wir – je nach hypervisor Ihres hypervisor – einige native Integrationsfunktionen bieten.
Wir verfügen außerdem über diese Funktion, die wir „Continuous Data Protection“ nennen, und in der Praxis ermöglicht sie uns – so wie wir arbeiten, leiten wir buchstäblich einfach den gesamten eingehenden E/A-Verkehr weiter. Wir können, wenn man so will, buchstäblich snapshot die E/A-Ebene snapshot . Wir überwachen also ständig den eingehenden E/A-Verkehr; und man kann im Grunde genommen, wenn man so will, einen snapshot von jedem einzelnen E/A-Vorgang erstellen, der gerade stattfindet, und dann auf einen bestimmten Zeitpunkt zurücksetzen. Das wird immer häufiger. Einer der häufigsten Anwendungsfälle, den ich beobachte, ist, wenn jemand vor etwa einer Stunde einen Datenverlust hatte; und er muss den Zustand vor dem Datenverlust wiederherstellen – oder wenn Malware in seinen Datenspeicher eingedrungen ist, kann er zu dem bestimmten Zeitpunkt zurückkehren, zu dem er wusste, dass die Daten noch an ihrem Platz waren.
Wir stellen diese Funktion also nativ innerhalb unserer Plattform bereit und verfügen darüber hinaus über einige weitere Funktionen. Wir haben beispielsweise ein integriertes Caching, das dafür sorgt, dass alles so schnell wie möglich abläuft, denn der schnellste Speicher, den es gibt, ist der Arbeitsspeicher. Daher wickeln wir unsere gesamte Kommunikation und unsere E/A-Interaktionen zunächst über unseren Cache im Arbeitsspeicher ab und schreiben die Daten dann je nach E/A-Profil auf die Festplatte. Wenn also häufig darauf zugegriffen wird – also bei „Hot Data“ –, schreiben wir diese Daten auf das schnellste Medium, das uns zur Verfügung steht und das wir entsprechend ermitteln; und sobald die Anfragen nach diesen Daten oder Geboten immer seltener werden, verlagern wir sie auf langsamere Speichermedien. Wir stellen also die am häufigsten angeforderten Daten stets von dem Speicher mit der höchstmöglichen Leistung bereit, sei es aus dem Arbeitsspeicher, von flash , SSDs oder sogar bis hin zur cloud für ein [In]-Tier oder ein cloud .
David: Also, Steve, hier ist eine Frage zum VMware Recovery Manager eingegangen. Tut SANsymphonysupport ?
Steven: Ja, das tun wir. Wir verfügen über einen Speicherreplikationsadapter, der die Integration dabei erleichtert. Es nützt nämlich nicht viel, wenn man seine Daten im Backend replizieren kann, aber nicht sicherstellen kann, dass die Arbeitslasten zusammen mit den Daten migriert werden können. Wir sind also in der Lage, eine Integration durchzuführen. Wir haben einen Speicherreplikationsadapter entwickelt, der mit dem Site Recovery Manager zusammenarbeitet.
David: Und dann kam noch eine weitere Frage zur cloud . Zum Beispiel: Welche Cloud-Dienste support ihr support Ich meine support S3 oder welche Technologien kommen dort zum Einsatz?
Steven: Tolle Frage. Also, heute verfügen wir bereits über die entsprechenden Funktionen. Sie können buchstäblich eine Instanz unserer Software auf Ihrer AWS-Umgebung bereitstellen und diese dann als – es handelt sich um einen weiteren DataCore-Speicherserver – nutzen, an den Sie dann den Speicher anschließen können, den Sie bereits verbunden haben – wahrscheinlich eine Reihe von EBS-Volumes im Backend –, und diesen als weitere Ebene in Ihrem Speicherpool nutzen. Das ist also die Funktion, über die wir heute verfügen. Wir arbeiten an einigen zusätzlichen Funktionen, mit denen wir unsere Möglichkeiten erweitern und verschiedene Komponenten des verfügbaren cloud nutzen können, aber derzeit beschränkt es sich darauf, eine Instanz unserer Software aus dem Marketplace bereitzustellen und diese dann als weitere Ebene innerhalb Ihres Speicherpools zu nutzen.
David: Okay. Sehr schön. Sehr schön.
Steven: Anstatt nur darüber zu reden, können wir uns doch mal konkret ansehen, wie man mit DataCore-Software ein hyperkonvergentes Szenario umsetzen könnte. Ist das für dich in Ordnung, David?
David: Los geht’s. Rick hat uns gerade eine Frage geschickt. Im Grunde genommen geht es darum: Wie funktioniert das genau? Muss ich LUNs anlegen? Wie stellt ECR eine Verbindung zum Speicher her? Schauen wir uns das also in der Praxis an.
Steven: Cool. Super. Also, ich werde hier einen konkreten Anwendungsfall vorstellen und anschließend noch einige der anderen Funktionen hervorheben, die wir ebenfalls bieten; ich denke, das wird helfen, einen Teil dieser Frage zu beantworten. Die kurze Antwort lautet: Solange Sie uns Rohfestplatten zur Verfügung stellen, die wir formatieren und mit denen wir interagieren können, können wir diese nutzen. Unabhängig davon, ob es sich um lokale Festplatten oder gemeinsam genutzten Speicher handelt – solange Sie uns diese so bereitstellen, dass wir sie übernehmen, formatieren und anschließend wieder bereitstellen können, ist das unser Vorgehen. In diesem Szenario habe ich im Grunde genommen ein paar vSphere-Server, auf denen ich ESXi 6.5 installiert habe; diese verfügen über einige Festplatten, und ich möchte diese in hyperkonvergente Knoten umwandeln. Wie gehen wir also dabei vor?
Nun, als Erstes sollten Sie unseren vCenter-Installationsmanager herunterladen und ausführen. Ich muss mich also lediglich mit einem vCenter-Server verbinden. In der Regel stelle ich einfach eine vCenter-Appliance auf dem Rechner selbst bereit. Also, lassen Sie mich hier einloggen. Und eine Sache, die Ihnen dabei auffallen wird: Ich habe es ein bisschen im Ronco-Stil gemacht, denn je nachdem, wie schnell oder langsam Ihr Rechner ist, kann es eine Weile dauern, bis die virtuellen Maschinen erstellt und alles eingerichtet ist. Deshalb habe ich mir überlegt, Ihnen zunächst den Ablauf des Installationsmanagers zu zeigen und dann – ganz wie in den Ronco-Werbespots – das „Gericht“ fertig aus dem Ofen zu holen; anschließend werden wir noch etwas näher darauf eingehen. Andernfalls hätte die Präsentation wahrscheinlich viel länger gedauert, wenn wir die deployment virtuellen Maschinen von Anfang bis Ende hätten verfolgen müssen.
Sobald also die Verbindung hergestellt ist – da haben wir es. Alles klar. Wir haben also eine Verbindung zur vCenter-Umgebung hergestellt. Nun werden Sie feststellen: Hey, es heißt, dass bereits eine bestehende deployment gefunden wurde. Was soll ich tun? Ich könnte also eine Aktualisierung vornehmen oder einen Knoten hinzufügen. Wenn noch gar keine Bereitstellung vorhanden ist, wenn im Hintergrund keine HVSAN-Server gefunden werden, wird einfach eine komplett neue deployment durchgeführt. Ich klicke also einfach auf „Knoten hinzufügen“, und ihr könnt euch ansehen, wie das aussieht. Zunächst legen wir die Einstellungen für die virtuelle Maschine von DataCore fest. Wir gehen die einzelnen Punkte durch, legen fest, wie diese aussehen sollen – sofern ich alles richtig eingebe –, und registrieren dann diese VM bei vCenter bzw. den vCenter-Server in unserer Software.
Und Sie können dies anpassen, ganz gleich, ob Sie CPU, RAM oder lokale Festplattenkapazität benötigen – wir stellen Ihnen Richtlinien zur Dimensionierung zur Verfügung, damit Sie diese optimal nutzen können. Sie legen Ihre Netzwerkkonfiguration fest. Im Grunde benötigen wir also ein Zielnetzwerk, damit wir die Verbindung zu der virtuellen Festplatte herstellen können, die wir bereitstellen werden. Und dann benötigen wir ein Spiegelnetzwerk, damit der gesamte lokale Speicher auf allen Knoten im Cluster verfügbar ist, wenn wir ihn benötigen. Wir definieren standardmäßig ein Netzwerk für Sie, das Sie jedoch ändern können, falls Sie dies wünschen. Wie bereits erwähnt, läuft unsere Software auf der Windows-Plattform. Sie stellen daher eine Windows-ISO-Datei und einen Windows-Lizenzschlüssel bereit, um anschließend die Betriebssysteminstallation durchzuführen. Darauf aufbauend installieren wir dann unsere Software.
Anschließend wählen Sie einfach aus, auf welchen ESXi-Servern Sie die virtuelle Maschine tatsächlich bereitstellen möchten. Auch hier handelt es sich im Grunde um unsere virtuelle Speicher-Controller-Maschine, die auf jedem einzelnen ESXi-Server bereitgestellt werden muss, den Sie als Teil Ihrer deployment nutzen möchten. Ich kann diese also nicht auswählen, da dies bereits geschehen ist; und sobald Sie sie ausgewählt haben, klicken Sie auf „Bereitstellen“ und können dann den Fortschritt der Erstellung verfolgen. Wir werden also den VM-Speichercontroller erstellen. Wir werden alle lokalen Festplatten von diesem Rechner erfassen. Wir werden diese dem Speichercontroller zur Verfügung stellen und diesen Speichercontroller anschließend mit vCenter verbinden und integrieren.
Wir werden all diese Hosts dort hinzufügen; und sobald das erledigt ist, können Sie sich bei einem Ihrer HVSAN-Server anmelden, und Sie werden etwa Folgendes sehen. Das ist also unsere Verwaltungskonsole; und wie Sie sehen, werden hier meine DataCore-Server angezeigt, die mir einen Überblick über meine Verbindungsmöglichkeiten und verschiedene Aspekte davon geben, und dann sehe ich hier in diesem Fenster die vSphere-Umgebung. Jetzt wechsle ich ganz schnell zurück zum vSphere-Client; ich möchte euch zeigen, wovon ich spreche. Wie ihr seht, habe ich hier ein paar ESXi-Knoten; und auf diesen befinden sich eine Reihe lokaler Festplatten. Ich habe hier also zwei flash .
Es handelt sich um flash , und außerdem habe ich fünf Festplatten. Eine davon wird tatsächlich nur als lokaler Datenspeicher für den Host genutzt, auf dem ich vSphere installiert habe, während die anderen vier für HVSANs zur Verfügung standen. Wie Sie sehen können, haben wir HVSANs-Server erstellt, die jeweils auf einem bestimmten Host laufen. Eines möchte ich hier noch hervorheben: Normalerweise muss man diese nicht in einem Cluster betreiben. Ich habe sie für diese Zwecke in einen Cluster eingebunden, weil mir nach dem Aufbau meiner Umgebung klar wurde, dass ich auf jedem der Server zwei verschiedene Prozessortypen hatte.
Um also aufgrund der Prozessorinkompatibilität ein vMotion von einem Host zum anderen durchführen zu können, musste ich die Hosts in einen Cluster einbinden, um die erweiterte vMotion-Funktion nutzen zu können. Wenn man über Hardware verfügt, die vMotion auch ohne Cluster-Zugehörigkeit ermöglicht, wäre das natürlich möglich. Also, noch einmal: Auf jedem Host läuft HVSAN; und natürlich müssen wir warten, bis der vSphere-Webclient – da ist es.
David: Und Steve, hier ist eine Frage eingegangen. Gibt es eine Mindestanforderung für SSDs auf jedem der Hosts?
Steven: Das gibt es nicht. Sie können also, wie gesagt, beliebige lokale Speichermedien verwenden, sei es eine SD-Karte oder eine normale SAS-Festplatte. Letztendlich kommt es darauf an, wie viel Leistung Sie daraus herausholen möchten. Je schneller die Speichermedien sind, die Sie einsetzen, und je schneller die Speichergeräte sind, die Sie verwenden, desto höhere Leistung können wir Ihnen ermöglichen. Und noch einmal: Ein Teil davon besteht darin, dass Sie einen Cache aus dem Arbeitsspeicher für die HVSAN-VM erstellen, sodass zunächst alles diesen Cache durchläuft und anschließend auf die Festplatte zurückgeschrieben wird. Wenn Sie also eine enorme E/A-Aktivität haben und Ihren Cache gefüllt haben, erfolgt der nächste Schritt tatsächlich über die Interaktion mit den Festplatten, um diese Daten abzurufen. Je schneller also die Speichermedien sind, desto höher ist die Gesamtleistung; in der Praxis ist dies jedoch keine zwingende Voraussetzung; und solange Sie über eine große Menge an RAM verfügen, können Sie eine große Datenmenge über Ihren Speicher-Cache verarbeiten.
David: Und hier noch eine weitere Frage. Es wird gefragt, ob die SSD nur zum Caching, nur zur Speicherung oder für beides verwendet wird.
Steven: Es dient zur Speicherung. Der Cache wird also tatsächlich außerhalb des Arbeitsspeichers bereitgestellt, und die SSD wird ausschließlich für schnelle Medien genutzt. Wenn wir damit beginnen, die E/A-Vorgänge von den beiden Festplatten aus dem Arbeitsspeicher zu schreiben, greifen wir einfach auf die nächstschnellste Speicherebene zurück. Wenn Sie also einige SSD-Laufwerke im System haben, ist das die nächstschnellste Speicherebene, und wir schreiben die Daten darauf. Nun können Sie Speicherprofile festlegen. Sie können also sagen: „Hey, das ist normal“, und die Daten gleichmäßig auf alle Speichermedien verteilen, oder Sie können angeben, dass es sich um kritische Daten handelt, die jederzeit der schnellsten Ebene zugewiesen werden müssen. In diesem Fall werden die Daten also nicht auf langsamere Speichermedien kaskadiert, da wir so viel wie möglich davon innerhalb der schnellsten Ebene bereitstellen müssen.
Die Realität sieht also so aus: Die Anforderungen an Ihre Laufwerke hängen davon ab, wie viel Speicherplatz Sie nutzen möchten und welche Leistung Sie dabei benötigen. Wenn alles so schnell wie möglich sein soll, benötigen Sie wahrscheinlich eine große Speichermenge und einen X86-Server, der bis zum Rand voll ist – Sie werden aus flash eine HCI-Lösung zusammenstellen. Wenn dies jedoch nicht erforderlich ist, können Sie in der Praxis wahrscheinlich erhebliche Vorteile erzielen. Wir haben tatsächlich einige Tests durchgeführt und Leistungsdaten zusammengestellt, die zeigen, dass wir lediglich ein paar SSD-Laufwerke eingesetzt haben, um den Zugriff auf die am häufigsten genutzten Daten zu beschleunigen. Tatsächlich haben wir jedoch eine enorme IO-Leistung bei minimaler Latenz und mit einer sehr kleinen Anzahl von Laufwerken erreicht – eine Leistung, die die meisten Menschen eigentlich von einemflash erwarten würden.
David: Und das liegt daran, dass du den Arbeitsspeicher für das Caching nutzt. Stimmt das?
Steven: Richtig. Denn wir speichern zunächst alles im RAM, und dann kommt es auch darauf an, wie wir unser Auto-Tiering umsetzen. Wir leiten nämlich die gesamte E/A auf die schnellstmöglichen Speichermedien um; das heißt, die am häufigsten abgerufenen Daten werden in den schnellsten Teil des Speichermediums geschrieben. Die weniger häufig abgerufenen Daten werden dann auf den Rest verfügbaren Speichermediums ausgelagert. Und wir zirkulieren diese Daten einfach ständig zwischen diesen verschiedenen Speicherebenen hin und her.
David: Okay. Hier kommt noch eine Frage. Es geht um das Netzwerk. Benötigt man mindestens ein 10-GB-Netzwerk, oder wie sehen die Anforderungen in diesem Bereich aus?
Steven: Wir empfehlen mindestens 10 GB, insbesondere wenn es um einen hyperkonvergenten Knoten geht, da dies die Durchführung aller synchronen Spiegelungen ermöglicht und dafür sorgt, dass alles so schnell wie möglich auf dem neuesten Stand bleibt. In der Praxis wird jedoch zunächst alles über diesen Speicher-Cache abgewickelt; erst danach schreiben wir die Daten auf die Festplatte und führen den Schreibvorgang durch, während wir gleichzeitig die Kommunikation gewährleisten und sicherstellen, dass die Spiegelung auf die andere Seite übertragen wird. Wenn also sehr viele E/A-Vorgänge stattfinden, sollten Sie die Bandbreite möglicherweise erhöhen; in den meisten Umgebungen reicht jedoch ein 10-GB-Netzwerk aus. Wir support allerdings auch 40 GB.
David: Okay, gut. Jeff fragt, ob ich mehr als zwei Kopien meiner Daten haben kann. Könnte ich, sagen wir mal, vier Kopien meiner Daten haben, wenn ich DataCore auf vier vSphere-Hosts installiere?
Steven: Also, heute führen wir eine Drei-Wege-Kopie durch, und wir streben das an, was wir als „In-Way“ bezeichnen – im Grunde genommen die Möglichkeit, eine Kopie über so viele Knoten hinweg zu erstellen, wie wir wollen. Das Maximum, das wir derzeit umsetzen, ist eine Drei-Wege-Kopie. Wir haben festgestellt, dass die von uns gebotene Datenresilienz in der Regel nicht darüber hinausgehen muss. Bei einigen Kunden sind wir auf Szenarien gestoßen, in denen – ich weiß nicht, ob es sich dabei um eine Definition oder eine Anforderung aus Compliance-Sicht handelt –, aber wir haben diese Anfrage so häufig erhalten, dass wir derzeit prüfen, ob eine Kopie über mehr als nur drei Knoten hinweg möglich ist; wir haben jedoch festgestellt, dass eine Dreifachkopie in der Praxis für die meisten Kunden aus Compliance-Sicht ausreichend ist.
David: Und dann noch eine letzte Frage. Ich lasse dich jetzt wieder zu deiner Demo zurückkehren, und ich glaube, das knüpft direkt an das an, was du gleich zeigen wirst. Die Frage lautet: Wie sind die physischen Festplatten mit dem Virtualisierungs-Hypervisor verknüpft? Wie wird die VM letztendlich auf diesen von dir erstellten physischen Festplatten gespeichert?
Steven: Ja. Also, lasst uns gleich damit loslegen und das Ganze mal erklären. Ich werde das hier alles über die DataCore-Verwaltungskonsole machen; aber eigentlich haben wir ja auch das vSphere-Client-Plugin. Ihr könnt das also laden und dann alles – oder zumindest fast alles, was ihr tun müsst – direkt über die vSphere-Konsole erledigen. Aber ich wollte euch die DataCore-Verwaltungskonsole zeigen, damit ihr euch mit den dortigen Konzepten vertraut macht – das lässt sich dann sofort auf das vSphere-Plugin übertragen, sobald ihr es geladen habt. Wie ich bereits erwähnt habe, sind unsere HVSAN-Server – sozusagen unsere VM-Controller – geladen. Diese sind in unserer DataCore-Servergruppe aufgeführt.
Hier sind unsere ESXi-Knoten aufgelistet. Wie ich bereits gezeigt habe, gab es also physische Festplatten, die sich direkt auf dem Knoten befanden. Wenn Sie also den DataCore-Server aufrufen und dann unter „Disk Pools“ nachsehen, haben wir tatsächlich einen ersten Disk Pool mit allen gefundenen Festplatten angelegt. Wenn ich also auf „Disk Pool“ klicke, kann ich meine physischen Festplatten einsehen; und ich sehe, dass dort meine beiden SSD-Laufwerke sind, und dann gibt es noch die anderen vier Festplatten. Und das waren die physischen Medien, die reinen physischen Festplatten, die bei der Installation unserer Software verfügbar waren.
Also haben wir das übernommen. Wir haben diesen Festplattenpool zugewiesen. Tatsächlich könntet ihr zusätzliche Pools erstellen. Ihr könntet diese Festplatten ausgliedern. Ihr könntet den Server herunterfahren und weitere Festplatten hinzufügen. Nehmen wir mal an, euer Regal wäre nur halb voll. Wir haben also die Flexibilität, sicherzustellen, dass Sie, wenn Sie weitere Datenträger einlegen oder diesen Pool aus bestimmten Gründen vielleicht in verschiedene Pools aufteilen möchten, die Möglichkeit dazu haben; aber in diesem Fall haben wir alle physischen Festplatten, die sich auf diesem bestimmten Host befanden, genommen und daraus einen Festplattenpool erstellt. Der nächste Schritt ist also – bitte, David.
David: Hier kommt eine Frage von Eric. Er fragt, ob es eine Möglichkeit gibt, Daten mit SANsymphony zu verschlüsseln.
Steven: Wir verfügen derzeit also nicht über eine native Verschlüsselung. Wir arbeiten gemeinsam mit einigen Partnern daran, diese Funktion bereitzustellen, und prüfen zudem Möglichkeiten für eine Festplattenverschlüsselung; was Sie jedoch tun können, ist, auf der Ebene des physischen Speichercontrollers die Festplattenverschlüsselung zu aktivieren – die Möglichkeit dazu ist also vorhanden. Wir prüfen aber derzeit auch die Möglichkeit, eine Verschlüsselung auf Softwareebene nativ innerhalb unserer Software selbst zu realisieren. In Ordnung. Wir haben also unsere Pools erstellt. Sobald Sie alles eingerichtet haben, müssen Sie noch einige virtuelle Festplatten erstellen und diese dem Host selbst zur Verfügung stellen. Ich habe also tatsächlich eine virtuelle Festplatte erstellt. Ich habe sie „Mirrored Datastore 1“ genannt; im Grunde habe ich diese Festplatte erstellt.
Und ich sagte, ich möchte dies auf meinen beiden DataCore-Servern spiegeln. Also spiegele ich die Daten, die von einem Server geschrieben werden, auf den anderen und stelle so sicher, dass sie jederzeit verfügbar sind. Ich zeige Ihnen also, wie einfach es ist, eine virtuelle Festplatte zu erstellen; und wir werden einfach einen weiteren Datenspeicher anlegen und diesen vorstellen. Wir haben hier also diese „Erste Schritte“-Anleitung, bei der all diese Schritte, die wir bereits durchlaufen haben, automatisch für Sie erledigt werden. Sobald Sie den Installationsmanager ausgeführt haben, kommen Sie einfach hierher und erstellen virtuelle Festplatten. Wir werden diesen gespiegelten Datenspeicher „2“ nennen. In Ordnung? Wie bereits erwähnt, handelt es sich hierbei um einen gespiegelten Datenspeicher. Man könnte auch nur einen einzigen DataCore-Server verwenden, was jedoch keine Hochverfügbarkeit gewährleisten würde. Man könnte zwei Server einsetzen und so eine gewisse Fehlertoleranz auf Serverebene bieten, oder man kann eine Spiegelung einrichten, bei der buchstäblich jeder Host auf den gesamten Datenspeicher schreibt.
Die Lösung mit der höchsten Verfügbarkeit und der größten Fehlertoleranz ist also die Spiegelung. Ich werde diesem Pool also einfach 100 GB zuweisen. Alles andere lasse ich auf den Standardwerten. Wenn ich weitere solche Pools einrichten möchte, könnte ich das tun, aber ich lasse den Rest einfach Rest den Standardwerten. Sobald Sie Ihre Definition für die virtuelle Festplatte erstellt haben, müssen Sie als Nächstes Ihre Serverquellen definieren. Ich habe also Festplattenpool 1 und Festplattenpool 2. Richtig? Festplattenpool 1 stammt von HVSAN SPCTest 3, und Festplattenpool 2 stammt von Test 2. Im Grunde sage ich also nur: Hey, ich möchte diese beiden Pools als Teil meines Spiegels verwenden. Wie ihr wisst, habe ich bereits einige der erweiterten Funktionen erwähnt, über die wir verfügen, wie zum Beispiel die kontinuierliche Datensicherung.
Wissen Sie, hier wird angezeigt, dass wir einen redundanten Pfad für die Spiegelung einrichten. Ich könnte mein Speicherprofil ändern. Das werde ich auch gleich tun. Das wird einfach entscheidend sein. Das bedeutet, dass wir alles auf das schnellste verfügbare Speichermedium schreiben werden; und alles andere, das auf eine niedrigere Priorität eingestellt ist – sei es „hochkritisch“, „normal“ oder „niedrig“ –, wird auf die langsameren Medien übertragen, die dort vorhanden und verfügbar sind. Also klicke ich hier auf „Fertigstellen“. Damit haben wir unsere virtuelle –
David: Und Steve, hier kommt eine Frage von Robert. Er fragt, ob die Nutzung einiger der erweiterten Funktionen mit zusätzlichen Kosten verbunden ist. Gibt es verschiedene Zusatzoptionen oder wie funktioniert die Lizenzierung?
Steven: Tolle Frage. Wir haben also drei verschiedene Varianten: „Standard“, „Enterprise“ und das, was wir als „Large Scale“ bezeichnen – das ist im Grunde genommen Sekundärspeicher, wenn man so will. Die „Standard“-Variante verfügt also grundsätzlich nicht über Fibre-Channel-Fähigkeit. „Enterprise“ verfügt über Fibre-Channel-Fähigkeit und einige zusätzliche Leistungsmerkmale im Bereich der E/A. Was wir Ihnen gerade zeigen, lässt sich buchstäblich mit einer Standard-Lizenz realisieren. Alle Funktionen, die Sie hier sehen – wie die kontinuierliche Datensicherung, die Replikation und all diese Dinge – sind in der Lizenz enthalten. Das Einzige, wofür Sie bezahlen, ist die Kapazität, die Sie Ihrer Umgebung zur Verfügung stellen möchten. Also, nehmen wir mal an, ich hätte – mal sehen, Ihre zwei Terabyte plus noch etwas – ich glaube, ich hatte etwas mehr als 3½ Terabyte; dafür bräuchte ich die Lizenz, um die gesamte Kapazität bereitstellen und nutzen zu können.
David: Also, wenn ich –
Steven: Und ich bekomme all diese anderen Funktionen dazu.
David: Ja. Wenn ich also einen zweiten Standort hinzufüge und eine Replikation dorthin durchführe, muss ich keine neue Lizenz für den zweiten Standort bezahlen. Ich bezahle lediglich für die Datenmenge, die ich durch die Replikation zusätzlich hinzufüge. Funktioniert das so?
Steven: Ja. Genau. Nehmen wir also an, dieser Cluster, den ich erstellt habe, ist ein Cluster mit drei Knoten. Er umfasst 100 Terabyte. Ich würde also buchstäblich 100 Terabyte Kapazität lizenzieren und hätte dann diese drei Knoten. Nehmen wir an, ich möchte das in vier Knoten aufteilen und diese 100 Terabyte auf die vier Knoten verteilen – dann muss ich keine zusätzliche Kapazität kaufen. Ich muss lediglich meine Festplatten umverteilen und dann eine weitere Version des Servers installieren. Man muss also keine Lizenz pro Knoten erwerben, mit dem man eine Verbindung herstellt oder über den man Serverspeicher bereitstellt. Es geht ausschließlich um die Kapazität. Nehmen wir nun an, ich möchte diesen zweiten Standort einbinden – beispielsweise für die Notfallwiederherstellung –, dann muss ich nicht alles replizieren, sondern nur eine bestimmte Gruppe von Pools.
Und wenn ich dort beispielsweise nur 10 Terabyte an Daten replizieren möchte und dieser Server nur über 10 Terabyte verfügt, würden Sie einfach eine Lizenz für weitere 10 Terabyte Kapazität erwerben. Diese könnten Sie dann auf einen einzelnen Knoten, zwei Knoten, drei Knoten oder so viele Server verteilen, wie Sie benötigen. Sie lizenzieren also lediglich die Kapazität am anderen Standort.
David: Sehr schön. Sehr schön.
Steven: Also, ich habe meine virtuelle Festplatte erstellt. Jetzt müssen wir sicherstellen, dass sie als Datenspeicher für meine Server verfügbar ist. Also gehe ich hier hinein. Ich werde sie dem Host zur Verfügung stellen. Eigentlich möchte ich sie beiden meiner ESXi-Hosts zur Verfügung stellen. Ich könnte sie zwar direkt den laufenden virtuellen Maschinen zur Verfügung stellen, aber in diesem Szenario werde ich sie der Einfachheit halber dem Host zur Verfügung stellen. Welche virtuelle Festplatte werde ich bereitstellen? Ich werde diejenige nehmen, die ich gerade erstellt habe, den gespiegelten Datenspeicher 2. Ich stelle sicher, dass unser redundanter Pfad aktiviert ist, und erstelle dann einen VMFS-Datenspeicher auf Basis dieser erkannten Festplatte.
Im Grunde sage ich vSphere also Folgendes: „Hey, sobald du das findest, formatiere es als VMFS – Zungenbrecher – und dann sollte mir ein Datenspeicher zur Verfügung stehen.“ Also klicke ich auf „Fertigstellen“ – ja – und nun sollten wir auf der anderen Seite sehen, wie einige Datenspeicher angezeigt werden, oder besser gesagt, wir können das wahrscheinlich im Überwachungsbereich nachsehen. Habt bitte noch einen Moment Geduld.
David: Während du das machst, ist eine Frage von Rick hereingekommen. Kann ich Host-Gruppen anlegen? Zum Beispiel „Produktion“, „Nicht-Produktion“, „Test/Entwicklung“ und so weiter?
Steven: Ja. Ja, das geht. Auf jeden Fall. Schau dir die Ereignisse an. Manchmal dauert es etwas länger, bis der vSphere-Webclient tatsächlich aktualisiert wird.
David: Übrigens finde ich es gut, dass du den neuen HTML5-vSphere-Webclient nutzt. Da muss ich immer zweimal hinschauen, um sicherzugehen: Moment mal, ist das wirklich der vSphere-Client? Denn er ist ja nicht blau – aber es ist tatsächlich er.
Steven: Ja, das stimmt. Weißt du, ich finde es toll, dass ich das über einen Browser nutzen kann; aber manchmal ärgere ich mich auch ganz schön darüber, und dann vermisse ich doch den guten alten Vollclient, weißt du. Vielleicht liegt das einfach daran, dass ich ein bisschen altmodisch bin. Ich bin eben ein Windows-Fan der alten Schule.
David: Es ist eine weitere Frage eingegangen. Ken fragt nach der Ausfallsicherheit. Ist es empfehlenswert, das hyperkonvergente SAN über mehrere Hosts hinweg bereitzustellen?
Steven: Ja.
David: Also, mindestens zwei –
Steven: Ganz genau.
David: Aber vielleicht –
Steven: Richtig. Ja, es sind mindestens zwei. Je mehr Hosts man hat, desto höher ist also die Ausfallsicherheit. Und je mehr Hosts man hat, desto größer ist die Ausfallsicherheit – und wenn man redundante Pfade hat, fügt man dem Ganzen noch mehr Speicher-Cache hinzu, und auf diese Weise erhält man dann auch die Gesamtleistung dieser Caches. Alles klar. Es gibt also den gespiegelten Datenspeicher 2. Er wurde tatsächlich erstellt. Er steht allen meinen Servern zur Verfügung, und ihr könnt hier die Konnektivität sehen. Er wurde sowohl dem Host .39 als auch dem Host .40 meiner beiden Hosts zur Verfügung gestellt. Was ich euch außerdem zeigen möchte, ist, dass es sich hierbei tatsächlich um gemeinsam genutzten Speicher handelt. Wir haben Festplatten von beiden vSphere-Hosts genommen und diese bereitgestellt, sodass sie als aggregierte Lösung übergreifend verfügbar sind.
Also, ich habe hier diesen Windows-Server 2016 laufen, und wie ihr im Grunde sehen könnt – wir haben hier etwas Aktivität, CPU- und Festplattenaktivität. Ich werde das jetzt einfach migrieren. Lassen wir das hier einfach so stehen, und wir starten den Migrationsprozess – eigentlich, ich zeige es euch lieber. Das sollte auf .40 sein. Nein. Wir sind also bei .39. Also werden wir das auf den anderen Host migrieren, auf .40.
David: Also, nutzen wir hier die vSphere-Speichermigration, um die Festplattendatei einer virtuellen Maschine von einer Festplatte auf eine andere zu migrieren, oder – was genau machen wir da eigentlich?
Steven: Wir nutzen kein Storage-vMotion, sondern nur vMotion. Im Grunde legen wir fest, dass die Ausführung und die Laufzeit auf dem anderen Server stattfinden sollen. Der gesamte Speicher für diesen Server befindet sich auf einer virtuellen Festplatte, die wir über DataCore bereitgestellt haben, und dadurch können beide Hosts darauf zugreifen. Denken Sie also daran, dass wir die Daten spiegeln. Wir schaffen damit Redundanz und Fehlertoleranz. So können wir diese virtuelle Maschine im Grunde migrieren, ohne die Dateien verschieben zu müssen, da sie tatsächlich für beide Hosts verfügbar sind.
David: Sehr schön.
Steven: Also, wir klicken jetzt auf „Beenden“, und dann könnt ihr sehen, dass die virtuelle Maschine im Hintergrund noch läuft; und hier sollten wir in einem Moment sehen, wie sich der Host ändert. Jeden Moment, sobald der Vorgang abgeschlossen ist. Da ist es, und jetzt laufen wir auf .40. Alles läuft noch. Alles ist noch aktiv. Wir hatten keine Probleme. Wir haben buchstäblich gerade eine virtuelle Maschine von einem Host auf einen anderen übertragen, und tatsächlich läuft das alles auf dem lokalen Speicher der vSphere-Server selbst.
David: Sehr schön. Coole Demo. Ich finde es toll, Live-Demos in Aktion zu sehen. Noch besser ist es, wenn sie auf Anhieb funktionieren. Echt cool.
Steven: Bevor wir losgelegt haben, habe ich zu den Demo-Göttern gebetet, und sie haben mir ein Lächeln geschenkt.
David: Gut. Hier ist noch eine weitere Frage eingegangen. Es geht um Deduplizierung, Komprimierung und Provisioning. Ich meine diese Funktionen, die man oft in einem SAN nutzt, um Speicherkapazität zu sparen. Sind diese Funktionen verfügbar, und wenn ja, wie funktioniert das im Rahmen des Lizenzmodells?
Steven: Also, alles ist bereits enthalten. Es gibt also keine integrierte Duplizierung. Wir verfügen über Komprimierungsfunktionen. Wir prüfen derzeit, diese zu erweitern, und werden die Plattform selbst weiter verbessern; aber alles, was wir heute tun, ist bereits in der bestehenden Lizenzierung enthalten. Die Frage bezog sich also auf Deduplizierung, Komprimierung und noch etwas Drittes. Was war das noch gleich? Mir fällt es gerade nicht ein.
David: Und dann die Bereitstellung.
Steven: Dann die Bereitstellung.
David: Native Bereitstellung.
Steven: Wir support also mittlerweile nativ support . Wir können also sowohl Thick- als auch thin provisioning, und noch einmal: All das sind, wie Sie wissen, Standardfunktionen. Keine Funktionen, für die eine zusätzliche Lizenz erforderlich ist.
David: Sehr gut, sehr gut. Es sieht so aus, als hätten wir hier bei der Veranstaltung noch sieben Minuten Zeit. Ich werde nun diese Folie aufrufen, auf der die zusätzlichen Ressourcen aufgeführt sind, die allen Teilnehmern zur Verfügung stehen. Über den dort angegebenen Link auf der Website von DataCore können Sie mehr über die virtuelle SAN-Software von DataCore erfahren. Sie können eine live demo anfordern. Sie können eine kostenlose Testversion herunterladen; und wenn Sie auf Ihrer Benutzeroberfläche auf den Reiter „Handouts“ gehen, können Sie mit einem Klick direkt von dort aus die Webseite hyperconverged virtual SAN sowie eine Reihe weiterer Ressourcen aufrufen, die Steve für die heutige Veranstaltung ausgewählt hat. Wir haben also noch ein paar Minuten Zeit für Fragen. Wenn Sie da draußen sind und weitere Fragen haben, ist jetzt der richtige Zeitpunkt, diese zu stellen.
Eine der Fragen, die hier eingegangen sind, Steve: Es geht um – mal sehen – integrierte Datensicherung und -wiederherstellung. Ist das eine Funktion, die in DataCore integriert ist, oder arbeiten Sie mit bestehenden Datensicherungslösungen zusammen? Wie funktioniert das?
Steven: Wir unterhalten also Partnerschaften mit einigen Anbietern von Datenschutzlösungen. Tatsächlich gibt es bestimmte Aspekte wie die Einhaltung der DSGVO, die Patienten möglicherweise nutzen möchten, aber wir verfügen bereits über eine native Funktion. Ich habe ja bereits von der asynchronen Replikation gesprochen. Wir können sicherstellen, dass die Daten verfügbar sind, und mit einigen unserer Integrationskomponenten, wie zum Beispiel dem Storage Resource Adapter, können Sie dafür sorgen, dass Ihre Daten gesichert und verfügbar sind und bei Bedarf von Standort zu Standort übertragen werden können. Auch wenn Sie einen snapshot bestehenden Daten erstellen und diese wiederherstellen müssen, verfügen wir über zahlreiche integrierte Funktionen dafür.
David: Kann man einen NAS [Filer] vor den hyperkonvergenten DataCore vSAN-Cluster schalten? Ist das möglich?
Steven: Ja. Auf dem DataCore-Server gibt es tatsächlich einige Empfehlungen, wie man das machen kann; aber man könnte auch einfach die nativen NFS von Microsoft nutzen und diese direkt, sagen wir in diesem Szenario, auf dem HVSAN-Server, also der von uns erstellten VM, bereitstellen. Man kann dort buchstäblich einfach die NFS aktivieren und über diese Dateifreigaben bereitstellen – oder, wenn man möchte, seine bevorzugte NAS-Software auswählen, diese installieren und den Speicher aus unserer Lösung auf diesem Server bereitstellen, um dann die NFS zu nutzen, die man über diese Lösung erstellt hat.
David: Das ist wieder eine gute Frage. Müssen die Knoten im Cluster identisch sein?
Steven: Sie müssen nicht identisch sein. Man kann also unterschiedliche Arbeitsspeicher, unterschiedliche CPUs und unterschiedliche Festplattentypen verwenden. Aus Sicht des Hypervisors gibt es natürlich einige Einschränkungen. Ich habe diese im Laufe unserer Erläuterung vielleicht ganz kurz angesprochen. Ich habe diese Server in einen Cluster zusammengefasst, da sie nicht identisch sind; und tatsächlich werde ich es Ihnen hier zeigen. Wenn ich mich recht erinnere, sollten wir das im Web-Client sehen können. Ich habe auf jedem dieser Server unterschiedliche CPU-Typen. Einer davon ist – ja, genau. Das hier ist also eine Intel-CPU vom Typ Sandy Bridge, und ich glaube, diese hier ist eine Ivy Bridge. Aus diesem Grund musste ich einen Cluster erstellen, um vMotion nutzen zu können; aber unsere Anforderungen sehen nicht vor, dass die Knoten gleich oder identisch sein müssen.
David: Und dann habe ich hier noch eine Frage zum Einstieg. Gibt es eine Testversion oder eine Version, die man für einen Proof-of-Concept nutzen könnte?
Steven: Auf jeden Fall. Wir bieten also eine kostenlose 30-Tage-Testversion an. Wenn Sie unsere Website besuchen und auf „Download“ klicken, können Sie die kostenlose 30-Tage-Testversion herunterladen und dann mit uns zusammenarbeiten. Falls Sie Ihren Proof of Concept verlängern müssen, sind wir natürlich gerne bereit, mit Ihnen zusammenzuarbeiten; aber wir bieten diese kostenlose Testversion an, die zum Download bereitsteht und verfügbar ist.
David: Und was die Migration angeht: Wenn jemand daran interessiert ist, von einem bestehenden SAN zu DataCore zu wechseln, wie läuft das ab? Gibt es Dienstleistungen, die dabei helfen? Gibt es Tools, die dabei helfen?
Steven: Das ist eine tolle Frage. Die Sache ist die: Man verbindet einfach nur den vorhandenen Shared-Storage-Dienst mit dem, was man aus Sicht von DataCore bereits bereitgestellt hat. Man kann also buchstäblich die DataCore-Software auf einem x86-Server bereitstellen – Windows installieren, DataCore installieren und dann das SAN damit verbinden; und schon ist DataCore Ihre Speichersteuerungslösung. Oder man kann es verbinden mit – nehmen wir mal an, Sie haben es so bereitgestellt, wie ich es hier getan habe. Und wenn Sie dann diesen gemeinsam genutzten Speicher damit verbinden möchten, müssen Sie diesen gemeinsam genutzten Speicher lediglich dem DataCore-Server zur Verfügung stellen, und wir übernehmen das dann und ermöglichen Ihnen – sagen wir, Sie möchten eine sogenannte „Evakuierung“ durchführen, also alle Ihre Daten von einem Pool in einen anderen verschieben –, dann sagen Sie einfach: „Hey, das möchte ich tun.“
Und ich möchte, dass die Daten von meinem Shared-Storage-Server zu meinem – sagen wir mal – vielleicht meinem X86-Hyperkonvergenz-System übertragen werden, und ich möchte, dass alle diese Daten dorthin übertragen werden. Das ermöglichen wir, weil Sie diesen Shared Storage einfach an uns angeschlossen haben, und wir dann die Steuerung übernehmen, die die Übertragung der Daten zwischen diesen verschiedenen Speicherpools ermöglicht.
David: Nun, ich glaube, das war’s dann mit den Live-Fragen und Antworten. Wir verlosen noch eine Amazon-Geschenkkarte im Wert von 300 Dollar. Der Gewinner dieser Geschenkkarte ist Bryant Godfrey aus Idaho. Herzlichen Glückwunsch, Bryant. Wir werden uns bei dir melden, um dir deine Geschenkkarte zukommen zu lassen. Tolle Präsentation, Steve. Vielen Dank, dass du heute bei unserer Veranstaltung dabei warst.
Steven: Danke für die Einladung. Das weiß ich sehr zu schätzen.
David: Vielen Dank an alle, die heute dabei waren. Wenn Sie Fragen zur Hyperkonvergenz-Lösung von DataCore haben, können Sie eine E-Mail an info@DataCore.com senden oder die Website DataCore.com besuchen. Werfen Sie auch einen Blick auf die Ressourcen, die dort in Ihrer Konsole verfügbar sind. Nochmals vielen Dank an alle und einen schönen Tag noch.