ESXi Resoucen Bedarf

[esquire1968]

Hello!

Ich habe einen Server mit 32 GB RAM und 8 Cores (4 CPUs x Intel(R) Xeon(R) CPU E3-1230 v6).

Wieviel RAM bzw. wieviele Cores kann ich den VM's maximal zur Verfügung stellen, bzw. was muss für ESXi übrig bleiben? Die VM's zu in der Regel nicht den gesamten RAM der zur Verfügung gestellt wurde. Kann ich alles auf die VM's "verteilen" und ESXi nimmt sich was es braucht.

Danke vorab!

Gruß
Thomas

 

[besterino]

CPU ist im Prinzip eher egal, RAM würde ich eher nicht überprovisionieren und als Daumenregel ca. 2GB für ESXi selbst „unbelegt“ lassen.

Wieviel Cores/RAM Du dann im Detail wohin packst, hängt dann ganz von deinen VMs ab. Eine Linux-VM, die nur ab und an benötigte Dienste ohne Rechenpwowerbedarf bereit stellt und größtenteils nur rumidled, ist mit einem Core und 1GB RAM schon überversorgt. Einer Win10-VM hingegen würde ich wohl min. 2 Cores / 4GB-RAM mitgeben, wenn das noch halbwegs Spaß machen soll, die auch (z.B. mit RDP) zu benutzen und wenn’s auch nur für Word ist. Ne Storage-VM mit verschlüsselten Laufwerken, guten RAM-Cache Features usw. dann eben gerne 4 Cores mit 16GB RAM. Je nachdem halt. Wäre erstmal großzügig und bei steigender Zählt VMs wenn eine VM dann hakt muss man umdisponieren und Ressourcen umallokieren so dass das Gesamtbild passt.

 

[esquire1968]

Danke für die Antwort. Hilft mir schon weiter.

Aktuell habe ich meine 8 cores und 32 RAM so verteilt:

VM                            core   RAM
----------------------------------------
Storage (OmniOS/napp-it)         2    16
debian9 (Unifi, Resilio ...)     1     4
debian8 (div. Sync)              1     1
pfSense (Test)                   1     2
debian9 (Test)                   1     2
Domain-Controller                1     2
(univention Test)
----------------------------------------
                                 7    27

Da bleibt dann ausreichend für ESXi. Würdest Du das anders verteilen?

Gruß
Thomas

 

[bf1967]

Hallo Thomas,

Du verwendest einen Prozessor mit 4 Cores + Hyperthreading.

Prozessoren kann man nach meiner Erfahrung ganz gut überprovisionieren. In der großen Umbegebung bei mir auf der Arbeit haben wir mit ca. Faktor 4 überprovisioniert und sind von der CPU Last zwischen 10% und 30%. Wenn also eine Deiner VMs zeitweise zwei CPU Threads auslasten will dann gib ihr besser zwei Prozessoren als einen. Du solltest aber möglichst nicht mehr als 4 Prozessoren zuweisen. Einer Windows VM gebe ich z.B. immer mindestens zwei CPUs - eine für den Virenscanner und eine für den Workload).

Speicher kann man grundsätzlich auch überprovisionieren. Es gibt diverse Mechanismen das zu kompensieren. VMware ESXi 6.0 und höher stellt fünf verschiedene Techniken zur Optimierung des Speichers zur Verfügung: Page Sharing, Arbeitsspeicherrückgewinnung (Memory Ballooning), Arbeitsspeicherkomprimierung (Memory Compression), Swap-to-Host-Cache und Swapping. Bis auf Swap-to-Host-Cache das nach meinem Kenntnisstand eine SSD und eine Enterprise (Plus?) Lizenz benötigt sollte auch bei Dir alles funktionieren. Praktische Erfahrung damit habe ich persönlich keine. In unserer Firmenumgebung haben wir genug Speicher um die Anforderung aller VMs mit physikalischem Speicher bedienen zu kommen.

Wenn Du beim Storage auf ZFS verzichtest würdest Du mit deutlich weniger RAM auskommen. Für ZFS sollte Dein Server unbedingt ECC RAM nutzen.

Nicht vergessen solltest Du Disk I/O. Falls Du lokale Disks in Form von Festplatten verwendest kann der recht schnell zum Engpass werden. Mit SSDs kannst Du das etwas enspannter sehen.

Einfach mal loslegen, die Umgebung überwachen (z.B. mit der kostenlosen Variante von PRTG - eventuell bietet der Client des ESXi auch entsprechende Funktionalität) und die CPUs und den Hauptspeicher entsprechend anpassen und/oder Festplatten gegen SSDs austauschen.

Gruß
Bernd

 

[Trambahner]

