Besprechung von Migrationsvarianten Pro + Contra

[roeschu]

Hallo

Eine Migrationsprojekt für einen Kunden für welchen ich am Brainstormen bin:


Umgebung:
*************
-> Standort A mit Vmware Cluster A,Netapp NFS Anbindung, Vsphere 5.5, Bladecenter
-> Standort B mit Netapp NFS Anbindung,Bladecenter
-> Standort A ist momentan produktiv und alles soll zu Standort B gezügelt werden. Standort A wird danach abgebaut
-> Angenommene Leitung zwischen Standort A und B: 10gb Dark Fiber (Latenz noch unbekannt, aber sicher über >10ms), Layer 2 Verbindung (dasselbe interne Subnet)

Rahmenbedingungen zu einer Migration:
***********************************************
-> Stretched Cluster + VMotion nicht möglich für eine Migration (wg. Lizenz) unt RRT > 10ms



Folgende Migrationsvarianten gehen mir durch den Kopf:


Variante 1)
***********
- Snapmirror initial ins neue RZ
- VMs runterfahren
- Snapmirror sync ins neue RZ
- VMs deregistrieren im alten cluster und im neuen registrieren (wenn ein zusätzliches Vcenter im Standort B verwendet wird!)
- VMs in neuen Cluster schieben (Cold Migration) wenn der Cluster in Standort B) im selben VCenter ist welches vorerst noch in Standort A läuft
- Pro: Schnellste Lösung
- Contra: Downtime alle VM's, Alles in einem Rutsch (in einer Nacht/Wochendende)



Variante 2)
***********
-VM's runterfahren
-Cold Migration (in Vsphere Storage und VM Move in neue Datastore/Cluster, wenn Cluster im Standort B im selben Vcenter ist welches in Standort A läuft)
- Pro VM's verteilt migrieren über mehrere Wochen, keine harte Migration
- Contra: Braucht viel Zeit über mehrere Woche verteilt,Downtime VM's



Variante 3)
***********
-Storage Vmotion der VM's (während VM's laufen) machen in NFS Datastore welcher vom Netapp an Standort B an die bisherigen ESX Server von Standort A gemountet ist - - Cold Migration VMs (nur noch VM Move) in neuen Cluster schieben (Cold Migration) wenn der Cluster in Standort B im selben VCenter ist welches vorerst noch in Standort A läuft
- Pro: Kürzeste Downtime pro VM von allen Szenarien,VM's verteilt migrieren über mehrere Wochen, pro Kunde
- Contra: Zeitaufwand



Vsphere Replikation 4)
*********************
-Migration via Vsphere Replication
- Pro:
- Contra: Zwei Vcenter, kenne Möglichkeiten von Vsphere Replication nicht (eignet sich das für solche Migrationen?), Geschwindigkeit Replikation?


Damit (ob) Variante 2 und 3 überhaupt möglich sind stellen sich folgende Fragen:

1) Kann VCenter am alten Standort A einen ESX Cluster vom neuen Standort B managen (oder habe ich da diesselben 10ms Latenzbedingungen wie beim VMotion)

2) Kann man am ESX Server im alten Standort A einen NFS Mount vom Standort B anhängen damit Szenarien 2) und 3) möglich sind (Latenzen?). Anders gefragt ist der Vmotion Latzenztoleranz Wert nur für die ESX wichtig untereinander oder gibt es auch Datastore Latenzen zu beachten?


Habe ich einfachere Varianten übersehen? Was sind eure Erfahrungen + Empfehlungen?

Leider kommt Vsphere 6 mit Long Distance Vmotion in dieser Sache wohl grad 2-3 Monate zu spät...

Grüsse

[irix]

Um wieviele VMs reden wir in Summe und welcher Zeitrahmen steht zur Verfuegung. Wenn es weniger als 200-300 sind dann nehme ich gerne Veeam/vRanger Replizierung weil ich da sehr granular eine VM nach dem anderen machen kann.

Bei kleineren Anzahlen und wenn es wichtig ist das die VMID sich im zentralen vCenter nicht aendern dann haenge ich nach der replizierung die vDisk ab und migrieren dann die "leere" VM und haenge die replizierten vDisks wieder ein.

Gruss
Joerg

[roeschu]

Hallo Joerg

