Odzyskiwanie wielodostępnej aplikacji SaaS z kopii zapasowych bazy danych przy użyciu przywracania geograficznego

Dotyczy:Azure SQL Database

W tym samouczku przedstawiono pełny scenariusz odzyskiwania po awarii dla wielodostępnej aplikacji SaaS zaimplementowanej z bazą danych na model dzierżawy. Przywracanie geograficzne służy do odzyskiwania baz danych katalogu i dzierżawy z automatycznie utrzymywanych geograficznie nadmiarowych kopii zapasowych do alternatywnego regionu odzyskiwania. Po rozwiązaniu awarii należy użyć replikacji geograficznej do repatriacji zmienionych baz danych do ich oryginalnego regionu.

Przywracanie geograficzne to rozwiązanie do odzyskiwania po awarii o najniższych kosztach dla usługi Azure SQL Database. Jednak przywracanie z geograficznie nadmiarowych kopii zapasowych danych może spowodować utratę danych w niektórych scenariuszach, ponieważ Azure Geo-Redundant Storage (GRS) replikuje dane asynchronicznie do regionu wtórnego. Oznacza to, że istnieje pewne opóźnienie związane z procesem replikacji, ale dokładne opóźnienie może się różnić w zależności od kilku czynników, w tym odległości między regionami podstawowymi i pomocniczymi a bieżącymi warunkami sieci. Zazwyczaj opóźnienie replikacji w GRS osiąga zakres minut, ale nie ma gwarancji, że mieści się w określonym przedziale czasu. Może to zająć dużo czasu, w zależności od rozmiaru każdej bazy danych.

Uwaga

Odzyskiwanie aplikacji przy użyciu najniższego możliwego celu punktu odzyskiwania i celu punktu odzyskiwania przy użyciu replikacji geograficznej zamiast przywracania geograficznego.

W tym samouczku przedstawiono przepływy pracy przywracania i repatriacji. Dowiedz się, jak odbywa się:

• Synchronizuj informacje o konfiguracji bazy danych i puli elastycznej z wykazem dzierżaw.
• Skonfiguruj środowisko obrazu dublowanego w regionie odzyskiwania obejmującym aplikacje, serwery i pule.
• Odzyskiwanie baz danych katalogu i dzierżawy przy użyciu przywracania geograficznego.
• Użyj replikacji geograficznej, aby ponowić wykaz dzierżaw i zmienić bazy danych dzierżaw po rozwiązaniu awarii.
• Zaktualizuj wykaz, gdy każda baza danych jest przywracana (lub repatriowana), aby śledzić bieżącą lokalizację aktywnej kopii bazy danych każdej dzierżawy.
• Upewnij się, że aplikacja i baza danych dzierżawy są zawsze współlokowane w tym samym regionie świadczenia usługi Azure, aby zmniejszyć opóźnienie.

Przed rozpoczęciem tego samouczka wykonaj następujące wymagania wstępne:

• Wdróż bazę danych SaaS biletów Wingtip na aplikację dzierżawy. Aby wdrożyć w mniej niż pięć minut, zobacz Wdrażanie i eksplorowanie bazy danych SaaS biletów Wingtip na aplikację dzierżawy.
• Zainstaluj program Azure PowerShell. Aby uzyskać szczegółowe informacje, zobacz Wprowadzenie do programu Azure PowerShell.

Wprowadzenie do wzorca odzyskiwania przywracania geograficznego

Odzyskiwanie po awarii (DR) jest ważną kwestią dla wielu aplikacji, zarówno ze względu na zgodność, jak i ciągłość działalności biznesowej. Jeśli występuje długotrwała awaria usługi, dobrze przygotowany plan odzyskiwania po awarii może zminimalizować przerwy w działaniu firmy. Plan odzyskiwania po awarii na podstawie przywracania geograficznego musi osiągnąć kilka celów:

