CRN: Was sind Ihrer Erfahrung nach typische Herausforderungen in Hyper-Converged-Projekten?
Träger: Stilisiert der Kunde in blindem Vertrauen an die neue Technik diese zum alleinigen Heilsbringer, ist es in der Pre-Sales-Phase wichtig, Abgrenzungen und Möglichkeiten klar aufzuzeigen. So kann es passieren, dass neben dem HC-System ein separates NAS-Device als Ablage für unstrukturierte Daten nötig wird. Denn in den meisten Fällen entwickeln sich File-Systeme divergent, also Kapazitäts- und Perfomance-Wachstum steigen nicht gleichmäßig an. Mit dem Verzicht auf ein SAN-Netzwerk steigt die Anforderung an das meist nur 1Gb breite Ethernet. Eine Erneuerung des Netzwerks hat neben hohen Investitionskosten auch einen nicht unerheblichen Einfluss auf die initialen technischen Aufwände. Bisher ist bei keiner der HC-Lösungen eine native synchrone Replikation über zwei Brandabschnitte möglich. Das führt vor allem bei Kunden mit einem Aktiv-Aktiv-Betrieb zu Akzeptanzproblemen. Kann funktional eine Anforderung, wie die synchrone Replikation, nicht abgebildet werden, ist es weniger eine Option, diese über ein Drittanbieterprodukt zu verwirklichen, da damit die vereinfachte Administration ad absurdum geführt wird.
Schlussendlich muss auch für HC-Systeme die Umgebung, die Anforderung und die Entwicklung betrachtet werden und der Kunde muss bereit sein, eine veränderte Philosophie zu akzeptieren.
CRN: Wie entwickelt sich die Nachfrage nach hyperkonvergenten Lösungen bei MTI?
Träger: Wenn HC-Systeme bisher mit einem abgegrenzten Anforderungsprofil durch die Kunden abgefragt wurden, ist ein langsamer, aber stetiger Zuwachs von HC-Systemen in der Basis-IT-Infrastruktur zu verzeichnen. Treiber sind zum einen die Simplizität bei der Administration der Infrastruktur über ein Management Interface, wie zum Beispiel VMware vCenter sowie der Verzicht auf ein separates Fibre Channel SAN. Die Motivation liegt klar in der Simplifizierung der blechgewordenen IT-Infrastruktur mit der Fokussierung auf das virtuelle Datacenter. Die Möglichkeit der Skalierung ist bisher mehr Investitionssicherung als operative Anforderung.
CRN: Was entgegnen Sie Kunden, die fürchten, sich mit einem hyperkonvergenten System zu sehr an einen Hersteller zu binden?
Träger: Kunden, die HC-Systeme zur Erfüllung einer abgegrenzten Aufgabe einführen, stehen selten vor der Fragestellung eines Vendor-Locks. Entscheiden sich Kunden explizit für die Ablösung ihrer bisherigen IT-Infrastrukturen und für eine HC-Lösung, findet mit dieser Lösung keine massivere Vergrößerung der Herstellerbindung statt als mit der bisherigen Umgebung. Zumal die Praxis den Kunden zeigt, dass eine vermeintlich offene Infrastruktur beim Support mehr Probleme birgt als der befürchtete Vendor-Lock.
CRN: Inwieweit verliert man durch hyperkonvergente Systeme an Flexibilität, weil man immer nur eine Appliance beziehungsweise ein Komplettsystem ergänzen kann, auch wenn man nur mehr Storage oder mehr Computing-Kapazitäten benötigt?
Träger: Durch die Scale-out Architecture bieten HC-Systeme per se bereits eine ähnliche oder gleiche Flexibilität wie Legacy IT-Strukturen. Wie alle All-in-one-Geräte sucht auch die HC-Infrastruktur den Kompromiss zur Befriedigung aller in sich vereinten Teilmengen. Das gelingt einmal besser und einmal schlechter. Betrachtet man ausschließlich das Wachstum einer virtuellen Infrastruktur in Form von immer mehr virtuellen Maschinen, ist das Verhältnis zwischen steigender Performance-Anforderung und Kapazität meist ausgeglichen. Zu einem Schiefstand kommt es allerdings dann, wenn eine der virtuellen Maschinen ein Anwender-File-Server ist. Hier wächst die Kapazität überproportional zum Performancewachstum. Wie bei herkömmlichen Umgebungen auch ist hier Erweiterung der HC-Infrastruktur durch ein exklusives NAS-Device, das über NFS oder CIFS mit einer VM verbunden wird, möglich.