Tipps zur Auswahl des passenden Hypervisors für den Cloud-Stack

Beim Hosting von Applikationen in der Cloud spielt der Hypervisor eine zentrale Rolle. Je nach Anwendungsfall empfiehlt sich ein anderer Typ.

Cloud-Computing basiert auf einer Vielzahl unterschiedlicher Softwarekomponenten. Da deren Integration oft kostenintensiv, riskant und zeitaufwändig ist, entscheiden sich IT-Architekten häufig für fertig integrierte Pakete. Ein besonders kritisches Element eines Cloud-Stacks ist der Hypervisor, hier kann die Stack-Option integrierter Systeme für die Hypervisor-Unterstützung aber mitunter sehr suboptimal sein.

Um integrierte Systeme hinsichtlich des Hypervisors einer kritischen Prüfung zu unterziehen, müssen zunächst die drei Hypervisor-Beziehungsdimensionen verstanden werden, um anschließend die Softwareoptionen in der Cloud gegenüber den Anwendungsanforderungen zu überprüfen und schließlich die an die Hardware gebundenen Funktionen zu verifizieren.

Sowohl beim Cloud-Computing als auch bei der Virtualisierung trennt der Hypervisor einen physischen Server in virtuelle Bestandteile auf, die unabhängig voneinander Anwendungen zugeordnet werden können. Hypervisoren treten mit drei unterschiedlichen Bereichen in Beziehung: mit der zugrundeliegenden Hardware, dem Host-Betriebssystem und dem Gast-Betriebssystem. Nicht alle Hypervisoren verhalten sich gegenüber diesen drei Bereichen identisch, und genau diese drei Dimensionen sind es, die man bei den eigenen Cloud-Anwendung verifizieren muss, um den optimalen Hypervisor auszuwählen.

Drei unterschiedliche Hypervisor-Typen

Die erste Frage, die sich bei Hypervisoren stellt, ist die nach den Beziehungen zwischen Hardware, Gast- und Host-Betriebssystem. Prinzipiell gibt es drei unterschiedliche Möglichkeiten: Den Typ-1-Hypervisor (Bare-Metal-Hypervisor), den Typ-2-Hypervisor (Hosted Hypervisor) und Container-Virtualisierung beispielsweise mit Docker.

Typ-1-Virtualisierung erzeugt ein Framework, in dem virtuelle Maschinen sehr stark von der Hardware isoliert sind, und in dem es kein Host-Betriebssystem gibt. Diese Isolation ist dann besonders sinnvoll, wenn eine Cloud-Anwendung mehrere unterschiedliche Gast-Betriebssysteme erfordert und die Anwendungen stringent nach Security, Compliance und Mandantenfähigkeit aufgeteilt werden.

Typ-2-Virtualisierungen dagegen verbindet Hypervisor-Funktionen direkt mit dem Host-Betriebssystem. Diese enge Beziehung ist hilfreich, wenn Host- und Gast-Betriebssystem übereinstimmen, denn es können dann alle (oder fast alle) Anwendungen unter demselben Betriebssystem ablaufen. Typ-2-Hypervisoren bieten weniger Anwendungsisolation, so dass Anwendungen sich gegenseitig die Leistung streitig machen könnten. Dafür sind wiederum Ressourceneffizienz und Betrieb viel einfacher handzuhaben. Hier gilt es, die Performance sehr sorgsam zu überprüfen und daran zu denken, dass möglicherweise kein Zugriff auf sämtliche vorhandene Hardware und Beschleunigungsfunktionen möglich ist.

Die dritte Kategorie wird oft auch als Hypervisor-freier Hypervisor oder containerbasiertes Cloud-System bezeichnet. Container sind leichtgewichtige Anwendungs-Hosts, die sogar noch weniger voneinander isoliert sind als bei Typ-2-VMs. Sie bieten kaum Ressourcensteuerung zwischen Anwendungen und wenig Sicherheit gegen Crosstalk. Was sie aber anbieten ist eine außerordentlich simple Anwendungsentwicklung und effiziente Ressourcennutzung, bei der mitunter bis zu zehn Mal mehr Container als virtuelle Maschinen auf einem Server untergebracht werden können. Allerdings ist es schwierig, einen generischen Container so zu gestalten, dass er beliebige Anwendungen aufnimmt. Wer also viele unterschiedliche Anwendungen in einem großen und unterschiedlichen Ressourcen-Pool unterzubringen hat, der dürfte beim Container-Ansatz Probleme bekommen.

