Ogólne pytania dotyczące usługi Azure Site Recovery

Usługa Site Recovery przyczynia się do strategii ciągłości działania i odzyskiwania po awarii (BCDR), organizując i automatyzując replikację maszyn wirtualnych platformy Azure między regionami, lokalnymi maszynami wirtualnymi i serwerami fizycznymi na platformie Azure oraz maszynami lokalnymi do dodatkowego centrum danych. Dowiedz się więcej.

Nie, usługa Azure Site Recovery nie obsługuje obciążeń platformy Docker działających na maszynach wirtualnych. Aby chronić te maszyny wirtualne za pomocą usługi Site Recovery, wyklucz dyski, na których zainstalowano platformę Docker.

Istnieją różne środki podjęte przez usługę Site Recovery w celu zapewnienia integralności danych. Bezpieczne połączenie jest ustanawiane między wszystkimi usługami przy użyciu protokołu HTTPS. Dzięki temu żadne złośliwe oprogramowanie lub jednostki zewnętrzne nie mogą manipulować danymi. Inną podjętą miarą jest użycie sum kontrolnych. Transfer danych między źródłem a obiektem docelowym jest wykonywany przez obliczanie sum kontrolnych danych między nimi. Zapewnia to spójność przesyłanych danych.

Platforma Azure nie obsługuje trwałych adresów MAC i dlatego nie można używać oprogramowania z modelami licencji opartymi na komputerach MAC zarówno do migracji na platformę Azure, jak i odzyskiwania po awarii.

Nie, usługa Azure Site Recovery obecnie nie obsługuje dysków efemerycznych.

Agent usług Microsoft Azure Recovery Services służy do konfigurowania/rejestrowania w usługach Site Recovery oraz do monitorowania kondycji wszystkich składników. Ten składnik jest jednym z podstawowych bloków konstrukcyjnych całej infrastruktury lokalnej usługi Azure Site Recovery. Ułatwia ona replikowanie obciążeń do innego regionu świadczenia usługi Azure z lokacji lokalnej i przechodzenie w tryb failover na platformę Azure w przypadku awarii.

Tak. Usługa Site Recovery obsługuje modele oparte na infrastrukturze dedykowanej i współdzielonej.

L.p. Tożsamość dzierżawy pozostaje anonimowa. Twoje dzierżawy nie wymagają dostępu do portalu usługi Site Recovery. Tylko administrator dostawcy usług wykonuje czynności w portalu.

Podczas replikacji na platformę Azure dane aplikacji są wysyłane do usługi Azure Storage, ale nie do usługi Site Recovery. Dane są szyfrowane podczas przesyłania (HTTPS) i pozostają zaszyfrowane na platformie Azure.

L.p. Relacja rozliczeniowa platformy Azure jest nawiązana bezpośrednio z dostawcą usług. Dostawcy usług są odpowiedzialni za generowanie konkretnych rachunków dla swoich dzierżaw.

Nie, dane są replikowane do usługi Azure Storage w ramach subskrypcji. Podczas testowania pracy w trybie failover (próbne odzyskiwanie po awarii) lub rzeczywistego przejścia w tryb failover usługa Site Recovery automatycznie tworzy maszyny wirtualne w ramach subskrypcji.

Tak.

Obsługujemy wdrożenia oparte na pakietach Azure Pack, Cloud Platform System i System Center (2012 i nowszych). Dowiedz się więcej o integracji z pakietem Azure Pack i usługą Site Recovery.

Nie. Maszyny wirtualne funkcji Hyper-V można replikować tylko na platformę Azure.

Przejrzyj szczegóły cennika usługi Site Recovery.

Skorzystaj z kalkulatora cen, aby oszacować koszty korzystania z usługi Site Recovery.

Aby uzyskać szczegółowe oszacowanie kosztów, uruchom narzędzie planisty wdrożenia dla oprogramowania VMware lub funkcji Hyper-V i użyj raportu szacowania kosztów.