Es geht bei dieser Vsphere 5.5 Umgebung um ca. 240 Vm's (Storage Total ca. 5-6tb; zugewiesen zu VM's nicht besetzt, das meiste Thin Prov). Was ich allerdings mit Absicht ausgelassen habe bei meiner Frage ist der Aspekt das dies Hälftig geteilt ist auf zwei verschiedene Vsphere Umgebungen am jetzigen Standort (beide Vsphere 5.5 aber unabhängig voneinander (kein linked mode), in einem Vsphere allerdings noch ESX 5.1 Server; im anderen alle 5.5 ESX).

Der Migrationszeitraum wird nicht ein Wochenende betragen. Ich nehme an (steht noch nicht fest) das wird über mind 4 Wochen und max. 8 Wochen stufenweise (da sind aber auch noch Migrationen andere Plattformen unabhängig der virtuellen Umgebung drin). Aber ob man jetzt dann die gesamte Virt. Umgebung an einem Wochenden/Nacht macht oder stufenweise VM um VM verteilt über mehrere Wochen hängt von der gewählten Variante ab.

edit: Ich sehe das http://www.veeam.com/de/vm-backup-recov ... tware.html die Vollversion zeitlich beschränkt zur Verfügung stände (1 Monat).
Allerdings bin ich nicht sicher ob man wirklich zur Migration noch ein, bis jetzt, unbekanntes Tool einsetzen soll (Veeam wird nicht eingesetzt dort zurzeit, keine Kenntnisse diesbetreffend)

Grüsse

[bla!zilla]

Ist eine Enterprise Plus Lizenz vorhanden?

[roeschu]

Ist eine Enterprise Plus Lizenz vorhanden?

Es ist eine Entreprise + DVSwitch Lizenz vorhanden. Nicht zu verwechseln mit der "Entreprise plus" Lizenz...

[bla!zilla]

Kannst du mal einen anonymisierten Screenshot von den Lizenzen machen?

[roeschu]

Kannst du mal einen anonymisierten Screenshot von den Lizenzen machen?

Meinst du das:

http://imgur.com/dy17Inr

[bla!zilla]

Eher diese Ansicht:

http://imgur.com/VBW27vx

[roeschu]

http://imgur.com/vgfhUe5

[bla!zilla]

Ah, nun kann ich mir auch eure Lizenzierung erklären.

Bist du sicher das die Latenz nicht < 10ms ist? Darüber ist vMotion Metro notwendig >> Nur Enterprise Plus.

Zu deinen Fragen: Klar kann das vCenter am Standort A Hosts am Standort B managen. Beim Storage sieht es anders aus. Da sind 10ms Latenz schon eine Hausnummer...

Was wäre mit dieser Idee:

- Migrations-Datastore bauen und per NFS an Hosts in Cluster A und Cluster B hängen
- Alle Hosts/ Cluster in ein vCenter bringen (müssen dort in einem Datacenter abgebildet sein)
- Storage vMotion einer VM in den Migrations-Datastore. Shutdown der VM. Migration der VM auf Host in Cluster B (es wird dabei ja nur die Registrierung geändert, Daten bleiben wo sie sind). Einschalten der VM und Storage vMotion in den Ziel-Datastore.

Evtl. kann man sich den Shutdown und die Neuregistrierung der VM sogar sparen. vMotion zwischen Clustern geht ja.

Hängen die Hosts am gleichen dvSwitch?

[PeterDA]

Hi,
ich häng mich hier mal rein.

Ich würde die Variante mit SnapMirror nehmen. Um hier nicht alle VMs in einem Rutsch migrieren zu müssen einfach einen Migration DS anlegen und den dann mit dem VM die migriert werden befüllen. So kann man du steuern welche VMs umgezogen werden.

Gruß Peter

[roeschu]

Ah, nun kann ich mir auch eure Lizenzierung erklären.

Bist du sicher das die Latenz nicht < 10ms ist? Darüber ist vMotion Metro notwendig >> Nur Enterprise Plus.

Nein bin nicht sicher die Leitung besteht noch nicht . Sind wirklich mal Planspiele. Sollte die Latenz unter 10ms sein würde es sich natürlich extrem vereinfachen. Weiss aber nicht was eine Dark Fiber Leitung so für Latenzen mit sich bringen kann im besten Fall, hängt wohl von diversen Faktoren ab.

