Zarządzanie uaktualnieniami stopniowego aplikacji w chmurze przy użyciu aktywnej replikacji geograficznej usługi SQL Database

Dotyczy:Azure SQL Database

Dowiedz się, jak używać aktywnej replikacji geograficznej w usłudze Azure SQL Database, aby włączyć uaktualnienia stopniowe aplikacji w chmurze. Ponieważ uaktualnienia są operacjami destrukcyjnymi, powinny one być częścią planowania i projektowania ciągłości działania firmy. W tym artykule przyjrzymy się dwóm różnym metodom organizowania procesu uaktualniania i omawiamy korzyści i kompromisy poszczególnych opcji. Na potrzeby tego artykułu odwołujemy się do aplikacji składającej się z witryny internetowej połączonej z pojedynczą bazą danych jako warstwą danych. Naszym celem jest uaktualnienie wersji 1 (V1) aplikacji do wersji 2 (V2) bez znaczącego wpływu na środowisko użytkownika.

Podczas oceniania opcji uaktualniania należy wziąć pod uwagę następujące czynniki:

  • Wpływ na dostępność aplikacji podczas uaktualniania, na przykład czas, w jaki funkcje aplikacji mogą być ograniczone lub obniżone.
  • Możliwość wycofania, jeśli uaktualnienie zakończy się niepowodzeniem.
  • Luka w zabezpieczeniach aplikacji, jeśli podczas uaktualniania wystąpi niepowiązana awaria katastrofalna.
  • Całkowity koszt dolara. Ten czynnik obejmuje dodatkową nadmiarowość bazy danych i przyrostowe koszty składników tymczasowych używanych przez proces uaktualniania.

Uaktualnianie aplikacji korzystających z kopii zapasowych bazy danych na potrzeby odzyskiwania po awarii

Jeśli aplikacja korzysta z automatycznych kopii zapasowych bazy danych i używa przywracania geograficznego na potrzeby odzyskiwania po awarii, zostanie wdrożona w jednym regionie świadczenia usługi Azure. Aby zminimalizować zakłócenia użytkownika, utwórz środowisko przejściowe w tym regionie ze wszystkimi składnikami aplikacji zaangażowanymi w uaktualnienie. Pierwszy diagram ilustruje środowisko operacyjne przed procesem uaktualniania. Punkt końcowy contoso.azurewebsites.net reprezentuje środowisko produkcyjne aplikacji internetowej. Aby można było wycofać uaktualnienie, należy utworzyć środowisko przejściowe z w pełni zsynchronizowaną kopią bazy danych. Wykonaj następujące kroki, aby utworzyć środowisko przejściowe na potrzeby uaktualnienia:

  1. Utwórz pomocniczą bazę danych w tym samym regionie świadczenia usługi Azure. Monitoruj pomocniczą, aby sprawdzić, czy proces rozmieszczania został ukończony (1).
  2. Utwórz nowe środowisko dla aplikacji internetowej i wywołaj je jako "Przejściowe". Zostanie on zarejestrowany w usłudze Azure DNS przy użyciu adresu URL contoso-staging.azurewebsites.net (2).

Uwaga

Te kroki przygotowywania nie będą mieć wpływu na środowisko produkcyjne, które może działać w trybie pełnego dostępu.

Diagram shows the SQL Database geo-replication configuration for cloud disaster recovery.

Po zakończeniu kroków przygotowywania aplikacja jest gotowa do rzeczywistego uaktualnienia. Na następnym diagramie przedstawiono kroki związane z procesem uaktualniania:

  1. Ustaw podstawową bazę danych na tryb tylko do odczytu (3). Ten tryb gwarantuje, że środowisko produkcyjne aplikacji internetowej (V1) pozostaje tylko do odczytu podczas uaktualniania, co uniemożliwia rozbieżność danych między wystąpieniami bazy danych w wersji 1 i 2.
  2. Odłącz pomocniczą bazę danych przy użyciu trybu planowanego zakończenia (4). Ta akcja tworzy w pełni zsynchronizowaną, niezależną kopię podstawowej bazy danych. Ta baza danych zostanie uaktualniona.
  3. Przełącz pomocniczą bazę danych w tryb odczytu i zapisu i uruchom skrypt uaktualniania (5).

Diagram shows SQL Database geo-replication configuration for cloud disaster recovery that runs the upgrade script.

Jeśli uaktualnienie zakończy się pomyślnie, możesz teraz przełączyć użytkowników na uaktualnioną kopię aplikacji, która stanie się środowiskiem produkcyjnym. Przełączanie obejmuje kilka kolejnych kroków, jak pokazano na następnym diagramie:

  1. Aktywuj operację zamiany między środowiskami produkcyjnymi i przejściowymi aplikacji internetowej (6). Ta operacja przełącza adresy URL dwóch środowisk. Teraz contoso.azurewebsites.net wskazuje wersję 2 witryny internetowej i bazę danych (środowisko produkcyjne).
  2. Jeśli po zamianie nie potrzebujesz już wersji 1, która stała się tymczasową kopią, możesz zlikwidować środowisko przejściowe (7).

