Cloud Director - Ressourcenzuweisung

Update 18.11.2024: Wir haben einige externe Links aktualisiert oder entfernt.

Mit VMware vCloud Director nutzen Sie ein virtuelles Datacenter, um IT-Ressourcen als katalogbasierten Service bereitzustellen. In unserem vCloud Datacenter stehen Ihnen je nach Anwendungsfall 3 unterschiedliche Typen zur Verfügung:

Production

Die Datacenterklasse "Production" zeichnet sich durch folgende Eigenschaften aus:

• garantierte Ressourcen für vCPUs (GHz) und RAM (Reservierungspool)
• Sie können die Zuweisung von Ressourcen an Ihre vApps / VMs selbst bestimmen.
• Datenspeicherklassen "High Performance" und "Standard Performance"
• Katalogdatenspeicher für vApps und ISO Images
• Mindestabnahme: 10GHz, 10GB RAM, 100GB Datenspeicher "Standard Performance"

Pay-As-You-Go

Die Datacenterklasse "Pay-As-You-Go" zeichnet sich durch folgende SLAs aus:

• Dynamische Zuweisung beim Erstellen von VMs per Pay-As-You-Go mit 100% garantiereten Ressourcen für vCPUs (GHz) und RAM
• Datenspeicherklasse "High Performance" und "Standard Performance"
• Katalogdatenspeicher für vApps und ISO Images

Dev & Test

Die Datacenterklasse "Dev & Test" zeichnet sich durch folgende SLAs aus:

• Zuweisungspool mit 50% garantiereten Ressourcen für vCPUs (GHz) und RAM
• Datenspeicherklasse "Dev & Test Standard Performance"
• Katalogdatenspeicher für vApps und ISO Images
• Mindestabnahme: 10GHz, 10GB RAM, 100GB Datenspeicher "Development Performance"

Zuweisung von Ressourcen

In einem virtuellen Datacenter werden alle Ressourcen fest zugewiesen, um eine vorhersagbare Performance der vApps zu gewährleisten. RAM und GHZ (vCPUs) können in Schritten von 10GHz bzw. 10 GByte RAM gebucht werden. Das "Pay-as-you-go" - Modell wird in unseren vCD-Instanzen derzeit nicht unterstützt. Datenspeicher aller Klassen kann in Schritten von 100 GByte gebucht werden.
Innerhalb des vCD kann der Administrator damit seinen VMs je nach Bedarf entsprechenden Ressourcen und Prioritäten (Shares) zuteilen.

Grundsätzlich gilt:

• Jede VM sollte eine CPU Reservierung haben, ggf. nur 100 MHz, bei wichtigen VMs die dauernd laufen auch mehr.
• Jede VM sollte eine RAM Reservierung haben. Bei wichtigen VMs mindestens 50% sonst mindestens 25%.
• Eine vCPU entspricht mindestens 2 GHz, d. h. das ein Ressourepool von 10 GHz ca. 5 vCPUs ohne Überbuchung ausführen kann.
• Shares (Priorität) regeln die Verteilung der verfügbaren 100% bei Überbuchung der im vCD zur Verfügung stehenden Rechenleistung / RAM.
• Wenn es bei Überbuchungen Engpässe gibt, werden die niedrig oder gar nicht priorisierten VMs u. U. bis zum Stillstand benachteiligt.
• Die Überbuchung von CPU Ressourcen führt bei hoher Auslastung bzw. Engpässen zu Einschränkungen der Netzwerkperformance und generellem Performanceverlust aller VMs.
• Die Überbuchung des Verfügbaren RAM führt aufgrund von Ballooning und ggf. sogar Auslagerung des RAM durch den Hypervisor auf den Datenspeicher zu hoher Load im Gast OS bis hin zum Stillstand der VMs.
• Prüfen Sie z. Bsp. mittels cat /proc/cpuinfo | grep name den Typ der CPU des ESXi.
  Weisen Sie einer VM keinesfalls mehr vCPUs zu, als die physische CPU Cores hat.
• Zur optimalen Funktion einer VM ist die Installation von VMwareTools sowie die korrekte Konfiguration von NTP obligatorisch.

Zur Verwendung von Shares und Reservierungen ist folgende Lektüre zu empfehlen:

• http://wahlnetwork.com/2012/02/01/understanding-resource-pools-in-vmware-vsphere
• https://anthonyspiteri.net/cpu-overallocation-and-poor-network-performance-in-vcd-beware-of-resource-pools
• https://blogs.vmware.com/performance/2017/03/virtual-machine-vcpu-and-vnuma-rightsizing-rules-of-thumb.html

Einstellung von CPU- und RAM- Reservierungen

