VMs mit hoher CPU Anzahl

[wbdan]

Hi ihrs,

nachdem wir mittlerweile schon verschiedene Cluster für verschiedene VM KLassen laufen haben, kam heute die nächste Anfrage rein.

Es geht um die Virtualisierung von Maschienen mit einer hohen Anzahl an CPU, welche bislang einzeln und nativ auf einem Blech gelaufen sind.

Bei Ent+ und VM LVL8 ist ja die Maximale Anzahl an vCPU 32.
An vRam müsste der Kiste dann natürlich auch einiges zugestanden werden,
sagen wir mal ab 32GB

Wie sieht es bei einer solchen Maschine aus mit VMotion, hat dass schon einmal jemand getestet ? Dauer ?

Welche Vor/Nachteile sind zu erwarten, wenn diese Kisten nun virtualisiert werden. Ich gehe hier NICHT von Overbooking aus, eher von 1:1 Virtualisierung.

Auf der Pro Seite habe ich bisher:
- Einfachere Realisierung von Desaster Recovery / Failover Szenarien
- Hardware(Vendor) unabhänigkeit / innerhalb der VM keine änderungen nötig bei Umzug auf andren Host (Bei gleichem CPU Typ)

Grüsse
wbdan

[irix]

Hi ihrs,

nachdem wir mittlerweile schon verschiedene Cluster für verschiedene VM KLassen laufen haben, kam heute die nächste Anfrage rein.

Es geht um die Virtualisierung von Maschienen mit einer hohen Anzahl an CPU, welche bislang einzeln und nativ auf einem Blech gelaufen sind.

Bei Ent+ und VM LVL8 ist ja die Maximale Anzahl an vCPU 32.

Sofern du vSphere 5 verwendest. Da du hier unter vSphere 4 gepostet hast das nur als kleiner Hinweis.

An vRam müsste der Kiste dann natürlich auch einiges zugestanden werden,
sagen wir mal ab 32GB

32GB fuer eine Monster VM ist nun im Verhaeltnis nicht viel.

Wie sieht es bei einer solchen Maschine aus mit VMotion, hat dass schon einmal jemand getestet ? Dauer ?

Ich habe einen Kunden mit 40GB Terminal Server von den die VM aktiv 32GB benutzt und selbst bei 1Gb vMotion kann man es aushalten.... es dauer nur ein wenig.

In anderen Umgebungen haben wir 10GbE und da ist vMotion dann ein Traum.

Welche Vor/Nachteile sind zu erwarten, wenn diese Kisten nun virtualisiert werden. Ich gehe hier NICHT von Overbooking aus, eher von 1:1 Virtualisierung.

Auf der Pro Seite habe ich bisher:
- Einfachere Realisierung von Desaster Recovery / Failover Szenarien
- Hardware(Vendor) unabhänigkeit / innerhalb der VM keine änderungen nötig bei Umzug auf andren Host (Bei gleichem CPU Typ)

Grüsse
wbdan

Nachteile waeren:
- Zusaetzliche Lizenzkosten
- Lizenz gebaren von MS/Oracle fuer SQL Server usw. wenn dieser Host Mitglied eines Clusters ist

Vorteile:
- Der vRAM welcher mit den E+ Lizenzen kommt fliesst ja in einen Pool auf dem vCenter mit ein. Also profitiert unter Umstaenden die Gesamtumgebung bei Hosts/Clustern welche eine hoehere Konsolidierungsrate haben und dazu Overprovisioning verwenden.

Gruss
Joerg

[pirx]

Bei uns kommen auch immer mehr VMs die mit 8 vCPUs und 32 - 64 GB vRAM ausgestattet werden sollen. Ob das immer sinnvoll ist... auf jeden Fall ist der Wunsch da einen möglichst hohen Virtualisierungsgrad zu erreichen.

