Die hyperkonvergente Infrastruktur in komplexen Rechenzentren wird durch immer gezieltere Produkte vorangetrieben. Ein kritischer Aspekt ist die Unterstützung von Hypervisoren.
Hypervisoren, die für hyperkonvergente Infrastrukturen (HCI, hyper converged infrastructures) verwendet werden, gibt es viele. Frühe Auslegungen der heute gängigen hyperkonvergenten Systeme konzentrierten sich auf die Ausweitung der Funktionalitäten in den Lösungen von Unternehmen wie VMWare und später Microsoft.
Frühe hyperkonvergente Lösungen für VMware vSphere oder Microsoft Hyper-V mögen wie moderne Vorlagen für Hypervisoren in hyperkonvergenten Produkten aussehen. Mit ihnen sollen die Speicherlandschaften vereinfacht und so die Speicherkosten gesenkt werden. Das war es aber auch schon. Im Laufe der Zeit suchten einige HCI-Anbieter nach Alternativen bei der Open-Source-Gemeinde und dort bei Kernel-basierten KVM-Hypervisoren (Virtual Machine). Nutanix, einer der HCI-Vorreiter, ist mit einem eigenen KVM-basierten Hypervisor im Markt, aber es gibt auch andere.
Der Aufstieg von vSphere
Die Unterstützung von vSphere war für frühe HCI-Anbieter sehr sinnvoll. VMware war und ist der Hypervisor-Marktführer, auch wenn die Dominanz des Produkts mit dem Erfolg von Microsofts Hyper-V und KVM abnimmt. Unternehmen, die nach kostengünstigeren Alternativen bei der Virtualisierung suchen, wenden sich an die Public Cloud. Dann vor allem mit dem Ziel, zum Beispiel E-Mails vom eigenen Standort auszulagern oder eine CRM-Plattform (Customer Relationship Management) bereitzustellen. Aufgrund dieser Änderungen sinkt der Bedarf an lokalen Diensten, die vSphere enthalten. VMware arbeitet natürlich hart daran, dem Rückgang von vSphere durch die ständige Erweiterung um neue Services und neue Betriebsmethoden entgegenzuwirken, einschließlich der Möglichkeit, direkt in Amazon-Rechenzentren zu arbeiten.
Ein Grund für die Dominanz von vSphere war das breite Ökosystem, das in den letzten anderthalb Jahrzehnten entstand. Heute gibt es Hunderte, wenn nicht Tausende von Unternehmen, die Produkte mit Unterstützung von vSphere anbieten.
KVM kommt auf den Markt
Warum sollte man angesichts des umfangreichen Ökosystems und der ausgereiften Funktionen von vSphere überhaupt auf KVM (Kernel-basierende Virtual Machine ) wechseln? Kosten könnten ein Argument sein, aber da es gibt noch eine Anzahl anderer guter Gründe.
KVM erlaubt es Unternehmen, die Lizenzkosten für Hypervisor zu senken. Aufgrund seines Enterprise-Lizenzmodells ist Hyper-V in der Regel nicht so teuer. Allerdings sind die Kosten für vSphere-Kunden im Laufe der Jahre stetig gestiegen. Das macht CIOs und anderen Entscheidungsträgern die Entscheidung schwer. VSphere ist mittlerweile der Kern vieler Rechenzentrumslandschaften. Die Ablösung ist teuer und technisch anspruchsvoll. Da jedoch der Preisunterschied zwischen vSphere und seinen Konkurrenten weiter steigt, ist die finanzielle Rechtfertigung für einen Wechsel einfacher geworden. Unternehmen wollen zu Recht die „VMware-Steuer“ vermeiden.
HCI-Anbieter haben entweder die Unterstützung für KVM eingeführt oder ihre Plattformen um den Open-Source-Hypervisor herum aufgebaut. Der Anfang der Hyperkonvergenz für KVM war einfach, da viele hyperkonvergente Produkte entwickelt wurden. Die meisten verwenden eine so genannte virtuelle Speicher-Appliance (VSA). Die VSA ist die laufende Virtuelle Maschine, die den Speicher lokal auf einem hyperkonvergenten Knoten verwaltet und den Traffic mit den VSAs koordiniert, die auf den anderen Knoten in einem Cluster laufen. Das VSA-Modell bietet Flexibilität und ermöglicht den Austausch von Hypervisoren, solange der HCI-Anbieter das Swapping unterstützt. Schon früh haben einige Anbieter die vSphere-Unterstützung um Hyper-V- oder KVM-Unterstützung erweitert.
Einige Unternehmen haben ihre gesamte hyperkonvergente Plattform um den KVM-Hypervisor herum aufgebaut und gehen also über weiter, als einfach zusätzlich KVM zu betreiben.
Einige Unternehmen haben ihre gesamte hyperkonvergente Plattform um den KVM-Hypervisor herum aufgebaut und gehen also über weiter, als einfach zusätzlich KVM zu betreiben. In diesen Fällen bildet KVM den Kern der Architektur, ohne dass vorgesehen ist, andere Hypervisor zu unterstützen. Während VSA-zentrierte Hypervisor-Unterstützung eben mit VSA operieren, nutzen HCI-Architekturen ohne Multi-Hypervisor-Support eine nicht diese Abstraktion des Storage-Managements. Das Betriebssystem auf dem lokalen Knoten bietet Zugriff auf den lokalen Speicher, und in einigen Fällen kann ein Kernel-Hypervisor-Modul dieses Ziel erreichen. Diese VSA-freien Architekturen vermitteln ein Gefühl der Einfachheit, und je nachdem, wie das Produkt aufgebaut ist, kann es auch Leistungsvorteile geben.
Darüber hinaus haben HCI-Anbieter, die sich für KVM als wichtigen Bestandteil ihrer Plattform entschieden haben – wie Cloudistics, Nutanix und Scale Computing – KVM modifiziert und erweitert, um die Erwartungen an Hypervisoren in modernen Unternehmen zu erfüllen. Zum Beispiel nutzt Scale Computing sein patentiertes Speichersystem, genannt Scribe (Scale Computing Reliable Independent Block Engine). Scribe ist technisch nicht zu KVM hinzugefügt und lässt sich in die KVM-Variante von Scale Computing integrieren, um vollständig integrierten Speicher mit erhöhter Leistung im Vergleich zu anderen HCI-Plattformen, die auf VSAs und anderen Speicherfunktionen basieren, bereitzustellen.
Die Speicherlandschaft ist natürlich nur ein Aspekt einer kompletten hyperkonvergenten Plattform. Cloudistics und Nutanix bringen mehr Netzwerkfähigkeiten in ihre Plattformen und erweitern sie um Funktionen, die Kunden neben dem KVM-Hypervisor nutzen können. Cloudistics verfügt zum Beispiel über ein SDN (Software-Defined Network) für die tiefergehende Steuerung der Anwendungen. Bei Nutanix gibt es Flow mit erweiterten netzwerk- und anwendungsseitigen Netzwerksicherheitsfunktionen. Flow ist eng in die auf KVM basierende AHV-Virtualisierung integriert. AHV ist der Hypervisor für Nutanix Acropolis, das Betriebssystem für den HCI des Unternehmens.
Gibt es Anlaufschwierigkeiten?
Bei der Verwendung von KVM oder einem der anderen hier genannten Beispiele von Hypervisoren müssen Kompromisse eingegangen werden. Das VMware-Ökosystem ist riesig, und VMware wird nicht so schnell verschwinden. Nutanix wurde 2016 in eine Aktiengesellschaft umgewandelt und scheint sich gut zu entwickeln. Andere Player im Markt für KVM-zentrierte, hyperkonvergente Systeme sind immer noch privat gehaltene Start-ups, wie zum Beispiel Cloudistics, Maxta und Scale Computing. Ganz gleich, wie stark eine Technologie auch erscheint, besteht immer das Risiko, dass der Anbieter bei dem Sie gekauft haben, es langfristig nicht schafft.
Mein Ratschlag ist daher: betrachten Sie einen kürzeren Zeithorizont. Wenn Sie alle drei bis fünf Jahre IT-Komponenten erneuern, wäre das die Zeitspanne, die Ihr Lieferant überleben muss. Schafft Ihr Lieferant das, können Sie in der nächsten Runde den Anbieter wechseln.
Wissen, Fähigkeiten und Ausbildung
Wer sich länger mit Virtualisierung beschäftigt, verfügt über IT-Mitarbeiter mit fundierten Kenntnissen in VMware- oder Microsoft-Technologien. Da kann KVM ein zu großer Spagat sein, wenn Sie auch den Sprung in eine hyperkonvergente Infrastruktur wagen.
Wichtig ist vor allem: Hyperkonvergente Infrastrukturen, die KVM als einzige Hypervisor-Option verwenden, haben auch einfach zu bedienende administrative Schnittstellen. Diese verbergen viel, wenn nicht sogar alles, von der gesamten Komplexität eines Umstiegs auf eine hyperkonvergente Infrastruktur.
Ich habe in meinem Labor einen Cluster mit drei Knoten Scale Computing, den ich für Tests und Setup-Projekte verwende. Die Hypervisor-Management-Oberfläche darf als unangenehm nackt bezeichnet werden. Das ist nicht negativ gemeint, denn obwohl ich den Begriff Nerd-Buttons nicht mag, muss gesagt werden, dass Scale Computing auch gar nicht viele davon hat. Alles lässt sich mit der Maus anklicken. Wer eine VM zu einem anderen Knoten verschieben möchten, klickt einfach auf „VM verschieben“ und wählt den Knoten aus. Die Einrichtung eines Zeitplans für das Senden von Snapshots an einen Remote-Cluster erfordert ebenfalls nur ein paar Klicks.
Andere KVM-zentrierte, hyperkonvergente Plattformen haben mehr Hypervisor-Funktionalitäten als Scale Computing (zum Beispiel Cloudistics und Nutanix AHV), aber sie sind mit höherer Komplexität verbunden. Das wird nicht jedem gefallen. Eingefleischte Virtualisierer möchten vielleicht detaillierte Konfigurationseinstellungen haben, die bei einigen Produkten nicht vorhanden sind. Wenn Sie nicht jeden Parameter optimieren können, wie können Sie dann das Beste aus Ihrem Cluster herausholen? Vergleichen Sie die hyperkonvergenten Produkte und vergleichen Sie nochmals, bevor Sie sich entscheiden, damit Sie die tatsächlich die gewünschte Konfigurierbarkeit des Hypervisors vorfinden.
Das vielleicht größte Problem bei den Produktfähigkeiten ist die Migration Hunderter oder Tausender von VMs von vSphere nach KVM. Dafür gibt es Tools wie Red Hat's virt-v2v oder Carbonite HC3 Move Powered für die KVMs von Scale Computing. Mit diesen Tools können Kunden vSphere VMs und Windows Server in das KVM-Format migrieren.
Wie sieht die Zukunft für KVM aus?
Warum sollte man den KVM-Weg einschlagen, wenn vSphere immer noch dominiert, Hyper-V seinen Aufstieg fortsetzt und Unternehmen auf die Cloud setzen, um mehr Workloads zu bearbeiten? Da sind zunächst die Kosten ein erheblicher Faktor. KVM ist kostengünstiger als VMware, und die HCI-Anbieter leisten gute Arbeit, indem sie alle erforderlichen Funktionen und Fähigkeiten für den Wechsel zu KVM anbieten.
Es gibt jedoch noch weitere Gründe für KVM. HCI-Anbieter suchen Möglichkeiten zur Differenzierung. Dazu müssen sie ihren Kunden komplette Plattformen anbieten. Damit die gewünschten Effekte entstehen, müssen die Lösungen die Steuerung über den gesamten Stack bieten. Bei Anbietern, die nur vSphere oder Hyper-V unterstützen, lässt sich der Hypervisor nur schwach anpassen. Die Kernel-Funktionen eines Hypervisors lassen sich da auch nicht ändern, um die Bedarfe der Anwender besser zu erfüllen. Als Open Source ist das bei KVM anders. Die Anbieter haben die Freiheit, die Entwicklungsziele ihrer HCI-Plattform durch entsprechende Anpassungen zu erreichen.
Ein Landkarte für KVM-hyperkonvergierte Umgebungen
Beliebte Beispiele für Hypervisor in hyperkonvergenten Umgebungen sind VMware vSphere und Microsoft Hyper-V. Viele Anbieter von Lösungen für hyperkonvergente Infrastrukturen haben sich außerdem mit den Open-Source-KVM-Hypervisoren angefreundet. Dazu gehören:
Cloudistics: Der Cloudistics Spark Hypervisor bietet KVM-Virtualisierung als Basis und bildet die Grundlage für die gesamte Cloudistics-Plattform.
Maxta: Das VSA-Modell von Maxta unterstützt mehrere Hypervisoren, hauptsächlich KVM, OpenStack und vSphere. Maxtas VSA-Modell macht es dem Unternehmen leichter, alternative Hypervisoren zu unterstützen.
Nutanix: Nutanix hat sich schnell eine führende Position in der Welt der Hyperkonvergenz erarbeitet. Seit seiner Gründung unterstützt Nutanix vSphere. Als wesentliches Unterscheidungsmerkmal entwickelte das Unternehmen den Hypervisor Akropolis, der heute einfach AHV genannt wird. Es handelt sich um eine stark angepasste Version von KVM mit zusätzlichen Funktionen, die es in die Unternehmenswelt bringen soll. So können Kunden beispielsweise mit AHV einen HCI-Cluster mit vSphere um reine AHV-Speicherknoten erweitern, so dass sie mehr Speicherplatz hinzufügen können, ohne für mehr vSphere-Lizenzen bezahlen zu müssen.
Scale Computing: Die Hyperkonvergenzplattform von Scale Computing basiert auf einer erweiterten Version von KVM. Es verwendet keine virtuelle Speicher-Appliance oder kein VSA-Virtualisierungsmodell in seiner Plattform, wie es beispielsweise Maxta tut. Mit nativer Unterstützung für KVM und nur KVM hat Scale ein System entwickelt, das die Abstraktion minimiert und umfassende Hypervisorservices für sein HCI-System bereitstellt.
Public Clouds bieten HCI-Anbietern noch mehr Gründe, sich für ein KVM-zentriertes Modell zu entscheiden. Google und Amazon unterstützen KVM-basierte Workloads. Die Cloud-Plattform von Google läuft auf einer stark modifizierten und stabilisierten KVM-Variante. Ende 2017 brachte Amazon den Nitro-KVM-basierten Hypervisor auf den Markt. Amazon plant, alle Instance-Typen auf Nitro um- und den Einsatz des Xen-Hypervisors einzustellen.
Es ist also einfacher geworden, hybride Clouds anzulegen. Hybride Clouds umfassen, die Public Cloud und On-Premises-Ressourcen, wobei die Workloads zwischen den Architekturen nicht dauernd umgewandelt werden müssen. Für Anwender von KVM-zentrierten, hyperkonvergenten Infrastruktursystemen wird es immer üblicher, Partnerschaften zwischen dem HCI-Anbieter und KVM-zentrierten Cloud-Anbietern zu finden. Diese Partnerschaften machen es Unternehmen leicht, Umgebungen zu erstellen, die sowohl lokale als auch Cloud-Umgebungen umfassen.
Ich glaube nicht, dass Open Source der einzige Weg ist, um für alles Unternehmen zu gehen. Im Falle von Hyperkonvergenz glaube ich jedoch, dass die Offenheit von KVM es unglaublich attraktiv für Anbieter macht, umfassende hyperkonvergente Plattformen aufzubauen. Es gibt Vorteile – Kosten, Auswahl und neue Möglichkeiten, wie Workloads, Anwendungen und Denkweisen im Rechenzentrum – auch für Kunden.
Es gibt natürlich Nachteile. Dazu gehören die Anpassung der Fähigkeiten der IT-Mitarbeiter, die Anpassung an ein weniger ausgereiftes Ökosystem und die Abkehr von anderen, oft etablierten, umfassenden Technologien wie vSphere. Anbieter von KVM-zentrischen, hyperkonvergenten Systemen arbeiten daran, die Nachteile zu minimieren. Im Laufe der Zeit erwarte ich, dass sie in den meisten Bereichen Parität mit etablierten Plattformen erreichen, die teurere Hypervisoren in ihrer hyperkonvergierten Produktlinie verwenden.
Folgen Sie SearchDataCenter.de auch auf Twitter, Google+, Xing und Facebook!
