Odzyskiwanie po awarii dla aplikacji SaaS z wieloma dzierżawami przy użyciu replikacji geograficznej bazy danych

Dotyczy: Azure SQL Database

W tym samouczku przedstawiono pełny scenariusz odzyskiwania po awarii dla wielodostępnej aplikacji SaaS zaimplementowanej przy użyciu modelu bazy danych na dzierżawę. Aby chronić aplikację przed awarią, należy użyć replikacji geograficznej, aby utworzyć repliki dla baz danych katalogu i dzierżawy w alternatywnym regionie odzyskiwania. Jeśli wystąpi awaria, możesz szybko przejść w tryb failover do tych replik w celu wznowienia normalnych operacji biznesowych. W trybie failover bazy danych w oryginalnym regionie stają się replikami pomocniczymi baz danych w regionie odzyskiwania. Po powrocie tych replik do trybu online automatycznie nadrabiają zaległości w stanie baz danych w regionie odzyskiwania. Po rozwiązaniu awarii wróć do baz danych w oryginalnym regionie produkcyjnym.

W tym samouczku przedstawiono przepływy pracy trybu failover i powrotu po awarii. Dowiesz się, jak:

• Synchronizowanie informacji o konfiguracji bazy danych i puli elastycznej z wykazem dzierżaw
• Konfigurowanie środowiska odzyskiwania w regionie alternatywnym obejmującym aplikacje, serwery i pule
• Replikacja geograficzna służy do replikowania katalogów i baz danych dzierżawy do regionu odzyskiwania
• Przełącz aplikację i katalog i bazy danych dzierżawy w tryb failover do regionu odzyskiwania
• Później przełącz w tryb failover bazy danych aplikacji, katalogu i dzierżawy z powrotem do oryginalnego regionu po rozwiązaniu awarii
• Aktualizowanie wykazu, ponieważ każda baza danych dzierżawy jest przełączona w tryb failover, aby śledzić lokalizację podstawową bazy danych każdej dzierżawy
• Upewnij się, że aplikacja i podstawowa baza danych dzierżawy są zawsze kolokowane w tym samym regionie świadczenia usługi Azure, aby zmniejszyć opóźnienie

Przed rozpoczęciem tego samouczka upewnij się, że zostały spełnione następujące wymagania wstępne:

• Baza danych SaaS biletów Wingtip na aplikację dzierżawy jest wdrażana. Aby wdrożyć w mniej niż pięć minut, zobacz Wdrażanie i eksplorowanie bazy danych SaaS biletów Wingtip na aplikację dzierżawy
• Zainstalowany jest program Azure PowerShell. Aby uzyskać szczegółowe informacje, zobacz Rozpoczynanie pracy z programem Azure PowerShell

Wprowadzenie do wzorca odzyskiwania replikacji geograficznej

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ąpi długotrwała awaria usługi, dobrze przygotowany plan odzyskiwania po awarii może zminimalizować zakłócenia biznesowe. Użycie replikacji geograficznej zapewnia najniższy cel punktu odzyskiwania i cel punktu odzyskiwania przez utrzymywanie replik bazy danych w regionie odzyskiwania, które można w krótkim czasie przepracować w tryb failover.

Plan odzyskiwania po awarii oparty na replikacji geograficznej składa się z trzech odrębnych części:

• Konfigurowanie — tworzenie i konserwacja środowiska odzyskiwania
• Odzyskiwanie — przechodzenie aplikacji i baz danych w tryb failover do środowiska odzyskiwania, jeśli wystąpi awaria,
• Repatriacja — tryb failover aplikacji i baz danych z powrotem do oryginalnego regionu po rozwiązaniu aplikacji

Wszystkie części muszą być starannie brane pod uwagę, zwłaszcza jeśli działają na dużą skalę. Ogólnie rzecz biorąc, plan musi osiągnąć kilka celów:

• Instalacji
  • Ustanów i zachowaj środowisko dublowania obrazu w regionie odzyskiwania. Tworzenie elastycznych pul i replikowanie wszystkich baz danych w tym środowisku odzyskiwania powoduje rezerwowanie pojemności w regionie odzyskiwania. Obsługa tego środowiska obejmuje replikowanie nowych baz danych dzierżaw w miarę ich aprowizacji.
• Odzyskiwania
  • W przypadku gdy skalowane w dół środowisko odzyskiwania jest używane do minimalizowania codziennych kosztów, pule i bazy danych muszą być skalowane w górę, aby uzyskać pełną pojemność operacyjną w regionie odzyskiwania
  • Jak najszybciej włącz nową aprowizację dzierżawy w regionie odzyskiwania
  • Optymalizacja pod kątem przywracania dzierżaw w kolejności priorytetów
  • 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ść
  • Jeśli oryginalny region wróci do trybu online, można anulować ten proces w połowie lotu.