Tak, podczas replikowania maszyn wirtualnych przy użyciu usługi Site Recovery są naliczane dodatkowe opłaty za użycie konta magazynu pamięci podręcznej. Koszty konta magazynu pamięci podręcznej pozostają takie same, gdy magazyn repliki jest typu dyski zarządzane lub dyski niezarządzane.

Tak. Każde wystąpienie chronione w usłudze Azure Site Recovery działa bez opłat przez pierwsze 31 dni. Na przykład w przypadku ochrony 10 wystąpień z ostatnich sześciu miesięcy i połączenia 11 wystąpienia z usługą Azure Site Recovery nie są naliczane żadne opłaty za 11 wystąpienie w ciągu pierwszych 31 dni. Za pierwsze 10 wystąpień nadal będą naliczane opłaty w usłudze Azure Site Recovery, ponieważ są one chronione od ponad 31 dni.

Tak. Mimo że usługa Site Recovery jest bezpłatna w ciągu pierwszych 31 dni działania wystąpienia chronionego, mogą zostać naliczone opłaty za usługę Azure Storage, transakcje magazynu i transfer danych. Odzyskana maszyna wirtualna może również spowodować naliczenie opłat za operacje obliczeniowe platformy Azure.

Nie ma żadnych oddzielnych kosztów dla próbnego odzyskiwania po awarii. Po utworzeniu maszyny wirtualnej po zakończeniu testu pracy w trybie failover są naliczane opłaty za obliczenia.

Nie, usługa Site Recovery nie przechwytuje replikowanych danych i nie zawiera żadnych informacji o tym, co działa na maszynach wirtualnych lub serwerach fizycznych. Dane replikacji są wymieniane między lokalnymi hostami funkcji Hyper-V, funkcjami hypervisor VMware lub serwerami fizycznymi i usługą Azure Storage lub lokacją dodatkową. Usługa Site Recovery nie ma możliwości przechwycenia tych danych. Do usługi Site Recovery są wysyłane jedynie metadane wymagane do organizowania replikacji i trybu failover.

Usługa Site Recovery ma certyfikat ISO 27001:2013, 27018, HIPAA, DPA i jest w trakcie ocen SOC2 i FedRAMP JAB.

Tak. Podczas tworzenia magazynu usługi Site Recovery w regionie upewniamy się, że wszystkie metadane, które musimy włączyć i zorganizować replikację i tryb failover, pozostają w granicach geograficznych tego regionu.

W przypadku maszyn wirtualnych i serwerów fizycznych replikowanych na platformę Azure obsługiwane są zarówno szyfrowanie podczas przesyłania, jak i szyfrowanie magazynowane (na platformie Azure).

Tak, protokół TLS 1.2 jest domyślnie wymuszany dla scenariusza azure-to-Azure Site Recovery.

Agenci mobilności zainstalowani na replikowanych elementach komunikują się z serwerem przetwarzania tylko w protokole TLS 1.2. Jednak komunikacja z serwera konfiguracji do platformy Azure i z serwera przetwarzania na platformę Azure może znajdować się w protokole TLS 1.1 lub 1.0. Postępuj zgodnie ze wskazówkami, aby wymusić protokół TLS 1.2 na wszystkich serwerach konfiguracji i serwerach przetwarzania skonfigurowanych przez Ciebie.

Cała komunikacja między mikrousługami usługi Azure Site Recovery odbywa się w protokole TLS 1.2. Usługa Site Recovery używa dostawców zabezpieczeń skonfigurowanych w systemie (OS) i używa najnowszego dostępnego protokołu TLS. Należy jawnie włączyć protokół TLS 1.2 w rejestrze, a następnie usługa Site Recovery rozpocznie korzystanie z protokołu TLS 1.2 na potrzeby komunikacji z usługami.

Tożsamość zarządzana magazynu usługi Recovery Services można włączyć, przechodząc do ustawienia Tożsamość . Po zarejestrowaniu magazynu w usłudze Microsoft Entra ID możesz przejść do kont magazynu i przekazać następujące przypisania ról do magazynu:

• Konta magazynu oparte na usłudze Resource Manager (typ standardowy):
  • Współautor
  • Współautor danych w usłudze Blob Storage