SQL Database geo-replication configuration for cloud disaster recovery.

Jeśli proces uaktualniania nie powiedzie się (na przykład z powodu błędu skryptu uaktualniania), rozważ naruszenie środowiska przejściowego. Aby przywrócić aplikację do stanu przed uaktualnieniem, przywróć aplikację w środowisku produkcyjnym, aby uzyskać pełny dostęp. Na następnym diagramie przedstawiono kroki zmiany wersji:

  1. Ustaw kopię bazy danych na tryb odczytu i zapisu (8). Ta akcja przywraca pełną funkcjonalność kopii produkcyjnej w wersji 1.
  2. Przeprowadź analizę głównej przyczyny i zlikwidowanie środowiska przejściowego (9).

W tym momencie aplikacja jest w pełni funkcjonalna i można powtórzyć kroki uaktualniania.

Uwaga

Wycofanie nie wymaga zmian DNS, ponieważ nie wykonaliśmy jeszcze operacji zamiany.

Diagram shows SQL Database geo-replication configuration for cloud disaster recovery with the staging environment decommissioned.

Kluczową zaletą tej opcji jest to, że można uaktualnić aplikację w jednym regionie, wykonując zestaw prostych kroków. Koszt dolara uaktualnienia jest stosunkowo niski.

Głównym kompromisem jest to, że jeśli podczas uaktualniania wystąpi awaria katastrofalna, odzyskiwanie do stanu przed uaktualnieniem obejmuje ponowne wdrożenie aplikacji w innym regionie i przywrócenie bazy danych z kopii zapasowej przy użyciu przywracania geograficznego. Ten proces powoduje znaczny przestój.

Uaktualnianie aplikacji korzystających z replikacji geograficznej bazy danych na potrzeby odzyskiwania po awarii

Jeśli aplikacja używa aktywnej replikacji geograficznej lub grup trybu failover na potrzeby ciągłości działania, zostanie wdrożona w co najmniej dwóch różnych regionach. W regionie podstawowym znajduje się aktywna podstawowa baza danych oraz pomocnicza baza danych tylko do odczytu w regionie kopii zapasowej. Oprócz czynników wymienionych na początku tego artykułu proces uaktualniania musi również zagwarantować, że:

  • Aplikacja pozostaje chroniona przed katastrofalnymi awariami przez cały czas w procesie uaktualniania.
  • Składniki geograficznie nadmiarowe aplikacji są uaktualniane równolegle z aktywnymi składnikami.

Aby osiągnąć te cele, oprócz korzystania ze środowisk Web Apps, skorzystasz z usługi Azure Traffic Manager przy użyciu profilu trybu failover z jednym aktywnym punktem końcowym i jednym punktem końcowym kopii zapasowej. Na następnym diagramie przedstawiono środowisko operacyjne przed procesem uaktualniania. Witryny contoso-1.azurewebsites.net internetowe i contoso-dr.azurewebsites.net reprezentują środowisko produkcyjne aplikacji z pełną nadmiarowością geograficzną. Środowisko produkcyjne obejmuje następujące składniki:

  • Środowisko produkcyjne aplikacji contoso-1.azurewebsites.net internetowej w regionie podstawowym (1)
  • Podstawowa baza danych w regionie podstawowym (2)
  • Wystąpienie rezerwowe aplikacji internetowej w regionie kopii zapasowej (3)
  • Pomocnicza baza danych replikowana geograficznie w regionie kopii zapasowej (4)
  • Profil wydajności usługi Traffic Manager z punktem końcowym online o nazwie i punktem końcowym offline o nazwie contoso-1.azurewebsites.netcontoso-dr.azurewebsites.net

Aby umożliwić wycofanie uaktualnienia, należy utworzyć środowisko przejściowe z w pełni zsynchronizowaną kopią aplikacji. Ze względu na to, że aplikacja może szybko odzyskać sprawność w przypadku wystąpienia katastrofalnego błędu podczas procesu uaktualniania, środowisko przejściowe musi być również geograficznie nadmiarowe. Do utworzenia środowiska przejściowego na potrzeby uaktualnienia wymagane są następujące kroki:

  1. Wdróż środowisko przejściowe aplikacji internetowej w regionie podstawowym (6).
  2. Utwórz pomocniczą bazę danych w podstawowym regionie świadczenia usługi Azure (7). Skonfiguruj środowisko przejściowe aplikacji internetowej, aby nawiązać z nią połączenie.
  3. Utwórz inną geograficznie nadmiarową, pomocniczą bazę danych w regionie kopii zapasowej, replikując pomocniczą bazę danych w regionie podstawowym. (Ta metoda jest nazywana łańcuchową replikacją geograficzną). (8).
  4. Wdróż środowisko przejściowe wystąpienia aplikacji internetowej w regionie kopii zapasowej (9) i skonfiguruj je w celu połączenia geograficznie nadmiarowej pomocniczej bazy danych utworzonej pod adresem (8).

Uwaga