• Repatriacja
  • Przełącz bazy danych w tryb failover z regionu odzyskiwania do replik w oryginalnym regionie z minimalnym wpływem na dzierżawy: brak utraty danych i minimalny okres poza wierszem na dzierżawę.

W tym samouczku te wyzwania zostały rozwiązane przy użyciu funkcji usługi Azure SQL Database i platformy Azure:

• 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 serwerów produkcyjnych i elastycznych pul w regionie odzyskiwania.
• Replikacja geograficzna w celu utworzenia asynchronicznie replikowanych sekund tylko do odczytu dla wszystkich baz danych. Podczas awarii przełączysz repliki w tryb failover w regionie odzyskiwania. Po rozwiązaniu awarii wróć do baz danych w oryginalnym regionie bez utraty danych.
• Asynchroniczne operacje trybu failover wysyłane w kolejności priorytetu dzierżawy, aby zminimalizować czas pracy w trybie failover dla dużej liczby baz danych.
• Funkcje odzyskiwania zarządzania fragmentami w celu zmiany wpisów bazy danych w wykazie podczas odzyskiwania i repatriacji. Te funkcje umożliwiają aplikacji łączenie się z bazami danych dzierżaw niezależnie od lokalizacji bez konieczności ponownego konfigurowania aplikacji.
• Aliasy DNS serwera SQL, aby umożliwić bezproblemową aprowizację nowych dzierżaw niezależnie od regionu, w którym działa aplikacja. Aliasy DNS są również używane do umożliwienia procesowi synchronizacji katalogu nawiązywania połączenia z aktywnym wykazem niezależnie od jego lokalizacji.

Pobieranie skryptów odzyskiwania po awarii

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.

Skrypty odzyskiwania używane w tym samouczku i kod źródłowy aplikacji Wingtip są dostępne w bazie danych SaaS biletów Wingtip 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.

Samouczek — omówienie

W tym samouczku najpierw użyjesz replikacji geograficznej, aby utworzyć repliki aplikacji Wingtip Tickets i jej baz danych w innym regionie. Następnie przełączysz w tryb failover do tego regionu, aby symulować odzyskiwanie po awarii. Po zakończeniu aplikacja jest w pełni funkcjonalna w regionie odzyskiwania.

Później w osobnym kroku repatriacji przełączysz katalog i bazy danych dzierżaw w regionie odzyskiwania do oryginalnego regionu w trybie failover. Aplikacja i bazy danych pozostają dostępne w trakcie repatriacji. Po zakończeniu aplikacja jest w pełni funkcjonalna w oryginalnym regionie.

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.

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 <użytkownika> 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ę. PORADA: Umieść kursor myszy nad lokalizacją, aby powiększyć ekran.

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

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

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

   • Zwróć uwagę na region, w którym są wdrażane serwery.

Synchronizacja konfiguracji dzierżawy z wykazem

W tym zadaniu uruchomisz proces, który synchronizuje konfigurację serwerów, elastycznych pul i baz danych z wykazem dzierżaw. Ten proces zapewnia aktualność tych informacji w katalogu. Proces współpracuje z aktywnym wykazem, zarówno w oryginalnym regionie, jak i w regionie odzyskiwania. Informacje o konfiguracji są używane w ramach procesu odzyskiwania w celu zapewnienia, że środowisko odzyskiwania jest zgodne z oryginalnym środowiskiem, a następnie później podczas repatriacji w celu zapewnienia, że oryginalny region jest zgodny z wszelkimi zmianami wprowadzonych w środowisku odzyskiwania. Wykaz jest również używany do śledzenia stanu odzyskiwania zasobów dzierżawy

Ważne

Dla uproszczenia proces synchronizacji i inne długotrwałe procesy odzyskiwania i repatriacji są implementowane w tych samouczkach jako lokalne zadania programu PowerShell lub sesje uruchamiane w ramach logowania użytkownika klienta. Tokeny uwierzytelniania wystawione podczas logowania wygasną po kilku godzinach, a następnie 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-FailoverToReplica\Demo-FailoverToReplica.ps1 i ustaw:

   • $DemoScenario = 1, uruchom zadanie w tle, które synchronizuje serwer dzierżawy i informacje o konfiguracji puli do katalogu