Überprovisionieren ist kein Problem, aber man sollte einer VM auch wirklich nur soviel vCPU zuweisen, wie sie wirklich nutzt. Wenn überschüssige vCPU zugewiesen werden, dann erzeugt das durchaus eine kleine Last durch die Verwaltung dieser zusätzlichen CPU-Anteile. Bei sehr wenig laufenden VMs fällt das nicht so auf, aber dieser Overhead wird durchaus merkbar wenn mehr VMs auf der Maschine laufen oder die Auslastung bereits hoch ist.

Daher nicht einfach nach dem Motto "mehr hilft mehr" verfahren sondern so provisionieren, wie es die VMs wirklich nutzen können.

 

[AliManali]

Hi

Habe auch für CPU intensive Anwendungen/VM's nur 1 Thread pro Gast. So zum Beispiel zwei Windows VM's mit je einem DirectX Gameclient, welche die zugewiesene CPU Leistung voll auslasten. Trotzdem reagieren die VM's noch super.

Wegen dem Virenscanner 2 Threads zuweisen halte ich für arg übertrieben. Ich mach bei meinen Windows Gästen die periodische Überprüfung auf aus, und lass nur den Echtzeitschutz laufen. In den produktiven VM's surfe ich eh weniger dubiose Seiten an, oder lasse den Speicher auf nonpersistent bei Bastel VM's.

Gerade auch wenn nur ein Vierkerner vorhanden ist: weniger ist manchmal mehr. Das selbe gilt für den Speicher, welchen ich auf keinen Fall überprovisionieren würde! Engpässe sind eh meist beim Storage zu suchen, meiner Erfahrung nach.

Positiver Nebeneffekt von nur einem Thread pro VM ist ein besserer Schutz gegen Spectre II. Gibt auch welche, die machen im BIOS HTT aus aus dem Grund. Das Problem besteht vor allem dann, wenn fremde Benutzer Zugriff auf Gäste haben, und dort eigenen (bösen) Code ausführen können.

 

[gea]

Wenn Du beim Storage auf ZFS verzichtest würdest Du mit deutlich weniger RAM auskommen. Für ZFS sollte Dein Server unbedingt ECC RAM nutzen.

Ähmmm, NEIN

Ein 64 bit OS sollte 2 GB RAM haben (alle aktuellen Systeme mit ZFS sind 64bit), egal welches. Oracle nennt auch diese 2 GB als Minimum, egal wie groß ein ZFS Pool ist. Damit ist das OS stabil und schnell.

ZFS ist aber Erster wenn es um ein neues Level and Datensicherheit geht. Dank Copy On Write ist es Crashsicher (kein defektes Dateisystem bei Absturz beim Schreiben oder defektes Raid), das bringt auch Versionierung durch Snaps. Der Preis ist eine höhere Fragmentierung.

ZFS fügt an alle Daten/ Metadate Prüfsummen an um die beim Lesen zu verifizieren. Jegliche Veränderung wird entdeckt und mit Raid /Redundanz sofort repariert. Der Preis ist eine etwas höhere CPU Last und mehr Daten. Könnte man abschalten, ist aber wie das Ausschalten eines Airbags im Auto, recht sinnfrei.

Diese Sicherheit kostet. Zum Ausgleich hat ZFS die besten RAM basierten Cache Mechamismen. Dafür brauchts RAM, nicht für ZFS. Mit einer Highspeed Disk wie eine Intel Optane gint es kaum eine Verbesserung mit viel RAM.


ECC
Ohne ECC kann jeder RAM Fehler zu Datenfehlen führen. Ist bei jedem System so, nichts besonderes mit ZFS. Ein verbreiteter Mythos meint dass bei ZFS ein Prüfsummenfehler beim Lesen (z.B. wegen RAM-Fehler) zu einem endlosen Kaputtreparieren eines ZFS Pools führt. Das ist blanker Unsinn. ZFS wird die Disk oder den Pool einfach offline stellen oder das OS vorher abstürzen.

Nichts desto weniger. Bei heutigen Speichergrößen ist non-ECC RAM schlicht fahrlässing - in etwa so wie Raid-0 bei Platten.

 

[esquire1968]

Danke für die Antworten!
Habe ECC RAM (2x Kingston ValueRAM Server Premier DIMM 16GB, DDR4-2400, CL17-17-17-32, ECC).

Sollte ich jetzt meine Core/RAM ändern (zB napp-it mehr cores/RAM geben) oder passt das so?

 

[gea]

Sollte ich jetzt meine Core/RAM ändern (zB napp-it mehr cores/RAM geben) oder passt das so?

Die jetzige Konfiguration ist bereits auf Storage optimiert. Das paßt so.