vMSC Host Ressourcen

[pirx]

Hallo,

aktuell betreiben wir einen stretched cluster mit 16 Hosts und EMC VPLEX (ca. 400m Entfernung). In einigen Wochen steht die Umstellung auf den IBM SVC an, danach wird eine Hälfte des Clusters an einen neuen Standort gebracht. Der Abstand ist dann 40 Km (dark fibre). Der Cluster muss deswegen umgebaut werden, bisher haben wir wegen der kurzen Entfernung zwischen den 2 Seiten keine affinity rules, die die VMs auf eine bestimmte Seite festlegen. Mit dem SVC soll sich das ändern.

In diesem Zuge wird auch überlegt die Host Ressourcen aufzustocken. Aktuell verkraften wir den Ausfall von 1-2 Hosts. Der Fokus liegt momentan darauf, dass einige wenige (ca. 80 VMs) beim Ausfall einer Seite weiter laufen müssen, dafür haben wir Ressource Pools angelegt und die HA Restart Policy verändert. Künftig soll das Ziel sein, dass alle VMs in diesem Cluster beim Ausfall eine Seite weiter laufen können.

Aktuelle Daten:
16 Hosts, 32 Sockel, 256 Cores, 6144 GB pRAM
410 VMs, 1256 vCPUs & 4165 vRAM provisioniert, vCPU:pCPU=4,9:1

Beim vRAM nutzen wir kein Overprovisioning.

Was mich beschäftigt ist die Frage, wie viele zusätzliche Hosts wir künftig tatsächlich brauchen werden. Die einfache Rechnung wäre das vergebene vRAM und die vCPUs zu verdoppeln und zumindest beim vRAM dafür zu sorgen, dass die benötigten 100% auf beiden Seiten zur Verfügung stehen.

Damit wäre ich dann bei 24 Hosts, 9216 GB pRAM, 384 Cores, vCPU:pCPU=3,2:1

Im Normalbetrieb bedeutet das natürlich auch, dass viele Host Ressourcen ungenutzt bleiben. Alternativ könnte man mit weniger zusätzlichen Hosts starten und hoffen, dass ballooing für die VMs, die keinen Speicher fest über die Ressource Pools zugesichert haben, trotzdem einiger Maßen weiter laufen.

Mir fehlt hier das Gefühl, was sinnvoll/notwendig ist. Wie wird das in andere Umgebungen gemacht, knallhart 200% Ressourcen vorhalten?

[Gad]

Wenn du sagst dass es dir im Notfall reicht dass 80 VMs weiterlaufen, wieso willst du dann Ressourcen schaffen das du alle VMs auf einer Seite laufen lassen kannst?

Edit: ok, den Satz nach den 80 VMs hab ich überlesen, meinen Beitrag damit einfach ignorieren.

[pirx]

Das Problem ist, dass die Definition der wichtigen System sehr schwammig ist. Die "wichtigen" Systeme machen keine 10% aller VMs aus. Ich habe Zweifel das der Verlust von 90% der Systeme ohne Spuren bleiben würde. Die Definition davon wird aber an anderer Stelle getroffen. Meine persönliche Meinung ist die, dass eine Firma die nicht gerade geringe Investitionen in ein neues RZ an einem zweiten Standort getätigt hat, auch das Budget einplanen sollte, alle VMs (oder zumindest VMs in diesem Cluster) weiter laufen zu lassen.

Dazu kommt, dass unser Backup Konzept noch sehr altmodisch ist. Mit Agenten in dem VMs, kein LANless Backup, keine VMware Integration. Im Fehlerfall würde das Desaster Recovery von vielen VMs extrem lange dauern. Daher würde ich die VMs alle auf gespiegelten Storage legen. Das ist kein Ersatz für eine cleverere Backup Strategie, fängt aber den Wegfall eines RZs ab.

[irix]

Unsere "Streched" Cluster sind in der Tat darauf ausgelegt das wir 200% an Memory spezifiziert haben bassieren auf Overcomitting.
Bei CPU tu ich mich ein wenig schwerer und hab ein Script in der Ueberwachung welches auf die pCPU<->vCPU Ratio schaut weil MHZ nun leider nicht der Maßstab ist.

Wir haben aber eine Anforderung zu erfuellen und somit gibts da auch nicht soviele Alternativen fuer uns.

Zum Balloning... das findet ja extrem spaet statt und dauert ja auch. Das HA moechte die VMs schneller starten also du "Autsch, da ist was..." sagen kannst und somit wuesste ich nicht ob das hier eine Hilfe ueberhaupt waere.

