Bewertung RAM Ressourcen im Cluster

[pirx]

Hallo,

kann mir jemand sein Einschätzung zur Vergabe/Auslastung von RAM Ressourcen in folgendem Cluster geben (4x ESXi mit je 96 GB RAM, 52 VMs)?

http://i.imgur.com/oDpqn.png
http://imgur.com/DzZSl

Ich würde gerne mal hören, ob jemand zum gleichen Schluss kommt wie ich.

[sirrossi]

Moin pirx,

möchtest Du uns noch mitteilen, zu welchem Schluß Du gekommen bist

[pirx]

Ich hätte gerne erst mal andere Meinungen gehört, bevor ich meine Schlussfolgerung schreibe. Vor allem was das active RAM angeht.

[Dayworker]

http://imgur.com/DzZSl

Die 4 Hosts sind zu ~60% RAM-technisch ausgelastet.

http://i.imgur.com/oDpqn.png

~295GB sind durchschnittlich Granted, aber davon sind ebenfalls im Durchschnitt nur ~23GB aktiv in Verwendung. Das du die VMs nicht viel in Richtung geringeren RAM-Verbruach tunen kannst, läßt sich zum einen am Ballooning als auch am max.Consumed-Wert von ~316GB ablesen.

Da du rein rechnerisch nur 384GB abzüglich 2GB pro ESXi-Eigenbedarf verbaut hast, stossen einige Hosts temporär bereits an ihre Grenzen. Ansonsten müßte in meinen Augen bei Balloon überall eine Null stehen.

Was ist eigentlich am 16-19.September bzw 04-06.Oktober passiert?
In beiden Zeiträumen hat der Consumed-Wert einen kleinen aber dauerhaften Sprung nach oben gemacht, obwohl der Active-Wert fast durchgängig um 23GB liegt.

[pirx]

Im Sep./Okt. wurden einige VMs heruntergefahren und neu installiert.

Mein Einschätzung wäre eigentlich gewesen, dass wir zu großzügig mit den vRAM Ressourcen umgehen. Vor allem wegen des sehr niedrigen active RAM Wertes. Das mit dem Ballon Wert kann ich mir erst mal nicht erklären. Aus meiner Sicht dürfte in dem Cluster der balloon Treiber gar nichts auf den VMs machen. Ich sehe praktisch keine VM mit hohem active memory Werten.

esxtop Beispiel für einen Server:

Code: Alles auswählen

 9:26:47am up 160 days  2:19, 351 worlds; MEM overcommit avg: 0.00, 0.00, 0.00
PMEM  /MB: 98293   total:  1908     vmk, 89229 other,   7155 free
VMKMEM/MB: 96881 managed:  5812 minfree, 10970 rsvd,  85910 ursvd,  high state
NUMA  /MB: 48815 ( 8624), 48473 ( 2925)
PSHARE/MB:  5383  shared,   779  common:  4604 saving
SWAP  /MB:     0    curr,     0 rclmtgt:                 0.00 r/s,   0.00 w/s
ZIP   /MB:     0  zipped,     0   saved
MEMCTL/MB:   202    curr,   157  target, 60564 max

   GID NAME               MEMSZ    GRANT    SZTGT     TCHD   TCHD_W %ACTV %ACTVS %ACTVF %ACTVN MCTL?   MCTLSZ  MCTLTGT  MCTLMAX    SWCUR    SWTGT   SWR/s   SWW/s   OVHDUW     OVHD  OVHDMAX
