Uruchamianie aplikacji N-warstwowej w wielu regionach usługi Azure Stack Hub w celu zapewnienia wysokiej dostępności

Ta architektura referencyjna przedstawia zestaw sprawdzonych rozwiązań dotyczących uruchamiania w wielu regionach usługi Azure Stack Hub w ramach aplikacji N-warstwowej w celu zapewnienia dostępności i niezawodnej infrastruktury odzyskiwania po awarii. W tym dokumencie usługa Traffic Manager jest używana do osiągnięcia wysokiej dostępności, jednak jeśli usługa Traffic Manager nie jest preferowanym wyborem w danym środowisku, można również zastąpić parę modułów równoważenia obciążenia o wysokiej dostępności.

Uwaga

Należy pamiętać, że usługa Traffic Manager używana w poniższej architekturze musi być skonfigurowana na platformie Azure, a punkty końcowe używane do konfigurowania profilu usługi Traffic Manager muszą być publicznie routingowymi adresami IP.

Architektura

Ta architektura opiera się na architekturze pokazanej w aplikacji N-warstwowej z SQL Server.

• Region podstawowy i pomocniczy. Aby osiągnąć wyższą dostępność, użyj dwóch regionów. Jeden jest regionem podstawowym. Drugi region jest przeznaczony dla trybu failover.

• Azure Traffic Manager. Usługa Traffic Manager kieruje żądania przychodzące do jednego z regionów. Podczas wykonywania zwykłych operacji kieruje żądania do regionu podstawowego. Jeśli ten region staje się niedostępny, usługa Traffic Manager przechodzi w trybie failover do regionu pomocniczego. Aby uzyskać więcej informacji, zobacz sekcję Konfiguracja usługi Traffic Manager.

• Grupy zasobów. Utwórz oddzielne grupy zasobów dla regionu podstawowego, regionu pomocniczego. Umożliwi to elastyczne zarządzanie każdym regionem jak pojedynczą kolekcją zasobów. Na przykład możesz ponownie wdrożyć jeden region, bez konieczności wyłączania drugiego. Połącz grupy zasobów, aby umożliwić uruchamianie zapytania wyświetlającego listę wszystkich zasobów dotyczących aplikacji.

• Sieci wirtualne. Utwórz oddzielną sieć wirtualną dla każdego regionu. Upewnij się, że przestrzenie adresowe nie nakładają się na siebie.

• SQL Server zawsze włączoną grupę dostępności. Jeśli używasz programu SQL Server, w celu uzyskania wysokiego poziomu dostępności zalecamy korzystanie z zawsze włączonych grup dostępności SQL. Utwórz pojedynczą grupę dostępności zawierającą wystąpienia programu SQL Server w obu regionach.

• Połączenie sieci VPN sieci wirtualnej z siecią wirtualną. Ponieważ komunikacja równorzędna sieci wirtualnych nie jest jeszcze dostępna w usłudze Azure Stack Hub, użyj sieci wirtualnej do połączenia sieci VPN sieci wirtualnej, aby połączyć te dwie sieci wirtualne. Aby uzyskać więcej informacji, zobacz Sieć wirtualna do sieci wirtualnej w usłudze Azure Stack Hub .

Zalecenia

Architektura obejmująca wiele regionów może zapewnić większą dostępność niż wdrożenie w pojedynczym regionie. W przypadku wystąpienia regionalnej awarii, która będzie miała wpływ na region podstawowy, korzystając z usługi Traffic Manager, możesz przejść w trybie failover do regionu pomocniczego. Ta architektura może również pomóc w przypadku awarii poszczególnych podsystemów aplikacji.

Istnieje kilka ogólnych metod umożliwiających osiągnięcie wysokiej dostępności we wszystkich regionach:

• Aktywne/pasywne z gorącą rezerwą. Ruch jest przesyłany do jednego regionu, a drugi w tym czasie czeka w trybie rezerwy dynamicznej. Rezerwa dynamiczna oznacza, że maszyny wirtualne w regionie pomocniczym są przydzielone i przez cały czas uruchomione.

