Die wichtigsten Trends, die Sie kennen sollten: Hyperkonvergenz, SDS, Flash und Cloud

Danielle: Guten Morgen und guten Nachmittag, liebe Teilnehmer. Mein Name ist Danielle Brown. Ich bin Marketingmanagerin bei DataCore Software und werde heute als Moderatorin fungieren. Wir heißen Sie herzlich willkommen zum heutigen Webinar mit dem Titel „Die wichtigsten Trends, die Sie kennen sollten: Hyperkonvergenz, SDS, Flash Cloud “. Bevor wir mit der heutigen Präsentation beginnen, möchte ich noch kurz einige organisatorische Hinweise mit Ihnen besprechen. Diese Präsentation wird aufgezeichnet und steht Ihnen später auf Abruf zur Verfügung.

Nach dem Webinar erhalten Sie eine E-Mail von BrightTALK mit einem Link zur Aufzeichnung. Sie können während der Präsentation gerne Fragen eingeben; wir werden diese am Ende des Webinars beantworten. Und schließlich haben wir für Sie im Abschnitt „Anhänge“ eine PDF-Version dieser Präsentation sowie einige weitere Links bereitgestellt. Damit möchte ich die Präsentation eröffnen und einen unserer ganz besonderen Referenten von heute vorstellen: unseren CEO, Präsidenten und Mitbegründer George Teixeira. George?

George: Vielen Dank für die Einführung. Mit mir hier ist auch Sushant Rao, unser Senior Director of Product Marketing. Und ich möchte nur sagen, dass es mir immer wieder Freude bereitet, über DataCore zu sprechen, aber es ist eine interessante Perspektive, schon so lange in dieser Branche tätig zu sein und tatsächlich zu den Pionieren zu gehören, die die Speichervirtualisierung bereits in den 1990er Jahren erfunden haben, und zu beobachten, wie sich diese weiterentwickelt und zu dem gewachsen ist, was wir heute als Software-Defined Storage und auch in die Hyperkonvergenz – all diese Funktionen – entwickelt und gewachsen ist.

Wir verfügen also über viel Erfahrung. Und eines der Highlights jedes Jahres ist, dass wir zu diesem Thema unsere jährliche Software-Umfrage durchführen. Ich finde es wirklich interessant zu sehen, wie sich die Welt verändert hat und welche Trends sich abzeichnen. Dieses Jahr haben etwa 426 IT-Fachleute an der Umfrage teilgenommen; wir möchten diese Informationen unbedingt mit Ihnen teilen und Ihnen unsere Gedanken und Analysen zu den Ergebnissen präsentieren. Sushant?

Sushant: Ganz genau, George. Also, ich denke – lassen Sie uns direkt zu einigen der Ergebnisse kommen. Fangen wir also mit dem ersten Punkt an: Was sind die Treiber für den Bedarf an software-defined storage? Wie Sie auf dem Bildschirm rechts sehen können, beziehen sich die vier wichtigsten Punkte auf eine vereinfachte Verwaltung (55 Prozent), die Zukunftssicherheit der Infrastruktur (53 Prozent), die Vermeidung von Hardware-Lock-in (52 Prozent) und die Verlängerung der Lebensdauer bestehender Speicherressourcen (47 Prozent).

Also, George, was fällt dir an diesen Fahrern besonders auf?

George: Nun, weißt du, das ist interessant, denn ich habe – als wir das Unternehmen gegründet haben, haben wir tatsächlich über softwaregesteuerten Speicher gesprochen und über die Idee, dass Software der Schlüssel dafür ist, wohin die Entwicklung wirklich geht. Und ehrlich gesagt hat es lange gedauert, aber wenn man sich die Anfänge dieses Ansatzes ansieht, haben wir uns vom ersten Tag an wirklich damit beschäftigt, wie man Ressourcen bündeln und die Verwaltung vereinfachen kann. Es ist also nach wie vor faszinierend zu sehen, dass die Vereinfachung und die Fähigkeit, mit unterschiedlichen Speichersystemen zu arbeiten, immer noch von entscheidender Bedeutung sind.

Übrigens muss ich darauf hinweisen, dass es bei unserer Umfrage nicht nur um verschiedene Anbieter geht, sondern auch um verschiedene Marken und Modelle. Ich meine, oft nutzen die Leute Speicherlösungen von – sagen wir mal – einem Anbieter wie HP, und dann stellt man fest, dass es aufgrund all der Übernahmen möglicherweise 10 verschiedene Typen, Modelle und Marken gibt, die untereinander nicht miteinander kommunizieren.

Das ist also nach wie vor der naheliegende erste Punkt. Und ich denke, die anderen sind auch irgendwie naheliegend. Ich meine, wenn man einen Software-Ansatz verfolgt, bereitet man sich damit im Grunde auf die Zukunft vor. Aber man möchte auch sicherstellen, dass bestehende Investitionen in dieser Speicherwelt weiterhin eine Rolle spielen können. Für mich sind das also die logischen Ansatzpunkte, und wenn ich sogar auf die letzten sechs Jahre zurückblicke, in denen wir diese Umfragen durchgeführt haben, sind dies tendenziell immer noch die wichtigsten Treiber.

Sushant: Ja, und was mir außerdem aufgefallen ist: Wenn man mal richtig darüber nachdenkt, was hinter all diesen Maßnahmen steckt, dann ist es doch das Bestreben, Kosten zu senken, oder? Die Vereinfachung der Verwaltung ist also ein Betriebsaufwand (OPEX), bei dem es darum geht, den Zeitaufwand zu reduzieren. Aber die anderen Punkte hängen alle mit den Investitionsausgaben (CAPEX) zusammen, oder? Zukunftssicherheit, damit man neue Komponenten hinzufügen kann, ohne das Vorhandene zu verschwenden; die Vermeidung von Hardware-Lock-in; die Wahlfreiheit, die beste Lösung für die bestehende Umgebung auszuwählen; die Verlängerung der Lebensdauer bestehender Speicherressourcen – all das zielt darauf ab, mehr aus den Investitionen herauszuholen, die man bereits in die Infrastruktur getätigt hat.

George: Ja, und ich denke, abgesehen von den Kosten – ich meine, jeder, der sich mit Speicherverwaltung beschäftigt, weiß, dass wir in einer Welt des Wandels leben. Und Begriffe wie „Zukunftssicherheit“, die Vermeidung von Hardware-Bindung und die Verlängerung der Lebensdauer drehen sich alle darum, mit Veränderungen umzugehen. Je mehr man sich also in einer softwaredefinierten Welt bewegt, desto flexibler ist man und desto besser kann man damit umgehen – ganz gleich, welche Veränderungen auf einen zukommen, ob es nun um eine Migration oder ein Upgrade auf zukünftige Lösungen geht.

Vor allem angesichts der neuen Technologien, die ständig hinzukommen.

Sushant: Und das ist interessant. Denn manchmal bekommen wir solche Anfragen von, na ja, Analysten, die sagen: „Geben Sie uns doch Ihre Prognosen für die nächsten fünf oder zehn Jahre.“ Und was mir dabei auffällt, ist, dass es schon so schwer ist, drei Jahre im Voraus zu prognostizieren, oder? Und diese Möglichkeiten, von denen du sprichst – bei denen die Intelligenz der Software es einem ermöglicht, sozusagen die derzeit angesagten Technologien zu kombinieren, die in drei bis fünf Jahren vielleicht schon nicht mehr aktuell sind.

George: Genau.

Sushant: Also, lassen Sie uns weitermachen und noch ein bisschen darüber reden, wissen Sie, und uns einige der anderen Aspekte ansehen, die wir beim software-defined storage beobachtet haben. Diese Frage hängt also wirklich damit zusammen, was die Leute sich von ihrer Infrastruktur erwarten, oder? Da wäre also die Kosteneffizienz mit 60 Prozent; Disaster-Recovery-Fähigkeiten mit 65 Prozent; Speichererweiterung ohne Unterbrechungen mit fast drei Vierteln; und dann die Geschäftskontinuität, was im Grunde hochverfügbare Systeme bedeutet – das gaben mehr als vier von fünf Befragten an.

Welchen Trend beobachtest du, George?

George: Um ehrlich zu sein, überrascht mich nach wie vor, wie leistungsfähig die Funktionen im Bereich Geschäftskontinuität und Notfallwiederherstellung sind. Ich glaube, es ist so: Während alle davon ausgehen, dass die Architekturen immer zuverlässiger werden, sind die Folgen von Ausfallzeiten oder Datenverlusten mittlerweile so gravierend, dass sie für die meisten Unternehmen praktisch eine existenzbedrohende Situation darstellen.

Es überrascht mich also nicht wirklich, dass das, na ja, so entscheidend ist. Ich kann dir sagen: Wenn ich an die Zeit vor Jahren zurückdenke, gingen die Leute davon aus, dass Software nicht der richtige Weg sei, um ein solches Maß an Zuverlässigkeit zu erreichen. Sie gingen davon aus, dass man einfach redundante Hardware einsetzen müsse und dass die Hardware die Lösung sein würde. Interessant ist jedoch, dass es bei praktisch allen Softwarefunktionen letztendlich auf die Software ankommt.