3. Naciśnij F5 , aby uruchomić skrypt synchronizacji. Zostanie otwarta nowa sesja programu PowerShell w celu zsynchronizowania konfiguracji zasobów dzierżawy.

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

Uwaga

Proces synchronizacji łączy się z wykazem za pośrednictwem aliasu DNS. Ten 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.

Tworzenie pomocniczych replik bazy danych w regionie odzyskiwania

W tym zadaniu uruchomisz proces, który wdraża zduplikowane wystąpienie aplikacji i replikuje katalog i wszystkie bazy danych dzierżawy do regionu odzyskiwania.

Uwaga

W tym samouczku dodano ochronę replikacji geograficznej do przykładowej aplikacji Wingtip Tickets. W scenariuszu produkcyjnym dla aplikacji korzystającej z replikacji geograficznej każda dzierżawa zostanie aprowizowana z bazą danych z replikacją geograficzną od samego początku. Zobacz Projektowanie usług o wysokiej dostępności przy użyciu usługi Azure SQL Database

1. W programie PowerShell ISE otwórz skrypt ...\Learning Modules\Business Continuity and Disaster Recovery\DR-FailoverToReplica\Demo-FailoverToReplica.ps1 i ustaw następujące wartości:

   • $DemoScenario = 2, utwórz środowisko odzyskiwania obrazu dublowanego i replikuj bazy danych katalogu i dzierżawy

2. Naciśnij klawisz F5, aby uruchomić skrypt. Zostanie otwarta nowa sesja programu PowerShell w celu utworzenia replik.

Przeglądanie normalnego stanu aplikacji

W tym momencie aplikacja działa normalnie w oryginalnym regionie, a teraz jest chroniona przez replikację geograficzną. Repliki pomocnicze tylko do odczytu istnieją w regionie odzyskiwania dla wszystkich baz danych.

1. W witrynie Azure Portal przyjrzyj się grupom zasobów i zwróć uwagę, że grupa zasobów została utworzona z sufiksem -recovery w regionie odzyskiwania.

2. Zapoznaj się z zasobami w grupie zasobów odzyskiwania.

3. Kliknij bazę danych Contoso Concert Hall na serwerze tenants1-dpt-user-recovery><. Kliknij pozycję Replikacja geograficzna po lewej stronie.

   

Na mapie regionów platformy Azure zanotuj link replikacji geograficznej między elementem podstawowym w oryginalnym regionie a pomocniczym w regionie odzyskiwania.

Przełącz aplikację w tryb failover do regionu odzyskiwania

Omówienie procesu odzyskiwania replikacji geograficznej

Skrypt odzyskiwania wykonuje następujące zadania:

1. Wyłącza punkt końcowy usługi 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. Używa wymuszonego trybu failover bazy danych katalogu w regionie odzyskiwania, aby uczynić ją podstawową bazą danych, a następnie aktualizuje alias activecatalog , aby wskazywał serwer wykazu odzyskiwania.

3. Aktualizuje alias nowego dzierżawcy, aby wskazywał serwer dzierżawy w regionie odzyskiwania. Zmiana tego aliasu gwarantuje, że bazy danych dla wszystkich nowych dzierżaw są aprowidowane w regionie odzyskiwania.

4. Oznacza wszystkie istniejące dzierżawy w wykazie odzyskiwania jako offline, aby zapobiec dostępowi do baz danych dzierżawy przed ich przełączeniem w tryb failover.

5. Aktualizuje konfigurację wszystkich elastycznych pul i replikowanych pojedynczych baz danych w regionie odzyskiwania w celu zdublowania ich konfiguracji w oryginalnym regionie. (To zadanie jest wymagane tylko wtedy, gdy pule lub zreplikowane bazy danych w środowisku odzyskiwania są skalowane w dół podczas normalnych operacji w celu zmniejszenia kosztów).

6. 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.

7. Przesyła partie żądań w celu wymuszenia przełączenia baz danych w tryb failover w kolejności priorytetów.

   • Partie są zorganizowane tak, aby bazy danych zostały przełączone w tryb failover równolegle we wszystkich pulach.
   • Żądania trybu failover są przesyłane przy użyciu operacji asynchronicznych, dzięki czemu są one przesyłane szybko, a wiele żądań można przetwarzać jednocześnie.

   Uwaga

   W scenariuszu awarii podstawowe bazy danych w oryginalnym regionie są w trybie offline. Wymuś przejście w tryb failover na pomocniczym przerywa połączenie z serwerem podstawowym bez próby zastosowania żadnych pozostałych transakcji w kolejce. W scenariuszu testowania odzyskiwania po awarii, takim jak w tym samouczku, w momencie przejścia w tryb failover jakiekolwiek działanie aktualizacji może spowodować utratę danych. Później podczas repatriacji podczas przełączania baz danych w tryb failover w regionie odzyskiwania z powrotem do oryginalnego regionu jest używany normalny tryb failover w celu zapewnienia braku utraty danych.

