Am 14. September 2017 haben wir eine überarbeitete Fassung unserer Datenschutzrichtlinie veröffentlicht. Wenn Sie video2brain.com weiterhin nutzen, erklären Sie sich mit diesem überarbeiteten Dokument einverstanden. Bitte lesen Sie es deshalb sorgfältig durch.

Microsoft Azure: Azure Backup

Replikation mit Azure Site Recovery

LinkedIn Learning kostenlos und unverbindlich testen!

Jetzt testen Alle Abonnements anzeigen
Mit Azure Site Recovery können Sie mehrere virtuelle Maschinen direkt über den Hypervisor in die "Public Cloud" oder die "Private Cloud" replizieren, um "Disaster Recovery"-Szenarien umzusetzen.
12:46

Transkript

Azure Site Recovery ist Replikation auf der Ebene eines Hypervisors. Wie das funktioniert, möchte ich Ihnen in diesem Video zeigen. Dreh- und Angelpunkt für dieses Szenario ist wieder mal ein Recovery Services-Tresor. Dort haben wir immer den Eintrag für "Site Recovery" unter den ersten Schritten. Und wir können hier sehen, dass sich der Aufbau eines Site Recovery-Szenarios grundsätzlich über drei Schritte beläuft. Im ersten Schritt bereiten wir die Infrastruktur vor. Das bedeutet, als Erstes definieren wir ein Schutzziel, das heißt, wohin möchten wir das, was in dem Hypervisor drin ist an virtuellen Maschinen bzw. wiederum Applikationen denn replizieren? Entweder nach Azure oder zu einem Wiederherstellungsstandort. Das könnte eine Private Cloud sein. In dem Fall sagen wir, wir möchten gerne nach Azure replizieren. Wie sind denn Ihre Computer virtualisiert? Entweder per Hyper-V bzw per VMware oder nicht virtualisiert. Die Auswahl, die wir hier treffen, leitet im Grunde weiter auf einen entsprechenden Agenten, den wir auf dem Hypervisor installieren müssen. Ich habe ein kleines HyperV-Szenario vorbereitet. Dazu möchte ich kurz etwas sagen. Und zwar handelt es sich hier ebenfalls um eine Azure-VM, die wiederum als HyperV-Server fungiert. Wenn Sie sich mit Azure-VMs schon etwas näher auseinandergesetzt haben, dann haben Sie sicherlich schon gelesen, dass Azure-VMs grundsätzlich über einen Plattform-Azure- Service-Mechanismus über Hyper-V betrieben werden. Das heißt, wir haben hier einen Hypervisor verschachtelt in einem Hypervisor. Das ist nicht supportet. Dennoch möchte ich Ihnen jetzt gerne die Funktionsweise von Azure Site Recovery demonstrieren. Wieder zurück im Azure-Portal können wir nun somit den Schritt eins, das Schutzziel, abschließen. Jetzt werden wir weitergeleitet auf das nächste Blade. Und wir werden aufgefordert, einen Hyper-V-Standort anzugeben. Diesen nennen wir: "v2b-site1". Nun wird der Standort erstellt. Das sollte aber nach wenigen Sekunden erledigt sein. Und da sind wir, der Standort ist registriert. Jetzt fügen wir den Hyper-V-Server hinzu. Hier werden wir vom Assistenten noch einmal aufgefordert, dass lediglich Windows Server 2012 R2-Server für den Host supportet sind. Die Proxy-Einstellungen sollen so konfiguriert sein, dass wir einen freien Netzzugang haben. Und man soll doch bitte einen Agent herunterladen, natürlich. Denn ohne Agent kann natürlich der Durchstich in die Cloud nicht funktionieren. Derweil habe ich die Sourcen auf unseren Hyper-V-Server kopiert und jetzt können wir mit der Installation beginnen. Die Installations-Location ist in diesem Fall trivial und dementsprechend können wir jetzt die Installation starten. Das, was hier gemacht wird, ist im Grunde die Installation eines Agents, der wiederum eine verschlüsselte Tunnelverbindung in die Microsoft-Cloud erstellt. Jetzt ist der Agent im Grunde genommen schon installiert, mit Firewall-Exceptions und allem, was dazugehört. Was jetzt noch fehlt, ist -- Sie ahnen es schon --, die Registrierung bei unserem Tresor. Zurück im Azure-Portal nehmen wir also nun diesen Schritt vor. Das heißt, wir laden unsere Vault-Credetials herunter. Auch diese habe ich jetzt auf den Hyper-V-Server kopiert, sodass wir diese nun über einen einfachen Dialog einfügen können. Sämtliche Parameter wie die "Subscription", der "Vault Name" und der "Hyper-V Site Name", den wir vorhin registriert haben, sind bereits angegeben; einen Proxyserver haben wir in diesem Szenario nicht, dementsprechend können wir hier mit der Standardeinstellung arbeiten. Nun ist der Wizard durchgelaufen, das heißt, unser Hyper-V-Server wurde erfolgreich am Azure Site Recovery Vault registriert. Zurück im Azure-Portal müssen wir jetzt einen Moment Geduld haben. Wie hier in dieser Meldung schon angekündigt wird. Aktuell ist der Hyper-V-Server noch nicht gefunden worden. Das kann aber durchaus 15 bis 30 Minuten dauern. Dementsprechend machen wir jetzt einen kleinen Zeitsprung. In der Zwischenzeit können wir noch einen Blick in die Services-Konsole von unserem Hyper-V-Host werfen. Wir sehen hier in dem Fall drei laufende Services, die in dem Fall für das Azure Site Recovery zuständig sind. Wenn Sie darüber hinaus den Wunsch verspüren, an der Konfiguration noch einmal eine Änderung vorzunehmen, gibt es dazu natürlich auch die Möglichkeit, in dem Fall über das Startmenü über das "Azure Site Recovery Configurator"-Tool. Jetzt gehen wir in das Azure-Portal zurück und sorgen für eine Aktualisierung. Jetzt werden wir zwar gewarnt, dass wir einen Informationsstand verlieren könnten, aber das Risiko können wir eingehen. Denn mittlerweile hat sich, wie wir sehen können, die Verbindung zwischen dem Azure-Portal über den Agent zu unserem Hyper-V-Host aufgebaut. Jetzt können wir fortfahren und klicken auf "OK" und gehen weiter zum dirtten Schritt. Jetzt haben Sie hier noch die Möglichkeit, eine Subscription aussuchen. Wenn Sie mehrere haben, gibt es diese Option; ich habe in diesem Fall nur eine. Wir werden gefragt: Möchten wir im Ressource-Manager bleiben als Bereitstellungsmodell? Oder möchten wir in den Classic-Mode zurück? In diesem Videotraining fokussieren wir uns auf den Ressource-Manager. Jetzt werden wir aufgefordert, eine Replikationsrichtlinie zu definieren. Das heißt, wann und wie oft soll eigentlich repliziert werden. Zu diesem Zweck nenne ich diese Richtlinie "default" und belasse die Parameter am Standard, weil mir das für dieses Szenario ganz sinnvoll erscheint. Nun wird die Replikationsrichtlinie erstellt, das sollte nicht lange dauern und dann sind wir auch fast fertig. Auch dieser Schritt ist nun abgeschlossen. Und jetzt können wir mit einem Klick auf "OK" in die Kapazitätsplanung wechseln. Wenn Sie vorhaben, Azure Site Recovery für ein produktives Szenario zu verwenden, ist es durchaus sinnvoll, sich den Capacity Planner herunterzuladen, um etwas über die sinnvolle Netzwerkbandbreite, Speicher etc. zu erfahren. In diesem Fall machen wir das später. Jetzt haben wir alle fünf Schritte erbracht, um die Infrastruktur als ersten Gesamtschritt vorzubereiten und wir klicken "OK". Und können nun als Nächstes weitermachen im zweiten Schritt für die Replikation der Anwendung. Dann nehmen wir uns nun den zweiten Schritt von insgesamt drei Schritten vor. Und keine Sorge, der wird nicht ganz so viel Zeit in Anspruch nehmen wie der letzte Schritt. Erst einmal wählen wir unsere Quelle aus, das ist unsere "v2b-site1". Im Ziel-Blade können wir einiges am Standard lassen. Alles, was wir tun müssen, ist, ein Speicherkonto auszuwählen. Wir erinnern uns, das hier ist eine Demonstration, dementsprechend müssen wir jetzt nicht so hart konfigurieren, dass das hier für alle Zeiten in Stein gemeißelt ist, sondern wir gucken auf die weiteren Einstellungen. Wir müssen noch ein Netzwerk angeben, welches nach dem Failover verwendet werden soll. Und wir tragen noch ein Subnet ein. In diesem Fall nehmen wir dieses hier und dann ist auch das Ziel konfiguriert. Jetzt machen wir weiter mit der Auswahl der virtuellen Computer. Jetzt sehen wir eine Übersicht der virtuellen Maschinen, die wir in die Replikation mitnehmen können. Wenn wir noch einmal einen Vergleich mit dem Hyper-V-Host antreten, sehen wir hier eine VM namens "New Virtual Machine" und genau diese VM haben wir jetzt hier in der Übersicht, da der Agent auf den Hypervisor zugreift und somit sehen kann, welche virtuellen Maschinen vorhanden sind. Als Nächstes müssen wir jetzt für diese VM, die wir ausgewählt haben, noch ein paar Eigenschaften definieren. Das ist aber ganz einfach. Wir weisen das Betriebssystem zu, in dem Fall Windows. Der Betriebssystemdatenträger heißt "New Virtual Machine". Und beim Zielnamen stößt der Assistent sich noch an den Leerzeichen; die entfernen wir kurzerhand. Und dann ist alles auf grün und wir können weiter. Im Blade für die Replikationsrichtlinie bekommen wir jetzt noch mal die ursprüngliche Replikationsrichtlinie zu Gesicht, die wir uns vorhin selber konfiguriert haben. Mich interessiert jetzt in dem Szenario, dass die Startzeit auf "Sofort" eingestellt ist, damit wir zum nächstmöglichen Zeitpunkt ein Ergebnis sehen können. Und jetzt können wir die Replikation endlich aktivieren. Das hat jetzt nochmal gut zwei Minuten lang gedauert, bis der Schutz tatsächlich aktiviert worden ist. Jetzt können wir uns im System mal umsehen. Und zwar haben wir jetzt hier unten die replizierten Elemente innerhalb von unserem Vault. Und wir sehen, unsere "New Virtual Machine" ist hier registriert. Der Grund, weshalb der Status für diese Virtual Machine jetzt schon auf "Geschützt" steht, ist schlicht und ergreifend, dass es sich hier bei dieser VM um eine leere Hülse handelt. Das habe ich extra so gemacht, um diesen Ablauf etwas zu beschleunigen. Wenn das eine wirkliche virtuelle Maschine gewesen wäre mit virtueller Festplatte hinten dran, mit Betriebssystem et cetera, hätte das durchaus Stunden dauern können, bis dies in die Cloud hochgeladen worden ist. Dann schauen wir uns zum Schluss noch ein paar Metadaten zu dieser Replikation an. Der Health-Status bzw. auf Deutsch die Integrität sieht gut aus. Und wir haben natürlich noch die gewohnten Metainformationen, in welchem Recovery Services-Tresor liegt diese Replikation, welche Richtlinie ist verwendet worden usw. Natürlich können wir hier noch durchgehen, bis hin zu den Eigenschaften, wo wir alle relevanten Metainformationen zu dieser VM-Replikation nachvollziehen können. Jetzt können wir uns anschauen, wozu dieser ganze Aufwand eigentlich gut ist. Und zwar können wir jetzt hier geplante und ungeplante Failover durchführen. Unter einem Failover können wir uns beispielsweise Folgendes vorstellen. Nehmen wir an, wir haben in diesem Hyper-V-Manager oder auch in Ihrem vSphere, das würde ja auch gehen, eine ganze SharePoint-Farm am Laufen, beispielsweise bestehend aus zwei Applikations-Servern, zwei Web-Front-End-Servern, einem Datenbank-Server. Und diese Farm möchten Sie patchen. In genau solchen Situationen können Sie Azure Site Recovery nutzen, um das Patching durchführen zu können, ohne dass eine Downtime entsteht. In diesem Video haben wir also gesehen, wie wir den Inhalt eines Hypervisors erfolgreich replizieren.

Microsoft Azure: Azure Backup

Sichern Sie Ihre Daten einfach und zuverlässig mit dem Clouddienst Microsoft Azure Backup.

1 Std. 55 min (23 Videos)
Derzeit sind keine Feedbacks vorhanden...
 
Hersteller:
Software:
Exklusiv für Abo-Kunden
Erscheinungsdatum:02.12.2016

Dieser Online-Kurs ist als Download und als Streaming-Video verfügbar. Die gute Nachricht: Sie müssen sich nicht entscheiden - sobald Sie das Training erwerben, erhalten Sie Zugang zu beiden Optionen!

Der Download ermöglicht Ihnen die Offline-Nutzung des Trainings und bietet die Vorteile einer benutzerfreundlichen Abspielumgebung. Wenn Sie an verschiedenen Computern arbeiten, oder nicht den ganzen Kurs auf einmal herunterladen möchten, loggen Sie sich auf dieser Seite ein, um alle Videos des Trainings als Streaming-Video anzusehen.

Wir hoffen, dass Sie viel Freude und Erfolg mit diesem Video-Training haben werden. Falls Sie irgendwelche Fragen haben, zögern Sie nicht uns zu kontaktieren!