• Konta magazynu oparte na usłudze Resource Manager (typ Premium):
  • Współautor
  • Właściciel danych obiektu blob usługi Storage
• Klasyczne konta magazynu:
  • Współautor klasycznego konta magazynu
  • Rola usługi klasycznego operatora klucza konta magazynu

Usługa Azure Site Recovery nie śledzi zmian źródłowej maszyny wirtualnej poza źródłowym systemem operacyjnym. Jeśli na przykład używasz platformy Azure do replikacji platformy Azure i zmieniasz rozmiar źródłowej maszyny wirtualnej, zmiana rozmiaru źródłowej maszyny wirtualnej nie jest replikowana do docelowej maszyny wirtualnej.

• Maszyny wirtualne platformy Azure: usługa Site Recovery może replikować dowolne obciążenie uruchomione na obsługiwanej maszynie wirtualnej platformy Azure.
• Maszyny wirtualne funkcji Hyper-V: usługa Site Recovery może chronić dowolne obciążenie uruchomione na maszynie wirtualnej funkcji Hyper-V.
• Serwery fizyczne: usługa Site Recovery może chronić serwery fizyczne z systemem Windows lub Linux.
• Maszyny wirtualne VMware: usługa Site Recovery może chronić dowolne obciążenie uruchomione na maszynie wirtualnej VMware.

Usługa Site Recovery umożliwia ochronę większości obciążeń uruchomionych na obsługiwanej maszynie wirtualnej lub serwerze fizycznym. Usługa Site Recovery zapewnia obsługę replikacji z obsługą aplikacji, dzięki czemu aplikacje można odzyskać do stanu inteligentnego. Integruje się z aplikacjami firmy Microsoft, takimi jak SharePoint, Exchange, Dynamics, SQL Server i Active Directory, oraz ściśle współpracuje z wiodącymi dostawcami, w tym Oracle, SAP, IBM i Red Hat. Dowiedz się więcej o ochronie obciążeń.

Tak. Gdy używasz usługi Site Recovery do organizowania replikacji i trybu failover w biurach oddziałów, uzyskasz ujednoliconą aranżację i widok wszystkich obciążeń biura oddziału w centralnej lokalizacji. Możesz z łatwością uruchomić tryb failover i zarządzać odzyskiwaniem po awarii wszystkich oddziałów z siedziby, bez konieczności odwiedzania oddziałów.

Tak, usługa Site Recovery obsługuje awarie maszyn wirtualnych platformy Azure między regionami świadczenia usługi Azure. Zapoznaj się z typowymi pytaniami dotyczącymi odzyskiwania po awarii maszyny wirtualnej platformy Azure. Jeśli chcesz replikować między dwoma regionami platformy Azure na tym samym kontynencie, skorzystaj z naszej oferty odzyskiwania po awarii na platformie Azure. Nie trzeba konfigurować serwera konfiguracji/serwera przetwarzania i połączeń usługi ExpressRoute.

Tak, usługa Site Recovery obsługuje odzyskiwanie po awarii lokalnych maszyn wirtualnych VMware. Zapoznaj się z typowymi pytaniami dotyczącymi odzyskiwania po awarii maszyn wirtualnych VMware.

Tak, usługa Site Recovery obsługuje odzyskiwanie po awarii lokalnych maszyn wirtualnych funkcji Hyper-V. Zapoznaj się z typowymi pytaniami dotyczącymi odzyskiwania po awarii maszyn wirtualnych funkcji Hyper-V.

Tak, usługa Site Recovery obsługuje odzyskiwanie po awarii lokalnych serwerów fizycznych z systemami Windows i Linux na platformie Azure. Dowiedz się więcej o wymaganiach dotyczących odzyskiwania po awarii na platformie Azure. Serwery fizyczne działają jako maszyny wirtualne na platformie Azure po przejściu w tryb failover. Powrót po awarii z platformy Azure do lokalnego serwera fizycznego nie jest obecnie obsługiwany. Powrót po awarii można przywrócić tylko do maszyny wirtualnej VMware.

Nie, usługa Azure Site Recovery nie obsługuje przenoszenia magazynu usługi Recovery Services, który ma chronione maszyny wirtualne hostowane w nim.

