HyperV Cluster mit zwei Nodes

[rusher 0]

Hallo

 

ich hab mal eine Frage bzw Ratschläge wie ihr das machen würdet.

 

Ich hab ein HyperV Cluster mit zwei Nodes die an einen SAS Storage System angeschlossen sind.

Nun läuft aber bald der Support von einen Node ab so dass der eine Node ausgetauscht werden muss.

 

Würde ihr den jetztigen zweiten Node entfernen und dann den neuen Node hinzufügen oder erst den neuen Node hinzufügen und das den alten Node entfernen?

 

Danke schon mal für eure Antworten.

 

Beste Grüße

 

 

[Doso 77]

Support verlängern, wenn möglich.

 

Neuer Node heisst neue CPU, neue CPU heisst die Live Migration wird wohl nicht mehr gehen. Wenn es geht würde ich beide Nodes gleichzeitisch tauschen damit die Dinger die selbe Hardware haben.

 

Wenn nicht möglich, wirst du bei den VMs die CPU Kompatibilität konfigurieren müssen. Ich würde den neuen Node hinzufügen und erst danach den anderen Node entfernen. Sonst hast du während der Umstellung die Hochverfügbarkeit verloren.

[NilsK 2.957]

Moin,

 

solange die CPU dieselbe "Hersteller-Achitektur" hat (kurz: nur Intel oder nur AMD), ist eine neuere CPU kein Problem. Man muss dann nur das Häkchen für die CPU-Kompatibilität bei allen VMs setzen, die evtl. live migriert werden sollen. Dafür muss man die jeweilige VM einmal kurz runterfahren. Kann man auch automatisieren:

 

[Hyper-V-VMs per Skript umkonfigurieren | faq-o-matic.net]
https://www.faq-o-matic.net/2015/07/15/hyper-v-vms-per-skript-umkonfigurieren/

 

Die Reihenfolge für den Austausch ist technisch egal und ein organisatorisches Thema. Sofern drei Nodes an dein Storage passen, würde ich erst den neuen hinzufügen, dann die VMs migrieren und dann den alten entfernen.

 

Gruß, Nils

[zahni 554]

Hi,

 

ich frage nur aus Neugier (keine Diskussion pro/contra): Muss man die alten VMs wirklich neu starten?

Ich habe neulich in unserem Vsphere-Cluster einen neuen Host reingenommen. 

Den Cluster habe ich vorher auf "Sandy-Bridge" (entspricht der Hardware der alten Hosts) konfiguriert.

Ich konnte laufende VM problemlos hin und her verschieben ohne die VMs neu zu starten.

Die CPU-Info im Windows ändert sich dann je nachdem auf welchem Host die VM gestartet wurde.

[Nobbyaushb 1.475]

Moin,

 

da bin ich bei Nils.

 

Wenn möglich (nicht immer geht das mit SAS-Storge..) den neuen Knoten hinzufügen und die VM´s schieben.

 

Bei unserer letzten Aktion hatte keine der VM´s Probleme oder wollte einen Reboot, gleiche Architectur nur schneller und mehr RAM (jetzt 512GB)

 

;)

[rusher 0]

Hallo danke für die schnelle Antwort

 

leider hat das Storage System nur 4 SAS Schnittstellen. Die CPU Kompatibilität musst ich schon vorher aktivieren.

OK dann müsste ich halt doch den alten HyperV Node entfernen und den neuen hinzufügen.

Kann dann der Computername der gleiche sein oder sollte es ein anderer Computername sein?

[NilsK 2.957]

Moin,

 

wenn du den Namen aus dem DNS usw. entfernst, kannst du ihn wiederverwenden. Darin sehe ich allerdings auch keinen Sinn. Wozu würde man einen identischen Hostnamen benötigen?

 

ich frage nur aus Neugier (keine Diskussion pro/contra): Muss man die alten VMs wirklich neu starten?

 

Sofern man die CPU-Kompatibilität umschalten muss, geht das in Hyper-V nur bei abgeschalteter VM. Es gibt dort keine Host-übergreifende Einstellung. Wenn man dies in vSphere nachträglich ändern würde, müsste man dort aber die VMs auch herunterfahren, weil sie sonst ja von der "falschen" CPU ausgehen.

 

Ob das tatsächlich nötig ist, kann man aber auch einfach testen: Live Migration beginnen. Wenn die CPU nicht kompatibel ist, warnt Hyper-V und verweigert den Vorgang. In dem Fall muss man dann eben umschalten.

 

 

Die CPU-Info im Windows ändert sich dann je nachdem auf welchem Host die VM gestartet wurde.

 

Das ist in Hyper-V auch so, denn die VM sieht ja immer die reale CPU.

 

[Was die Prozessorkompatibilität in Hyper-V wirklich tut | faq-o-matic.net]
https://www.faq-o-matic.net/2013/09/23/was-die-prozessorkompatibilitt-in-hyper-v-wirklich-tut/

 

Gruß, Nils

bearbeitet 29. März 2017 von NilsK

[rusher 0]

ok Danke

nur kurz zum Verständnis als kleine Checkliste

1. alten HyperV entfernen vom Cluster

2. neuen HyperV installieren 

3. Netzwerkkarten konfigurieren

4 Failovercluster Rolle installieren

5 MPIO Treiber installieren

6. HyperV zum Cluster hinzufügen

 

Dann müsste es funktionien oder?

