cherezoff - stock.adobe.com
Größe von VMware-Hosts zur Steuerung der VM-Dichte begrenzen
Große VMware-Hosts sind nützlich, die VM-Dichte kann aber bei einem Systemausfall fatale Folgen haben. Man sollte daher für den Extremfall gerüstet sein.
Große VMware-Hosts erscheinen vielen Admins attraktiv. Allerdings kann die daraus resultierende Dichte an virtuellen Maschinen (VM) eine schnelle Wiederherstellung nach einem Ausfall verringern.
Es ist durchaus verlockend, VMWare-Hosts aus Hardwareperspektive zu betrachten und sich darauf zu konzentrieren, diese so groß wie möglich zu machen. In einer gemeinsamen Umgebung scheinen mehr Ressourcen immer besser zu sein, als das Risiko einzugehen, nicht genug Ressourcen zu haben.
Die Entwicklung in der IT tut das ihre dazu: Die Speicherkapazitäten in Hardwareplattformen sind gewachsen, und die schiere Anzahl der Kerne, die in eine CPU passen, lassen sich nur noch schwer zählen. Die Fähigkeit, Hosts zu skalieren, bedeutet oft, dass VMs schwindelerregende Größen erreichen müssen. Aber das passiert nicht oft.
Die Anwendungsentwicklung hat sich hin zu einem Scale-Out-Ansatz verlagert, so dass das massive Single-Server-Modell nicht mehr so beliebt ist wie früher. Dadurch stehen IT-Mitarbeitern leistungsstarke ESXi-Hosts zur Verfügung, die eine höhere VM-Dichte erlauben.
Steuerung der VM-Dichte
Eine erhöhte VM-Dichte ist nicht unbedingt schlecht. Diese kann dazu beitragen, die Lizenzkosten für Betriebssysteme, Netzwerkverbindungen und die Größe des Rechenzentrums zu reduzieren.
Der Schlüssel zur Steuerung der VM-Dichte liegt in der Bewertung ihrer Funktionalität bei einem Ausfall. VMware bietet High Availability (HA), Predictive HA und Fault Tolerance, um die Wiederherstellung nach Systemausfällen zu unterstützen. Diese Technologien verhindern, dass Workloads offline gehen und reduzieren die Notwendigkeit eines schnellen Neustarts nach einem Host-Ausfall. Diese Features funktionieren sowohl mit kleinen als auch großen Hosts, aber ihre Effektivität kann je nach Größe der VMware-Hosts und VM-Dichte variieren.
Die Host-Größe hängt oft von der CPU- oder Speicher-Auslastung ab. Die CPU hat in der Regel die oberste Priorität, da sich der Speicher leichter anpassen lässt als die CPU-Kerne. Abhängig von Ihrer Mathematik lassen sich zwei bis vier vCPUs pro Kern zuweisen.
Am unteren Ende – mit einer älteren CPU – kann dies eine Quad-Core-CPU sein, die für acht verwendbare Kerne hyper-threaded ist. Wenn man drei VM vCPUs pro Core zuweist, ergibt das etwa 24 vCPUs pro physischem CPU-Sockel. Wenn man einen Dual-CPU-Socket-Server einkalkuliert, der 48 vCPUs für VMs liefert, sind das durchschnittlich 24 VMs pro Host, wobei jede VM zwei vCPUs erhält.
Die VM-Konfiguration variiert zwar je nach Bedarf, aber dieses Beispiel ist allgemein anwendbar. Hyper-Threading erhöht die Dichte der physischen CPUs von 8 auf 48 Kerne.
Mit der gleichen Rechnung – drei vCPUs pro CPU-Kern auf einem Dual-CPU-Socket-Server – erweitert man 16 Kerne im Host auf 96. Das bedeutet, dass die Anzahl der unterstützten vCPUs von 48 auf 288 steigt. Das erhöht die mögliche VM-Dichte von 24 VMs auf 144 VMs pro Host.
Das klingt aufgrund der Reduzierung des Hardware-Footprints und möglicher Einsparungen beim Betriebssystem vielleicht großartig. Man sollte aber bedenken, was bei einem Ausfall passiert. 24 VMs zu verlieren ist schlecht. Aber was bedeutet es erst, 144 auf einmal zu verlieren? Fault Tolerance kann nur vier VMs pro Host schützen, was möglicherweise nicht ausreicht. Jede Erhöhung der Dichte erfordert eine Prüfung auf mögliche Ausfälle.
HA-Neustart-Geschwindigkeit bewerten
Mehr Hosts reduzieren die Dichte, was Technologien wie Fault Tolerance attraktiver macht, da weniger VMs pro Host verarbeitet werden müssen.
Beispielsweise erfordert die Unterstützung einer Anzahl von 400 VMs mit einem Verhältnis von 25 VMs zu 1 Host ein Minimum von rund 17 Hosts, um den Verlust von einem zu bewältigen. Ein Neustart von 25 VMs auf 16 Hosts bedeutet, dass man nicht mehr als zwei VMs pro Host für einen schnellen Neustart benötigt.
Wenn man die gleiche Rechnung anwendet – vier Hosts und 400 VMs – erhält man durchschnittlich 100 VMs pro Host. Ein Verlust bedeutet, dass die verbleibenden VMware-Hosts 33 weitere VMs neu starten müssen. Das Hinzufügen von zwei VMs zu 16 Hosts macht keinen spürbaren Unterschied aus, aber das Hinzufügen von 33 VMs zu 3 Hosts im Neustart-Modus ist ein erheblicher Sprung, der die Service-Level-Agreements (SLAs) deutlich beeinflussen kann.
Der Nachteil der Skalierung ist ein erhöhter Platzbedarf im Rechenzentrum, mehr Netzwerkverbindungen und natürlich mehr VMware-Lizenzen.
Es ist technisch möglich, die beste Dichte durch eine Kostenanalyse herauszufinden, aber es ist schwierig, einen Festpreis mit einem umfangreichen Ausfall zu verknüpfen. Das liegt an der Art der Virtualisierung und der Art und Weise, wie die Workload-Verlagerung die Fähigkeit verschleiert, genau vorherzusagen, was passieren wird.
Man kann Disaster-Recovery-Tests planen, aber die Disaster-Vorbereitung beginnt, sobald man sich zur Erweiterung der virtuellen Infrastruktur verpflichtet hat. Dies erfordert es, ein Gleichgewicht zu finden zwischen massiven VMware-Hosts und der Skalierung für potenzielle Ausfälle.
Folgen Sie SearchDataCenter.de auch auf Twitter, Google+, Xing und Facebook!