Probleme hatte ich bisher nicht, wobei hier VMs denen viel vRAM zugewiesen sind häufig nur einen Bruchteil davon nutzen. Es gibt aber einige sehr aktive VMs mit nur 8 GB vRAM, bei denen es regelmäßig bei vMotion mehrere Anläufe braucht, bis sie migriert werden können (Fehlermeldung von wegen die Änderungen sind größer als die zur Verfügung stehende Netzwerkbandbreite).

[wbdan]

Sofern du vSphere 5 verwendest. Da du hier unter vSphere 4 gepostet hast das nur als kleiner Hinweis.

Sorry, ich hab zwar den Bereich für ESXi5 gesehen, aber nicht für vSphere 5

32GB fuer eine Monster VM ist nun im Verhaeltnis nicht viel.

Nuja, deswegen schrieb ich ja auch "ab 32G"

Ich habe einen Kunden mit 40GB Terminal Server von den die VM aktiv 32GB benutzt und selbst bei 1Gb vMotion kann man es aushalten.... es dauer nur ein wenig.

In anderen Umgebungen haben wir 10GbE und da ist vMotion dann ein Traum.

Ist die Dauer der Migration bei 10G etwa auch ca. 10x schneller ?


wbdan

[irix]

...
Ist die Dauer der Migration bei 10G etwa auch ca. 10x schneller ?


wbdan

Nein, weil VMware hat da einen Deckel drauf hat und ein einzelnes vMotion nicht so skallieren laesst. Ob sich mit v5 da was getan hat weis ich nicht aber damals zu v4 Zeiten lag der Faktor bei 3-4.

Gruss
Joerg

[Dayworker]

Bei uns kommen auch immer mehr VMs die mit 8 vCPUs und 32 - 64 GB vRAM ausgestattet werden sollen. Ob das immer sinnvoll ist... auf jeden Fall ist der Wunsch da einen möglichst hohen Virtualisierungsgrad zu erreichen.

Speziell die SMP=8 Maschinen dürften ohne adequate Hostausstattung mit einigen Wartezeiten bestraft werden. Mit SMP=4 sind die Maschinen sicherlich um einiges schneller und agieren vor allem spontaner...

[irix]

Bei uns kommen auch immer mehr VMs die mit 8 vCPUs und 32 - 64 GB vRAM ausgestattet werden sollen. Ob das immer sinnvoll ist... auf jeden Fall ist der Wunsch da einen möglichst hohen Virtualisierungsgrad zu erreichen.

Speziell die SMP=8 Maschinen dürften ohne adequate Hostausstattung mit einigen Wartezeiten bestraft werden. Mit SMP=4 sind die Maschinen sicherlich um einiges schneller und agieren vor allem spontaner...

Es lassen sich keine groesseren vCPUs konfigurieren als der Host auch logische CPUs hat. Da man natuerlich noch eine vCPU fuer den Host haben sollte erklaert sich von selbst genau wie das mehr nicht immer schneller ist. Aber das ist ja nun nichts neues

Gruss
Joerg

[Dayworker]

Bei uns kommen auch immer mehr VMs die mit 8 vCPUs und 32 - 64 GB vRAM ausgestattet werden sollen. Ob das immer sinnvoll ist... auf jeden Fall ist der Wunsch da einen möglichst hohen Virtualisierungsgrad zu erreichen.

Speziell die SMP=8 Maschinen dürften ohne adequate Hostausstattung mit einigen Wartezeiten bestraft werden. Mit SMP=4 sind die Maschinen sicherlich um einiges schneller und agieren vor allem spontaner...

Es lassen sich keine groesseren vCPUs konfigurieren als der Host auch logische CPUs hat. Da man natuerlich noch eine vCPU fuer den Host haben sollte erklaert sich von selbst genau wie das mehr nicht immer schneller ist. Aber das ist ja nun nichts neues

Das ist mir klar, aber beim Gedanken an eine hohe Virtualisierungsrate mit SMP=8-VMs rollen sich meine Fußnägel und das willst du echt nicht sehen.

[irix]

