Jump to content

HyperV Cluster mit zwei Nodes


Der letzte Beitrag zu diesem Thema ist mehr als 180 Tage alt. Bitte erstelle einen neuen Beitrag zu Deiner Anfrage!

Empfohlene Beiträge

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

 

 

Link zu diesem Kommentar

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.

Link zu diesem Kommentar

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

Link zu diesem Kommentar

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.

Link zu diesem Kommentar

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 von NilsK
Link zu diesem Kommentar

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 von magheinz
Link zu diesem Kommentar

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 von NilsK
Link zu diesem Kommentar

@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 von zahni
Link zu diesem Kommentar

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 von NilsK
Link zu diesem Kommentar
Der letzte Beitrag zu diesem Thema ist mehr als 180 Tage alt. Bitte erstelle einen neuen Beitrag zu Deiner Anfrage!

Schreibe einen Kommentar

Du kannst jetzt antworten und Dich später registrieren. Falls Du bereits ein Mitglied bist, logge Dich jetzt ein.

Gast
Auf dieses Thema antworten...

×   Du hast formatierten Text eingefügt.   Formatierung jetzt entfernen

  Only 75 emoji are allowed.

×   Dein Link wurde automatisch eingebettet.   Einbetten rückgängig machen und als Link darstellen

×   Dein vorheriger Inhalt wurde wiederhergestellt.   Editor-Fenster leeren

×   Du kannst Bilder nicht direkt einfügen. Lade Bilder hoch oder lade sie von einer URL.

×
×
  • Neu erstellen...