Ich denke also, dass die Möglichkeit, sozusagen alles in der Software abzubilden und alle Funktionen dort zu realisieren, der eigentliche Schlüssel dazu ist. Die Kontinuität ist also ein wichtiger Punkt. Sie haben bereits über die Kosteneffizienz gesprochen. Ich denke, das zieht sich wie ein roter Faden durch alle hier vorgestellten Ansätze. Also, wie ich schon sagte: Die Geschäftskontinuität ist aus meiner Sicht ein wichtiger Faktor, und ich bin wirklich froh, dass sie für viele Menschen nach wie vor der Haupttreiber ist, denn ich glaube, das ist eines dieser Dinge, die man zwar irgendwie für selbstverständlich hält, deren Notwendigkeit einem aber erst dann wirklich bewusst wird, wenn das Problem auftritt.

Und ich glaube, was viele der Ausfälle da draußen und sogar Ausfallzeiten bei cloud und so weiter angeht – na ja, die Unternehmen erkennen einfach, dass sie sich heutzutage keine Ausfallzeiten mehr leisten können.

Sushant: Ja, das ist wirklich interessant, denn – weißt du – das ist das, wofür ich immer das Beispiel anführe: Wie ist das eigentlich, wie viel kann man schon erledigen, wenn man keinen Zugang zu Kommunikationssystemen wie E-Mail hat, oder? Stell dir nun vor, wichtige, geschäftskritische Systeme fallen aus; wenn sie ausfallen, welche Auswirkungen hat das auf die Organisation, auf das Unternehmen? Und ich denke, genau das zeigt sich hier.

Kommen wir also zur nächsten Folie und sprechen wir ein wenig über die Leistung und – sowie darüber, inwiefern dies mit flash zusammenhängt. Wir haben also eine Frage zur Virtualisierung gestellt, richtig, und gefragt, welche Überraschungen es nach der Virtualisierung geschäftskritischer Anwendungen gab. Wie Sie sehen werden, gaben etwa 31 Prozent an, dass sie gemeinsam genutzte Speicher benötigten, um die Hochverfügbarkeit der Cluster zu gewährleisten; 29 Prozent stellten fest, dass die Reaktionszeiten der Anwendungen langsamer waren als vor der Virtualisierung. Und schließlich gaben ebenfalls 29 Prozent an, dass die Ermittlung des Speicherbedarfs schwieriger geworden sei.

Also, George, ich würde gerne deine Meinung zur Anwendungsreaktion hören. Weißt du, angesichts der Tatsache, dass wir schon seit 10 Jahren virtualisieren – Unternehmen beschäftigen sich ja schon seit 10 Jahren mit Virtualisierung –, überrascht es mich, dass die Leute immer noch – ich nehme an – von den Leistungseinbußen nach der Virtualisierung überrascht sind, insbesondere bei ihren geschäftskritischen Systemen.

George: Na ja, ich meine, ich glaube, was passiert ist, ist, dass die Leute einfach davon ausgehen, dass die virtuellen Maschinen exakte Kopien der physischen Maschinen sind. Und weißt du, um ehrlich zu sein: Wenn man noch auf einer physischen Maschine läuft, kann man mehr Leistung herausholen. Und das liegt zum großen Teil an den Ressourcen und so weiter; vor allem bei der Virtualisierung neigt man dazu, viele Ressourcen gemeinsam zu nutzen.

Die Wahrheit ist, dass es immer besser wird. Und ich denke, neue Technologien wie parallele E/A und Ähnliches sowie die Art und Weise, wie man Speicher zwischenspeichern und nutzen kann, sind entscheidend. Aber viele Technologien haben es noch nicht auf den Markt geschafft. Was also die Anwendungsleistung angeht, ist meiner Erfahrung nach das Hauptproblem in der Regel bei transaktionsorientierten Workloads, insbesondere bei hohem Datenverkehr – also bei Vorgängen, die viel grundlegende E/A erfordern. Und in solchen Fällen lässt sich das Problem nicht einfach durch den Einsatz von mehr Rechenleistung lösen.

Und was dabei passiert, ist, dass es zu zahlreichen E/A-Konflikten kommt, und wenn man versucht, all das sozusagen auf demselben Server zu bündeln, entsteht im Grunde ein Wettbewerb um die Ressourcen für die E/A-Vorgänge, was zu einem Problem wird. Hier kommt meiner Meinung nach intelligenter Speicher ins Spiel, der tatsächlich mehr aus dieser Hardware herausholen und die Arbeitslast verteilen kann, um eine bessere Anwendungsleistung zu erzielen – das ist entscheidend.

Sushant: Nun, du sprichst da etwas an, das meiner Meinung nach wirklich wichtig ist: Wenn die meisten Unternehmen eine Ursachenanalyse durchgeführt haben, haben sie festgestellt, dass es nicht unbedingt am Server liegt und auch nicht an der Anwendung selbst; in den meisten Fällen sind es sozusagen die E/A und der Speicher, die den Schwachpunkt darstellen. Richtig? Dort liegt also der Engpass. Und das verlangsamt die gesamte Anwendung.

George: Ja, und ich denke, ein weiterer Punkt ist: Wenn man mit der Virtualisierung beginnt, haben viele Unternehmen zunächst Dinge wie virtuelle Desktops und vielleicht weniger anspruchsvolle Anwendungen virtualisiert. Am zurückhaltendsten bei der Virtualisierung waren Bereiche wie Datenbanken, insbesondere solche, die sehr transaktions- und E/A-intensiv sind – dort war der Nutzen einer Umstellung auf den virtuellen Modus bisher geringer. Und es gibt noch weitere Gründe dafür, zum Beispiel die Unterstützung von Fibre Channel, was oft gleichbedeutend damit ist, an die Datenbank gebunden zu sein.

In vielen dieser Fälle schneiden sie nicht so gut ab, wenn man auf virtuelle Plattformen umsteigt. Es gibt also noch andere Gründe, die meiner Meinung nach dazu geführt haben, dass die Umstellung in diese Richtung etwas langsamer voranschreitet. Auch wenn es ein Trend ist, dass immer mehr Unternehmen dazu übergehen, diese geschäftskritischen Anwendungen zu virtualisieren.

Sushant: Ja, ich meine, ich glaube, die Flexibilität, die ihnen die Virtualisierung bietet, ist etwas, das sie sich wünschen. Aber wenn ich mit Kunden spreche, geht es ihnen vor allem darum, wie sie die Vorteile der Virtualisierung in Bezug auf Flexibilität und Agilität nutzen können, ohne dabei Leistungseinbußen in Kauf nehmen zu müssen, verstehen Sie? Das ist also etwas, worauf Unternehmen achten müssen, wenn sie ihre geschäftskritischen oder wichtigsten Anwendungen virtualisieren.

Kommen wir also zur nächsten Folie, in der es darum geht, welche Anwendungen die gravierendsten Leistungsprobleme im Zusammenhang mit dem Speicher aufweisen. Wie Sie sehen können, liegen auf einer Skala von 1 bis 5 – wobei 1 die meisten Probleme und 5 die wenigsten bedeutet – Datenbanken, wie Sie bereits sagten, George, an erster Stelle. Interessanterweise liegen VDI und Unternehmensanwendungen – ERP, CRM und J2EE – auf dem zweiten Platz fast gleichauf.

Dann folgen Web- und Mail-Server und anschließend Datei- und Druckerserver. Ich war schon ein bisschen überrascht, dass VDI so weit oben steht. Aber vielleicht sollte ich das gar nicht sein, denn schließlich sitzt da ja jemand am Desktop, drückt eine Taste und erwartet dann eine Antwort, oder?

George: Ja. Nein, ich meine, ich glaube, das passt irgendwie zu dem, was wir gerade besprochen haben, und wenn ich mir die Virtualisierungspyramide anschaue, folgt sie irgendwie diesem Muster. Ich meine, die Pioniere haben viel getestet und entwickelt; sie haben ihre Datei-, Druck-, Web- und Mailserver verlagert – das ist die VDI; und jetzt wenden sie sich den schwierigeren Aufgaben und Anwendungen zu, seien es Unternehmensanwendungen oder Datenbanken – diese beanspruchen viel mehr CPU-Leistung, Rechenkapazität und Arbeitsspeicher und sind daher schwieriger in die virtuelle Welt zu übertragen.

Sushant: Ein weiterer interessanter Aspekt ist der Unterschied zwischen „Scale-up“ und „Scale-out“. Richtig? Manche Anwendungen eignen sich besser für „Scale-out“ – wie zum Beispiel VDI: Wenn man mehr Leistung benötigt, kann man „Scale-out“ betreiben, indem man weitere Server oder Knoten hinzufügt, und so die Leistung steigern. Das gilt jedoch nicht für Datenbanken und Unternehmensanwendungen. Ich meine, bei diesen gibt es nur begrenzte Möglichkeiten für „Scale-out“. Weißt du, wenn man Analysen durchführen oder viele Transaktionen abwickeln will, muss man manchmal – ab einem bestimmten Punkt – wirklich über „Scale-up“ nachdenken, oder?