..
Das ist mir klar, aber beim Gedanken an eine hohe Virtualisierungsrate mit SMP=8-VMs rollen sich meine Fußnägel und das willst du echt nicht sehen.

Evtl. verwechselt du das mit Konsolidierungsrate. Er, genau wie andere, moechten moeglichst wenig OS auf Blech Installation haben. Das heißt am besten eine 100% Virtualisierungsrate wenn wir Backup mal aussen vorlassen.

Mit ist noch ein Vorteil eingefallen:
- Snapshots vor einspielen von Patchen bzw. Konfigurationsaenderungen

Gruss
Joerg

[stahly]

Interessantes Thema...!

Heute steht eine Migration eines phys. DB-Servers mit 2 Quadcores an. Leider sind die neuen Hosts noch nicht da, so dass ich die Maschine vorerst auf einen 12 Core ESX5 Host schieben muss.

Da dort noch einige andere VMs laufen, ist es wahrscheinlich sinnvoller, dem DB Server "nur" 4 bis 6 vCPUs zuzuordnen??

[Dayworker]

Evtl. verwechselt du das mit Konsolidierungsrate. Er, genau wie andere, moechten moeglichst wenig OS auf Blech Installation haben. Das heißt am besten eine 100% Virtualisierungsrate wenn wir Backup mal aussen vorlassen.

Ich seh zwischen einer hohen Konsolidierungsrate und 100% Virtualisierung keinen Unterschied. Beides läuft daraus hinaus, daß vorher viele Rechner auf einigen wenigen virtualisiert weiterleben und etwaige HW/SW-Ausfälle komplett ihren Schrecken verlieren. Trotzdem halte ich SMP=8-VMs für wenig erstrebenswert.
Ich habe meinen privaten Gerätepark auch weitestgehend virtualisiert. Um aber möglichst viele VMs mit Betonung auf größtmöglicher Schwuppdizität innerhalb der Gäste auf einem kleinen System ans gleichzeitige Laufen zu bekommen, habe ich die grosse Keule geschwungen und die VMs bis auf 2 Ausnahmen auf SMP=1 zurückgestuft. Für ein W2k8-R2 dürfte das unabhängig vom Anwendungsbereich zuwenig sein, aber mit SMP=2 bekommt man auch diesen ans Laufen.
Je nach DB-Art, SQL oder NoSQL und vor allem In-Memory-DBs ala SAP Hana und Oracle TimesTen, dürfte der begrenzende Faktor nicht die SMP-Anzahl sondern eher der verfügbare vRAM sein.

[wbdan]

Interessantes Thema...!

Heute steht eine Migration eines phys. DB-Servers mit 2 Quadcores an. Leider sind die neuen Hosts noch nicht da, so dass ich die Maschine vorerst auf einen 12 Core ESX5 Host schieben muss.

Da dort noch einige andere VMs laufen, ist es wahrscheinlich sinnvoller, dem DB Server "nur" 4 bis 6 vCPUs zuzuordnen??

Es ist halt immer zu bedenken, dass die VM jedesmall einen Timeslot benötigt, in dem auf dem Host (im Zweifel) die Anzahl der in der VM konfigurierten CPUs frei ist.

8 Cores von einem 12 Cores Host zu bekommen der leer ist kein Ding.
Ist da sonnst noch viel Konkurenz, dann sieht es schlecht aus ....

Auf unsrem ältetsten Cluster (reine Konsolidierung DL385 G5p 52 pCPU 178 VMs )
haben wir vorwiegend 1 vCPU VMs. Hier wird es mit 2 vCPU VMs schon schwierig, obwohl ab ESX4 schon besser wurde.

In meiner Anfrage geht es wirklich rein darum die Virtualisierungsrate bis auf ~95% zu bekommen (Evaluierung Failover Szenario mit 2. Standort).
Kosten spielen erst einmal eine untergeordnete Rolle.

Grüsse
wbdan

[Martin]

Ich erlaube hier in unserer Umgebung auch nur 8-vCPU VMs auf den großen Hosts, die mindestens 24 pCores haben.