Sie entwerfen eine Notfallwiederherstellung für eine zweistufige Gehaltsabrechnungsanwendung, die auf lokalen VMware-Hosts ausgeführt wird. Sie planen, Azure Site Recovery (ASR) zu verwenden, um die Datenbank-VM und die Anwendungs-VM in Azure zu replizieren. Anforderungen: Sie müssen in der Lage sein, einen nicht-invasiven DR-Test in Azure durchzuführen, ohne die lokalen Workloads zu beeinträchtigen, und Sie müssen sicherstellen, dass die Datenbank-VM vor der Anwendungs-VM während des Failovers startet. Welche zwei Aktionen sollten Sie im Recovery Services-Tresor implementieren? Wählen Sie zwei aus.

Ein Wiederherstellungsplan ermöglicht es Ihnen, die Startreihenfolge von VMs während eines Failovers zu definieren, was entscheidend ist, um sicherzustellen, dass die Datenbank-VM vor der Anwendungs-VM startet. Sie können auch Skripte oder manuelle Aktionen vor und nach dem Failover hinzufügen, um die Anwendungskonsistenz zu gewährleisten. Ein Test-Failover in einem isolierten virtuellen Azure-Netzwerk ist die empfohlene Methode, um die DR-Lösung nicht-invasiv zu testen, ohne die lokalen Produktions-Workloads zu beeinträchtigen. Die Konfiguration der Netzwerkzuordnung stellt sicher, dass die replizierten VMs im Testnetzwerk korrekt kommunizieren. Die Option "Planned Failover" ist für die Migration oder das geplante Failover gedacht, nicht für einen nicht-invasiven DR-Test. Das Aktivieren der Multi-VM-Konsistenz ist zwar wichtig für die Datenkonsistenz, löst aber nicht die Anforderungen an die Startreihenfolge oder den nicht-invasiven Test. Ein "Unplanned Failover" wird im Katastrophenfall verwendet und ist nicht für Tests gedacht, da es die lokalen Workloads stoppen würde.