Te kroki przygotowywania nie będą mieć wpływu na aplikację w środowisku produkcyjnym. Pozostanie ona w pełni funkcjonalna w trybie odczytu i zapisu.

Diagram shows SQL Database geo-replication configuration for cloud disaster recovery with a fully synchronized copy of the application.

Po zakończeniu kroków przygotowywania środowisko przejściowe jest gotowe do uaktualnienia. Na następnym diagramie przedstawiono następujące kroki uaktualniania:

  1. Ustaw podstawową bazę danych w środowisku produkcyjnym na tryb tylko do odczytu (10). Ten tryb gwarantuje, że produkcyjna baza danych (V1) nie ulegnie zmianie podczas uaktualniania, co uniemożliwia rozbieżność danych między wystąpieniami bazy danych w wersji 1 i 2.
-- Set the production database to read-only mode
ALTER DATABASE [<Prod_DB>]
SET READ_ONLY
  1. Zakończ replikację geograficzną, rozłączając pomocniczą (11). Ta akcja tworzy niezależną, ale w pełni zsynchronizowaną kopię produkcyjnej bazy danych. Ta baza danych zostanie uaktualniona. W poniższym przykładzie użyto języka Transact-SQL, ale program PowerShell jest również dostępny.
-- Disconnect the secondary, terminating geo-replication
ALTER DATABASE [<Prod_DB>]
REMOVE SECONDARY ON SERVER [<Partner-Server>]
  1. Uruchom skrypt uaktualniania względem contoso-1-staging.azurewebsites.netbazy danych , contoso-dr-staging.azurewebsites.neti tymczasowej podstawowej bazy danych (12). Zmiany bazy danych zostaną automatycznie zreplikowane do przejściowego pomocniczego.

Diagram shows SQL Database geo-replication configuration for cloud disaster recovery with database changes replicated to staging.

Jeśli uaktualnienie zakończy się pomyślnie, możesz teraz przełączyć użytkowników do wersji 2 aplikacji. Na następnym diagramie przedstawiono kroki, których dotyczy:

  1. Aktywuj operację zamiany między środowiskami produkcyjnymi i przejściowymi aplikacji internetowej w regionie podstawowym (13) i w regionie kopii zapasowej (14). Wersja 2 aplikacji staje się teraz środowiskiem produkcyjnym z nadmiarową kopią w regionie kopii zapasowej.
  2. Jeśli nie potrzebujesz już aplikacji w wersji 1 (15 i 16), możesz zlikwidować środowisko przejściowe.

Diagram shows SQL Database geo-replication configuration for cloud disaster recovery with optional decommissioning of the staging environment.

Jeśli proces uaktualniania nie powiedzie się (na przykład z powodu błędu skryptu uaktualniania), rozważ wystąpienie środowiska przejściowego w stanie niespójnym. Aby przywrócić aplikację do stanu przed uaktualnieniem, wróć do korzystania z wersji 1 aplikacji w środowisku produkcyjnym. Wymagane kroki są wyświetlane na następnym diagramie:

  1. Ustaw kopię podstawowej bazy danych w środowisku produkcyjnym na tryb odczytu i zapisu (17). Ta akcja przywraca pełną funkcjonalność V1 w środowisku produkcyjnym.
  2. Przeprowadź analizę głównej przyczyny i napraw lub usuń środowisko przejściowe (18 i 19).

W tym momencie aplikacja jest w pełni funkcjonalna i można powtórzyć kroki uaktualniania.

Uwaga

Wycofanie nie wymaga zmian DNS, ponieważ nie wykonaliśmy operacji zamiany.

Diagram shows SQL Database geo-replication configuration for cloud disaster recovery with the upgrade process rolled back.

Główną zaletą tej opcji jest możliwość uaktualnienia aplikacji i jej kopii geograficznie nadmiarowej równolegle bez naruszania ciągłości działania podczas uaktualniania.

Głównym kompromisem jest to, że wymaga podwójnej nadmiarowości każdego składnika aplikacji i dlatego wiąże się z wyższymi kosztami dolara. Obejmuje to również bardziej skomplikowany przepływ pracy.

Podsumowanie

Dwie metody uaktualniania opisane w artykule różnią się złożonością i kosztami dolara, ale koncentrują się na zminimalizowaniu czasu, przez jaki użytkownik jest ograniczony do operacji tylko do odczytu. Ten czas jest definiowany bezpośrednio przez czas trwania skryptu uaktualniania. Nie zależy to od rozmiaru bazy danych, wybranej warstwy usługi, konfiguracji witryny internetowej ani innych czynników, które nie można łatwo kontrolować. Wszystkie kroki przygotowywania są oddzielone od kroków uaktualniania i nie mają wpływu na aplikację produkcyjną. Wydajność skryptu uaktualniania jest kluczowym czynnikiem, który określa środowisko użytkownika podczas uaktualniania. Najlepszym sposobem na ulepszenie tego środowiska jest skoncentrowanie wysiłków na jak najbardziej wydajnym tworzeniu skryptu uaktualniania.