• Aktywne/pasywne z zimnym wstrzymaniem. Ruch jest przesyłany do jednego regionu, a drugi w tym czasie czeka w trybie rezerwy w stanie zimnym. Rezerwa w stanie zimnym oznacza, że maszyny wirtualne w regionie pomocniczym nie są przydzielone, dopóki nie będą potrzebne w trybie failover. Uruchomienie tej metody jest tańsze, ale na ogół przejście w tryb online po wystąpieniu awarii trwa dłużej.

• Aktywne/aktywne. Oba regiony są aktywne, a obciążenie żądaniami jest równomiernie rozkładane między nimi. Jeśli jeden region staje się niedostępny, jest wykluczany z cyklu.

W tej architekturze referencyjnej skoncentrowano się na metodzie „aktywny/pasywny z rezerwą dynamiczną”, a tryb failover korzysta z usługi Traffic Manager. Można wdrożyć niewielką liczbę maszyn wirtualnych na potrzeby rezerwy dynamicznej, a następnie skalować w poziomie zgodnie z potrzebami.

Konfiguracja usługi Traffic Manager

Podczas konfigurowania usługi Traffic Manager weź pod uwagę następujące kwestie:

• Routing. Usługa Traffic Manager obsługuje kilka algorytmów routingu. Na potrzeby scenariusza opisanego w tym artykule zastosuj routing oparty na priorytecie (nazywany wcześniej routingiem dla trybu failover). Przy tym ustawieniu usługa Traffic Manager wysyła wszystkie żądania do regionu podstawowego, chyba że region podstawowy staje się niedostępny. W tym momencie automatycznie przechodzi w trybie failover do regionu pomocniczego. Zobacz Konfigurowanie metody routingu dla trybu failover.

• Sonda kondycji. Usługa Traffic Manager monitoruje dostępność każdego regionu za pomocą sondy HTTP (lub HTTPS). Sonda sprawdza odpowiedź HTTP 200 dla określonej ścieżki URL. Najlepszym rozwiązaniem jest utworzenie punktu końcowego, który będzie zgłaszał ogólną kondycję aplikacji, i używanie tego punktu końcowego na potrzeby sondy kondycji. W przeciwnym razie sonda może zgłaszać, że punkt końcowy jest w dobrej kondycji, podczas gdy krytyczne części aplikacji faktycznie nie działają prawidłowo. Aby uzyskać więcej informacji, zobacz Wzorzec monitorowania punktu końcowego kondycji.

Po przejściu usługi Traffic Manager w tryb failover klienci przez pewien czas nie mogą uzyskać dostępu do aplikacji. Na ten czas mają wpływ następujące czynniki:

• Sonda kondycji musi wykryć, że region podstawowy stał się niedostępny.

• Serwery DNS muszą zaktualizować rekordy DNS adresu IP w pamięci podręcznej, co zależy od czasu wygaśnięcia (TTL) DNS. Domyślny czas wygaśnięcia wynosi 300 sekund (5 minut), ale możesz skonfigurować tę wartość podczas tworzenia profilu usługi Traffic Manager.

Aby uzyskać szczegółowe informacje, zobacz About Traffic Manager Monitoring (Informacje dotyczące monitorowania usługi Traffic Manager).

W przypadku przejścia usługi Traffic Manager w tryb failover zalecamy przeprowadzenie ręcznego powrotu po awarii, zamiast implementowania automatycznego powrotu po awarii. W przeciwnym razie może powstać sytuacja, w której aplikacja będzie przełączała się tam i z powrotem między regionami. Przed powrotem po awarii sprawdź, czy wszystkie podsystemy aplikacji są w dobrej kondycji.

Pamiętaj, że domyślnie usługa Traffic Manager wraca po awarii automatycznie. Aby tego uniknąć, po wystąpieniu zdarzenia przejścia w tryb failover obniż ręcznie priorytet regionu podstawowego. Na przykład załóżmy, że region podstawowy ma priorytet 1, a pomocniczy — 2. Po przejściu w tryb failover ustaw dla regionu podstawowego priorytet 3, aby uniknąć automatycznego powrotu po awarii. Gdy wszystko będzie gotowe do przełączenia, zaktualizuj priorytet do 1.