Zu deinen Fragen: Klar kann das vCenter am Standort A Hosts am Standort B managen. Beim Storage sieht es anders aus. Da sind 10ms Latenz schon eine Hausnummer...

Das ist schon mal gut das dies geht. Da sind nämlich bereits 3 Vcenter im Einsatz (unabhängig von einander,aus Lizengründen). Käme da noch ein viertes für die Migration dazu...puuuh

- Migrations-Datastore bauen und per NFS an Hosts in Cluster A und Cluster B hängen
- Alle Hosts/ Cluster in ein vCenter bringen (müssen dort in einem Datacenter abgebildet sein)
- Storage vMotion einer VM in den Migrations-Datastore. Shutdown der VM. Migration der VM auf Host in Cluster B (es wird dabei ja nur die Registrierung geändert, Daten bleiben wo sie sind). Einschalten der VM und Storage vMotion in den Ziel-Datastore.

Evtl. kann man sich den Shutdown und die Neuregistrierung der VM sogar sparen. vMotion zwischen Clustern geht ja.

Das ist eine gute Idee. Rückfrage: Wieso würdest du den Umweg über einen "Migrations-Datastore" machen? Da könnte ich doch auch gleich die zukünftigen produktiven Datastore von Standort B Cluster an die ESX Servers des Standort A Clusters hängen und würde mir somit die zweite Storage Vmotion aktion sparen; oder verstehe ich da was falsch?

Hängen die Hosts am gleichen dvSwitch?

Ahh scheisse...habe ich vergessen, das muss ich ja auch noch beachten...Die Hosts am Cluster A hängen alle am selben DvSwitch. Die Hosts an Cluster B hätten ihren eigenen DvSwitch. Da würde sie wohl schnell den Netzconnect verlieren (falls deine obige Variante mit Vmotion im laufenden Zustand der VM geht)...wobei das wäre nicht so tragisch

Grüsse

[bla!zilla]

vMotion zwischen unterschiedlichen dvSwitches geht nicht. Die müssen vorher an einem hängen. Das mit dem Migrations-Datastore hätte ich der EInfachheit halber gemacht: Da muss ich nur einen Datastore anhängen und wenn ich den Umzug per PowerCLI automatisiere, dann ist mir die zweite sVmotion egal.

@ PeterDA

Snapmirror ist sicherlich schnellste Variante, aber auch da habe ich das Problem der unterschiedlichen dvSwitches.

[roeschu]

Hi,
ich häng mich hier mal rein.

Ich würde die Variante mit SnapMirror nehmen. Um hier nicht alle VMs in einem Rutsch migrieren zu müssen einfach einen Migration DS anlegen und den dann mit dem VM die migriert werden befüllen. So kann man du steuern welche VMs umgezogen werden.

Gruß Peter

Danke. Ja das wäre noch eine Zwischen Variante auf welche ich nicht gekommen bin bei Variante 1). Also

- je ein Migrationsdatastore an Standort A und B
- VM's welche gezügelt via Storage Vmotion in den Migrationsdatastore moven
- VMs welche gezügelt werden runterfahren und deregistrieren
- Snapmirror syncen
- VMs an Standort B registrieren/rauffahren und via Storage VMotion in den definitiven Datastore verschieben

Grüsse

[roeschu]

vMotion zwischen unterschiedlichen dvSwitches geht nicht. Die müssen vorher an einem hängen. Das mit dem Migrations-Datastore hätte ich der EInfachheit halber gemacht: Da muss ich nur einen Datastore anhängen und wenn ich den Umzug per PowerCLI automatisiere, dann ist mir die zweite sVmotion egal.

@ PeterDA

Snapmirror ist sicherlich schnellste Variante, aber auch da habe ich das Problem der unterschiedlichen dvSwitches.

Bezüglich Snapmirror Geschwindigkeitsvorteilen bin ich auch dieser Meinung. Wenn ich die Snapmirror lösung nehme muss ich allerdings die VM ja sowieso mal runterfahren (damit sie konsistent gesynct wird). D.h da spielt es dann keine Rolle mehr ob ich auch noch die Netzwerkkarte neu einstellen muss.