George: Ja, und ich glaube, bei diesen Anwendungen, die du gerade erwähnt hast, ist es entscheidend, die Leistung zu steigern. Und weißt du, es ist interessant, denn wenn man sich die Umstellung auf virtuelle Umgebungen ansieht, ist das ein Sprungbrett für den Weg in die cloud. Ich meine, es ist sozusagen ein Übergang vom Physischen zum Virtuellen. Die virtuelle Umgebung ermöglicht es mir dann, softwaredefiniert zu werden. Sobald ich softwaredefiniert bin, ist das die Brücke in die cloud.

Die Leute verstehen also, dass sie das tun müssen. Das Problem ist: Wenn ich nicht die Antwortzeiten erhalte, die ich von der Datenbank erwarte, und ich einen Schritt zurücktreten muss, ist das nicht akzeptabel. Ja, ich investiere mehr in die Leistung durch CPUs und dergleichen, aber wir stehen immer noch vor einer großen Herausforderung, insbesondere im Bereich der E/A und der Speichersysteme.

Sushant: Ja. Und was du noch über cloud gesagt hast, also den Schritt in Richtung cloud: Selbst wenn man sich die cloud ansieht, bieten sie doch unterschiedlich große – im Grunde genommen virtuelle Maschinen – an, oder? Von eher klein bis groß. Denn sie wissen ja, dass manche Anwendungen einfach eine größere „Box“ brauchen, oder? Es ist zwar eine virtuelle Maschine, aber es ist immer noch eine Maschine – im Gegensatz zu anderen Lösungen, bei denen man mit kleineren Maschinen auskommt, aber im Grunde skaliert und einfach immer mehr dieser Instanzen hinzufügt.

Genau hier kommt also VDI ins Spiel. Aber noch einmal: Bei etwas wie einer Datenbank muss man sich wirklich überlegen, wie man die Kapazität ausbauen kann. Also weiter im Text: Wir haben dann die Frage gestellt, bei welchen Anwendungen die meisten Probleme auftreten. Anschließend haben wir untersucht, welche Ansätze die Nutzer bevorzugen, um diese Leistungsprobleme zu lösen. Auch hier gilt: Eins ist die höchste Präferenz, fünf die geringste, und dies sind die fünf häufigsten Antworten.

Also, zunächst einmal waren da flash . Dann kam die Softwarebeschleunigung auf den Host-Rechnern. Anschließend erfolgte der Umstieg auf eine In-Memory-Datenbank. Danach erfolgte die Umstellung auf eine private oder hybride Cloud . Und schließlich – zumindest unter den Top 5 – stand die Neuprogrammierung der Anwendung. George, was fällt dir an den Antworten besonders auf?

George: Eigentlich überrascht mich das nicht. Ich meine, alsflash auf den Markt kamen, lautete der Hype: „Alles wird schneller.“ Und es schien die einfache Lösung zu sein. Ich meine, wenn man ein Stück Hardware kaufen kann, das einen Unterschied macht, dann tut man das natürlich. Nun gab es natürlich Kostenprobleme, es gibt ein paar Probleme hinsichtlich der richtigen Leistung und so weiter. Aber ich denke, dassflash – einfach als Technologie im Allgemeinen – einen Unterschied machen.

Das macht es, wissen Sie, in vielerlei Hinsicht viel schneller. Man muss sich aber auch bewusst machen, dass D-RAM und diese Art von Speicherlösungen immer noch, wissen Sie, sechsmal schneller sind alsflash . Es gibt also noch Luft nach oben. Die anderen Fragen, die wir gestellt haben – ob es nun um Softwarebeschleunigung oder Switching ging –, wenn man sich diese einzeln ansieht, gibt es dabei eine Menge Probleme. Ich meine, Softwarebeschleunigung auf dem Host-Rechner – um ehrlich zu sein, erforderten viele dieser Lösungen spezielle Anpassungen und führten daher zu Betriebsunterbrechungen.

Wenn man wieder auf eine In-Memory-Datenbank umsteigt, gibt es da erstens oft hohe Kosten; zweitens kann das zu Betriebsstörungen führen. Und wissen Sie, der Umstieg auf die Private cloud führt meiner Meinung nach wieder zu dem von Ihnen angesprochenen Problem zurück: Wenn man horizontal skalieren und die gewünschte Leistung erzielen kann, ist das gar nicht so schlecht. Aber oft kann man einfach nicht nach oben skalieren und mehr Leistung erzielen. Und andererseits kann cloud in der Public cloud ziemlich teuer werden. Das ist also ein weiteres Problem. Und die Anwendung neu zu schreiben, ist, ehrlich gesagt, eines der letzten Dinge, die die Leute wirklich tun wollen. Sie tun es also nur, wenn es sich um eine wirklich kritische Situation handelt. Ich weiß, wir haben sogar andere Fragen gestellt, zum Beispiel, ob man auf einen Supercomputer umsteigen möchte und so weiter. Aber ich denke, insgesamt habe ich daraus mitgenommen, dass flash der naheliegende, schnelle Weg flash , um zu versuchen, etwas mehr herauszuholen.

Aber wissen Sie, man muss sich wirklich die Kosten ansehen und prüfen, ob es tatsächlich sinnvoll ist. Bei vielen Anwendungen macht es vielleicht gar keinen Unterschied. Wenn wir also auf die vorherigen Folien zurückblicken, die wir gerade besprochen haben, sind es wirklich vor allem die ERP-Systeme, Windows, virtuelle Desktops und die Datenbanken – das sind die Bereiche, in denen es wirklich einen Unterschied machen wird.

Sushant: Was mir außerdem aufgefallen ist: Ich glaube, die Leute haben mehrere Schritte unternommen. Ich glaube, sie haben esflash versuchtflash da das das Problem bei bestimmten Anwendungen nicht wirklich gelöst hat, haben sie sich dann mit einigen der eher ausgefallenen oder, na ja, etwas schwierigeren Maßnahmen befasst, wie zum Beispiel: „Na ja, der Umstieg aufflash geholfen; vielleicht muss ich mir dann die nächste Lösung ansehen, nämlich die In-Memory-Datenbank, oder die Anwendung neu schreiben.“ Stimmt’s?

Wenn man Leistungsprobleme mit einer kritischen Anwendung hat – man weiß ja: Gäbe es so etwas wie ein Wundermittel, das all diese Probleme löst, würde man es nutzen. Und ich denke, im Allgemeinen sagen die Leute dann: „Oh, ich probiere malflash aus“, oder? Und wenn das nicht funktioniert, probieren sie einige dieser anderen Lösungen aus. Denn ehrlich gesagt ist die Umstellung auf In-Memory – wie die Leute, mit denen wir gesprochen haben und die das in Betracht ziehen, bestätigen – ein langwieriger Prozess. Das ist nichts, was man an einem Wochenende erledigen kann, im Gegensatz zum Hinzufügen einesFlash ; das kann man potenziell schon an einem Wochenende in der Infrastruktur bereitstellen.

Einige dieser anderen Dinge werden viel länger dauern, und ich glaube, das liegt daran, dassFlash ganz das Wundermittel ist, als das es oft dargestellt wird. Kommen wir also zum nächsten Punkt. Wir haben uns also die Einführung flash angesehen – wir haben danach gefragt, richtig? Und da sieht man das Ausmaß. Richtig? Die Zahl derjenigen, die keinen flash nutzen, flash von Jahr zu Jahr kleiner geworden. Derzeit liegt sie bei etwa 15 Prozent, also unter 15 Prozent. Interessant ist aber auch, dass der Anteil derjenigen, bei denen der Anteil von Flash-Speicher mehr als die Hälfte ausmacht, bei etwa 10 Prozent liegt.

Die Mehrheit der Leute scheint also irgendwo in der Mitte zu liegen. Sag mal, George, was denkst du dir bei solchen Kommentaren? Ach, jeder muss auf einflash umsteigen.

George: Nun, ich meine, ich denke, es ist auch eine wirtschaftliche Frage. Und das ist irgendwie interessant. Ich habe all diese Trends beobachtet, und wenn man dem Hype zuhört, sagen alle: „Na ja, flash doch klar, alle steigen auf flash um.“ Und sie gehen davon aus, dass alle so schnell umsteigen werden. Aber es dauert eine gewisse Zeit, bis die Leute umsteigen, selbst wenn die Richtung klar ist. Ein Grund dafür sind die flash , denn dieser ist zum Großteil immer noch teuer. Ein weiterer Grund ist, dass die Leute massiv in bestehende Festplatten investiert haben. Und es ist schon ein bisschen verrückt anzunehmen, dass die Leute nicht versuchen werden, diese weiter zu nutzen. Und genau das ist einer der großen Treiber für Software-Defined-Storage: die Möglichkeit, das Vorhandene zu nutzen und mehr daraus herauszuholen. Das lässt sich durch Caching und andere Techniken erreichen, die es wiederum ermöglichen, einen größeren Teil der E/A-Vorgänge im Arbeitsspeicher abzuwickeln, sodass man sich den Geschwindigkeiten flash annähert.