• Zarezerwuj całą wymaganą pojemność w wybranym regionie odzyskiwania tak szybko, jak to możliwe, aby upewnić się, że jest ona dostępna do przywrócenia baz danych dzierżawy.
• Ustanów środowisko odzyskiwania obrazu dublowanego, które odzwierciedla oryginalną pulę i konfigurację bazy danych.
• Zezwalaj na anulowanie procesu przywracania w połowie lotu, jeśli oryginalny region wróci do trybu online.
• Włącz aprowizację dzierżawy szybko, aby nowe dołączanie dzierżawy było możliwe do ponownego uruchomienia tak szybko, jak to możliwe.
• Należy zoptymalizować w celu przywrócenia dzierżaw w kolejności priorytetu.
• Być zoptymalizowane pod kątem jak najszybszego uzyskiwania dzierżaw w trybie online, wykonując kroki równolegle, gdy jest to praktyczne.
• Odporność na awarie, możliwość ponownego uruchomienia i idempotentność.
• Repatriuj bazy danych do ich oryginalnego regionu z minimalnym wpływem na dzierżawy, gdy awaria zostanie rozwiązana.

Uwaga

Aplikacja jest odzyskiwane w sparowanym regionie regionu, w którym aplikacja jest wdrażana. Aby uzyskać więcej informacji, zobacz Regiony sparowane platformy Azure.

W tym samouczku używane są funkcje usługi Azure SQL Database i platformy Azure, aby sprostać następującym wyzwaniom:

• Szablony usługi Azure Resource Manager, aby zarezerwować całą wymaganą pojemność tak szybko, jak to możliwe. Szablony usługi Azure Resource Manager służą do aprowizowania obrazu dublowanego oryginalnych serwerów i elastycznych pul w regionie odzyskiwania. Na potrzeby aprowizacji nowych dzierżaw jest również tworzony oddzielny serwer i pula.
• Biblioteka klienta elastycznej bazy danych (EDCL) w celu utworzenia i obsługi wykazu baz danych dzierżawy. Rozszerzony wykaz zawiera okresowo odświeżane informacje o konfiguracji puli i bazy danych.
• Funkcje odzyskiwania zarządzania fragmentami listy EDCL, aby zachować wpisy lokalizacji bazy danych w katalogu podczas odzyskiwania i repatriacji.
• Przywracanie geograficzne w celu odzyskania baz danych katalogu i dzierżawy z automatycznie obsługiwanych geograficznie nadmiarowych kopii zapasowych.
• Operacje przywracania asynchronicznego, wysyłane w kolejności priorytetu dzierżawy, są kolejkowane dla każdej puli przez system i przetwarzane w partiach, dzięki czemu pula nie jest przeciążona. Te operacje można anulować przed wykonaniem lub podczas wykonywania, jeśli to konieczne.
• Replikacja geograficzna w celu repatriacji baz danych do oryginalnego regionu po awarii. Brak utraty danych i minimalny wpływ na dzierżawę podczas korzystania z replikacji geograficznej.
• Aliasy DNS serwera SQL, aby umożliwić procesowi synchronizacji katalogu nawiązywanie połączenia z aktywnym wykazem niezależnie od jego lokalizacji.

Pobieranie skryptów odzyskiwania po awarii

Skrypty odzyskiwania po awarii używane w tym samouczku są dostępne w bazie danych SaaS Wingtip Tickets na dzierżawę w repozytorium GitHub. Zapoznaj się z ogólnymi wskazówkami dotyczącymi kroków pobierania i odblokowywania skryptów zarządzania biletami Wingtip.

Ważne

Podobnie jak w przypadku wszystkich skryptów zarządzania biletami Wingtip, skrypty odzyskiwania po awarii są jakością przykładową i nie są używane w środowisku produkcyjnym.

Przeglądanie stanu dobrej kondycji aplikacji

Przed rozpoczęciem procesu odzyskiwania przejrzyj normalny stan dobrej kondycji aplikacji.