Ich muss auch hier sagen: Das die Hosts im Cluster A Standort einen DVSwitch haben und die Hosts im Cluster B Standort einen anderen, ist vorerst mal einfach eine Annahme. Wenn ich das natürlich trotzdem alles über denselben dvswitch machen kann (also Cluster A und B hängen am gleichen) dann würde ich das natürlich so machen. Aber ich ueberblicke das im Moment noch grad nicht, sind noch zuviele offene Variablen. Spricht den etwas dagegen beide Cluster am selben dvSwitch zu haben (vorausgesetzt Layer2,gleiche Subnets etc)? Bin absolut nicht der dvSwitch Spezialist...

Auch hier könnte vsphere 6 Abhilfe schaffen mit Migration zwischen dvswitches..

[bla!zilla]

Die Cluster müssen halt in einem vCenter und einem DataCenter sein. Im Prinzip spricht nichts dagegen, mehrere Cluster an einem dvS zu haben.

Wenn Downtime nicht so euer Problem ist, dann könnt ihr natürlich Variante A nehmen. Bei vielen meiner Migrationen ist Downtime immer ein Riesenproblem.

[roeschu]

Die Cluster müssen halt in einem vCenter und einem DataCenter sein. Im Prinzip spricht nichts dagegen, mehrere Cluster an einem dvS zu haben.

Wenn Downtime nicht so euer Problem ist, dann könnt ihr natürlich Variante A nehmen. Bei vielen meiner Migrationen ist Downtime immer ein Riesenproblem.

Downtime ist unschön auch in diesem Fall; aber wenn es nötig wäre gäbe es halt Downtime. Aber klar: einfacher wäre es ohne. Ich bevorzuge, wenn terminlich möglich, jeweils "softe Migrationen" bei welchem man stufenweise nach und nach migriert und nicht in einer Nacht alles. Aber natürlich: hat beides Vor- und Nachteile

Ich denke es wird deine Variante, Peters Variante oder die Variante A) sein schlussendlich. Warte jetzt mal ab wie die Rahmenbedingungen, vorallem Leitung, sein werden.

Besten Danke euch allen für eure Inputs und die klasse Anregungen! Ich schreibe dann hier wenn es klarer ist wie es gemacht wird (oder wenn alles erledigt ist) :=)

Schönes Wochenende

[sirrossi]

Dann könntest Du doch einen vFiler/vServer Umzug durchführen, oder?

Oder einen neuen "Migration vFiler/vServer" anlegen und die jeweiligen umzuziehenden VMs hinein migrieren?

[PeterDA]

@sirrossi
das mit dem Umzug der vServer geht allerdings nur, wenn die Darkfiber genügend power hat und wenn beide System auf CDOT laufen.

Gruß Peter

[sirrossi]

Moin Peter,

wir haben in 2013 Umzüge von mehreren vFilern ohne Unterbrechung auf ONTAP 8.1x im 7-Mode durchgeführt.
Übrigens auf nur 3 x 1 Gbit/s, ingesamt waren es mehr 30 TB Daten (VMs, VDIs, SQL, Exchange, SEV, TSM, ...).

Kommt halt auf die täglichen Änderungsraten an.

[PeterDA]

Okay vFiler kann man auch verschieben ist halt die Frage ob man welche hat.
Das Feature ist ja auch Lizenzpflichtig (wie fast alles bei NetApp....)

Gruß Peter

[roeschu]

Ihr stellt euch das viel zu einfach vor...Netapp an Standort A ist ein 7-mode filer, Netapp an Standort B wird ein CDot Filer sein

[irix]

Wenn es immer einfach waere dann bekommt man Langeweile und es koennte jeder.... also sei froh und beschwer dich nicht.

Gruss
Joerg

[PeterDA]

Hi,
wenn du einen 7-Mode und ein CDOT System hast dann bin ich mir nicht 100% sicher, ob SnapMirror überhaupt geht! Das solltest du mal beim Support checken lassen.

Ich bin mir nicht sicher ob es überhaupt geht oder man eine min. ONTAP Version benötigt.

Gruß Peter

[roeschu]

Snapmirror zwischen 7-mode und Cdot geht inzwischen. Allerdings wird es seitens Netapp explizit nur für Migrationsszenarien supportet.