vMotion/ Cluster CPU Kompatibilität

[vmx2]

Hallo zusammen,

gegeben: 1 ESXi 5.1 ca. 1 Jahr alt.

Wir wollen einen weiteren Server anschaffen und ich möchte sicherstellen das vMotion bzw. Cluster mit den beiden Server möglich ist.

Hierfür müssen meines Wissens nach "nur" die CPUs miteinander Kompatibel sein.

Wo kann ich dies überprüfen? Ich suche also was wo ich dann z.B. CPU-Typ 1 und dann dann CPU-Typ 2 eingebe und als Ergebnis kommt dann ob es Kompatibel ist oder nicht.

Ist es möglich einen Cluster aus ESXi 5.1 und ESXi 5.5 zu erzeugen? oder muss ich den 5.1er zwingend updaten?

Könnt hier mir da helfen?

Vielen Dank!

[irix]

Ich kenne 2 VMware KB Seiten welche sich mit AMD bzw. Intel beschaeftigen. Allerdings nicht immer der aktuelle Stand.

Du hast uns leider nicht veraten was fuer eine CPU dein erster Host hat und was der zweite Host haben wird. Mit dem passenden EVC Mode ist das normalerweise kein Problem dann.

Ja gemischte Cluster sind supportet und funktionieren auch was HA und vMotion/DRS angeht. Aber wenn der Host erst ein Jahr als ist dann wird er auch fuer 5.5 supportet sein. Du solltest einfach mehr Infos geben.

Gruss
Joerg

[vmx2]

Hallo Joerg!

Also der alte host ist ein ESXi 5.1.0u1 1065491, passt das als Cluster mit 5.5u1 1623387?

CPU des alten Server ist E5-2620(6core)

Der neue Server soll entweder mit dem E5-2620v2 oder E52650v2(8core) ausgestattet werden.

Hier sind die exakten unterscheide der CPUs zu finden:

http://ark.intel.com/de/compare/75269,64594,75789

Danke!

[irix]

Hallo Joerg!

Also der alte host ist ein ESXi 5.1.0u1 1065491, passt das als Cluster mit 5.5u1 1623387?

Ich sagte bereits das gemischte Cluster (vSphere 4 - 5.5) kein Problem darstellen. Bei deinen alten Versionsstaenden trotzdem Patches einspielen (OpenSSL Heartbleat, E1000, NFS) um nur mal die schwerwiegenden Probleme zunennen.

CPU des alten Server ist E5-2620(6core)

Der neue Server soll entweder mit dem E5-2620v2 oder E52650v2(8core) ausgestattet werden.

Hier sind die exakten unterscheide der CPUs zu finden:

http://ark.intel.com/de/compare/75269,64594,75789

Danke!

vSphere hat einen SandyBridge EVC Mode und somit kannst du diesen im lfd. Betrieb fuer deinen alten Host einschalten und der neue tritt dann dem Cluster bei. Nur so zur Info.. aber Intel e26XXv3 steht unmittelbar bevor.

Was fuer Server sind das denn genau? HP, IBM,DELL?

Gruss
Joerg

[vmx2]

Ok vielen Dank! Wird also kein Problem, werde EVC einschalten den und 5.1er updaten.
Es sind Fujitsu Server.

Andere Frage:

Szenario:

Cluster bestehend aus 2 Hosts.

ESX1 ist mit 64 GB RAM ausgestattet und es laufen 4 VMs mit jeweils 10GBvRAM zuweisung.

ESX2 ist mit 32GB augestattet, es laufen keine VMs.

Wenn der ESX1 stirbt, werden dann alle 4 VMs auf dem ESX2 eingeschaltet oder werden nur 3 VMs eingeschaltet weil nicht genug RAM zur Verfügung steht?

Ich stelle mir das so vor, das alle 4 VMs eingeschaltet werden und memory overcommitment eintritt. (Was erstmal nicht schlimm wäre).

[JustMe]

Das haengt zuerst einmal von der verwendeten vSphere-Lizenz ab. Erst ab Essentials Plus ist HA enthalten; die "guenstigere" Essentials (ohne Plus) erlaubt das noch nicht.
Aber wenn vMotion schon geht, dann ist das ein klarer Hinweis auf die Ess-Plus, da auch vMotion nicht im Essentials enthalten waere...

Ansonsten waere die Annahme korrekt, wenn die HA-Failover-Einstellungen korrekt stehen (z.B. wenn alles auf Default Werten gelassen wurde). Sollte stattdessen an der Failover Capacity oder an VM-Speicher-Reservierungen gedreht worden sein, koennte es bereits im normalen Ablauf Probleme geben, alle vier VMs einzuschalten, da das vCenter erkennen wuerde, dass nicht alle Hosts gleich ausgestattet sind.

[vmx2]

Ok verstanden. Ja es ist eine EssPL Lizenz.
Also wenn man die "policy" nicht deaktiviert, dann kann man schon auf dem ESX1 die 4te VM nicht starten.

Was ist wenn man ohne vRAM Resevierungen arbeitet. Also Default werte.

Kann ich die 4te VM auf dem ESX1 starten? Und im Fehlerfall werden auch auf dem ESX2 alle gestartet?

Oder muss ich hier diese Policy deaktivieren?

[irix]

Das Wort vRAM hat einen negativen Beigeschmack weil es vor einiger Zeit, so zu vSphere 5.0 - 5.1 eine Lizenzeinschraenkung darstellte. Ich glaube du meinst etwas anderes.