Usługa Azure Site Recovery replikuje dane na konto magazynu platformy Azure lub dyski zarządzane za pośrednictwem publicznego punktu końcowego. Można jednak również przeprowadzić replikację za pośrednictwem sieci VPN typu lokacja-lokacja. Łączność sieci VPN typu lokacja-lokacja umożliwia organizacjom łączenie istniejących sieci z platformą Azure lub ze sobą sieci platformy Azure. Sieć VPN typu lokacja-lokacja odbywa się za pośrednictwem tunelowania IPSec przez Internet, korzystając z istniejącego lokalnego sprzętu sieciowego i urządzeń sieciowych na platformie Azure, natywnych funkcji, takich jak brama wirtualnej sieci prywatnej (VPN) platformy Azure lub opcje innych firm, takie jak Check Point CloudGaurd, Palo Alto NextGen Firewall.

• Łączność prywatna za pośrednictwem publicznego Internetu z przeglądarką Microsoft Edge
• Magazyny usługi Recovery Service skonfigurowane pod kątem zabezpieczeń z prywatnymi punktami końcowymi
• Replikacja za pośrednictwem prywatnego połączenia sieci wirtualnej klienta
• Łatwe przejście do "Przyszłego stanu"
• Brak umowy SLA i potencjalnie większe opóźnienie
• Wymaga dostępności lokalnego urządzenia sieci VPN

Nasz partner, Riverbed, zawiera szczegółowe wskazówki dotyczące pracy z usługą Azure Site Recovery. Zapoznaj się z przewodnikiem po rozwiązaniu.

Tak, usługa ExpressRoute może służyć do replikowania lokalnych maszyn wirtualnych na platformę Azure.

• Usługa Azure Site Recovery replikuje dane do usługi Azure Storage za pośrednictwem publicznego punktu końcowego. Należy skonfigurować komunikację równorzędną firmy Microsoft lub użyć istniejącej publicznej komunikacji równorzędnej (przestarzałej dla nowych obwodów) do korzystania z usługi ExpressRoute na potrzeby replikacji usługi Site Recovery.
• Komunikacja równorzędna firmy Microsoft to zalecana domena routingu na potrzeby replikacji.
• Replikacja jest obsługiwana za pośrednictwem prywatnej komunikacji równorzędnej tylko wtedy, gdy prywatne punkty końcowe są włączone dla magazynu.
• Jeśli chronisz maszyny VMware lub maszyny fizyczne, upewnij się, że zostały również spełnione wymagania dotyczące sieci dla serwera konfiguracji. Połączenie ivity do określonych adresów URL jest wymagany przez serwer konfiguracji do organizowania replikacji usługi Site Recovery. Usługi ExpressRoute nie można używać na potrzeby tej łączności.
• Po przełączeniu maszyn wirtualnych w tryb failover do sieci wirtualnej platformy Azure można uzyskać do nich dostęp przy użyciu konfiguracji prywatnej komunikacji równorzędnej z siecią wirtualną platformy Azure.

Używanie kont magazynu jako magazynu docelowego nie jest obsługiwane przez usługę Azure Site Recovery. Zaleca się raczej używanie dysków zarządzanych jako magazynu docelowego dla maszyn. Dyski zarządzane obsługują tylko typ LRS dla odporności danych.

• Hyper-V: maszyny wirtualne funkcji Hyper-V można replikować co 30 sekund (z wyjątkiem magazynu w warstwie Premium) lub pięć minut.
• Maszyny wirtualne platformy Azure, maszyny wirtualne VMware, serwery fizyczne: częstotliwość replikacji nie ma tutaj znaczenia. Replikacja jest ciągła.

Replikacja rozszerzona lub łańcuchowa nie jest obsługiwana. Zażądaj tej funkcji na forum opinii.

Taka sytuacja nie jest obsługiwana. Zażądaj tej funkcji na forum opinii.

Jest to obsługiwane w przypadku replikowania maszyn wirtualnych VMware i maszyn wirtualnych funkcji Hyper-V na platformę Azure przy użyciu witryny Azure Portal.