Das soll heißen: flash glaube, flash wird sich weiterentwickeln und in den Systemen immer häufiger zum Einsatz kommen. Das ist ganz offensichtlich, wenn man bedenkt, wo wir vor ein paar Jahren angefangen haben – damals sind ja jede Menge flash und flash wie Pilze aus dem Boden geschossen. Ich meine, vor drei Jahren gab es, glaube ich, etwa 150 neue flash . In allen Artikeln ging es um neue flash . Heute verkauft so gut wie jeder, der Speicherlösungen anbietet, auch flash. Und die Entwicklung wird sich ganz klar in Richtung PCI-Karten, NVME all das fortsetzen.

Es gibt hier also jede Menge Vorgaben. Aber ich sehe das als etwas Positives. Das wird einfach dazu beitragen, die Leistung zu steigern, aber ich möchte auch daran erinnern, dass es erstaunlich ist, wie die Leute Wege finden, diese zusätzliche Leistung zu nutzen – nur weil sie nun zur Verfügung steht.

Sushant: Ja, auf jeden Fall. Was mir daran außerdem auffällt – ich glaube, während du gesprochen hast, ist eines der interessanten Dinge, dass flash eigentlich für Daten in Bewegung flash , so wird es zumindest von manchen Leuten bezeichnet, oder? „Hot Data“, „Warm Data“. Aber wenn man Daten im Rest hat, also „Cold Data“, macht es keinen Sinn, diese auf flash zu speichern. Und ich denke, das ist – einer der Bedenken. Du hast vorhin über die Wirtschaftlichkeit gesprochen.

Also, wenn der Großteil Ihrer Daten im Rest ist, macht es dann wirklich Sinn, sie auf diesem extrem leistungsstarken flash zu speichern? Selbst wenn man all die Probleme mit der richtigen Leistung einmal außer Acht lässt: Gibt es ein wirtschaftliches Argument dafür, dass flash seinen Platz haben wird, aber nicht unbedingt das Rechenzentrum sozusagen komplett ablösen wird?

George: Nein, das ist ein guter Punkt, Sushant. Weißt du, ich habe in einer Zeit angefangen, in der man das noch „hierarchisches Speichermanagement“ nannte. Und das verrät mein Alter – das waren noch die IBM-Zeiten und so weiter.

Sushant: Ach komm schon, George, dafür bist du noch viel zu jung. Woher willst du das überhaupt wissen?

George: Aber in Wirklichkeit besteht dieses Problem schon seit jeher: Wenn neue Technologien und Speichermedien aufkommen, gibt es immer eine Geschwindigkeits- und Zeitlücke zwischen den einzelnen Ebenen. Wenn man sich das heute ansieht: Wenn ich in die cloud gehen cloud mir Dinge wie Glacial Storage und so weiter ansehen möchte, gibt es ein Geschwindigkeitsproblem. Bei den vorhandenen Festplatten habe ich einerseits die schnellen mit 15.000 U/min und andererseits die langsameren Laufwerke.

Ich habe – selbst im flash – mehrere Geschwindigkeitsstufen. Ich habe PCI-Karten usw. Und es kommen neue Versionen auf den Markt, die, wie Sie wissen, den D-RAM mit dem bestehenden flash kombinieren werden. Was Sie also brauchen, ist wirklich intelligenter, softwaredefinierter Speicher mit Funktionen zur automatischen Speichereinstufung. Und ich denke, das ist eines der Probleme. Der Kunde selbst denkt in erster Linie an die Wirtschaftlichkeit und daran, seine Aufgaben zu erledigen. Mit anderen Worten: Wie sieht die Service-Level-Vereinbarung in Bezug auf die Leistung aus?

Die Aufgabe unserer Software – oder besser gesagt: die Aufgabe von Software-Defined Storage – besteht darin, all das für den Anwender unsichtbar zu machen. Der Anwender sagt im Grunde nur: „Besorgt mir die kostengünstigsten Daten und stellt sie mir auf dem schnellsten Weg zur Verfügung, damit ich meine Anwendungsziele erreichen kann.“ Das ist wirklich der entscheidende Punkt. Wissen Sie, die Einführung flash ist zwar wichtig, aber wenn man sich das gesamte Unternehmen ansieht, geht es eigentlich darum, über welche Speicherressourcen man verfügt. Und wenn man über eine große Menge an bestehenden Daten verfügt und etwas flash hat – kann man die Daten flash Bedarf auf den flash verschieben und kann man die Daten in die cloud verschieben, cloud man sie beispielsweise nur archivieren möchte?

Das sind genau die Art von Abläufen, die derzeit stattfinden, und man braucht Software, die intelligent genug ist, um das zu bewältigen.

Sushant: Auf jeden Fall. Gut, dann gehen wir zur nächsten Folie über. Wir haben also über Leistung gesprochen, wir haben über flash gesprochen. Lassen Sie uns nun ein wenig das Thema wechseln und ein wenig über Hyperkonvergenz sprechen. Wir haben also zunächst die Frage gestellt: Was ist eigentlich die Definition von Hyperkonvergenz? Und wir haben den Teilnehmern verschiedene Antwortmöglichkeiten angeboten, da die Anbieter ja unterschiedliche Optionen auf dem Markt anbieten.

So gaben 41 Prozent an, dass die Lösung eng in hypervisor integriert, hypervisor hardwareunabhängig sei; 27 Prozent nannten eine integrierte Appliance, bei der Hardware und Software fest miteinander verbunden sind; 17 Prozent verfügten über Hardware und Software, die man separat zusammenstellen und aktualisieren kann; 12 Prozent hatten eine Hardware-/Software-Lösung, die unabhängig aktualisiert werden kann; und 3 Prozent wählten die Option „Sonstiges“.

Also, George, was hast du denn so gesehen, als du – oder was hast du gedacht, als du diese Definitionen und die Zahlen gesehen hast?

George: Ich war wohl überrascht und doch auch wieder nicht. Es ist interessant, denn als sich die ersten Definitionen dafür, wie man Dinge angeht, mehr annäherten – lassen Sie es mich so formulieren –, lag die Frage auf der Hand: Könnte ich die Hypervisoren nutzen und gleichzeitig Speicher auf derselben Plattform bereitstellen? Und es scheint, als sei diese Definition – die, wie ich hier überrascht feststelle, an erster Stelle steht – nun bekannt, seit Nutanix und andere in dieser Kategorie richtig durchgestartet sind. Und weißt du, wenn ich zwei, drei Jahre zurückblicke, ist es interessant: Man kam an einen Punkt, an dem die Leute es anscheinend so definierten: „Oh, das ist ein Nutanix, das ist eine Appliance.“ Und die Definition verschob sich schnell hin zu einer einfachen Appliance, die man einfach schlüsselfertig in Betrieb nimmt und die dann die Arbeit erledigt.

Ich glaube, da die Kunden immer versierter geworden sind, kommen sie wieder zu der Erkenntnis: „Hört mal, ich habe auch ein viel größeres Problem“, und, wisst ihr, da habe ich ja wieder Investitionen in Hypervisoren und Speicher getätigt. Wo ich diese beiden Komponenten miteinander integrieren kann, werde ich das auch tun. Und wisst ihr, die Realität sieht so aus, dass wir all das haben werden. Ich meine, ich denke, die integrierte Appliance und viele der Anwendungen wie ROBO, Remote Offices –

Sushant: Das leuchtet ein.

George: Weißt du, das leuchtet mir total ein. Aber ich glaube, wenn wir versucht haben, beispielsweise Hyperkonvergenz-Lösungen in Rechenzentren mit Gewalt unterzubringen – vor allem dort, wo es zum Beispiel Datenbanken mit einer Mischung aus Fibre-Channel-Netzwerken gibt und wo man eine Verbindung zu alten Unix-Servern und ähnlichen Systemen herstellen muss, oder zu Solaris und IBM AIX –, dann gibt es da draußen eben eine große Vielfalt.

Ich finde es interessant, dass Hyperkonvergenz ursprünglich mit so einer Art hypervisor begann. Ich glaube, das ist immer noch so. Die andere Gegenkraft war die Ansicht: Nein, es handelt sich eigentlich um eine Appliance. Die Appliance macht das Ganze zwar viel weniger flexibel, bietet aber auch deutlich mehr Einfachheit und Automatisierung. Diese beiden Ansätze stehen derzeit gewissermaßen im Widerspruch zueinander. Die gute Nachricht ist, dass meiner Meinung nach die Kunden in beiden Bereichen gewinnen. Denn ich glaube, dass das, was früher als Software-Defined-Storage bezeichnet wurde, komplexer war.

Es wird immer automatisierter und einfacher. Und man kann damit viel mehr anstellen. Und tatsächlich beginnt die Grenze zwischen sozusagen softwaredefiniertem Speicher und hyperkonvergenten Lösungen zu verschwimmen – genau das passiert gerade. Jetzt geht es wirklich nur noch darum, wie man die Lösung bereitstellen möchte.

Sushant: Und ich finde, diese Bemerkung, die du am Ende gemacht hast, trifft es wirklich genau, oder? Man muss den Anwendungsfall verstehen, den man lösen will, und sich dann fragen: Was ist am sinnvollsten? Weißt du, zum Beispiel hast du über die integrierte Appliance gesprochen, aber wenn man sich die vierte Option ansieht, nämlich ein Hardware-/Software-Bundle, dann geht es dabei um genau dasselbe: Hey, ich brauche etwas relativ Einfaches, ich muss es einfach nur bereitstellen, oder?