1. W przeglądarce internetowej otwórz centrum zdarzeń Wingtip Tickets (http://events.wingtip-dpt.<user>.trafficmanager.net, zastąp <user> wartością użytkownika wdrożenia).

   Przewiń do dołu strony i zwróć uwagę na nazwę i lokalizację serwera wykazu w stopce. Lokalizacja to region, w którym wdrożono aplikację.

   Napiwek

   Umieść kursor myszy nad lokalizacją, aby powiększyć ekran.

   

2. Wybierz dzierżawę Contoso Concert Hall i otwórz stronę wydarzenia.

   W stopce zwróć uwagę na nazwę serwera dzierżawy. Lokalizacja jest taka sama jak lokalizacja serwera wykazu.

   

3. W witrynie Azure Portal przejrzyj i otwórz grupę zasobów, w której wdrożono aplikację.

   Zwróć uwagę na zasoby i region, w którym wdrożono składniki usługi App Service i usługę SQL Database.

Synchronizowanie konfiguracji dzierżawy z wykazem

W tym zadaniu uruchomisz proces synchronizowania konfiguracji serwerów, pul elastycznych i baz danych z wykazem dzierżaw. Te informacje są później używane do konfigurowania środowiska obrazu dublowanego w regionie odzyskiwania.

Ważne

Dla uproszczenia proces synchronizacji i inne długotrwałe procesy odzyskiwania i repatriacji są implementowane w tych przykładach jako lokalne zadania programu PowerShell lub sesje uruchamiane w ramach logowania użytkownika klienta. Tokeny uwierzytelniania wystawione podczas logowania wygasają po kilku godzinach, a zadania kończą się niepowodzeniem. W scenariuszu produkcyjnym długotrwałe procesy powinny być implementowane jako niezawodne usługi platformy Azure pewnego rodzaju działające w ramach jednostki usługi. Zobacz Tworzenie jednostki usługi przy użyciu programu Azure PowerShell z certyfikatem.

1. W programie PowerShell ISE otwórz plik ...\Learning Modules\UserConfig.psm1. Zastąp <resourcegroup> wartości i <user> w wierszach 10 i 11 wartością używaną podczas wdrażania aplikacji. Zapisz plik.

2. W programie PowerShell ISE otwórz skrypt ...\Learning Modules\Business Continuity and Disaster Recovery\DR-RestoreFromBackup\Demo-RestoreFromBackup.ps1.

   W tym samouczku uruchomisz każdy ze scenariuszy w tym skryfcie programu PowerShell, więc pozostaw ten plik otwarty.

3. Ustaw następujące ustawienia:

   $DemoScenario = 1: Start a background job that syncs tenant server and pool configuration info into the catalog.

4. Aby uruchomić skrypt synchronizacji, wybierz pozycję F5.

   Te informacje są używane później w celu zapewnienia, że odzyskiwanie tworzy obraz dublowania serwerów, pul i baz danych w regionie odzyskiwania.

   

Pozostaw okno programu PowerShell uruchomione w tle i przejdź do pozostałej części tego samouczka.

Uwaga

Proces synchronizacji łączy się z wykazem za pośrednictwem aliasu DNS. Alias jest modyfikowany podczas przywracania i repatriacji w celu wskazania aktywnego wykazu. Proces synchronizacji zapewnia aktualność wykazu z wszelkimi zmianami konfiguracji bazy danych lub puli wprowadzonych w regionie odzyskiwania. Podczas repatriacji te zmiany są stosowane do równoważnych zasobów w oryginalnym regionie.

Omówienie procesu odzyskiwania przywracania geograficznego

Proces odzyskiwania przywracania geograficznego wdraża aplikację i przywraca bazy danych z kopii zapasowych do regionu odzyskiwania.

Proces odzyskiwania wykonuje następujące czynności:

1. Wyłącza punkt końcowy usługi Azure Traffic Manager dla aplikacji internetowej w oryginalnym regionie. Wyłączenie punktu końcowego uniemożliwia użytkownikom nawiązywanie połączenia z aplikacją w nieprawidłowym stanie, jeśli oryginalny region będzie dostępny w trybie online podczas odzyskiwania.

2. Aprowizuje serwer wykazu odzyskiwania w regionie odzyskiwania, przywraca geograficznie bazę danych katalogu i aktualizuje alias activecatalog, aby wskazywał przywrócony serwer wykazu. Zmiana aliasu wykazu gwarantuje, że proces synchronizacji katalogu zawsze jest synchronizowany z aktywnym wykazem.

3. Oznacza wszystkie istniejące dzierżawy w wykazie odzyskiwania jako offline, aby zapobiec dostępowi do baz danych dzierżawy przed ich przywróceniem.

4. Aprowizuje wystąpienie aplikacji w regionie odzyskiwania i konfiguruje go do używania przywróconego wykazu w tym regionie. Aby zachować opóźnienie do minimum, przykładowa aplikacja została zaprojektowana tak, aby zawsze łączyła się z bazą danych dzierżawy w tym samym regionie.

5. Aprowizuje serwer i elastyczną pulę, w której są aprowizowani nowi dzierżawcy. Utworzenie tych zasobów gwarantuje, że aprowizowanie nowych dzierżaw nie zakłóca odzyskiwania istniejących dzierżaw.

6. Aktualizuje nowy alias dzierżawy, aby wskazywał serwer dla nowych baz danych dzierżawy w regionie odzyskiwania. Zmiana tego aliasu gwarantuje, że bazy danych dla wszystkich nowych dzierżaw są aprowizowane w regionie odzyskiwania.

7. Aprowizowanie serwerów i elastycznych pul w regionie odzyskiwania na potrzeby przywracania baz danych dzierżawy. Te serwery i pule są obrazem dublowania konfiguracji w oryginalnym regionie. Aprowizowanie pul z góry rezerwuje pojemność wymaganą do przywrócenia wszystkich baz danych.

   Awaria w regionie może wywierać znaczną presję na zasoby dostępne w sparowanym regionie. Jeśli korzystasz z przywracania geograficznego na potrzeby odzyskiwania po awarii, zaleca się szybkie rezerwowanie zasobów. Rozważ replikację geograficzną, jeśli krytyczne jest odzyskanie aplikacji w określonym regionie.

8. Włącza punkt końcowy usługi Traffic Manager dla aplikacji internetowej w regionie odzyskiwania. Włączenie tego punktu końcowego umożliwia aplikacji aprowizowanie nowych dzierżaw. Na tym etapie istniejące dzierżawy są nadal w trybie offline.

9. Przesyła partie żądań w celu przywrócenia baz danych w kolejności priorytetu.

   • Partie są zorganizowane tak, aby bazy danych zostały przywrócone równolegle we wszystkich pulach.

   • Żądania przywracania są przesyłane asynchronicznie, dzięki czemu są one przesyłane szybko i kolejkowane do wykonania w każdej puli.

   • Ponieważ żądania przywracania są przetwarzane równolegle we wszystkich pulach, lepiej jest dystrybuować ważne dzierżawy w wielu pulach.

10. Monitoruje usługę w celu określenia, kiedy bazy danych są przywracane. Po przywróceniu bazy danych dzierżawy jest ona oznaczona w trybie online w wykazie, a suma rowversion bazy danych dzierżawy jest rejestrowana.

    • Dostęp do baz danych dzierżawy można uzyskać za pomocą aplikacji natychmiast po oznaczeniu ich w trybie online w wykazie.

    • Suma wartości rowversion w bazie danych dzierżawy jest przechowywana w wykazie. Ta suma działa jako odcisk palca, który umożliwia proces repatriacji w celu określenia, czy baza danych została zaktualizowana w regionie odzyskiwania.

Uruchamianie skryptu odzyskiwania

Ważne

Ten samouczek przywraca bazy danych z geograficznie nadmiarowych kopii zapasowych. Chociaż te kopie zapasowe są zwykle dostępne w ciągu 10 minut, może to potrwać dłużej. Skrypt zostanie wstrzymany do momentu ich udostępnienia.

Wyobraź sobie, że w regionie, w którym wdrożono aplikację, i uruchom skrypt odzyskiwania:

1. W tym programie PowerShell ISE w skrypcie ...\Learning Modules\Business Continuity and Disaster Recovery\DR-RestoreFromBackup\Demo-RestoreFromBackup.ps1 zdefiniuj następującą wartość:

   $DemoScenario = 2: Recover the app into a recovery region by restoring from geo-redundant backups.

2. Aby uruchomić skrypt, wybierz pozycję F5.

   • Skrypt zostanie otwarty w nowym oknie programu PowerShell, a następnie uruchomi zestaw zadań programu PowerShell uruchamianych równolegle. Te zadania przywracają serwery, pule i bazy danych do regionu odzyskiwania.

   • Region odzyskiwania to sparowany region skojarzony z regionem świadczenia usługi Azure, w którym wdrożono aplikację. Aby uzyskać więcej informacji, zobacz Regiony sparowane platformy Azure.

3. Monitoruj stan procesu odzyskiwania w oknie programu PowerShell.

   

Uwaga

Aby zapoznać się z kodem zadań odzyskiwania, przejrzyj skrypty programu PowerShell w folderze ...\Learning Modules\Business Continuity and Disaster Recovery\DR-RestoreFromBackup\RecoveryJobs.

Przeglądanie stanu aplikacji podczas odzyskiwania

Gdy punkt końcowy aplikacji jest wyłączony w usłudze Traffic Manager, aplikacja jest niedostępna. Wykaz jest przywracany, a wszystkie dzierżawy są oznaczone w trybie offline. Punkt końcowy aplikacji w regionie odzyskiwania jest następnie włączony, a aplikacja wraca do trybu online. Mimo że aplikacja jest dostępna, dzierżawy są wyświetlane w trybie offline w centrum zdarzeń do momentu przywrócenia ich baz danych. Ważne jest, aby zaprojektować aplikację do obsługi baz danych dzierżaw w trybie offline.

• Po odzyskaniu bazy danych wykazu, ale zanim dzierżawy będą z powrotem w trybie online, odśwież centrum zdarzeń Wingtip Tickets w przeglądarce internetowej.

  • W stopce zwróć uwagę, że nazwa serwera katalogu ma teraz sufiks -recovery i znajduje się w regionie odzyskiwania.

  • Zauważ, że dzierżawy, które nie zostały jeszcze przywrócone, są oznaczone jako offline i nie można ich wybierać.

    

  • Jeśli otworzysz stronę zdarzeń dzierżawy bezpośrednio, gdy dzierżawa jest w trybie offline, na stronie zostanie wyświetlone powiadomienie dzierżawy w trybie offline. Jeśli na przykład Contoso Concert Hall jest offline, spróbuj otworzyć http://events.wingtip-dpt.<user>.trafficmanager.net/contosoconcerthall.

    

Aprowizuj nową dzierżawę w regionie odzyskiwania

Jeszcze przed przywróceniem baz danych dzierżawy można aprowizować nowe dzierżawy w regionie odzyskiwania. Nowe bazy danych dzierżawy aprowidowane w regionie odzyskiwania są ponawiane przy użyciu odzyskanych baz danych później.

1. W programie PowerShell ISE w skrypcie ...\Learning Modules\Business Continuity and Disaster Recovery\DR-RestoreFromBackup\Demo-RestoreFromBackup.ps1 ustaw następującą właściwość:

   $DemoScenario = 3: Provision a new tenant in the recovery region.

2. Aby uruchomić skrypt, wybierz pozycję F5.

3. Strona zdarzeń Hawthorn Hall zostanie otwarta w przeglądarce po zakończeniu aprowizacji.

   Zwróć uwagę, że baza danych Hawthorn Hall znajduje się w regionie odzyskiwania.

   

4. W przeglądarce odśwież stronę centrum zdarzeń Wingtip Tickets, aby zobaczyć dołączona hala Hawthorn Hall.

   Jeśli aprowizujesz Halę Hawthorn bez oczekiwania na przywrócenie innych dzierżaw, inne dzierżawy mogą nadal być w trybie offline.

Przeglądanie odzyskanego stanu aplikacji

Po zakończeniu procesu odzyskiwania aplikacja i wszystkie dzierżawy są w pełni funkcjonalne w regionie odzyskiwania.

1. Po wyświetleniu w oknie konsoli programu PowerShell wskazuje, że wszystkie dzierżawy zostaną odzyskane, odśwież centrum zdarzeń.

   Wszyscy dzierżawcy pojawiają się online, w tym nowa dzierżawa, Hawthorn Hall.

   

2. Kliknij pozycję Contoso Concert Hall i otwórz stronę swoich wydarzeń.

   W stopce zwróć uwagę, że baza danych znajduje się na serwerze odzyskiwania znajdującym się w regionie odzyskiwania.

   

3. W witrynie Azure Portal otwórz listę grup zasobów.

   Zwróć uwagę na wdrożoną grupę zasobów, a także na grupę zasobów odzyskiwania, obie z sufiksem -recovery. Grupa zasobów odzyskiwania zawiera wszystkie zasoby utworzone podczas procesu odzyskiwania oraz nowe zasoby utworzone podczas awarii.

4. Otwórz grupę zasobów odzyskiwania i zwróć uwagę na następujące elementy:

   • Wersje odzyskiwania serwerów katalogu i tenants1 z sufiksem -recovery. Przywrócone bazy danych katalogu i dzierżawy na tych serwerach mają nazwy używane w oryginalnym regionie.

   • Serwer tenants2-dpt-<user>-recovery SQL. Ten serwer jest używany do aprowizowania nowych dzierżaw podczas awarii.

   • Usługa aplikacji o nazwie events-wingtip-dpt-<recoveryregion>-<user>, która jest instancją przywracającą aplikacji zdarzeń.

     

5. Otwórz serwer tenants2-dpt-<user>-recovery SQL. Zwróć uwagę, że zawiera ona bazę danych głóg i pulę elastyczną Pool1. Baza danych głóg jest skonfigurowana jako elastyczna baza danych w elastycznej puli Pool1.

Zmienianie danych dzierżawy

W tym zadaniu zaktualizujesz jedną z przywróconych baz danych dzierżawy. Proces repatriacji kopiuje przywrócone bazy danych, które zostały zmienione na oryginalny region.

1. W przeglądarce znajdź listę zdarzeń dla sali koncertowej Contoso, przewiń wydarzenia i zwróć uwagę na ostatnie wydarzenie Poważnie Strauss.

2. W programie PowerShell ISE, w skrypcie ...\Learning Modules\Business Continuity and Disaster Recovery\DR-RestoreFromBackup\Demo-RestoreFromBackup.ps1, ustaw następującą wartość:

   $DemoScenario = 4: Delete an event from a tenant in the recovery region.

3. Aby wykonać skrypt, wybierz pozycję F5.

4. Odśwież stronę wydarzeń Contoso Concert Hall (http://events.wingtip-dpt.<user>.trafficmanager.net/contosoconcerthall) i zwróć uwagę, że brakuje wydarzenia Serio Strauss.

Na tym etapie samouczka odzyskano aplikację, która jest teraz uruchomiona w regionie odzyskiwania. Aprowizowano nową dzierżawę w regionie odzyskiwania i zmodyfikowano dane jednej z przywróconych dzierżaw.

Uwaga

Inne samouczki w przykładzie nie są przeznaczone do uruchamiania z aplikacją w stanie odzyskiwania. Jeśli chcesz zapoznać się z innymi samouczkami, najpierw wykonaj repatriację aplikacji.

Omówienie procesu repatriacji

Proces repatriacji przywraca aplikację i jej bazy danych do oryginalnego regionu po rozwiązaniu awarii.

Proces:

1. Zatrzymuje wszelkie trwające działania przywracania i anuluje wszelkie zaległe lub w locie żądania przywracania bazy danych.

2. Reactivates w oryginalnych regionach baz danych dzierżawy, które nie zostały zmienione od czasu awarii. Te bazy danych obejmują te, które nie zostały jeszcze odzyskane, a te odzyskane, ale nie zostały później zmienione. Ponownie aktywowane bazy danych są dokładnie tak samo jak ostatnio używane przez ich dzierżawy.

3. Aprowizuje obraz dublowania serwera nowej dzierżawy i elastycznej puli w oryginalnym regionie. Po zakończeniu tej akcji nowy alias dzierżawy zostanie zaktualizowany w celu wskazania tego serwera. Aktualizacja aliasu powoduje wystąpienie nowego dołączania dzierżawy w oryginalnym regionie zamiast regionu odzyskiwania.

4. Używa replikacji geograficznej, aby przenieść katalog do oryginalnego regionu z regionu odzyskiwania.

5. Aktualizuje konfigurację puli w oryginalnym regionie, aby była zgodna ze zmianami, które zostały wprowadzone w regionie odzyskiwania podczas awarii.

6. Tworzy wymagane serwery i pule do hostowania wszelkich nowych baz danych utworzonych podczas awarii.

7. Używa replikacji geograficznej do repatriacji przywróconych baz danych dzierżawy, które zostały zaktualizowane po przywróceniu i wszystkich nowych baz danych dzierżawy aprowizowania podczas awarii.

8. Czyści zasoby utworzone w regionie odzyskiwania podczas procesu przywracania.

Aby ograniczyć liczbę baz danych dzierżawy, które muszą zostać repatriowane, kroki od 1 do 3 są wykonywane natychmiast.

Krok 4 jest wykonywany tylko wtedy, gdy wykaz w regionie odzyskiwania został zmodyfikowany podczas awarii. Wykaz zostanie zaktualizowany, jeśli nowe dzierżawy zostaną utworzone lub czy jakakolwiek konfiguracja bazy danych lub puli zostanie zmieniona w regionie odzyskiwania.

Ważne jest, aby krok 7 powodował minimalne zakłócenia dzierżaw i nie utraty danych. Aby osiągnąć ten cel, proces używa replikacji geograficznej.

Zanim każda baza danych zostanie zreplikowana geograficznie, odpowiednia baza danych w oryginalnym regionie zostanie usunięta. Baza danych w regionie odzyskiwania jest następnie replikowana geograficznie, tworząc replikę pomocniczą w oryginalnym regionie. Po zakończeniu replikacji dzierżawa jest oznaczona w trybie offline w katalogu, co powoduje przerwanie wszelkich połączeń z bazą danych w regionie odzyskiwania. Baza danych jest następnie przełączona w tryb failover, co powoduje przetworzenie oczekujących transakcji w pomocniczej bazie danych, więc żadne dane nie zostaną utracone.

W trybie failover role bazy danych są odwrócone. Pomocnicza w oryginalnym regionie staje się podstawową bazą danych odczytu i zapisu, a baza danych w regionie odzyskiwania staje się pomocnicza tylko do odczytu. Wpis dzierżawy w wykazie jest aktualizowany w celu odwołania do bazy danych w oryginalnym regionie, a dzierżawa jest oznaczona w trybie online. W tym momencie repatriacja bazy danych jest zakończona.

Aplikacje powinny być zapisywane za pomocą logiki ponawiania prób, aby upewnić się, że ponownie nawiążą połączenie automatycznie po przerwaniu połączeń. Gdy używają wykazu do brokera ponownego nawiązywania połączenia, łączą się z repatriowaną bazą danych w oryginalnym regionie. Chociaż krótki rozłączenie nie jest często zauważane, możesz zdecydować się na repatriację baz danych poza godzinami pracy.

Po repatriacji bazy danych można usunąć pomocniczą bazę danych w regionie odzyskiwania. Baza danych w oryginalnym regionie ponownie opiera się na przywracaniu geograficznym na potrzeby ochrony po awarii.

W kroku 8 zasoby w regionie odzyskiwania, w tym serwery odzyskiwania i pule, są usuwane.

Uruchamianie skryptu repatriacji

Wyobraźmy sobie, że awaria zostanie rozwiązana i uruchom skrypt repatriacji.

Jeśli wykonano czynności opisane w samouczku, skrypt natychmiast reactivates Fabrikam Jazz Club i Dogwood Dojo w oryginalnym regionie, ponieważ są one niezmienione. Następnie repatriates nowej dzierżawy, Hawthorn Hall i Contoso Concert Hall, ponieważ został zmodyfikowany. Skrypt repatriates katalogu, który został zaktualizowany, gdy Hawthorn Hall został zainicjowany.

1. W programie PowerShell ISE w skrypcie ...\Learning Modules\Business Continuity and Disaster Recovery\DR-RestoreFromBackup\Demo-RestoreFromBackup.ps1 sprawdź, czy proces synchronizacji katalogu jest nadal uruchomiony w jego wystąpieniu programu PowerShell. W razie potrzeby uruchom je ponownie, ustawiając następujące ustawienia:

   $DemoScenario = 1: Start synchronizing tenant server, pool, and database configuration info into the catalog.

   Aby uruchomić skrypt, wybierz pozycję F5.

2. Następnie, aby rozpocząć proces repatriacji, ustaw:

   $DemoScenario = 5: Repatriate the app into its original region.

   Aby uruchomić skrypt odzyskiwania w nowym oknie programu PowerShell, wybierz pozycję F5. Repatriacja trwa kilka minut i można je monitorować w oknie programu PowerShell.

3. Gdy skrypt jest uruchomiony, odśwież stronę centrum zdarzeń (http://events.wingtip-dpt.<user>.trafficmanager.net).

   Zwróć uwagę, że wszystkie dzierżawy są w trybie online i dostępne w tym procesie.

4. Wybierz klub Fabrikam Jazz Club, aby go otworzyć. Jeśli ta dzierżawa nie została zmodyfikowana, zwróć uwagę na to, że serwer został już przywrócony do oryginalnego serwera.

5. Otwórz lub odśwież stronę wydarzeń Contoso Concert Hall. Zwróć uwagę na stopkę, że początkowo baza danych jest nadal na serwerze -recovery.

6. Odśwież stronę zdarzeń Contoso Concert Hall po zakończeniu procesu repatriacji i zwróć uwagę, że baza danych znajduje się teraz w oryginalnym regionie.

7. Odśwież centrum zdarzeń ponownie i otwórz Halę Hawthorn. Zwróć uwagę, że jego baza danych znajduje się również w oryginalnym regionie.

Czyszczenie zasobów regionu odzyskiwania po repatriacji

Po zakończeniu repatriacji można bezpiecznie usunąć zasoby w regionie odzyskiwania.

Ważne

Usuń te zasoby natychmiast, aby zatrzymać wszystkie rozliczenia dla nich.

Proces przywracania tworzy wszystkie zasoby odzyskiwania w grupie zasobów odzyskiwania. Proces oczyszczania usuwa tę grupę zasobów i usuwa wszystkie odwołania do zasobów z wykazu.

1. W programie PowerShell ISE w skryscie ...\Learning Modules\Business Continuity and Disaster Recovery\DR-RestoreFromBackup\Demo-RestoreFromBackup.ps1 ustaw następujące ustawienia:

   $DemoScenario = 6: Delete obsolete resources from the recovery region.

2. Aby uruchomić skrypt, wybierz pozycję F5.

Po wyczyszczeniu skryptów aplikacja jest z powrotem tam, gdzie została uruchomiona. Na tym etapie możesz ponownie uruchomić skrypt lub wypróbować inne samouczki.

Projektowanie aplikacji w celu zapewnienia, że aplikacja i baza danych są współlokowane

Aplikacja została zaprojektowana tak, aby zawsze łączyć się z wystąpienia w tym samym regionie co baza danych dzierżawy. Ten projekt zmniejsza opóźnienie między aplikacją a bazą danych. W tej optymalizacji przyjęto założenie, że interakcja między aplikacjami i bazą danych jest bardziej rozmowna niż interakcja między użytkownikami i aplikacjami.

Bazy danych dzierżawy mogą być rozłożone na odzyskiwanie i oryginalne regiony przez jakiś czas podczas repatriacji. Dla każdej bazy danych aplikacja wyszukuje region, w którym znajduje się baza danych, wykonując wyszukiwanie DNS w nazwie serwera dzierżawy. Nazwa serwera jest aliasem. Nazwa aliasu serwera zawiera nazwę regionu. Jeśli aplikacja nie znajduje się w tym samym regionie co baza danych, przekierowuje do wystąpienia w tym samym regionie co serwer. Przekierowywanie do wystąpienia w tym samym regionie co baza danych minimalizuje opóźnienie między aplikacją a bazą danych.

Następne kroki

W tym samouczku zawarto informacje na temat wykonywania następujących czynności:

• Użyj wykazu dzierżaw, aby przechowywać okresowo odświeżane informacje o konfiguracji, które umożliwiają utworzenie dublowanego środowiska odzyskiwania obrazu w innym regionie.
• Odzyskiwanie baz danych w regionie odzyskiwania przy użyciu przywracania geograficznego.
• Zaktualizuj katalog dzierżawy, aby odzwierciedlał przywrócone lokalizacje bazy danych dzierżawy.
• Użyj aliasu DNS, aby umożliwić aplikacji łączenie się z wykazem dzierżaw bez ponownej konfiguracji.
• Użyj replikacji geograficznej, aby repatriować odzyskane bazy danych do ich oryginalnego regionu po rozwiązaniu awarii.

Wypróbuj odzyskiwanie po awarii dla wielodostępnej aplikacji SaaS korzystającej z samouczka replikacji geograficznej bazy danych, aby dowiedzieć się, jak używać replikacji geograficznej, aby znacznie skrócić czas potrzebny do odzyskania aplikacji wielodostępnej na dużą skalę.

Dodatkowe zasoby

Dodatkowe samouczki oparte na aplikacji SaaS Wingtip