7179746 xxxx 32768.00 31918.00 32984.52   327.68   327.68     1      0      0      0     Y     0.00     0.00 21298.91     0.00     0.00    0.00    0.00   158.97   298.07   494.60
5085715 xxxx 8192.00  8192.00  7638.81   491.52   409.60     7      3      6      2     Y     0.00     0.00  5324.51     0.00     0.00    0.00    0.00    61.85   128.23   204.02
6777531 xxxx 8192.00  8138.47  6500.56   244.15   162.77     1      1      1      0     Y    53.53    41.97  5324.51     0.00     0.00    0.00    0.00    58.41   125.71   188.24
4439449 xxxx 4096.00  4096.00  3607.36   204.80   204.80     3      2      3      1     Y     0.00     0.00  2662.11     0.00     0.00    0.00    0.00    42.22    75.49   139.79
9575334 xxxx 4096.00  4096.00  3479.05   245.76   122.88     4      1      3      1     Y     0.00     0.00  2662.11     0.00     0.00    0.00    0.00    42.22    75.59   139.79
4976180 xxxxx 4096.00  4096.00  4157.96  1720.32  1556.48    23     18     23     17     Y     0.00     0.00  2662.11     0.00     0.00    0.00    0.00    42.22    64.81   139.81
4425029 xxxx 4096.00  4096.00  4157.90   450.56   368.64     4      4      4      6     Y     0.00     0.00  2662.11     0.00     0.00    0.00    0.00    42.22    65.73   139.81
7658078 xxxx 4096.00  4096.00  4158.04   696.32   655.36     7      7      7      8     Y     0.00     0.00  2662.11     0.00     0.00    0.00    0.00    42.22    63.89   139.81
6442335 xxxx 4096.00  4035.04  3562.57   161.40   161.40     5      2      4      3     Y    60.96   114.52  2661.89     0.00     0.00    0.00    0.00    38.00    73.10   135.56
7322211 xxxx 4096.00  4007.80  3881.48   200.39   160.31     5      2      4      5     Y    88.20     1.39  2661.89     0.00     0.00    0.00    0.00    38.00    72.93   135.56
7527025 xxxx 4096.00  4096.00  4154.71   286.72   286.72     6      4      6      3     Y     0.00     0.00  2662.11     0.00     0.00    0.00    0.00    42.22    65.71   139.81
4556534 xxxx 4096.00  4096.00  4149.36   327.68   286.72     5      3      5      8     Y     0.00     0.00  2662.11     0.00     0.00    0.00    0.00    42.22    66.15   139.81
6286825 xxxx 3072.00  3072.00  3124.24  1075.20   890.88     5     11     10      7     Y     0.00     0.00  1996.41     0.00     0.00    0.00    0.00    33.95    52.88   123.45
8715924 xxxx 2048.00  2047.90  2091.73   266.24   225.28     5      5      5     13     Y     0.00     0.00  1330.81     0.00     0.00    0.00    0.00    29.90    44.46   111.34
4425033 xxxx 2048.00  2048.00  2079.58   204.80   184.32     1      4      1      2     Y     0.00     0.00  1330.77     0.00     0.00    0.00    0.00    29.90    45.87   111.34
7576670 xxxx 128.00   128.00   144.53     3.84     1.28     2      1      2      2     N     0.00     0.00     0.00     0.00     0.00    0.00    0.00    32.64    17.11    92.83



[pirx]

Ich habe noch einige vCOPS Graphen heraus gekramt.

http://i.imgur.com/CpX7D.png

Je mehr ich mich mit dem Thema Speicher/Ressourcen beschäftige, desto undurchsichtiger wird es für mich.

Die 4 Server habe insg. ~384 GB RAM.

- als Usable Memory wird 378 GB angezeigt (~384 - 4 x 2 GB ESXi)
- Memory Usage ist max. 73%
- als Provisioned wird 402 GB angezeigt. Wobei ich das nicht nachvollziehen kann, wenn ich mir die Werte für den Cluster aus RVTool in ein Excel exportiere, komme ich da nur auf rund 300 GB.
- Granted sind 284 GB, ok, könnte passen
- Consumed sind 293 GB
- Guest Active max. 35 GB

Mit den Zahlen ist mir nicht klar, warum trotzdem ballooning aktiv ist. Ich hätte anhand der Zahlen eigentlich gedacht, dass der Cluster noch genügend Speicher Ressourcen hat. Obwohl den Gästen recht großzügig vRAM zugewiesen wird. Reservierungen gibt es keine.