Wo macht das Sinn? Bei etwas wie ROBO, oder? Wenn man eine Außenstelle hat. Dort sind die Anforderungen nicht allzu hoch. Oder vielleicht bei etwas wie VDI, wo es sich um eine Standardlösung handelt, richtig? Man braucht einfach – gewissermaßen – eine Referenzarchitektur, bei der man, wenn man die Nutzerzahl erhöht, einfach die benötigte Anzahl an Servern nach Schema F bereitstellen kann. Das scheint also irgendwie Sinn zu machen. Aber ich denke, das, worüber wir vorhin gesprochen haben – nämlich die Möglichkeit der Integration in den hypervisor – spricht hypervisor für die Fähigkeit, die Verwaltung Ihrer Infrastruktur zu vereinfachen, oder? Wenn man jemanden betrachtet, der sagt: „Hey, ich habe größere Verwaltungsprobleme“, wie soll man dann wissen, wie man Silos bildet, was in manchen Fällen ein hyperkonvergentes Angebot mit sich bringen kann, oder? Das ist problematisch.

George: Ja. Ich meine, weißt du, die andere Sache ist – wenn man sich das alles ansieht –, dass wir Software-Defined-Storage sind und hyperkonvergiert arbeiten. Beides baut gewissermaßen auf demselben Grundkonzept auf, nämlich dass man versucht, auf Standard-Servern oder handelsüblichen X86-Servern zu arbeiten. Und das Ziel ist es, einen Ansatz zu entwickeln, mit dem man quasi eine Art Google Cloud Ort aufbauen kann.

Und ich denke, beide Ansätze sind sinnvoll. Ich meine, natürlich bietet Software-Defined-Storage mehr Flexibilität. Der Appliance-Ansatz bietet für manche Nutzer eine viel schlüsselfertigere, weniger komplexe Lösung. Die von Ihnen erwähnten Anwendungsfälle sind also der richtige Ansatz, den man bei der Umsetzung unbedingt berücksichtigen muss. Und es nervt mich irgendwie, wenn ich mit verschiedenen Leuten spreche und sie frage: „Warum wollen Sie das eigentlich kaufen?“, und sie dann sagen: „Na ja, ich möchte hyperkonvergieren“, und dann beschreiben sie etwas, bei dem man beim genauen Hinsehen feststellt, dass die Anforderungen eigentlich für ein Rechenzentrum gelten – es gibt Fibre-Channel, sie wollen eine Datenbank betreiben.

Und du sagst: „Ich bin mir nicht sicher, was das ist.“

Sushant: Ja, ja.

George: Hier gibt es also eine Mischung.

Sushant: Ich meine, weißt du, früher haben wir darüber gesprochen, dass flash sozusagen der Retter des Rechenzentrums flash . Und in gewisser Weise ist Hyperkonvergenz fast genau das: „Oh, du hast ein Problem? Dann setzen wir auf Hyperkonvergenz“, oder? Ohne wirklich darüber nachzudenken, was der Anwendungsfall ist und, na ja, was die richtige Lösung ist. Vielleicht ist es Hyperkonvergenz, vielleicht auch nicht, aber ich halte es für wirklich wichtig, zunächst zu klären: Was willst du erreichen, was ist dein Ziel, was ist dein Anwendungsfall? Und dann herauszufinden, was die richtige Lösung ist.

George: Und ich halte es für sehr wichtig, dass es sich bei beiden um großartige Technologien handelt. Sowohl Software-Defined Storage als auch Hyperkonvergenz führen uns zu einem Ansatz, der wirklich auf einem Softwaremodell basiert.

Sushant: Ja.

George: Und die Tatsache, dass man Hardware als – in Anführungszeichen – „Appliance“ nutzt – selbst solche Dinge verlieren zunehmend an Bedeutung. Ich meine, wenn man sich beispielsweise Nutanix ansieht: Auch dort versucht man, auf einen rein softwarebasierten Ansatz umzusteigen. Wissen Sie, am Anfang ist die Appliance für mich ein deployment , das den Einstieg etwas vereinfacht, aber sobald man loslegt und die Herausforderungen kennenlernt, ist die Flexibilität der Software der entscheidende Faktor. Der Umstieg auf Software-Defined bietet uns also die Möglichkeit, uns wirklich zukunftssicher zu machen.

Sushant: Auf jeden Fall. In der Umfrage haben wir dann gefragt, wie weit die Unternehmen bei deployment hyperkonvergenter deployment sind. Wie Sie sehen können, gibt es die Gruppe „ziehen es nicht in Betracht“ – fast ein Drittel der Befragten gehört dazu. Ein weiteres Drittel gab an, dass sie dies zwar ernsthaft in Erwägung ziehen, aber noch keine Lösung eingeführt haben. Das sind also zwei Drittel, die noch keine Lösung eingeführt haben. 20 Prozent hatten einige wenige Knoten; 7 Prozent hatten einige größere Implementierungen; 6 Prozent haben ihre Infrastruktur darauf standardisiert. Also, George, ich fand diese Zahlen wirklich interessant, wenn man bedenkt, wie viel Aufsehen hyperkonvergente Lösungen auf dem Markt erregen.

George: Nun, das ist interessant, denn – weißt du, wenn man sich den gesamten Speichermarkt ansieht, ist der riesig. Und man hört ja immer den ganzen Hype und Trubel in den Nachrichten und natürlich von Börsengängen und so weiter. Die Unternehmen, die schnell wachsen und viel Aufsehen erregen, bekommen also viel Aufmerksamkeit. Aber wenn man es sich genauer ansieht – ich meine, wir sprechen hier immer noch von einem Speichermarkt mit einem Volumen von 20 bis 30 Milliarden Dollar; der Bereich der Hyperkonvergenz ist immer noch relativ klein.

Insofern überrascht mich das also nicht wirklich. Was ich aber weiß, ist, dass es in diesem Bereich noch viel Wachstum geben wird. Ich glaube, dass hyperkonvergente Lösungen zu den am schnellsten wachsenden Bereichen gehören werden. Wenn ich mir Gartner anschaue: Selbst deren eigene Analysen besagen, dass bis 2019 30 Prozent aller Speichersysteme entweder softwaredefiniert oder hyperkonvergent sein werden. Es gibt hier also viel Spielraum und Wachstumspotenzial. Ich finde es allerdings interessant, dass man, wenn man sich einige der Hyperkonvergenz-Unternehmen und die Art und Weise ansieht, wie sie darüber sprechen, annehmen könnte, dass bereits 90 Prozent des Marktes davon erfasst sind. Das ist aber nicht der Fall.

Sushant: Ja. Und ich denke, das ist sozusagen – na ja, wenn dich der ganze Hype irgendwie stört, dann ist das hier eine Realitätsprüfung, die zeigt, dass zwei Drittel der Leute Hyperkonvergenz noch gar nicht einsetzen. Und ich denke, das sollte man im Hinterkopf behalten, denn vielleicht hört man von Kollegen oder sogar von Vertriebsmitarbeitern, die an die Tür klopfen und behaupten, Hyperkonvergenz sei das Allheilmittel für alle Probleme im Rechenzentrum. Und ich denke, was sie einem eigentlich sagen sollten, ist: Vielleicht doch nicht.

Vielleicht sollte ich erst mal einen Schritt zurücktreten. Ich meine, man sollte es sich natürlich ansehen, wie George bereits erwähnt hat – der Schlüssel liegt ja in der Software, richtig? Aber zuerst muss man verstehen, was man eigentlich erreichen will. Wenn man Datenbanken betreiben will, wenn man hohe Leistung benötigt und über eine Fibre-Channel-Infrastruktur verfügt – ist Hyperkonvergenz dann der richtige Weg? Möglicherweise. Aber man muss wirklich die richtige Lösung dafür finden.

Kommen wir also weiter. Wir haben die Frage gestellt: Was sind die wichtigsten Gründe, warum Unternehmen hyperkonvergente Lösungen einsetzen oder evaluieren? 48 Prozent nannten die vereinfachte Verwaltung, 39 Prozent die einfache Skalierbarkeit und etwas mehr als ein Drittel die Senkung der Hardwarekosten. George, das ähnelt doch ein wenig dem, was wir zuvor bei den geschäftlichen Treiber für Software-Defined-Storage gesehen haben, oder?

George: Ja, ich meine, ich denke, was diese Geräte angeht, vereinfachen sie zweifellos die Verwaltung. Wenn man weniger Optionen und weniger Funktionen hat, kann man daraus eine Appliance machen, man kann sie schlüsselfertiger gestalten. Und gerade in Unternehmen, in denen das IT-Personal weniger versiert ist und man einfach möchte, dass zum Beispiel die Büroangestellten etwas bedienen können, macht das sehr viel Sinn. Das umfasst auch die einfache Skalierbarkeit – da bin ich mir noch nicht ganz sicher – ich sehe die Zahlen und stimme zu, dass das das Marketing-Argument ist.

