Olivier Le Moal - Fotolia

Tipps zur Performance-Optimierung virtueller Maschinen auf hyperkonvergenter IT

Auch hyperkonvergente IT muss für die speziellen Anforderungen unterschiedlicher Workloads optimiert werden. Diese Tipps helfen beim Design.

Eines der grundlegenden Charakteristika hyperkonvergenter Infrastruktur sind die Bausteine, aus denen sie besteht. Diese identischen Bausteine werden dann zu Clustern kleiner Workloads zusammengefasst, die ausreichend Kapazität für die virtuellen Maschinen bieten.

Aber was passiert mit leistungshungrigeren Applikationen und großen virtuellen Maschinen? Wie entwirft man hyperkonvergente Architekturen für besonders anspruchsvolle Workloads? Der Schlüssel hierfür liegt in der genauen Kenntnis der jeweiligen Anforderung und einer speziell hierfür angepassten Infrastruktur.

Wenn man die Performance virtueller Maschinen betrachtet, dann meist mit Blick auf CPU, RAM, Festplatten und Netzwerk. Wenn man auf diesen vier Ebenen die Anforderungen der virtuellen Maschine adressiert, dann sollte daraus auch eine adäquate Performance resultieren. Bei regulären virtuellen Maschinen gibt es meist eine Ressource, die die Performance schnell begrenzt: Virtualisierungs-Hosts kommen schnell an die Grenzen der RAM-Kapazität, während alle anderen Ressourcen dann meist gerade einmal zu 20 Prozent ausgelastet sind.

Bei anspruchsvolleren virtuellen Maschinen ist dagegen ein etwas ausgefeilteres Balancing der vorhandenen Ressourcen notwendig. Einer Datenbank-VM mehr Arbeitsspeicher zuzuweisen kann zum Beispiel die Anforderungen an die Festplatte deutlich reduzieren, die sonst durch das Caching entstehen würden.

Dabei sollte man aber auch nicht vergessen, dass auch der hyperkonvergente Cluster selbst Ressourcen verbraucht. Je mehr Disk-Performance eine virtuelle Maschine benötigt, umso mehr CPU-Zeit wird auch die Storage-Software in Anspruch nehmen, um diese Performance zu liefern. Gleichzeitig wird auch der Netzwerk-Traffic des Storage-Clusters ansteigen.

Netzwerk-Performance hyperkonvergenter IT optimieren

Die Netzwerk-Performance lässt sich meist am einfachsten optimieren. Die meisten hyperkonvergenten Lösungen bieten die Möglichkeit, 1 GbE (Gigabit Ethernet) zu nutzen, bei vielen kann aber auch 10 GbE für den VM-Traffic genutzt werden. Probleme gibt es hier meist nur, wenn netzwerkintensive virtuelle Maschinen den gleichen 10 GbE-Port nutzen sollen wie der hyperkonvergente Storage-Cluster.

In diesem Fall funktioniert der Hypervisor so ähnlich wie vMotion. Wenn geschäftskritische virtuelle Maschinen hohe Ansprüche an die Netzwerkbandbreite und gleichzeitig an den Storage haben, dann sollte man sicherstellen, dass mehr als zwei GbE-Ports vorhanden sind. Der zusätzliche Anschluss sollte dann dafür genutzt werden, Storage- und VM-Traffic zu trennen und so eine ausreichende Performance der beiden sicherzustellen. Auf vSphere kann zum Beispiel ein verteilter Switch mit NIC-Teaming, Load Balancing und Network I/O Control verwendet werden.

Überlegungen zur Cluster-Größe hyperkonvergenter Architektur

Die meisten hyperkonvergenten Produkte sind auch an ein Maximum der Cluster- beziehungsweise Node-Größe gebunden. Entsprechende Lösungen eignen sich eher für Scale-out- als für Scale-up-Ansätze, wodurch vor allem große virtuelle Maschinen mitunter nicht darauf ausgeführt werden können.

Normalerweise ist jeder Knoten auf zwei CPU-Sockel und um die 40 CPU-Kerne mit etwa einem TB an RAM limitiert. Dabei sollte die größte virtuelle Maschine nicht mehr als 75 Prozent der installierten Ressourcen verbrauchen – einfach um ausreichend Kapazitäten für Hypervisor und Storage-Cluster zu lassen. Wenn die Applikation mit diesen Ressourcenbeschränkungen nicht zurechtkommt, dann ist ein hyperkonvergenter Ansatz einfach nicht das Richtige.

Allerdings haben Anbieter hyperkonvergenter Produkte meist unterschiedliche Hardwarekonfigurationen für unterschiedliche Anwendungsfälle im Programm. Als Alternative kommt aber auch ein Software-only-Ansatz in Frage, bei dem der physische Server dann selbst den Anforderungen entsprechend spezifisch angepasst wird.

Die meisten Applikationen beruhen dagegen meist auf Scale-up- statt auf Scale-out-Architekturen. Für Anwendungs-Teams ist es zum Beispiel wesentlich einfacher, einen Datenbankserver mit einer großen Ressourcenzuweisung zu verwalten, statt einen Datenbank-Cluster mit mehreren kleineren VMs – aber auch der letztere Ansatz ist natürlich möglich und eignet sich dann auch für hyperkonvergente Produkte.

Per Storage-Tiering zur höheren Performance

Für fast alle Unternehmen gehören Datenbankserver zu den geschäftskritischsten Komponenten der Applikations-Infrastruktur. Darauf ist die Anwendungs-Performance ausgelegt und meist können diese Komponenten nur schlecht in kleinere Teile zerlegt werden. Die Leistung traditioneller Datenbanken ist begrenzt durch die Disk-Performance, daher sollte man hierauf bei hyperkonvergenten Designs ein besonderes Augenmerk legen.

Die meisten hyperkonvergenten Produkte setzen auf Storage-Tiers (SSDs für oft genutzte Daten, HDDs für weniger oft genutzte). Die am häufigsten genutzten Daten, auch Working Set genannt, müssen dabei auf dem schnellsten Storage-Tier liegen, um die beste Storage-Performance zu realisieren. Wenn das Working Set nicht auf das schnellste SSD-Tier passt, dann wird sich das negativ auf die VM-Performance auswirken. In manchen Fällen führt das zur Entscheidung für All-Flash-Systeme, die für beide Storage-Tiers Flash-Speicher einsetzen. Damit leidet die Performance nicht mehr so stark, wenn das Working Set größer ist als das schnellste Storage-Tier.

Hyperkonvergente IT kann auch für anspruchsvolle Applikationen eine passende Plattform sein, wenn die Architektur nur vorher genau auf die Anforderungen abgestimmt wird. Trotzdem wird es immer einfacher sein, Applikationen aus kleinen virtuellen Maschinen auf hyperkonvergenter Infrastruktur zu hosten, als eine massive virtuelle Maschine.

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

Erfahren Sie mehr über Server- und Desktop-Virtualisierung

- GOOGLE-ANZEIGEN

ComputerWeekly.de

Close