Następujące polecenie interfejsu wiersza polecenia platformy Azure powoduje zaktualizowanie priorytetu:

az network traffic-manager endpoint update --resource-group <resource-group> --profile-name <profile>
    --name <endpoint-name> --type externalEndpoints --priority 3

Innym rozwiązaniem jest tymczasowe wyłączenie punktu końcowego do czasu, aż wszystko będzie gotowe do powrotu po awarii:

az network traffic-manager endpoint update --resource-group <resource-group> --profile-name <profile>
    --name <endpoint-name> --type externalEndpoints --endpoint-status Disabled

W zależności od przyczyny przejścia w tryb failover może być konieczne ponowne wdrożenie zasobów w obrębie regionu. Przed powrotem po awarii wykonaj test gotowości do działania. Test powinien sprawdzić m.in., czy:

• Maszyny wirtualne są poprawnie skonfigurowane. (Całe wymagane oprogramowanie jest zainstalowane, usługi IIS działają itd.).

• Podsystemy aplikacji są w dobrej kondycji.

• Aplikacja jest funkcjonalna. (Na przykład warstwa bazy danych jest dostępna z warstwy internetowej).

Konfigurowanie zawsze włączonych grup dostępności programu SQL Server

W systemach starszych niż Windows Server 2016 zawsze włączone grupy dostępności programu SQL Server wymagają kontrolera domeny, a wszystkie węzły w grupie dostępności muszą znajdować się w tej samej domenie usługi Active Directory (AD).

Aby skonfigurować grupę dostępności:

• Umieść co najmniej dwa kontrolery domeny w każdym regionie.

• Do każdego kontrolera domeny przypisz statyczny adres IP.

• Utwórz sieć VPN , aby umożliwić komunikację między dwiema sieciami wirtualnymi.

• Dla każdej sieci wirtualnej dodaj adresy IP kontrolerów domeny (z obu regionów) do listy serwerów DNS. Możesz użyć poniższego polecenia interfejsu wiersza polecenia. Aby uzyskać więcej informacji, zobacz Zmienianie serwerów DNS.

  az network vnet update --resource-group <resource-group> --name <vnet-name> --dns-servers "10.0.0.4,10.0.0.6,172.16.0.4,172.16.0.6"
  

• Utwórz klaster usługi Windows Server Failover Clustering (WSFC) zawierający wystąpienia programu SQL Server w obu regionach.

• Utwórz zawsze włączoną grupę dostępności programu SQL Server zawierającą wystąpienia programu SQL Server zarówno w regionie podstawowym, jak i pomocniczym. Aby uzyskać instrukcje, zobacz Extending Always On Availability Group to Remote Azure Datacenter (PowerShell) (Rozszerzanie zawsze włączonej grupy dostępności na zdalne centrum danych platformy Azure (PowerShell)).

  • Umieść replikę podstawową w regionie podstawowym.

  • Umieść co najmniej jedną replikę pomocniczą w regionie podstawowym. Skonfiguruj je tak, aby używały zatwierdzania synchronicznego z automatycznym przełączaniem w tryb failover.

  • Umieść co najmniej jedną replikę pomocniczą w regionie pomocniczym. Skonfiguruj zatwierdzanie asynchroniczne ze względu na wydajność. (W przeciwnym razie wszystkie transakcje T-SQL będą musiały czekać na komunikację dwustronną z regionem pomocniczym za pośrednictwem sieci).

Uwaga

Repliki zatwierdzeń asynchronicznych nie obsługują automatycznego trybu failover.

Zagadnienia dotyczące dostępności

W przypadku złożonej aplikacji n-warstwowej replikacja całej aplikacji w regionie pomocniczym może nie być potrzebna. Zamiast tego możesz replikować tylko krytyczny podsystem, który jest potrzebny do obsługi ciągłości prowadzenia działalności biznesowej.