Ich sage Ihnen: Nachdem ich mich mit Hunderten von Kunden unterhalten und mir angesehen habe, was sie einsetzen, ist es interessant zu beobachten, dass bei vielen dieser Systeme – wenn sie mit einer hyperkonvergenten deployment beginnen – oft mit etwa vier Knoten gestartet wird, um über genügend Leistung zu verfügen und Hochverfügbarkeit zu gewährleisten.

Sushant: Ja.

George: Und wenn ich ein Jahr später nachschaue, wie es diesen Kunden geht, stelle ich fest, dass sie ein Dutzend Knoten dazugewonnen haben.

Sushant: Ja.

George: Ja, die horizontale Skalierung ist also einfach. Aber die Kehrseite ist: Wenn diese Systeme von wenigen Knoten auf eine große Anzahl anwachsen, wird die Verwaltung plötzlich viel komplexer. Und das steht eigentlich im Widerspruch zu dem dritten Punkt, der dort gezeigt wird. Was ich tatsächlich von vielen Kunden gehört habe, ist, dass sie sagen: „Nachdem ich das eingeführt habe, sind meine Kosten eigentlich gar nicht mehr so wettbewerbsfähig, denn ich hätte dasselbe auch mit, na ja, mehr Standard-Hardware und einem softwaredefinierten Speichersystem erreichen können.“

Ich denke also, es ist eine Art Kompromiss. Die geringeren Betriebskosten sind wohl das, was die Leute gerne glauben möchten, und ich denke, bei einigen der ersten Implementierungen trifft das wahrscheinlich auch zu. Was die langfristige Entwicklung angeht, bin ich mir da allerdings nicht so sicher.

Sushant: Ja. Wir haben unter anderem festgestellt: Wenn man zwei Anbieter nimmt, von denen einer mit einem Gerät ähnlicher Größe eine bessere Leistung erzielt als der andere, dann hat man im Laufe der Zeit weniger Geräte von dem Anbieter, der mit einem einzigen Gerät mehr Effizienz und Leistung bietet, oder? Im Gegensatz zu einem Anbieter, der weniger effizient ist.

Ich glaube, eines der Dinge, die manchmal durch das ganze „Oh, es lässt sich leicht horizontal skalieren“ verschleiert werden, ist die Tatsache, dass die einzelnen Server – unabhängig von ihren Kapazitäten in Bezug auf RAM und CPU – ineffizient sind. Und man umgeht das Problem, indem man sagt: „Oh, fügen wir einfach immer mehr Server hinzu.“ Oh, man sitzt fest mit, sagen wir, vier Servern. Hier, fügen wir noch vier hinzu, und das löst dann deine Leistungsprobleme, oder? Anstatt zu sagen: „Okay, gut, hier stehe ich gerade. Hier muss ich in einem Jahr sein. Kann ich nicht mit zwei anfangen und dann auf vier aufstocken?“ Es ist viel besser, die Server so zu skalieren, dass sie die Last bewältigen können, als einfach immer weiter Server hinzuzufügen.

Kommen wir also zur nächsten Frage. Richtig. Welche Anwendungsfälle gibt es im Zusammenhang mit Hyperkonvergenz? Bei Remote-Standorten/ROBO lagen die Werte bei etwa 15 Prozent; bei VDI bei 27; bei Unternehmensanwendungen bei 28; bei der Konsolidierung von Rechenzentren bei 28; bei Datenbanken bei etwas mehr als einem Drittel. Aber bedenken Sie bitte, dass die meisten Befragten – fast 40 Prozent – derzeit keine entsprechenden Lösungen einsetzen.

George, was fandest du daran interessant?

George: Nun, das einzige Gegenargument, das mir aufgefallen ist, betraf die Datenbanken. Denn es ist ziemlich offensichtlich, dass ich in der Praxis am häufigsten höre: „Ich zögere immer noch, meine Datenbank auf eine hyperkonvergente Lösung zu verlagern, weil ich nicht glaube, dass diese derzeit über die erforderliche Leistung und die nötigen Funktionen verfügt.“ Andererseits muss man sich wirklich genauer ansehen, wie diese Datenbanken beschaffen sind. Und was ich aus Gesprächen mit einigen der Umfrageteilnehmer und anderen erfahren habe, ist, dass es selbst dort sozusagen zwei Kategorien von Datenbanken gibt.

Da gibt es zum einen Datenbanken, die viel stärker transaktionsorientiert sind. Und die gewissermaßen die Lebensader Ihres Unternehmens darstellen, Ihr ERP-System und so weiter. Und dann gibt es Datenbanken, die im Grunde genommen nur der Speicherung von Daten dienen –

Sushant: So etwas wie dein Batch-Job.

George: Batch-Jobs und so weiter. Ich glaube also, was hier passiert, ist: Wo sie die Datenbanken umstellen können, versuchen sie es auch. Aber ich denke, das wäre der Punkt, der mir besonders aufgefallen ist. Wenn ich mit den meisten Anwendern spreche, geht es immer noch hauptsächlich um ROBO, VDI und weniger geschäftskritische Anwendungen. Oder zumindest herrscht die Überzeugung, dass es derzeit noch nicht wirklich möglich ist, auf einer hyperkonvergenten Infrastruktur große Mengen an E/A oder Transaktionen zu verarbeiten.

Sushant: Ja, was ich noch sagen möchte, ist: Da ich versucht habe, mir das anzuschauen, und angesichts dessen, was wir über hyperkonvergente Lösungen wissen – nämlich, dass es sich dabei nicht wirklich um eine Hochleistungsplattform handelt –, ist mir genau wie dir aufgefallen: Warum eigentlich Datenbanken? Und als ich mich umhörte und mit Leuten sprach, wurde mir klar: Wenn jemand einen Datenbankcluster aufbauen will, um das Problem der „Noisy Neighbors“ zu beseitigen – wie macht man das dann?

Nun, der einfachste Weg, einen Cluster einzurichten, ist eine hyperkonvergente Lösung. Man besorgt sich vier Knoten und muss keinen separaten Speicher kaufen. Wenn man also, wie du gesagt hast, ein paar Datenbanken hat, die Batch-Jobs ausführen, und man einen Cluster nur zu deren Verwaltung einrichten möchte, kann eine hyperkonvergente Lösung für diesen Anwendungsfall durchaus geeignet sein, oder? Auch hier gilt: Es bietet zwar nur hohe Leistung, aber es ermöglicht es Ihnen, „laute Nachbarn“ loszuwerden, oder? Es ist sicherlich eine Infrastruktur, aber nur für eine bestimmte Anzahl von Datenbanken. Das war also sozusagen eine der Erkenntnisse, die ich gewonnen habe: „Oh, das macht Sinn.“ Auch hier gilt: Man muss den Anwendungsfall verstehen und sicherstellen, dass er zu der Lösung passt, nach der man sucht.

Im weiteren Verlauf haben wir auch die Frage gestellt – Sie wissen ja, falls jemand keine hyperkonvergente Lösung in Betracht zieht, denn offensichtlich setzten erhebliche Teile der Befragten keine hyperkonvergente Lösung ein –, warum das so ist. Der mit Abstand häufigste Grund war mangelnde Flexibilität mit 44 Prozent. Zu teuer: 24 Prozent; Herstellerabhängigkeit: 22 Prozent; keine Integration in die bestehende Infrastruktur: 19 Prozent; und der letzte Grund, der recht interessant war, war die Unmöglichkeit, Rechenleistung und Speicher unabhängig voneinander zu skalieren, mit 17 Prozent.

George, weißt du, es gibt da ein paar wirklich interessante, sozusagen Fallstricke für jeden, der sich mit Hyperkonvergenz beschäftigt, oder?

George: Ja, und ich denke, das hängt wieder damit zusammen, dass man anfangs glaubte, Hyperkonvergenz wäre ein Allheilmittel für alles. Und dann, nach der Bereitstellung, merkt man plötzlich Dinge wie: „Wenn ich mich für bestimmte Anbieter entscheide, bin ich so gut wie an diesen Anbieter gebunden.“ Die Kosten – wie ich schon sagte – klingen zwar gut, aber da man Speicher gleichzeitig mit der Rechenleistung kauft, erwirbt man ziemlich große Module. Wie gesagt: Statt vier Knoten hat man plötzlich 12 oder 20 Knoten. Und die Kosten steigen durch die Komplexität ziemlich stark an.

Die andere Sache ist, weißt du, ich glaube ehrlich gesagt, dass sich diese ganze Frage der Flexibilität hier wirklich deutlich zeigt, und zwar die Flexibilität, wie ich mit den vorhandenen Systemen und Investitionen, die ich bereits habe, arbeiten kann. Ich meine, es ist so: Wenn man diese Systeme neu einführt und es sich um eine neue, frische deployment handelt, kann ich das viel besser nachvollziehen. Aber wenn man bereits über bestehende Systeme verfügt, hat man es nun mit einem weiteren Verwaltungssilo zu tun, das versucht, dies als eine noch völlig von den Rest getrennte Umgebung zu behandeln.