Anwendungen gegenüber Hypervisoren validieren

Im nächsten Schritt müssen die Anwendungen gegenüber dem gewählten Hypervisor validiert werden. Je diversifizierter Anwendungen sind – etwa mit mehreren Gast-Betriebssystemen oder verschiedenen Middleware-Versionen –, desto wahrscheinlicher ist es, dass unabhängig von der vorhandenen Cloud-Software ein Typ-1-Hypervisor am besten in die Umgebung passt. Dabei sollte man dem Verbleib bei einem Cloud-Anbieter kritisch gegenüberstehen, nur weil man nur einige wenige Anwendungen gefunden hat, die nicht optimal in das Setting passen: Auf dem weiteren Weg ins Cloud-Hosting als generelle IT-Strategie werden hier noch einige mehr auftauchen.

Lizenzierung und Support sind ebenso relevante Kriterien einer Entscheidung für oder gegen die Optimierung von Anwendungen auf einen Hypervisor. Für jeden Hypervisor muss ein Gast-Betriebssystem betrieben werden, und dessen Lizenzierung und Support-Optionen können durchgreifende Auswirkungen auf die Gesamtkosten haben. Einige Typ-2-Anbeiter zögern dabei, andere Gast-Betriebssysteme als ihre eigenen zu unterstützen, was Preisgestaltung und Support bedeutsam verkomplizieren kann. Man sollte also jederzeit wissen, welches Gast-Betriebssystem die eigenen Anwendungen benötigen und wie deren Lizenzen zu vergüten sind.

Die Hardwareauswahl für einen Hypervisor ist der komplizierteste Teil. Je mehr sich Virtualisierung und Cloud-Computing durchgesetzt haben, umso mehr haben Anbieter die Leistung ihrer VMs durch verschiedene Hardwareverbesserungen und Software-Tools optimiert. Diese Tools dienen oft dazu, die Netzwerk- und Geräteverbindung zu den Gast-Betriebssystemen zu verbessern. Die damit erzielten Unterschiede in der Leistung können bemerkenswert sein, daher sollte sichergestellt werden, dass der gewählte Hypervisor all die von den jeweiligen eingesetzten Applikationen benötigten Beschleunigungsmöglichkeiten bietet.

Oder den Hypervisor einfach behalten?

Pauschale Regeln sind immer gefährlich, aber sie geben Anhaltspunkte dafür, ob man den Hypervisor einer Cloud-Plattform eher behalten oder lieber doch ersetzen sollte.

  • Wer Anwendungen für viele unterschiedliche Betriebssysteme einsetzt, der sollte Sie sich auf einen Typ-1-Hypervisor konzentrieren und das Cloud-Stack-Produkt ersetzen, falls dies von einem anderen Typ ist.
  • Wer dagegen die Cloud vorrangig zum Hosten multipler Instanzen einiger weniger Anwendungen nutzt, die alle auf identischen Betriebssystemen und Middleware aufsetzen und wenig Auslastung aufweisen, so ergibt ein Container-Ansatz meist mehr Sinn als eine klassische Hypervisor-Virtualisierung.
  • Basieren die Anwendungen vorrangig auf einer bleibenden Kombination aus Betriebssystem und Middleware, gibt es dabei aber auch einige Ausnahmen, so sollte man sich für einen Typ-2-Hypervisor entscheiden.

Dabei gilt natürlich auch immer zu bedenken, dass jeder Wechsel der Cloud-Software auch zusätzliche Integrations- und Support-Probleme mit sich bringen kann. Daher sollte man sich vorab vergewissern, dass die Vorteile eines Hypervisor-Wechsels dieses Risiko auch rechtfertigen.

Folgen Sie SearchDataCenter.de auch auf Twitter, Google+ und Facebook!

Erfahren Sie mehr über Containervirtualisierung

- GOOGLE-ANZEIGEN

ComputerWeekly.de

Close