Vijay Sistla
(letzte Session für heute… Der Raum ist trotz der späten Stunde gut gefüllt)
ehrliche Frage: Wer von den Lesern hat für sich und/oder seine Kunden einen echten Desaster Recovery Plan ?
UNter Hyper-V kann ich Hochverfügbarkeit haben – wenn eine Host ausfällt, übernimmt der andere
Hyper-V Replica übernimmt, wenn meine primary site ausfällt
Hyper-V Replica macht asyncrone Replikation von einem zum anderen Host
Replica ist Applikations-agnostic – die App bekommt nichts davon mit
Replica ist Storage-Agnostic – ich brauche auf der Replica-Seite nicht die gleiche Storage-Infrastruktur wie auf der Hauptseite
ich kann mixen wie ich will – von einem clustered Environment in ein non clustered environment
Beispiele:
Ich kann z.b. mein Branch Office als Replikationsort verwenden – und den Workload des Branch Offices in die Zentrale replizieren..
Ich kann mit einem Hoster replizieren – dort brauche ich nur für den Storage zahlen
Demo
Am Cluster muss ich den Broker enablen
Replication muss am Replicaserver enabled sein – ich kann http oder https verwenden für Replikation – HTTP verwende ich wenn ich Kerberos verwenden kann (innerhalb trusted umgebungen)
Und ich erlaube am Replicaserver, welche Server zu mir replizieren dürfen
Am Primary enable ich die Replikation pro VM
ich gebe den FQDN des Replikaserver ein und gebe an, welche VHDs ich replizieren möchte…
ich kann auch angeben, dass ich z.b. 4 Recoverypoints aufheben möchte (bis zu 15)
dann kann ich angeben, dass ich VSS nutzen möchte – von 1 Stunde bis zu 12 Stunden – dann kann ich im Fehlerfall auch auf ältere Replikas zugreifen
Asyncronous Replication
Sync geht auf HTTP – d.h. geht im LAN und im WAN
1. Check: Existiert die VM am Zielserver ?
2. Sende die VM zum Zielhost
3. dann machen wir ein Logfile mit allen Änderungen der VM – ein Logfile pro VHD
4. alle 5 Min senden wir das Logfile zum Zielserver und applien dort die Logs
Wie gehen wir mit Fehlern um ?
wenn Netzwerk ausfällt, probieren wir es wieder, wenn Netzwerk da ist und senden nur das, was fehlt
Was passiert, wenn ich die VM move ?
im Cluster oder ShareNothing ?
da ändert sich nichts 
Funkt trotzdem…
aber – alle primary server müssen authorisiert sein
bei Clustern kann ich den ganzen Cluster Broker name authorisieren
Bei planned Failover
habe ich keinen Datenverlust, aber eine Downtime
Will ich das machen, stoppe ich die VMs in der primary Site und starte sie auf der Replicasite
Wenn ich das mache, kann ich auch Reverse Replikation machen, damit ich dann wieder zurückswitchen kann
was passiert mit der Netzwerkkonfig ?
Ich muss auf der Replikaseite sicherstellen, dass die VM mit dem Netzwerk verbunden ist, das ich will
was passiert, wenn die VM in einem unterschiedlichen subnet starten soll ?
Mit DHCP – einfach …
Hyper-V kann mir auch helfen, eine statische IP Adresse in die VM zu injecten
oder ich nutze Netzwerk-Virtualisierung… damit ändert sich nichts…
Test Failover
beim Testfailover habe ich keine Downtime
ich kann trotzdem drüben die Replikation testen
mit allen Recoverypoints…
Beim Testfailover sollten die VMs aber in einem Failover-Netzwerk hochkommen…
während des Test läuft meine Echtumgebung weiter und auch die Replikation…
In den Properties der replizierten VM kann ich unter Netzwerk 2 Dinge einstellen:
welche IP Adresse soll die VM im Failoverfall bekommen
welchen Netzwerk-Switch soll die VM im Testfall bekommen
Demos sind nett, aber wie schaut mit der Netzwerkbandbreite aus ?
Was ist die Datenänderung bei deiner VM ? – das ergibt die notwendige Bandbreite
Wir arbeiten an einem Tool, das helfen soll, die Bandbreite abzuschätzen…
ich sollte auch Windows 2012 QoS am Netzwerk verwenden
Achtung: Replika ist KEIN Replacement für Backup
backu und Replikationen werden paralell behandelt
Wenn ich eine VM zurücksichere, wird sie neu gesynct
Kann ich die Replika-VMs für Backup verwenden ?
nein, sollte ich nciht – ist nicht app-konsisten und während dem Backup steht die Replikation
Was ist der Impact am Server ?
IOPs ? ca. 1,5 x write Iops
Größe: Genau die Größe der Änderungen
und am Replikaserver ?
0,6 x write Iops to receive
Memory Impact: 50 mb / vhd, CPU impact < 3 %
Christian – live aus Amsterdam
Subscribe