Sushant: Ja. Also, wenn man sich die ersten Punkte ansieht – also Punkt eins, Punkt – na ja, es geht um mangelnde Flexibilität; Anbieterabhängigkeit, Punkt drei; und keine Integration in bestehende Systeme, das ist Punkt vier; und der letzte Punkt, mangelnde Skalierbarkeit – all diese Punkte hängen mit ähnlichen Aspekten zusammen, nämlich Flexibilität und Auswahlmöglichkeiten. Stimmt’s? Wenn sich Leute gegen eine hyperkonvergente Lösung entscheiden, spricht das wirklich für das, was wir vorhin gesagt haben: Eine integrierte Appliance macht in bestimmten Fällen Sinn, aber es gibt auch Nachteile, oder?

Der Nachteil ist die mangelnde Flexibilität – man ist möglicherweise an diesen Anbieter gebunden, oder? Man kann die Lösung nicht in die bestehende Infrastruktur integrieren. Rechner und Speicher lassen sich nicht unabhängig voneinander skalieren, was auf Dauer sehr teuer wird. Stimmt’s? Ich denke also, wenn man sich mit Hyperkonvergenz beschäftigt, muss man sich wirklich genau überlegen, was da eigentlich passiert. Und noch etwas: Dieser letzte Punkt, die fehlende Skalierbarkeit von Rechenleistung und Speicher – wenn ich auf Messen mit Leuten spreche, die schon seit ein oder zwei Jahren mit Hyperkonvergenz arbeiten, dann nervt sie genau das am meisten.

Denn einer der Aspekte, an den sie anfangs vielleicht nicht gedacht haben, der aber mit der Zeit sehr deutlich wird, ist: Wenn man auf Hyperkonvergenz umsteigt – insbesondere bei diesen integrierten Appliances –, vermischt man im Grunde die Wachstumsraten von Daten und Rechenleistung. Und wissen Sie was? Bei den meisten Menschen wachsen die Datenmengen viel schneller als der Rechenbedarf. Und so kommt es letztendlich dazu, dass man, um die Rechenleistung in einer hyperkonvergenten Umgebung zu skalieren, am Ende einfach mehr Geräte kauft.

Also, wie du vorhin schon gesagt hast, George: Man fängt vielleicht mit vier an, aber ein Jahr später sind es schon acht oder zwölf, und dann denkt man sich: „Oh mein Gott“, oder? Ist das nun mein Leben geworden?

George: Ja.

Sushant: Okay, kommen wir also zum nächsten Punkt in der nächsten Kategorie, nämlich cloud . Hier haben wir die allgemeine Frage gestellt, was die größten Enttäuschungen im Bereich Speicher sind. 31 Prozent gaben an, dass cloud die Kosten nicht senken konnte; 29 Prozent nannten die schwierige Verwaltung von Objektspeicher; und 16 Prozent sagten, dass flash die Geschwindigkeit flash steigern flash . Das ist also ein guter Übergang, um über cloud zu sprechen. Und es ist schon interessant, dass zwar alle davon sprechen cloud Kosten senken, aber eine beträchtliche Anzahl von Befragten sagt: Nein, meine Speicherkosten haben sich dadurch nicht wirklich verringert.

George: Ja, das überrascht mich nicht. Ich meine, wenn man die cloud schon einmal genutzt hat – allein was die reine Kapazität angeht, sind die Kosten in der Regel sehr gering –, aber weißt du, es ist so eine Sache: Wenn man den Speicher erst einmal dort abgelegt hat, ist es sehr schwer, ihn wieder herauszuholen. Und die Herausforderung besteht darin, zu entscheiden, was man hochskalieren und was man herunterskalieren kann. Das Problem ist die Wartung in der cloud, besonders wenn man versucht, mit virtuellen Maschinen und all dem zu arbeiten.

Plötzlich bekommt man diese Rechnungen zurück, und das wird dann doch ziemlich teuer. Und das Interessante daran ist: Die Leute führen keine genauen Kostenrechnungen durch, um wirklich zu prüfen, wie hoch die Kosten für die cloud einer Eigenlösung sind. Und viele von ihnen berücksichtigen nicht, wie beispielsweise Software-Defined-Storage eine effektivere Auslastung des vorhandenen Speichers ermöglichen könnte. So muss man für die cloud nicht so viel bezahlen.

Wissen Sie, ich möchte auf keinen Fall den Eindruck erwecken, ich stünde diesem Trend, der cloud, ablehnend gegenüber, denn es ist offensichtlich: Das ist ein Megatrend, der unsere Branche erfasst. Die Leute wollen immer mehr in die cloud verlagern. Die Kunst besteht darin, selektiv vorzugehen. Hier kommen meiner Meinung nach Dinge wie das automatische Tiering ins Spiel, bei dem wir wirklich genau prüfen können: Wie sieht die Performance aus? Was soll gesichert werden? Was soll archiviert werden? Denn es ist ganz offensichtlich, dass genau diese Anwendungsfälle in Zukunft eine große Rolle spielen werden.

Sushant: Ja. Und ich finde, was du gesagt hast – du hast den Nagel auf den Kopf getroffen –, macht Sinn, oder? Es geht doch immer um den Anwendungsfall, oder? Wie bei fast jeder Technologie ist sie kein Allheilmittel, es gibt keine Wunderwaffe – entscheidend ist definitiv der Anwendungsfall.

George: Bevor wir zum nächsten Thema übergehen, möchte ich noch kurz anmerken, dass der Objektspeicher interessant ist, denn auch wir als Unternehmen haben in OpenStack investiert und viel Arbeit darin gesteckt. Was ich damit sagen will: Der Objektspeicher schien vor etwa drei Jahren ein großes Thema zu sein. Es sieht so aus, als würden die Leute immer noch ihre Dateisysteme nutzen, und ich glaube, vieles von dem, was damals als „Objekt“ bezeichnet wurde, ist heute Objekt-Speicher in der cloud.

Ich bin mir also nicht sicher – in diesem Fall ist die Enttäuschung wohl, dass die Leute heutzutage, wenn man über „Objekt“ spricht, sagen: „Na ja, wenn es für Objekte geeignet ist, warum lege ich das dann nicht einfach in die cloud?“, und sie nutzen es fast wie ein Archiv. Was flash angeht, haben wir das ja schon mehr oder weniger besprochen. Auch hier denke ich, dass es kein Allheilmittel ist. Es ist natürlich sehr gut, wenn man viele leseintensive Anwendungen hat. Wenn es schreibintensiv und transaktionsorientiert ist, flash das Allheilmittel.

Sushant: Klar, auf jeden Fall. Lassen Sie uns also noch ein bisschen mehr über cloud sprechen. Wir haben nach den wichtigsten Anwendungsfällen für cloud Public cloud gefragt. Auf Platz 33 lag „DR in der Cloud; gleichauf lag „Backup in cloud, Wiederherstellung vor Ort“; und dann lag die Langzeitarchivierung bei 35 Prozent. Zur Erinnerung: Der Anteil derjenigen, die diese Lösungen derzeit nicht einsetzen oder nutzen, lag bei etwa 40 Prozent. Ich meine, George, das trifft es wirklich ziemlich genau – es geht darum, seine Daten speichern zu können, fast wie bei einem Notfallplan, den man nur im äußersten Notfall in Anspruch nimmt.

George: Ja, ich meine, ich denke, das gilt generell. Wenn sie es für Backups und Archivierung nutzen können, ist das der wichtigste Anwendungsfall hier. Weißt du, ich habe sowohl mit Leuten bei Amazon als auch bei Azure gesprochen, und sie sagen alle dasselbe. Das ist der wichtigste Anwendungsfall. Wenn man sich dann natürlich mit Produktionsumgebungen, transaktionsorientierten und Echtzeit-Anwendungen beschäftigt, wird es schwierig, weil man sich wirklich mit all den Interaktionen auseinandersetzen muss, um in die cloud zu gelangen.

Deshalb cloud die Public cloud eben nicht das Allheilmittel. Es wird auch weiterhin eine Mischung sein, bei der Private Clouds und Public Clouds zusammenarbeiten. Und ich denke, Hybrid ist wirklich so etwas wie die langfristige Lösung.

Sushant: Ja, auf jeden Fall. Ich habe mit Kunden gesprochen, die zwar über einen zweiten Standort verfügen, diesen aber nicht unbedingt mit Personal besetzt haben – oder sogar Schwierigkeiten haben, überhaupt einen geeigneten zweiten Standort einzurichten. Einfach für den Fall, dass – sozusagen – ein Notfallstandort benötigt wird. Das Produkt ist also durchaus sinnvoll als Ort, an dem man seine Daten aufbewahrt, für den Fall, dass etwas passiert und man darauf zugreifen muss.

Wir haben auch nach den Gründen gefragt – wenn man sich diese 40 Prozent ansieht, die keinen öffentlichen Cloud einsetzten oder nutzten. Das war so bedeutend, dass wir einfach alles aufgelistet haben. Bei der Sicherheit lagen die Werte bei etwa 57 Prozent; bei sensiblen Daten bei 56 Prozent; bei regulatorischen Anforderungen bei 41 Prozent; bei der Kontrolle bei 33 Prozent; bei der Leistung bei 32 Prozent und bei den Kosten ebenfalls bei 32 Prozent. George, das spricht wirklich einige der Themen an, über die wir zuvor gesprochen haben. Richtig? Es geht darum, was der richtige Anwendungsfall ist.

