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
Please also mark the comments that contributed to the solution of the article
Content-ID: 391081
Url: https://administrator.de/contentid/391081
Printed on: November 13, 2024 at 22:11 o'clock
11 Comments
Latest comment
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.
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.
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.