Eine direkte Zuweisung für CPU- und RAM- Reservierung ist nur in Production vDCs möglich. Die konfigurierte RAM Reservierung muss immer kleiner als die tatsächliche RAM Größe sein, da es bei 100% RAM Reservierung zu Fehlfunktionen bei vMotion oder Hot-Add kommen kann.

Verwendung von Datenspeichern

Standardmäßig stehen folgende Klassen von Datenspeichern zur Verfügung:

• Standard Performance - Datenspeicher für vApps mit normalen Anforderungen, z. Bsp. Webserver oder Applikationen
• High Performance - Datenspeicher für vApps mit hohen Anforderungen an Latenzen und IOPS, z. Bsp. MySQL, MongoDB oder OLTP - Applikationen.
• Catalog - Datenspeicher zur Ablage von ISO-Images und vApp Templates. Dieser Datenspeicer ist nicht zum Betrieb von vApps geeignet.

Bitte beachten Sie bei der Provisionierung von vApps folgende Hinweise, um einen störungsfreien Betrieb zu gewährleisten:

• Zusätzlich zu den VMDK-Dateien der vApps wird für jede VM eine Auslagerungsdatei auf dem Datenspeicher angelegt. Die Größe der Auslagerungsdatei entspricht dem Anteil des nicht reservierten RAM der VM, z. Bsp. wird für eine VM mit 16 GByte RAM ohne Reservierung zusätzlich eine 16 GByte große Auslagerungsdatei auf dem Datenspeicher erzeugt, sobald die VM eingeschaltet wird. Bei einer entsprechenden Anzahl an VMs muss diese Größenordung in die Kapazitätsplanung des Datenspeichers einbezogen werden. Grundsätzlich ist zu empfehlen, für jede VM ab 8 GByte RAM, mindestens 50% RAM zu reservieren.
• VMs sollten wo immer möglich, mit nur einer virtuellen Festplatte konfiguriert werden.
• Pro VM kann maximal 1 Snapshot gleichzeitig erzeugt werden. Die Arbeitsweise von Snapshots wird in folgendem Artikel ausführlich beschrieben: https://kb.vmware.com/KB/1015180. Bitte beachten Sie in Ihrer Kapazitätsplanung, dass bei Erzeugung eines Snapshots zusätzlich Datenspeicher in der Größe der ursprünglichen VMDK - Datei reserviert wird. Wenn Sie einen Snapshot einer 100 GByte VMDK Datei (VM) erzeugen, so reserviert diese VMs für die Dauer der Existenz des Snapshots zusätzlich 100 GByte, da die für den Snapshot benötigte Sparse Disk maximal die Größe des Originals annehmen kann.
• Es ist zwar technisch möglich, eine vAPP / VM auf einem Catalog Datastore zu provisionieren bzw. zu starten. Laufende vAPPs auf dem Catalog Datastore werden bei regelmäßigen Überprüfungen automatisch verschoben bzw. bei Platzmangel abgeschaltet. Es kann nicht sichergestellt werden, dass vApps auf dem Catalog Datastore störungsfrei laufen. Catalog Datastores sind ausschließlich zur Speicherung von nicht aktiven Templates oder ISO Vorlagen vorgesehen. Die Provisionierung von aktiven vAPPs auf dem Catalog Datastore ist nicht gestattet.

Limitierung von VMs und vApps

Bei der Konfiguration von VMs muß den Gegebenheiten einer virtualisierten Infrastruktur unbedingt Rechnung getragen werden. Besonders bei der Zuteilung von vCPUs sollten nur soviel vCPUs wie unbedingt nötig verwendet werden. Das Motto "viel hilft viel" kehrt sich in diesem Zusammenhang bei der Zuweisung von vCPUs ins Gegenteil.

Frage: Wieviele vCPUs können maximal pro VM konfiguriert werden?
Antwort: Eine VM sollte grundsätzlich zum Anfang nur mit einer vCPU ausgerüstet werden. Falls die Applikation in der VM tatsächlich mit mehreren Threads arbeiten kann, sollten nicht mehr als 4 vCPUs pro VM konfiguriert werden, um eine optimale Leistung zu erzielen. Bei mehr als 6 vCPUs pro VM sinkt die Leistung der VM rapide ab. Achten Sie unbedingt darauf, dass Sie VMs immer 1,2,4 oder 6 vCPUs bzw. Cores zuweisen. VMs sollten niemals mit 3 oder 5 vCPUs bzw. Cores betrieben werden.
Frage: Wieviel RAM kann einer VM zugewiesen werden?
Antwort: Je nach Betriebssystem sollten einer VM maximal 32 GB oder 64 GB RAM zugewiesen werden.