[magheinz 110]

In vsphere kann man das auch im laufenden Betrieb setzen. Das gilt dann clusterweit.

HA als auch VMotion müssten funktionieren da man den EVC.Mode ja auf den kleinsten gemeinsamen Nenner setzen muss. Der neue Server wird also sozusagen runtergestuft womit sich für die VMs nichts ändert.

 

Will man einen älteren EVC-Mode einstellen als der Cluster bis dahin hatte, egal ob per konfig oder einfach per vorhandenen CPUs, dann wird ein Fehler geschmissen. Das unterbindet das vspherecenter.

bearbeitet 29. März 2017 von magheinz

[NilsK 2.957]

Moin,

 

im Wesentlichen schon. Ist ja kein besonders aufwändiger Vorgang.

 

Prinzipiell würde ich alles, was auf Host-Ebene anliegt, vor der Installation von Hyper-V und dem Cluster tun, auch wenn das seit Windows 2012 nicht mehr ganz so wild ist. Also:

1. alten HyperV entfernen vom Cluster

2. neuen Host installieren (OS) inkl. Treibern und Updates

3. Netzwerkkarten vorkonfigurieren

4. MPIO Treiber installieren

5. Storage-Verbindung herstellen

6. Hyper-V-Rolle aktivieren

7. Hyper-V-Grundkonfiguration inkl- vSwitch(es) vornehmen

8. Failovercluster-Feature installieren

9. HyperV zum Cluster hinzufügen

 

In vsphere kann man das auch im laufenden Betrieb setzen. Das gilt dann clusterweit.

HA als auch VMotion müssten funktionieren da man den EVC.Mode ja auf den kleinsten gemeinsamen Nenner setzen muss. Der neue Server wird also sozusagen runtergestuft womit sich für die VMs nichts ändert.

 

Will man einen älteren EVC-Mode einstellen als der Cluster bis dahin hatte, egal ob per konfig oder einfach per vorhandenen CPUs, dann wird ein Fehler geschmissen. Das unterbindet das vspherecenter.

 

... was im Wesentlichen ja dieselben technischen Einschränkungen wie unter Hyper-V sind. Eine laufende VM kann nicht den Prozessor runterstufen, das ist der springende Punkt. Der Unterschied ist nur, dass vSphere das auf anderer Ebene setzt. Das hat sowohl Vor- als auch Nachteile.

 

Gruß, Nils

bearbeitet 29. März 2017 von NilsK

[magheinz 110]

muss man das echt alles händisch machen bei hyperv?

Oder gibts da eine "höhere" Edition in der man solche Sachen automatisieren kann wie z.B. mit hostprofiles, distributet virtual switches etc?

[zahni 554]

@Nils,

 

bei VMware müsstest Du die VMs nur herunterfahren, wenn Du einen  Host mit älterer Hardware in einen Cluster mit neuerer Hardware einfügst.

Neuere Hardware in einen Cluster mit älteren Hardware ging ohne Neustart der laufenden VMs. Der laufenden VM wird ja nichts weggenommen.

Hatte auch Sorge das es nicht geht, ging aber...

 

@Magheinz,

 

ich wollte kein Diskussion "Pro/Contra" lostreten. Ich war nur mal neugierig, weil ich Hyper-V nicht benutze.

bearbeitet 29. März 2017 von zahni

[NilsK 2.957]

Moin,

 

nein, die Bordmittel zur Verwaltung sind da leider sehr beschränkt. Das kritisieren wir aus der Community schon seit langem gegenüber Microsoft. Die offizielle Antwort ist: Wer Management braucht, soll den SCVMM nehmen.

 

Allerdings ist das in dem Fall in der Praxis auch kein ernsthaftes Thema. Das muss man ja nicht dauernd machen, sondern nur in dem Fall, wo neue* (oder eben ältere) Host-CPUs hinzukommen, und dann ist es einmalig. Wer da auf der sicheren Seite sein will, setzt das Flag von vornherein und muss sich dann später nicht mehr kümmern - was dem Zustand unter vSphere entspricht. In der Praxis reicht auch die Granularität "ein oder aus" völlig hin, ich habe noch keinen Kunden getroffen, der wirklich einzelne Features nach CPU-Modell ein- oder abschalten musste (was bei vSphere ja auch eher vorgegaukelt ist).

 

Gruß, Nils

 

* um das noch zu ergänzen: Wenn eine neuere CPU hinzukommt, muss man das Flag nicht zwingend setzen. Man muss es nur dann setzen, wenn man VMs von einem "neuen" auf einen "älteren" Host live migrieren können möchte. Daher kann es durchaus auch Sinn ergeben, das nur selektiv pro VM zu setzen und nicht global. Im Fall von HA (Failover nach Host-Ausfall) braucht es den Haken gar nicht, weil dann die VM ja auf der jeweiligen CPU neu bootet.

bearbeitet 29. März 2017 von NilsK

[magheinz 110]

Wenn eine neue CPU dazukommt sollte man den kleinsten gemeinsamen Nenner im cluster als Flag setzen. Ansonsten geht die livemigration auf einen älteren Clusterknoten nicht!

[Doso 77]

Der SCVMM nimmt es leider genauer mit den CPUs, da reicht schon ein anderes Stepping und der verweigert die Live Migration, während Hyper-V Manager/Failovercluster Manager das ohne Probleme tun.