Gruss
Joerg

[pirx]

Unsere "Streched" Cluster sind in der Tat darauf ausgelegt das wir 200% an Memory spezifiziert haben bassieren auf Overcomitting.

Das mit dem Overcomitting interessiert mich jetzt. Weil wir bisher in unseren Clustern mind. soviel pRAM wie vRAM haben. Das ist ein altes Thema, und ich hatte hier auch schon mal danach gefragt. Ich bin mir sehr sicher, dass wir an VMs oft zu viel vRAM vergeben, an den Anforderungen kann ich aber nichts ändern (vCOPs meint wir hätten 99% waste, wobei ich diese Zahl auch nicht ganz ernst nehme).

Wenn wir von Overcomitting reden (welcher Faktor?), dann bedeutet das doch praktisch immer ballooning. Im HA Fall und dem Wegfall von 50% der Ressourcen wird ballooning nicht so schnell greifen können, die wichtigen Systeme die in Ressource Pools liegen, wird das aber hoffentlich nicht betreffen. Es wäre auch nicht so kritisch, wenn wir eine gewissen Downtime (x Stunden) haben und VMs manuell auf der anderen Seite starten müssen.

[irix]

Ich sags mal anders

1. Ueber das worueber wir hier Reden gibts keine Resourcen (*)Reservierung bei uns
2. Ich rechne pro Standort aus was an "Host MEM - MB"aktuell benoetigt wird, ich kenne meine Schwankungen und eine Reserve
3. Ich trage Sorge das dieser "Host Mem - MB" auf der anderen Seite als freie Resource zur Verfuegung steht.

Nicht mehr aber auch nicht weniger. Mit CPU tut ich mich ein wenig schwierig. Ja ich stimme zu das mir vRO was Thema Speicher angeht auch nicht gross erleuchtet.

* = Wenn man sich die Werte anschaut das sind diese bei 90% alle VMs gleich dem konfigurieren vMem oder hoeher (wegen Overhead). Gibts aber Ausreisser wo 16GB konfiguriert sind, die VM ist an und tut was und benoetigt aber nur 3.5GB. Das heist fuer einen Grossteil meiner VMs hat der Host 100% der Memory Resourcen zugewiesen. Das ist meine Rechengrundlage und das wird bei euch doch nicht viel anders sein.

VMware hat angekuendigt aus Sicherheitsgruenden das TPS per Default zu deaktivieren so das es erstmal nur innerhalb einer VM doppelte Speicherseiten optimiert und nicht mehr uebergreifend. In einem ResourcePool mit 76 mixed VMs und 300GB Verbrauch sind per TPS 1.58GB "gewonnen" worden.

Gruss
Joerg

[pirx]

Im VMware Whitpaper steht: "Set appropriate Virtual Machine memory size. The virtual machine memory size should be slightly larger than the average guest memory usage."

Damit tut ich mich schwer. "guest memory usage" ist für mich das active memory. Das wird im vCenter und in vCops mit run 400 GB für den gesamten Cluster angezeigt, mit einem Peak auf 530 GB vor einigen Wochen. Das pRAM in dem Cluster ist aber rund 5,3 TB. Irgendwie passen die Relationen da nicht

[~thc]

Ich würde davon ausgehen, dass die "average memory usage" der intern angezeigte Bedarf einer VM ist. "Guest Mem %" dagegen ist das aktive VM-RAM und ist meist sehr viel kleiner.

Beispiele aus der Praxis:

Code: Alles auswählen

Maschine        vRAM    Guest Mem %     internal RAM Usage      internal Commit

SQL Server      8 GB    6 (486 MB)      4,8 GB                  5,5 GB
Exchange 2010   16 GB   2 (327 MB)      10,8 GB                 11,8 GB
8.1 Desktop     4 GB    4 (163 MB)      924 MB                  2,0 GB

[pirx]

"internal RAM Usage", bzw. commit, ist dann also der Wert den ich innerhalb eines Windows z.B. über

Get-WmiObject win32_operatingsystem | Select @{L='commit';E={($_.totalvisiblememorysize- $_.freevirtualmemory)*1KB/1GB}}

herausbekomme? Wie hast du die Werte in deiner Tabelle erhaltent?

[~thc]

Ganz schnöde über den Process Explorer. Das ist natürlich für einen ganzen Cluster voller VMs unpraktikabel. Aber wenn es dir gelingt, das mit WMI-Abfragen zu vereinfachen, sollte der Aufwand vertretbar bleiben.