Usługa Traffic Manager jest punktem systemu, w którym mogą występować awarie. Jeśli usługa Traffic Manager ulegnie awarii, klienci nie będą mieli dostępu do aplikacji podczas przestoju. Zapoznaj się z dokumentem Traffic Manager — umowa SLA i ustal, czy korzystanie z samej usługi Traffic Manager spełnia Twoje wymagania biznesowe w zakresie wysokiej dostępności. Jeśli nie, rozważ dodanie kolejnego rozwiązania do zarządzania ruchem w ramach powrotu po awarii. W przypadku awarii usługi Azure Traffic Manager zmień rekordy CNAME w systemie DNS, aby wskazać inną usługę zarządzania ruchem. (Ten krok musisz wykonać ręcznie, a aplikacja będzie niedostępna do czasu rozpropagowania zmian systemu DNS).

W przypadku klastra SQL Server trzeba rozważyć dwa scenariusze trybu failover:

• Wszystkie repliki bazy danych programu SQL Server w regionie podstawowym nie działają. Na przykład może się to zdarzyć podczas awarii obejmującej cały region. W takim przypadku musisz ręcznie przełączyć grupę dostępności w tryb failover, mimo że usługa Traffic Manager automatycznie przechodzi w ten tryb na frontonie. Wykonaj kroki podane w artykule Perform a Forced Manual Failover of a SQL Server Availability Group (Wykonywanie wymuszonego, ręcznego przejścia grupy dostępności programu SQL Server w tryb failover), w którym opisano sposób wykonywania wymuszonego przejścia w tryb failover przy użyciu programu SQL Server Management Studio, Transact-SQL lub powłoki PowerShell w programie SQL Server 2016.

  Ostrzeżenie

  W przypadku wymuszonego przejścia w tryb failover istnieje ryzyko utraty danych. Po powrocie regionu podstawowego do trybu online wykonaj migawkę bazy danych i użyj narzędzia tablediff, aby znaleźć różnice.

• Program Traffic Manager awaryjnie przechodzi w tryb awaryjny do regionu pomocniczego, ale podstawowa replika bazy danych programu SQL Server jest nadal dostępna. Na przykład warstwa frontonu może ulec awarii bez wpływu na maszyny wirtualne programu SQL Server. W takim przypadku ruch internetowy jest kierowany do regionu pomocniczego, który nadal może łączyć się z repliką podstawową. Jednak powoduje to zwiększenie opóźnienia, ponieważ program SQL Server nawiązuje połączenia między regionami. W takiej sytuacji wykonaj ręczne przejście do trybu failover w następujący sposób:

  1. Tymczasowo przełącz replikę bazy danych programu SQL Server w regionie pomocniczym na zatwierdzanie synchroniczne. Dzięki temu w trybie failover nie nastąpi utrata danych.

  2. Przełącz tę replikę w tryb failover.

  3. Gdy wrócisz po awarii do regionu podstawowego, przywróć ustawienie zatwierdzania asynchronicznego.

Zagadnienia dotyczące możliwości zarządzania

Po zaktualizowaniu wdrożenia aktualizuj regiony pojedynczo, aby zmniejszyć możliwość wystąpienia błędu globalnego wynikającego z niepoprawnej konfiguracji lub błędu w aplikacji.

Przetestuj odporność systemu na awarie. Poniżej przedstawiono kilka typowych scenariuszy awarii do testowania:

• Wyłączenie wystąpień maszyn wirtualnych.

• Wykorzystanie zasobów, takich jak procesor CPU i pamięć.

• Odłączenie/opóźnienie sieci.

• Awarie procesów.

• Wygasłe certyfikaty.

• Symulacja awarii sprzętu.

• Wyłączenie usługi DNS na kontrolerach domeny.

Zmierz czasy odzyskiwania i sprawdź, czy spełniają wymagania biznesowe. Przetestuj również kombinacje trybów awarii.

Następne kroki

• Aby dowiedzieć się więcej na temat wzorców chmury platformy Azure, zobacz Wzorce projektowania chmury.