Dann noch die Empfehlungen von vCOPS, die eigentlich auch dafür sprechen das phy. Ressourcen noch genügend vorhanden sind.

http://i.imgur.com/1Nxrk.png

http://www.yellow-bricks.com/2010/12/20 ... y-metrics/ kenne ich, macht mir das Leben gerade aber auch nicht leichter.

[Dayworker]

Ich hab jetzt nicht alle neuen Links angesehen, aber im Bild http://imgur.com/DzZSl waren bereits zwei VMs mit jeweils mehr als 25% RAM eines Hosts zu sehen. Wenn speziell die erste VM auf Host1 keinen Reservierungen eingestellt bekommen hat, könnte diese natürlich auch auf einem anderen Host laufen, der zwar RAM-technisch stärker aber dafür CPU-technisch weit weniger stark belegt ist und der dem jeweiligen Host dafür fehlende RAM würde in meinen Augen über das Ballooning abgebildet werden.

Ob eine VM zu großzügig mit vRAM bedacht wurde, kannst du auch in jeder Win-VM über die "Verwaltung" unter "Leistungsprotokolle & Warnungen" oder Nagios für beide OS-Welten überprüfen. Dazu mußt du nur Trigger auf CPU- und RAM-Verbrauch setzen und kannst dir dann die Realität ansehen.
Bei zweiter Betrachtung entsprechen 23GB durchschnittlichem Realverbrauch gegenüber 293GB garantiertem RAM ja weniger als 8 Prozent. Falls die jeweiligen VMs keine grossen Programme oder DBs beherbergen, ließen sich diese doch noch reichlich abspecken.

[mangold]

ich habe ein ähnliches Problem mit unseren JBOSS Servern der Anwendungsentwicklung, die laut AE eben sehr Leistungshungrig sind. 8GB Vram werden gefordert. Leider haben sowohl Linux als auch JBOSS die unschöne Angewohnheit den gesamten zugewiesenen Ram zu allocieren, so dass der Host die nicht mehr frei geben kann. Der Consumed Ram ist immer gleich dem Granted Ram. Was in unserer Umgebung nun ziemlich ungewöhnlich ist, nur eben typisch für diese Anwendungsserver.

Leider fehlt mir pers. sowohl im Linux als auch auf Applikationsebene das Knowhow die reele Last und die damit verbundenen Impacts bei Reduzierung des vRams zu beurteilen. Echt ne Pest sowas.

Generell schwierig zu beurteilen und nach etlichen Jahren mit VMware immer noch nicht richtig verstanden, ist die Diskrepanz zwischen Consumed und Active. Etliches dazu gelesen, was es in der Praxis bedeutet kapiere ich immer noch nicht genau

@pirx; Was mir bei dir Sorgen machen würde ist, dass z.T. der Ausfall EINES Host dazu führen könnte, dass einige VMs nicht mehr gestartet werden können.

[Dayworker]

@pirx; Was mir bei dir Sorgen machen würde ist, dass z.T. der Ausfall EINES Host dazu führen könnte, dass einige VMs nicht mehr gestartet werden können.

Da wird meines Wissens nach nicht passieren, da ja nur 8% des zugewiesenen vRAMs von den VMs überhaupt genutzt werden. Falls es doch mal knapp wird, steigt der Ballooning-Wert halt an oder der ESXi selbst fängt an zu Swappen...

Generell schwierig zu beurteilen und nach etlichen Jahren mit VMware immer noch nicht richtig verstanden, ist die Diskrepanz zwischen Consumed und Active. Etliches dazu gelesen, was es in der Praxis bedeutet kapiere ich immer noch nicht genau :Sad:

Vielleicht hilft dir zum Verständnis das PDF http://www.vmware.com/files/pdf/mem_mgm ... phere5.pdf weiter.