Dyski dynamiczne są obsługiwane podczas replikowania maszyn wirtualnych funkcji Hyper-V oraz replikowania maszyn wirtualnych VMware i maszyn fizycznych na platformę Azure. Dysk systemu operacyjnego musi być dyskiem podstawowym.

Tak. Więcej informacji na temat ograniczania przepustowości można przeczytać w następujących artykułach:

• Planowanie wydajności replikacji maszyn wirtualnych VMware i serwerów fizycznych
• Planowanie pojemności replikacji maszyn wirtualnych funkcji Hyper-V na platformę Azure

Tak. Usługa Azure Site Recovery dla systemu operacyjnego Linux obsługuje niestandardowe skrypty aplikacji na potrzeby spójności aplikacji. Skrypt niestandardowy z opcjami wstępnymi i końcowymi jest używany przez agenta mobilności usługi Azure Site Recovery podczas spójności aplikacji. Poniżej przedstawiono kroki umożliwiające jego włączenie.

1. Zaloguj się jako użytkownik główny na maszynie.

2. Zmień katalog na lokalizację instalacji agenta mobilności usługi Azure Site Recovery. Wartość domyślna to "/usr/local/ASR"
   # cd /usr/local/ASR

3. Zmień katalog na "VX/scripts" w obszarze lokalizacja instalacji
   # cd VX/scripts