Natuerlich kannst du die VMs aufteilen und das wuerde man auch immer so machen da bei einem Hostausfall nicht 100% sondern evtl. nur 50% betroffen sind. VMware HA deckt alle Hosts im Cluster ab.

Die meisten Kunden haben Admission Control deaktiviert.

Wenn du mit vRAM eine Resverierung des Speichers fuer die VM meinst dann ist klar warum ein aktives Adminssion Control hier schon den Start verhindert. Lese mal nach was mit einer Slotsize gemeint ist.
http://www.yellow-bricks.com/vmware-hig ... hatisaslot

Gruss
Joerg

[vmx2]

Genau diesen Artikel habe ich gerade gelesen.
Der Fall das Admission Control deaktiviert ist, ist aber für mich noch nicht ganz schlüssig.

Admission Control ist dafür da um zu gewährleisten das genug Ressourcen auf den ESXi-Servern im Cluster vorhanden sind, sodass im Fehlerfall die übrigen Servern die VM des Ausgefallen Hosts übernehmen können.

Wenn dies jedoch deaktiviert ist, keine RAM-Reservierung in den VMs eingestellt ist und ein Server weniger Host-RAM zur Verfügung hat als den von dem ausgefallen Host zu übernehmenden VMs, was passiert dann?

Starten die VMs auf dem zweiten ESXi trotzdem (memory overcommitment) oder
starten nur so viele VMs wie der HOST RAM zur verfügung hat?

Danke für die aufschlussreichen Infos!

[irix]

Genau diesen Artikel habe ich gerade gelesen.

Aber scheinbar noch nicht ganzgenau

Wenn dies jedoch deaktiviert ist, keine RAM-Reservierung in den VMs eingestellt ist und ein Server weniger Host-RAM zur Verfügung hat als den von dem ausgefallen Host zu übernehmenden VMs, was passiert dann?

Starten die VMs auf dem zweiten ESXi trotzdem (memory overcommitment) oder
starten nur so viele VMs wie der HOST RAM zur verfügung hat?

Wenn es deaktiviert ist starten alle VMs neu. Punkt aus.
Der ESXi supportet ja Memory Overcommitment und somit bekommt er auch erstmal alle VMs gestartet.

- Den meisten Kunden ist es im Ernstfall wichtiger das die VMs starten als das sie performant laufen
- (Windows) VMs benoetigen durch die Speicher initialisierung erst einmal bis zu 100% des konfigurierten Speichers. Dann aber zur Laufzeit oftmals viel weniger. Das macht es unmoeglich zusagen ob der Speicher reicht oder nicht. Auch schaltet der Host von Large auf Small Pages um wenn er unter High Memory Pressure steht und das TPS kann erst sehr spaet wirken.
- In der Praxis wuerde man Test und Spiel VMs vom HA ausschliessen so das diese nicht neugestartet werden

Gruss
Joerg

[vmx2]

- Den meisten Kunden ist es im Ernstfall wichtiger das die VMs starten als das sie performant laufen

Ja genau so sehe ich das auch!

So jetzt kommt die letzte Frage, welche einfach zur sicherheit:

Ich erzeuge ein Cluster bestehend aus 2 Servern, jedes von Ihnen hat 2 NFS-Storages angebunden:

Beispiel: 10.10.10.1:/vol/nfsstorage1 und 10.10.10.2:/vol/nfsstorage2

Das HA kann mittels der datastore-heartbeats erkennen welches storage noch da ist.

Wenn VM1 auf dem ESX1 läuft und auf dem nfsstore1 liegt und

VM2 auf dem ESX2 auf nfsstore2 liegt, funktioniert der Failover der VM1 auf den den ESX2 beim Ausfall von ESX1?

Ich weiß nicht ob ich hier was durcheinander bringe mit Storage vMotion, welches ja im Essentials Plus nicht drin ist.

Nochmals vielen Dank für die Beantwortung.

[JustMe]

welches storage noch da ist.

Damit koennte es kompliziert werden...

Sind die beiden nfs-Stores vielleicht VMs auf den jeweiligen Hosts?

Wenn, wie es eigentlich ja sein sollte bei nicht-Spiel-/Bastelloesungen, die beiden Datastores unabhaengig von den ESXi-Hosts laufen, dann gibt es damit kein Problem beim Ausfall eines der beiden Hosts. Der ueberlebende Host sieht beide Datastores, somit alle VMs, und kann die mit dem anderen Host "gestorbenen" VMs einfach darauf neu starten.

Sollte da aber eine Spiegel-Spielerei zwischen virtuellen Datastores der beiden Hosts laufen, kommt's "drauf an"

Spaetestens jetzt koennte es sinnvoll sein, vielleicht ein paar mehr Details der angedachten Loesung im Gesamtschwung zu offenbaren, und nicht immer nur jedes kleine Fitzelchen einzeln.

[vmx2]

Das Storage ist eine echte Netapp mit zwei Köpfen. Jeder Kopf hat ein NFS-Datastore.

Aber meine Frage hast du ja auch beantwortet! Danke!

[irix]

Die 2 von der Netapp exportierten NFS Shares werden auf BEIDEN Hosts gemountet.

- Der Storage Heartbeat ist dazu da das der Master noch erkennen kann ob die Slaves was tun auch wenn das Netzwerk, welches den primaeren HA Heartbeat darstellt, ausgefallen ist
- Mit svMotion hat das alles nichts zutun

Gruss
Joerg

[vmx2]

Vielen Dank für die Ausführungen!