8. Monitoruje usługę w celu określenia, kiedy bazy danych zostały przełączone w tryb failover. Gdy baza danych dzierżawy zostanie przełączona w tryb failover, zaktualizuje katalog, aby zarejestrować stan odzyskiwania bazy danych dzierżawy i oznaczyć dzierżawę jako online.

   • 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 wartość 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 w trybie failover w regionie odzyskiwania

Teraz wyobraź sobie, że w regionie, w którym jest wdrożona aplikacja, i uruchom skrypt odzyskiwania:

1. W programie PowerShell ISE otwórz skrypt ...\Learning Modules\Business Continuity and Disaster Recovery\DR-FailoverToReplica\Demo-FailoverToReplica.ps1 i ustaw następujące wartości:

   • $DemoScenario = 3, Odzyskaj aplikację do regionu odzyskiwania, przechodząc w tryb failover do replik

2. Naciśnij klawisz F5, aby uruchomić skrypt.

   • Skrypt zostanie otwarty w nowym oknie programu PowerShell, a następnie uruchomi serię zadań programu PowerShell, które są uruchamiane równolegle. Te zadania przejmą bazy danych dzierżawy w tryb failover 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-FailoverToReplica\RecoveryJobs.

Przeglądanie stanu aplikacji podczas odzyskiwania

Gdy punkt końcowy aplikacji jest wyłączony w usłudze Traffic Manager, aplikacja jest niedostępna. Gdy wykaz zostanie przełączony w tryb failover do regionu odzyskiwania i wszystkie dzierżawy oznaczone w trybie offline, aplikacja zostanie przywrócona w trybie online. Mimo że aplikacja jest dostępna, każda dzierżawa jest wyświetlana w trybie offline w centrum zdarzeń, dopóki jej baza danych nie zostanie przełączona w tryb failover. Ważne jest, aby zaprojektować aplikację do obsługi baz danych dzierżaw w trybie offline.

1. Natychmiast po odzyskaniu bazy danych katalogu odśwież centrum zdarzeń Wingtip Tickets w przeglądarce internetowej.

   • W stopce zwróć uwagę, że nazwa serwera wykazu 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ć.

     Uwaga

     Po odzyskaniu tylko kilku baz danych może nie być możliwe odświeżenie przeglądarki przed zakończeniem odzyskiwania, więc dzierżawy mogą nie być widoczne w trybie offline.

     

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

Aprowizuj nową dzierżawę w regionie odzyskiwania

Nawet zanim wszystkie istniejące bazy danych dzierżawy zostały przełączone w tryb failover, możesz aprowizować nowe dzierżawy w regionie odzyskiwania.

1. W programie PowerShell ISE otwórz skrypt ...\Learning Modules\Business Continuity and Disaster Recovery\DR-FailoverToReplica\Demo-FailoverToReplica.ps1 i ustaw następującą właściwość:

   • $DemoScenario = 4 aprowizuj nową dzierżawę w regionie odzyskiwania

2. Naciśnij F5 , aby uruchomić skrypt i aprowizować nową dzierżawę.

3. Strona zdarzeń Hawthorn Hall zostanie otwarta w przeglądarce po zakończeniu. Zwróć uwagę na stopkę, że baza danych Hawthorn Hall jest aprowizowana w regionie odzyskiwania.

4. W przeglądarce odśwież stronę Centrum zdarzeń Wingtip Tickets, aby zobaczyć uwzględniona hala Hawthorn.

   • 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 pojawią się online, w tym nowa dzierżawa, Hawthorn Hall.

   

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

   • Zwróć uwagę na wdrożona grupa zasobów oraz grupę zasobów odzyskiwania z sufiksem -recovery . Grupa zasobów odzyskiwania zawiera wszystkie zasoby utworzone podczas procesu odzyskiwania oraz nowe zasoby utworzone podczas awarii.

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

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

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

   • Usługa App Service o nazwie events-wingtip-dpt-recoveryregion-user<<>>, czyli wystąpienie odzyskiwania aplikacji Zdarzenia.

     

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

5. Wróć do grupy zasobów i kliknij bazę danych Contoso Concert Hall na serwerze tenants1-dpt-user-recovery<>. Kliknij pozycję Replikacja geograficzna po lewej stronie.

   

Zmienianie danych dzierżawy

