dvbuddy 14 Geschrieben 28. August 2019 Melden Geschrieben 28. August 2019 (bearbeitet) Moin, ich habe zwei 2012r2 Cluster per Replikation auf zwei 2019 Cluster in der gleichen Domäne zu migrieren. Bei dem einen hat die Replikation geklappt, in dem ich für die Rolle des Hyper-V-Replikationsbrokers, vorher ein Computerobjekt angelegt habe. Dieses habe ich für die HV-Hosts mit den Computeraccounts berechtigt und deaktiviert. Danach klappte die Installation der Rolle und ich konnte sie online schalten. Beim zweiten Cluster schlägt das bei der Rollen Installation mit der Fehlermeldung, das das (deaktivierte) Computerobjekt bereits vorhanden ist, fehl. Hat jemand eine Idee? Gruß dvbuddy bearbeitet 28. August 2019 von dvbuddy Zitieren
Nobbyaushb 1.506 Geschrieben 28. August 2019 Melden Geschrieben 28. August 2019 Wer macht denn sowas? Shared-Nothing-Live Migration und gut. Replikation birgt viele Gefahren und ist bei vielen Gästen gar nicht Supportet (Exchange, AD, SQL mit Einschränkungen...) Zitieren
testperson 1.758 Geschrieben 28. August 2019 Melden Geschrieben 28. August 2019 Hi, du möchtest hier deinen 2012R2 Hyper-V Cluster ablösen und auf einen Hyper-V 2019 Cluster updaten? Hier dürfte eine Shared Nothing Livemigration von 2012 R2 auf einen der 2019er Hosts einfacher sein. Allerdings kann ich dir nicht sagen, ob die Shared Nothing Livemigration von 2012R2 auf 2019 direkt geht. Zur Not sollte das dann aber über einen 2016 "Zwischenhost" gehen. Damit du die Shared Nothing Livemigration "im Cluster" nutzen kannst, musst du die VM aus dem Cluster entfernen und dann auf einen neuen Host schieben. Dort angekommen dann einfach rein ins neue Cluster. Am besten mal mit ein, zwei TestVMs durchspielen. ;) Gruß Jan 1 Zitieren
dvbuddy 14 Geschrieben 28. August 2019 Autor Melden Geschrieben 28. August 2019 Moin, ich wußte bisher nicht das das Feature Replikation und ein Failover gefährlich und teilweise nicht Supportet ist. Ich habe das jetzt auf den einen Cluster erfolgreich durchgeführt. Wir haben zwar auch nur kleine Zeitfenster, aber Server herunterfahren, Replikations Failover durführen und Server auf den neuen 2019er Cluster hochfahren, war problemlos, streßfrei und erfolgreich. Wenn ich einen Server herunterfahre und dann über das Replikationsfailover den "Rest" des Replikates repliziere, habe ich doch einen konsistenten Server im neuen Cluster? Oder habe ich da etwas nicht richtig verstanden? Shared Nothig "Live" Migration scheint mir da doch nicht wirklich weniger aufwendig. Was ist denn der Vorteil? danke Gruß Bernd Zitieren
NorbertFe 2.155 Geschrieben 28. August 2019 Melden Geschrieben 28. August 2019 vor 4 Minuten schrieb dvbuddy: Shared Nothig "Live" Migration scheint mir da doch nicht wirklich weniger aufwendig. Ist aber supported in vielen Fällen und verursacht eben keine Downtime. 1 Zitieren
NilsK 2.978 Geschrieben 28. August 2019 Melden Geschrieben 28. August 2019 Moin, vor 33 Minuten schrieb dvbuddy: ich wußte bisher nicht das das Feature Replikation und ein Failover gefährlich und teilweise nicht Supportet ist. naja, "gefährlich" ist jetzt auch sehr hoch gegriffen. Da die Replikation aber immer asynchron ist, hat sie natürlich prinzipielle Nachteile. Und sie greift in die Konsistenz einer Applikation ein, wenn diese hinreichend komplex ist - daher der Supportausschluss für manche Applikationen. Zitat Shared Nothig "Live" Migration scheint mir da doch nicht wirklich weniger aufwendig. Shared-Nothing Live Migration ist die sinnvollste Methode für diese Sorte Migration. Und wirklich aufwändig ist das auch nicht. Vorteile u.a.: Keine Downtime, praktisch kein Risiko ... [Hyper-V von älteren Versionen nach Windows Server 2016 migrieren | faq-o-matic.net]https://www.faq-o-matic.net/2016/12/19/hyper-v-von-lteren-versionen-nach-windows-server-2016-migrieren/ Gruß, Nils 1 Zitieren
Dukel 460 Geschrieben 28. August 2019 Melden Geschrieben 28. August 2019 2 hours ago, NilsK said: naja, "gefährlich" ist jetzt auch sehr hoch gegriffen. Da die Replikation aber immer asynchron ist, hat sie natürlich prinzipielle Nachteile. Und sie greift in die Konsistenz einer Applikation ein, wenn diese hinreichend komplex ist - daher der Supportausschluss für manche Applikationen. Meines Wissens kann man die Replikation auch manuell triggern und ist dann synchron. Nur in einem DR Fall (dafür ist diese Replikation ja gedacht) ist das Asynchron. Aber ich würde auch in jedem Fall die Shared-Nothing-Live Migration vorziehen! Zitieren
dvbuddy 14 Geschrieben 28. August 2019 Autor Melden Geschrieben 28. August 2019 Mir war die Shared-Nothing-Live Migration bis jetzt nicht bekannt... Mach mir grad ne Testmaschine fertig zum Testen. Sieht ja recht simpel aus... Danke Zitieren
NilsK 2.978 Geschrieben 28. August 2019 Melden Geschrieben 28. August 2019 Moin, Nein, es gibt keine synchrone Replikation. Das wäre dann ja eine Spiegelung. Replikation ist immer ein "Point in time". Gruß, Nils Zitieren
Dukel 460 Geschrieben 28. August 2019 Melden Geschrieben 28. August 2019 (bearbeitet) https://docs.microsoft.com/en-us/windows-server/virtualization/hyper-v/manage/set-up-hyper-v-replica Quote Planned failover: To run a planned failover right-click the primary virtual machine and select Replication > Planned Failover. Planned failover performs prerequisites checks to ensure zero data loss. It checks that the primary virtual machine is shut down before beginning the failover. Mir war nicht mehr bewusst, dass bei einem geplanten Failover die Maschine aus sein muss. Edit: 28 minutes ago, NilsK said: Nein, es gibt keine synchrone Replikation. Das wäre dann ja eine Spiegelung. Replikation ist immer ein "Point in time". Ich meinte auch keine Synchrone Replikation, sondern ein manuellen Failover. Nur um die Begrifflichkeiten zu korrigieren. Aber das geht halt nicht ohne Downtime. bearbeitet 28. August 2019 von Dukel Zitieren
Empfohlene Beiträge
Schreibe einen Kommentar
Du kannst jetzt antworten und Dich später registrieren. Falls Du bereits ein Mitglied bist, logge Dich jetzt ein.