11
Flexible VMs ohne teures SAN - Hyper-V Livemigration und Replikation
In kleineren Firmen (z.B. in der Größenordnung <150 Clients) ist die Anschaffung der Komponenten für ein SAN im eigentlichen Sinne (Eigene Storage-Systeme, dediziertes SAN-Netzwerk für die Anbindung) oft zu teuer und steht in keinem Verhältnis zu den realen Anforderungen. Wir haben uns deshalb Gedanken darüber gemacht, wie wir trotzdem einige Vorteile eines SANs kostengünstiger und dadurch verhältnismäßiger umsetzen können. Dies wird über die Hyper-V-Funktionen Livemigration und Replikation in Verbindung mit mindestens zwei Hardware-Servern mit ausreichenden Ressourcen und jeweils einer zusätzlichen 10Gbit-Netzwerkkarte erreicht.
Livemigration: VMs können im laufenden Betrieb von einem Hyper-V-Host auf den anderen verschoben werden. Voraussetzung ist natürlich, dass auf dem Zielserver genügend Ressourcen verfügbar sind. Für Umgebungen mit größeren Datenmengen auf den VMs empfiehlt sich hier die Verwendung eines dedizierten 10Gbit-LAN, da Migrationen sonst sehr lange dauern würden.
Replikation: Eine VM wird auf eine andere Hardware repliziert, d.h. es werden in kurzen Abständen Snapshots der VM gemacht und auf den Replikatserver übertragen. Wenn die primäre Hardware ausfällt, kann die VM auf dem Replikatserver sofort wieder gestartet werden. Voraussetzung ist auch hier, dass auf dem Replikatserver genügend Ressourcen zur Verfügung stehen.
Hardware
Wir haben 2016 drei identische HPE ProLiant DL380 G9-Server angeschafft, die über jeweils 8x 1Gbit-NICs und 2x 10Gbit-NICs verfügen. Jeder der Server ist mit der selben Leistung und Speicherkapazität ausgestattet. Wir haben dazu je 8x 600GB-Platten mit 15000rpm für die produktiven VMs und 8x 600GB-Platten mit 10000rpm (ältere Platten aus dem Bestand) für die Replikate in die Server eingebaut. Die Performance der einzelnen Server ist so ausgelegt, dass im Notfall alle VMs auf zwei physikalischen Maschinen lauffähig sind.
Konfiguration Netzwerk
Konfiguration Hyper-V - Livemigration
In Hyper-V kann unter "Hyper-V Einstellungen > Livemigrationen" festgelegt werden
Hier muss die Netzadresse des 10Gbit Peer-to-Peer-Netzwerkes gesetzt werden, damit die Migration das Produktiv-Netz nicht beeinträchtigt.
VMs können nun über das Kontextmenü "Verschieben..." im laufenden Betrieb auf einen anderen Hyper-V-Host migriert werden.
Der Vorteil ist dabei, dass
Eine detaillierte Anleitung zur Konfiguration und Durchführung der Livemigration ist hier zu finden)
Konfiguration Hyper-V - Replikation
In Hyper-V kann unter "Hyper-V Einstellungen > Replikationskonfiguration" konfiguriert werden
VMs können nun über das Kontextmenü "Replikation aktivieren" auf einen anderen Hyper-V-Host repliziert werden. Die (große) Erstreplikation kann im (Produktiv-)Netz - möglicherweise außerhalb der Stoßzeiten - übertragen werden. Alternativ kann diese auch manuell per Wechseldatenträger gesendet werden.
Anmerkungen
Fragen, Verbesserungen und Anregungen gerne in die Kommentare.
Grüße, JD
Livemigration: VMs können im laufenden Betrieb von einem Hyper-V-Host auf den anderen verschoben werden. Voraussetzung ist natürlich, dass auf dem Zielserver genügend Ressourcen verfügbar sind. Für Umgebungen mit größeren Datenmengen auf den VMs empfiehlt sich hier die Verwendung eines dedizierten 10Gbit-LAN, da Migrationen sonst sehr lange dauern würden.
Replikation: Eine VM wird auf eine andere Hardware repliziert, d.h. es werden in kurzen Abständen Snapshots der VM gemacht und auf den Replikatserver übertragen. Wenn die primäre Hardware ausfällt, kann die VM auf dem Replikatserver sofort wieder gestartet werden. Voraussetzung ist auch hier, dass auf dem Replikatserver genügend Ressourcen zur Verfügung stehen.
Hardware
Wir haben 2016 drei identische HPE ProLiant DL380 G9-Server angeschafft, die über jeweils 8x 1Gbit-NICs und 2x 10Gbit-NICs verfügen. Jeder der Server ist mit der selben Leistung und Speicherkapazität ausgestattet. Wir haben dazu je 8x 600GB-Platten mit 15000rpm für die produktiven VMs und 8x 600GB-Platten mit 10000rpm (ältere Platten aus dem Bestand) für die Replikate in die Server eingebaut. Die Performance der einzelnen Server ist so ausgelegt, dass im Notfall alle VMs auf zwei physikalischen Maschinen lauffähig sind.
Konfiguration Netzwerk
- Auf den physikalischen Servern läuft Windows Server 2012 R2 mit installierter Hyper-V-Rolle.
- Die 10Gbit-NICs sind untereinander jeweils gekreuzte Peer-to-Peer-Verbindungen
- Sieben von acht 1Gbit-NICs sind per LACP-Trunk ans Servernetz angebunden und in Hyper-V einem virtuellen Switch zugeordnet
- Die Übrige NIC ist für die Verwaltung der Hyper-V-Server im Servernetz
Konfiguration Hyper-V - Livemigration
In Hyper-V kann unter "Hyper-V Einstellungen > Livemigrationen" festgelegt werden
- wie viele VMs gleichzeitig live von und auf den Host migriert werden können sollen
- und welche IP-Adressen für die Live-Migration genutzt werden sollen.
Hier muss die Netzadresse des 10Gbit Peer-to-Peer-Netzwerkes gesetzt werden, damit die Migration das Produktiv-Netz nicht beeinträchtigt.
VMs können nun über das Kontextmenü "Verschieben..." im laufenden Betrieb auf einen anderen Hyper-V-Host migriert werden.
Der Vorteil ist dabei, dass
Eine detaillierte Anleitung zur Konfiguration und Durchführung der Livemigration ist hier zu finden)
Konfiguration Hyper-V - Replikation
In Hyper-V kann unter "Hyper-V Einstellungen > Replikationskonfiguration" konfiguriert werden
- von welchen Servern die Replikation zugelassen werden soll
- und wo die Replikate standardmäßig gespeichert werden sollen.
VMs können nun über das Kontextmenü "Replikation aktivieren" auf einen anderen Hyper-V-Host repliziert werden. Die (große) Erstreplikation kann im (Produktiv-)Netz - möglicherweise außerhalb der Stoßzeiten - übertragen werden. Alternativ kann diese auch manuell per Wechseldatenträger gesendet werden.
Anmerkungen
- Durch die Replikation wird natürlich keine Ausfallsicherheit im eigentlichen Sinne erreicht. Es ist jedoch eine Möglichkeit bei einem Hardware-Ausfall ein schnelles Failover durchzuführen, ohne dass man z.B. ein Backup wiederherstellen müsste.
- Wenn z.B. eine Wartung eines Hardware-Servers ansteht, können die auf dem Host befindlichen VMs nacheinander auf die übrigen Hyper-V-Server migriert werden. Ggf. müssen dann jedoch vorübergehend Replikate aus Kapazitätsgründen gelöscht werden. Sobald der Host wieder einsatzbereit ist und die VMs wieder "zurück-migriert", müssen die Replikate neu erstellt werden.
- Eine Livemigration schlägt z.B. dann fehl, wenn auf dem Zielserver nicht genügend Ressourcen verfügbar sind. In unserer Umgebung hat ein Fehler bei der Migration nie zu einem Ausfall oder sonstigen Problemen der laufenden VM geführt.
- Eine Netzwerkanwendung (inkl. Datenbank mit ca. 1TB), die auf einer unserer VMs läuft und sonst sehr empfindlich auf Netzwerkausfälle reagiert, läuft während und nach einer Livemigration ohne Probleme weiter.
Fragen, Verbesserungen und Anregungen gerne in die Kommentare.
Grüße, JD
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 391081
Url: https://administrator.de/contentid/391081
Ausgedruckt am: 22.11.2024 um 07:11 Uhr
11 Kommentare
Neuester Kommentar
Hallo JD,
ich würde da noch etwas anmerken wollen. Die Zielrichtung Deines Beitrags sind ja kleinere Firmen, hierzu gäbe es noch eine andere Möglichkeit, die aber recht verwandt mit Deinem Konzept ist. In diesem Fall würde man einen Festplatten-Storage mit den jeweiligen Hyper-V-Hosts verbinden (bspw. SAS-Band oder ähnliches) und die Hyper-V-Hosts laufen im Failovercluster.
Die Festplatten des Storages werden als Datenträger im Cluster verfügbar gemacht und hierauf die VM's installiert. Fällt nun ein Host aus, übernimmt automatisch im laufenden Betrieb die übrigen Hosts die aktiven VM's die Downtime selbst ist dann nicht vorhanden (bzw. nicht spürbar).
Gerade für kleine Firmen wäre der Vorteil niedrigerer Anschaffungskosten und weniger Konfigurationsaufwand, da nicht zwingend der Replikationscluster aufgesetzt werden muss und der Bestand an Festplatten für die gleiche Kapazität niedriger ist. Auch wirkt sich diese Konfiguration günstig aus, da nicht über das Netzwerk die Festplatten ihren Datenbestand transferieren, sondern einfach über die Controllerbänder an den Storage die Umschaltung erfolgt und so auch riesige Datenmengen jedem Host zur Verfügung stehen.
Nachteile sind aber natürlich, das darf man nicht vergessen, fehlende Redundanz. Fällt der Storage aus, war es das erstmal. Wobei man über einen Backupserver eh den Bestand nochmal sichern sollte und man kann auch recht einfach den Storage einfach ergänzen und somit eine Redundanz bilden, ist dann halt wiederum eine Frage des leider oft knappen Budgets in Firmen.
ich würde da noch etwas anmerken wollen. Die Zielrichtung Deines Beitrags sind ja kleinere Firmen, hierzu gäbe es noch eine andere Möglichkeit, die aber recht verwandt mit Deinem Konzept ist. In diesem Fall würde man einen Festplatten-Storage mit den jeweiligen Hyper-V-Hosts verbinden (bspw. SAS-Band oder ähnliches) und die Hyper-V-Hosts laufen im Failovercluster.
Die Festplatten des Storages werden als Datenträger im Cluster verfügbar gemacht und hierauf die VM's installiert. Fällt nun ein Host aus, übernimmt automatisch im laufenden Betrieb die übrigen Hosts die aktiven VM's die Downtime selbst ist dann nicht vorhanden (bzw. nicht spürbar).
Gerade für kleine Firmen wäre der Vorteil niedrigerer Anschaffungskosten und weniger Konfigurationsaufwand, da nicht zwingend der Replikationscluster aufgesetzt werden muss und der Bestand an Festplatten für die gleiche Kapazität niedriger ist. Auch wirkt sich diese Konfiguration günstig aus, da nicht über das Netzwerk die Festplatten ihren Datenbestand transferieren, sondern einfach über die Controllerbänder an den Storage die Umschaltung erfolgt und so auch riesige Datenmengen jedem Host zur Verfügung stehen.
Nachteile sind aber natürlich, das darf man nicht vergessen, fehlende Redundanz. Fällt der Storage aus, war es das erstmal. Wobei man über einen Backupserver eh den Bestand nochmal sichern sollte und man kann auch recht einfach den Storage einfach ergänzen und somit eine Redundanz bilden, ist dann halt wiederum eine Frage des leider oft knappen Budgets in Firmen.
2
Ein redundantes Storage könnte man mit Starwind vSAN free abbilden. Läuft recht gut.
2
Hallo,
kann mir jemand sagen was passiert wenn ich die Replikation mit zwei hosts eingerichtet habe und dann eine VM per Live Migration verschiebe?
Wird dann automatisch in die andere Richtung repliziert oder lässt sich das so einrichten?
Gruß Michael
kann mir jemand sagen was passiert wenn ich die Replikation mit zwei hosts eingerichtet habe und dann eine VM per Live Migration verschiebe?
Wird dann automatisch in die andere Richtung repliziert oder lässt sich das so einrichten?
Gruß Michael
Zitat von @MichaelW84:
Hallo,
kann mir jemand sagen was passiert wenn ich die Replikation mit zwei hosts eingerichtet habe und dann eine VM per Live Migration verschiebe?
Wird dann automatisch in die andere Richtung repliziert oder lässt sich das so einrichten?
Gruß Michael
Hallo,
kann mir jemand sagen was passiert wenn ich die Replikation mit zwei hosts eingerichtet habe und dann eine VM per Live Migration verschiebe?
Wird dann automatisch in die andere Richtung repliziert oder lässt sich das so einrichten?
Gruß Michael
Grüße,
zwecks Vermeidung eines Denkfehlers, wenn Du zwei Host-Systeme hast und ein Host repliziert den anderen, ist eine Live-Migration der VM nicht notwendig, diese wird ja 1:1 auf dem anderen Host repliziert. Im Fehlerfall schaltet sich der die replizierte VM ein. Kommt der defekte Host wieder zurück wird die Replikation vom neuen auf den alten durchgeführt, bis wieder beide VMs (Original & Replikat) identisch sind. Danach sollte der Schwenk auf die ursprüngliche VM erfolgen.
Oder sprichst Du von einem anderen Setup?
Ja das ist so richtig was du beschreibst. Danke für die schnelle Antwort.
Die vm's müssen meines Wissens nach manuell gestartet werden wenn der primäre host ausfällt. Liege ich da falsch?
Wenn der primäre host zurück ist übernimmt der automatisch wieder die aktive vm und schaltet die andere wieder aus?
(wäre wünschenswert aber gelesen hätte ich mal was anderes.)
Aus Wartungs oder Performance gründen könnte es aber sein das ich eine aktive vm auf den anderen host verschiebe dann wäre aktive vm und Replikat auf dem gleichen host und der zweite Server. Und da bin ich mir nicht im klaren was passiert
Die vm's müssen meines Wissens nach manuell gestartet werden wenn der primäre host ausfällt. Liege ich da falsch?
Wenn der primäre host zurück ist übernimmt der automatisch wieder die aktive vm und schaltet die andere wieder aus?
(wäre wünschenswert aber gelesen hätte ich mal was anderes.)
Aus Wartungs oder Performance gründen könnte es aber sein das ich eine aktive vm auf den anderen host verschiebe dann wäre aktive vm und Replikat auf dem gleichen host und der zweite Server. Und da bin ich mir nicht im klaren was passiert
Also da müsste jetzt jemand kurz sich zu Wort melden der aktiv mit Replikation arbeitet - ich glaube das die VMs ausgeschaltet sein müssen und diese auch manuell eingeschaltet werden. Geht es Dir aber nur um den Ausfall von den Hyper-V-Hosts dann kannst Du das ganze über den Failovercluster automatisieren.
Failovercluster wollte ich aus Lizengründen vermeiden da dort jede vm lizensiert werden muss. Bei der Replikation nur die Maschinen die in den Speicher geladen werden also nicht die Replikate da diese aus sind.
Korrigiert mich jemand bitte, wenn ich was falsches jetzt sag, aber meiner Meinung nach ist der Failovercluster eine normale Rolle in Windows Server und unterliegt nicht einer separaten Lizenzierung.
Die Lizenzierungen fallen generell bei virtuellen Maschinen an je nachdem welches OS Du im Einsatz hast. Haben die Hosts Datacenter im Einsatz, sind die VMs automatisch mit lizenziert. Setzt Du Standard ein sind neben der Original-Instanz nur zwei zusätzliche VMs lizenziert (je Host).
Die Lizenzierungen fallen generell bei virtuellen Maschinen an je nachdem welches OS Du im Einsatz hast. Haben die Hosts Datacenter im Einsatz, sind die VMs automatisch mit lizenziert. Setzt Du Standard ein sind neben der Original-Instanz nur zwei zusätzliche VMs lizenziert (je Host).
Zitat von @Forseti2003:
Korrigiert mich jemand bitte, wenn ich was falsches jetzt sag, aber meiner Meinung nach ist der Failovercluster eine normale Rolle in Windows Server und unterliegt nicht einer separaten Lizenzierung.
Das Failovercluster seblst muss nicht lizensiert werden das ist richtig, allerdings laufen dann alle VM´s aktiv und es müssen alle laufenden VM´s Lizensierrt werden.Korrigiert mich jemand bitte, wenn ich was falsches jetzt sag, aber meiner Meinung nach ist der Failovercluster eine normale Rolle in Windows Server und unterliegt nicht einer separaten Lizenzierung.
Beim Replikat läuft nur die Original VM und das Replikat ist aus und muss dann auch niccht lizensiert werden.
Beispiel:
DC auf Host 1 = on Replikat von DC auf Host 2 off dann benötige ich eine Lizzenz für die VM auf Host 1
DC1 auf Host 1 =on Failover DC 2 auf Host 2 =on dann benötige ich zwei Lizenzen für jede VM eine.
Bei der Anzahl der eingesetten VM´s lohnt sich Datacenter leider nicht.
Das ist klar, aber die VM läuft ja im Failover nicht zweimal - sie wird ja nur im Failover-Fall verschoben. Welche Betriebssysteme setzt Du den für die Hosts ein und über wie viele aktive VMs sprechen wird?
Wir haben 9 vm alle Server 2019, vielleicht verstehe ich das failovercluster auch falsch.
Verschieben kann ich ja nur solange beide hosts laufen.
Bei der Replikation muss ich bei einem Ausfall aktiv die Maschinen auf dem Replikat Server starten, oder gibt es da eine andere Möglichkeit?
Verschieben kann ich ja nur solange beide hosts laufen.
Bei der Replikation muss ich bei einem Ausfall aktiv die Maschinen auf dem Replikat Server starten, oder gibt es da eine andere Möglichkeit?