4. Utwórz skrypt powłoki bash o nazwie "customscript.sh" z uprawnieniami wykonywania dla użytkownika głównego.
   a. Skrypt powinien obsługiwać opcje wiersza polecenia "--pre" i "--post" (Zwróć uwagę na podwójne kreski)
   b. Gdy skrypt jest wywoływany z opcją wstępną, powinien zablokować dane wejściowe/wyjściowe aplikacji, a po wywołaniu z opcją post-option należy rozmrozić dane wejściowe/wyjściowe aplikacji.
   c. Przykładowy szablon —
   

   # cat customscript.sh
   

    #!/bin/bash

    if [ $# -ne 1 ]; then
        echo "Usage: $0 [--pre | --post]"
        exit 1
    elif [ "$1" == "--pre" ]; then
        echo "Freezing app IO"
        exit 0
    elif [ "$1" == "--post" ]; then
        echo "Thawed app IO"
        exit 0
    fi

5. Dodaj polecenia blokowania i odmrażania danych wejściowych/wyjściowych we wstępnych i po krokach dla aplikacji wymagających spójności aplikacji. Możesz dodać inny skrypt określający te elementy i wywołać go z "customscript.sh" z opcjami wstępnymi i po nich.

Zasady replikacji definiują ustawienia historii przechowywania punktów odzyskiwania. Zasady określają również częstotliwość migawek spójnych na poziomie aplikacji. Domyślnie usługa Azure Site Recovery tworzy nowe zasady replikacji z domyślnymi ustawieniami:

• Jeden dzień historii przechowywania punktów odzyskiwania.
• Brak migawek spójnych na poziomie aplikacji.

Punkt odzyskiwania spójny na poziomie awarii zawiera dane na dysku, tak jak w przypadku ściągnięcia kabla zasilania z serwera podczas tworzenia migawki. Punkt odzyskiwania spójny na poziomie awarii nie zawiera żadnych elementów, które znajdowały się w pamięci podczas wykonywania migawki.

Obecnie większość aplikacji może prawidłowo odzyskiwać dane z migawek spójnych na poziomie awarii. Punkt odzyskiwania spójny na poziomie awarii jest wystarczający dla systemów operacyjnych bez bazy danych i aplikacji, takich jak serwery plików, serwery DHCP i serwery wydruku.

Usługa Site Recovery tworzy punkt odzyskiwania spójny na poziomie awarii co 5 minut.

Punkty odzyskiwania spójne na poziomie aplikacji są tworzone na podstawie migawek spójnych na poziomie aplikacji. Punkty odzyskiwania spójne na poziomie aplikacji przechwytują te same dane co migawki spójne na poziomie awarii, jednocześnie przechwytując dane w pamięci i wszystkie transakcje w procesie.

Ze względu na ich dodatkową zawartość migawki spójne z aplikacjami są najbardziej zaangażowane i trwają najdłużej. Zalecamy punkty odzyskiwania spójne z aplikacjami dla systemów operacyjnych i aplikacji bazy danych, takich jak SQL Server.

Punkty odzyskiwania spójne na poziomie aplikacji przechwytują wszystkie dane w pamięci i w procesie. Ponieważ punkty odzyskiwania przechwytują te dane, wymagają platformy, takiej jak usługa kopiowania woluminów w tle w systemie Windows, w celu spoczynku aplikacji. Jeśli proces przechwytywania jest częsty, może to mieć wpływ na wydajność, gdy obciążenie jest już zajęte. Nie zalecamy używania niskiej częstotliwości dla punktów odzyskiwania spójnych na poziomie aplikacji dla obciążeń innych niż bazy danych. Nawet w przypadku obciążenia bazy danych wystarczy 1 godzina.

Usługa Site Recovery może utworzyć punkt odzyskiwania spójny na poziomie aplikacji z minimalną częstotliwością wynoszącą 1 godzinę.

Aby zrozumieć, jak usługa Site Recovery generuje punkty odzyskiwania, zobaczmy przykład zasad replikacji. Te zasady replikacji mają punkt odzyskiwania z 1-dniowym oknem przechowywania i migawką częstotliwości spójnej z aplikacją o wartości 1 godziny.

Usługa Site Recovery tworzy punkt odzyskiwania spójny na poziomie awarii co 5 minut. Nie można zmienić tej częstotliwości. W ciągu ostatnich 2 godzin można wybrać 24 punkty spójne na poziomie awarii i 2 punkty spójne na poziomie aplikacji. W miarę postępów czasu usługa Site Recovery usuwa wszystkie punkty odzyskiwania poza ostatnie 2 godziny i zapisuje tylko jeden punkt odzyskiwania na godzinę przez maksymalnie 24 godziny dnia.

Poniższy zrzut ekranu ilustruje przykład. Na zrzucie ekranu:

• W ciągu ostatnich 2 godzin istnieją punkty odzyskiwania z częstotliwością 5 minut.

• W ciągu ostatnich 2 godzin usługa Site Recovery utrzymuje tylko jeden punkt odzyskiwania na godzinę.

  

Najstarszy punkt odzyskiwania, którego można użyć, to 15 dni z dyskiem zarządzanym i trzy dni z dyskiem niezarządzanymi.

Nie, usługa Site Recovery przechowuje wszystkie poprzednie punkty odzyskiwania. W zależności od okna przechowywania punktów odzyskiwania usługa Site Recovery zastępuje najstarszy punkt tylko wtedy, gdy generuje nowe punkty. Z powodu problemu usługa Site Recovery nie może wygenerować żadnych nowych punktów odzyskiwania. Do momentu pojawienia się nowych punktów odzyskiwania wszystkie stare punkty pozostają po osiągnięciu okna przechowywania.

Przejdź do pozycji Site Recovery Vault>Site Recovery Infrastructure Replication policies (Zasady replikacji infrastruktury>usługi Site Recovery w magazynie usługi Site Recovery). Wybierz zasady, które chcesz edytować, i zapisz zmiany. Każda zmiana dotyczy również wszystkich istniejących replikacji.

Pierwszy wygenerowany punkt odzyskiwania zawiera pełną kopię. Wszystkie kolejne punkty odzyskiwania mają zmiany różnicowe.

Tak, jeśli zwiększysz okres przechowywania z jednego dnia do trzech dni, usługa Site Recovery zapisze punkty odzyskiwania przez dodatkowe dwa dni. Dodatkowy czas spowoduje naliczanie opłat za magazyn, ponieważ będzie istnieć 12 dodatkowych punktów odzyskiwania, które muszą zostać zapisane ze wzrostem okresu przechowywania z jednego dnia do trzech dni. Na przykład pojedynczy punkt odzyskiwania może mieć zmiany różnicowe 10 GB z kosztem za GB w wysokości 0,16 USD miesięcznie. Dodatkowe opłaty będą wynosić 1,60 USD × 12 miesięcznie.

Dostęp do maszyn wirtualnych platformy Azure można uzyskać za pośrednictwem bezpiecznego połączenia internetowego, sieci VPN typu lokacja-lokacja lub usługi Azure ExpressRoute. Aby nawiązać połączenie, należy przygotować wiele rzeczy. Dowiedz się więcej.

Platforma Azure została zaprojektowana z myślą o odporności danych. Usługa Site Recovery jest już zaprojektowana pod kątem przejścia w tryb failover do pomocniczego centrum danych platformy Azure zgodnie z umową SLA platformy Azure. W takim przypadku upewnimy się, że metadane i magazyny pozostają w tym samym regionie geograficznym, który został wybrany dla magazynu.

Możesz wyzwolić nieplanowany tryb failover z lokacji dodatkowej. Usługa Site Recovery nie wymaga łączności z lokacją główną do pracy w trybie failover.

Tryb failover nie jest automatyczny. Możesz zainicjować tryb failover za pomocą jednego kliknięcia w portalu lub użyć programu PowerShell usługi Site Recovery do wyzwolenia trybu failover. Powrót po awarii to prosta akcja w portalu usługi Site Recovery.

Aby zautomatyzować korzystanie z lokalnego programu Orchestrator lub Operations Manager do wykrywania awarii maszyny wirtualnej, a następnie wyzwalania trybu failover przy użyciu zestawu SDK.

• Przeczytaj więcej na temat planów odzyskiwania.
• Przeczytaj więcej na temat trybu failover.
• Dowiedz się więcej na temat powrotu po awarii maszyn wirtualnych VMware i serwerów fizycznych

Tak, możesz użyć odzyskiwania alternatywnej lokalizacji do powrotu po awarii do innego hosta z platformy Azure.

• W przypadku maszyn wirtualnych VMware
• W przypadku maszyn wirtualnych funkcji Hyper-V

Gdy maszyna z lokalizacji źródłowej została przełączona w tryb failover do lokalizacji docelowej, dostępne są trzy opcje do wyboru. Wszystkie trzy służą różnym celom -

1. Ukończona migracja oznacza, że nie wrócisz już do lokalizacji źródłowej. Przeprowadzono migrację do regionu docelowego, a teraz wszystko jest gotowe. Kliknięcie pozycji Ukończ migrację powoduje zatwierdzenie, a następnie wewnętrznie wyłącz replikację.
2. Zatwierdzenie oznacza, że nie jest to koniec procesu replikacji. Element replikacji wraz ze wszystkimi konfiguracjami pozostanie i można go włączyć ponownie w późniejszym momencie, aby umożliwić replikację maszyn z powrotem do regionu źródłowego.
3. Wyłączenie replikacji spowoduje wyłączenie replikacji i usunięcie całej powiązanej konfiguracji. Nie wpłynie to na istniejącą maszynę w regionie docelowym.

Tak. Przepływy pracy usługi Site Recovery można zautomatyzować przy użyciu interfejsu API REST, programu PowerShell lub zestawu Azure SDK. Obecnie obsługiwane scenariusze wdrażania usługi Site Recovery przy użyciu programu PowerShell:

• Replikowanie maszyn wirtualnych funkcji Hyper-V w chmurach maszyn wirtualnych do usługi Azure PowerShell Resource Manager
• Replikowanie maszyn wirtualnych funkcji Hyper-V bez programu VMM do usługi Azure PowerShell Resource Manager
• Replikowanie oprogramowania VMware na platformę Azure przy użyciu usługi PowerShell Resource Manager

Nie, wycofanie modułu AzureRM nie wpływa na sposób działania automatycznych aktualizacji usługi Site Recovery. Nie są wymagane żadne zmiany dla wewnętrznego elementu Runbook, a używany interfejs API REST nadal działa zgodnie z oczekiwaniami dla konta automatyzacji.

Dowiedz się więcej o nowych aktualizacjach i uzyskaj informacje o zestawień.

Następne kroki

• Zapoznaj się z omówieniem usługi Site Recovery