George: Ja, und ehrlich gesagt finde ich das in diesem Zusammenhang interessant, denn ich glaube, die Sicherheit wird immer besser, die Möglichkeit, die Daten in verschiedenen Regionen zu speichern, bietet viel mehr Kontrolle – in Europa war zum Beispiel eines der großen Probleme, dass man sicherstellen musste, dass die Daten innerhalb des eigenen Landes bleiben.

Sushant: Ja, meine Grenze.

George: Aber weißt du, sowohl Azure als auch AWS bieten solche Funktionen an. Ich glaube, das ist ein Bereich, in dem wir in Zukunft viele Veränderungen erleben werden. Und ich denke, es wird immer besser werden. Die Grundlagen sind meiner Meinung nach nach wie vor Kosten, Leistung und Kontrolle. Weißt du, das Thema Kontrolle ist interessant. Es geht dabei auch um Angst. Weißt du, die Leute wollen die Kontrolle nicht verlieren. Sie verlagern ihre Systeme in die cloud etwas passiert.

Und wisst ihr, die Welt des Wechsels von einer cloud anderen und die Möglichkeit, schnell hin und her zwischen der cloud der cloud zu wechseln cloud nach wie vor ein großes Thema. Es ist ein bisschen so wie früher bei den Backups: Alle sagen, das Sichern sei einfach; das Problem sei die Wiederherstellung. Nun, ich glaube, die cloudunter dem gleichen Problem. Es ist einfach, Daten dort hineinzulegen. Aber wie im „Roach Motel“: Ist es erst einmal drin, kommt es nie wieder heraus. Also –

Sushant: Nun, ich denke, was die Kontrolle angeht, von der du gesprochen hast: Es gab doch vor einiger Zeit diesen Vorfall, bei dem AWS wegen eines Netzwerkproblems auf ihrer Seite ausgefallen ist. Stimmt’s? Wenn so etwas also innerhalb eines Unternehmens passiert, kann man sagen, man hat ein Team, bei dem man nachfragen kann: „Wie lange dauert es noch?“, „Was ist das Problem?“ und „Wann wird das behoben?“, richtig? Aber wenn es Amazon ist, ist man ihnen ausgeliefert, oder? Man geht davon aus, dass sie alles tun, was sie können, aber es fehlt einfach an Kontrolle, was die Fehlerbehebung angeht und daran, Updates darüber zu erhalten, wann das Problem behoben sein wird. Stimmt’s?

Ich denke, das wird zu einem Teil des Problems in Bezug auf die Kontrolle, insbesondere wenn man eine kritische Anwendung hat, die niemals ausfallen darf. Richtig? Dadurch ist man gewissermaßen eingeschränkt. Also, lassen Sie uns – wir haben noch ein paar, noch ein paar Folien, bevor wir zum Schluss kommen. Wir haben also über die wichtigsten Anwendungsfälle für öffentlichen und hybriden Cloud gesprochen. Also VDI, Datenbanken, Analytik, ERP. Und noch einmal: Richtig, keine. Stimmt’s? Noch einmal, George, ich denke, das spricht dafür, was der richtige Anwendungsfall ist.

George: Ja. Ich glaube, das haben wir jetzt ziemlich gut abgedeckt. Und noch einmal: Die Leute wollen tatsächlich mehr in ihre – ein Teil der Frage hier liegt darin, dass von Public- und cloud die Rede ist. Als wir uns damit näher befasst haben, war es interessant zu sehen, dass die meisten Datenbank- und eher anspruchsvollen Unternehmensanwendungen im Sinne einer cloud betrachtet werden, bei der man das, was man lokal erledigen kann, auch lokal erledigt, aber die cloud, also die cloud Backups und Archivierung nutzt.

Sushant: Klar. Als Nächstes haben wir ein wenig über die Ausgaben für Speicher gesprochen, und hier haben wir gefragt – die erste Frage lautete ja: Wofür geben die Leute ihr Speicherbudget aus? Wie man sieht, stehen Software-Defined-Storage und flash an erster Stelle, jeweils mit über 70 Prozent; etwas weiter unten liegen Private cloud, Hyperkonvergenz, Objektspeicher und konvergente Lösungen. Etwas weniger – also deutlich weniger – entfällt auf OpenStack; cloud Public cloud etwa im Mittelfeld.

Ich glaube, George, das, worüber wir vorhin gesprochen haben, spricht doch irgendwie dafür, oder?

George: Nein, da stimme ich zu. Ich finde es interessant zu sehen, wie stark Software-Defined- und Hyperkonvergenz-Lösungen derzeit an Bedeutung gewinnen. Und da wir als Unternehmen schon so lange an der Spitze der Software-Defined-Entwicklung stehen, freue ich mich natürlich immer besonders, wenn dieser Bereich ganz oben steht.

Sushant: Auf jeden Fall.

George: Aber weißt du, flash weiterhin stark bleiben. Und ich glaube, Dinge wie OpenStack und so weiter sind noch auf der Suche nach ihrem Platz.

Sushant: Genau, richtig. Ich denke, das bedeutet im Grunde genommen einfach, dass es einige Möglichkeiten gibt, wie man mithilfe von Software-Defined-Storage und flash seine Speicherinfrastruktur sozusagen modernisieren kann. Wir werden nicht allzu sehr darauf eingehen, aber es dient als Referenz für Sie. Dort wird etwas detaillierter auf die „Ja“-Spalte eingegangen, in der es darum geht, wo die Leute ihre Ausgaben tätigen – also 10 Prozent oder weniger, oder ob sie 15 bis 25 Prozent oder 25 Prozent und mehr dafür bereitstellen, richtig?

Das passt also wieder einigermaßen zu dem allgemeinen Trend, den Sie bei den Ausgaben beobachtet haben. Aber es gibt Ihnen einfach noch ein bisschen mehr Ausblick auf die Zukunft. In diesem Sinne: Lassen Sie uns zum Abschluss noch ein wenig darüber sprechen – ich sehe ja noch ein paar Fragen. Ich denke, wir haben noch Zeit für ein oder zwei davon. Es gibt also eine Frage, ob Sie die Details der Umfrage mitteilen können: Wie viele Antworten gab es, Endnutzer im Vergleich zu Anbietern, und wie groß waren die Unternehmen, die geantwortet haben?

Viele dieser Informationen sind also im Bericht enthalten. Wir wollten Ihre Zeit nicht damit beanspruchen, das alles durchzugehen. Wie Sie sehen, ist der Bericht verfügbar – es ist ein kostenloser Bericht, nicht wahr? Er soll den Lesern vor allem einen Einblick darin geben, was ihre Kollegen in anderen Unternehmen tun.

Also, klicken Sie einfach auf diesen Link, dann können Sie sich eine Kopie des Berichts herunterladen. Eines sollten Sie dabei beachten: Es handelt sich hier ausschließlich um Endnutzer oder Endkunden. Anbieter oder VARs sind hier nicht vertreten. Es sind echte Menschen, die diese Produkte nutzen und Kaufentscheidungen darüber treffen müssen.

George: Insgesamt haben 426 IT-Fachkräfte an dieser Umfrage teilgenommen. Sie kamen aus ganz Europa und Amerika und waren in kleinen, mittleren und großen Unternehmen tätig. Es war also eine ziemlich umfangreiche Umfrage – und natürlich hat nicht jeder jede Frage beantwortet. Aber ich denke, wenn Sie sich den Bericht durchlesen, werden Sie die Einzelheiten sehen.

Sushant: Ja. Wenn Sie Interesse haben und Ihre Anforderungen an die Speicherinfrastruktur oder etwaige Probleme mit dem DataCore-Lösungsarchitekten besprechen möchten, klicken Sie einfach auf diesen Link. Bei live demo können live demo dann in Ruhe darüber sprechen, was Sie genau erreichen möchten. Wie George und ich bereits besprochen haben, liegt der Schlüssel meiner Meinung nach im Anwendungsfall, oder? Was möchten Sie eigentlich erreichen? Und wie Sie wissen, bietet DataCore Software-Defined Storage an. Wir haben hyperkonvergente Lösungen im Angebot. Es hängt also wirklich davon ab, was Ihr Bedarf ist und was Sie erreichen möchten.

Und falls Sie es ausprobieren möchten: Wir bieten sowohl Software-Defined-Storage als auch hyperconverged virtual SAN an. Damit möchte ich nun Danielle wieder das Wort übergeben, hyperconverged virtual SAN sie die abschließenden Punkte klären kann. Ich möchte mich bei Ihnen für Ihre Zeit bedanken.

George: Ja, danke.

Sushant: Danielle?

Danielle: Ja. Vielen Dank, Sushant und George. Zum Schluss noch eine Bitte an alle: Wir sind stets auf der Suche nach Verbesserungsmöglichkeiten, also vergesst bitte nicht, dieses Webinar zu bewerten, bevor ihr euch verabschiedet. Und zögert nicht, euch – wie Sushant bereits gesagt hat – bei uns zu melden, um eine 20-minütige live demo einem unserer Lösungsarchitekten zu vereinbaren. Denn wir freuen uns immer darauf, mit euch in Kontakt zu treten. Und damit kommen wir nun zum Abschluss. Ich wünsche euch allen einen schönen Tag und danke euch für eure Teilnahme.