W tym zadaniu zaktualizujesz jedną z baz danych dzierżawy.

1. W przeglądarce znajdź listę zdarzeń dla sali koncertowej Contoso i zanotuj nazwisko wydarzenia.
2. W programie PowerShell ISE w skrypcie ...\Learning Modules\Business Continuity and Disaster Recovery\DR-FailoverToReplica\Demo-FailoverToReplica.ps1 ustaw następującą wartość:
   • $DemoScenario = 5 Usuń zdarzenie z dzierżawy w regionie odzyskiwania
3. Naciśnij F5 , aby wykonać skrypt
4. Odśwież stronę zdarzeń w sali koncertowej Contoso (http://events.wingtip-dpt.<user.trafficmanager.net/contosoconcerthall> — zastąp <użytkownika> wartością użytkownika wdrożenia) i zwróć uwagę, że ostatnie wydarzenie zostało usunięte.

Repatriuj aplikację do oryginalnego regionu produkcyjnego

To zadanie ponownie spatytuje aplikację w jej oryginalnym regionie. W rzeczywistym scenariuszu należy zainicjować repatriację po rozwiązaniu awarii.

Omówienie procesu repatriacji

Proces repatriacji:

1. Anuluje wszystkie zaległe lub w locie żądania przywracania bazy danych.
2. Aktualizuje alias nowego dzierżawcy, aby wskazywał serwer dzierżawy w regionie pochodzenia. Zmiana tego aliasu gwarantuje, że bazy danych dla wszystkich nowych dzierżaw będą teraz aprowizowane w regionie pochodzenia.
3. Zasiewuj wszystkie zmienione dane dzierżawy do oryginalnego regionu
4. W trybie failover bazy danych dzierżawy w kolejności priorytetu.

Tryb failover skutecznie przenosi bazę danych do oryginalnego regionu. Gdy baza danych ulegnie awarii, wszystkie otwarte połączenia zostaną porzucone, a baza danych będzie niedostępna przez kilka sekund. Aplikacje powinny być zapisywane za pomocą logiki ponawiania prób, aby upewnić się, że nawiążą połączenie ponownie. Chociaż ten krótki rozłączenie nie jest często zauważane, możesz zdecydować się na repatriację baz danych poza godzinami pracy.

Uruchamianie skryptu repatriacji

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

1. W programie PowerShell ISE w skrypcie ...\Learning Modules\Business Continuity and Disaster Recovery\DR-FailoverToReplica\Demo-FailoverToReplica.ps1.

2. Sprawdź, czy proces synchronizacji katalogu jest nadal uruchomiony w swoim wystąpieniu programu PowerShell. W razie potrzeby uruchom je ponownie, ustawiając następujące ustawienia:

   • $DemoScenario = 1, Rozpocznij synchronizowanie informacji o konfiguracji serwera dzierżawy, puli i bazy danych w wykazie
   • Naciśnij klawisz F5, aby uruchomić skrypt.

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

   • $DemoScenario = 6, repatriuj aplikację do jej oryginalnego regionu
   • Naciśnij F5 , aby uruchomić skrypt odzyskiwania w nowym oknie programu PowerShell. Repatriacja potrwa kilka minut i może być monitorowana w oknie programu PowerShell.

4. 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.

5. Po zakończeniu repatriacji odśwież centrum Zdarzenia i otwórz stronę zdarzeń dla Hawthorn Hall. Zwróć uwagę, że ta baza danych została repatriowana do oryginalnego regionu.

Projektowanie aplikacji w celu zapewnienia kolokacji aplikacji i bazy danych

Aplikacja została zaprojektowana tak, aby zawsze łączyła 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 pewien 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. W usłudze SQL Database 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:

• Synchronizowanie informacji o konfiguracji bazy danych i puli elastycznej z wykazem dzierżaw
• Konfigurowanie środowiska odzyskiwania w regionie alternatywnym obejmującym aplikacje, serwery i pule
• Replikacja geograficzna służy do replikowania katalogów i baz danych dzierżawy do regionu odzyskiwania
• Przełącz aplikację i katalog i bazy danych dzierżawy w tryb failover do regionu odzyskiwania
• Powrót po awarii aplikacji, katalogu i baz danych dzierżawy do oryginalnego regionu po rozwiązaniu awarii

Więcej informacji na temat technologii zapewnianych przez usługę Azure SQL Database w celu zapewnienia ciągłości działania w dokumentacji przeglądu ciągłości działalności biznesowej.

Dodatkowe zasoby

• Dodatkowe samouczki oparte na aplikacji SaaS Wingtip