Wdrażanie w przedsiębiorstwie o wysokiej dostępności przy użyciu środowiska App Service Environment

Strefy dostępności są fizycznie oddzielone kolekcjami centrów danych w danym regionie. Wdrażanie zasobów w różnych strefach gwarantuje, że awarie ograniczone do strefy nie wpływają na dostępność aplikacji. Ta architektura pokazuje, jak można poprawić odporność wdrożenia środowiska App Service Environment przez wdrożenie go w architekturze redudant strefy. Te strefy nie są powiązane z sąsiedztwem. Mogą mapować na różne lokalizacje fizyczne dla różnych subskrypcji. Architektura zakłada wdrożenie z jedną subskrypcją.

Po skonfigurowaniu środowiska App Service Environment jako strefowo nadmiarowego platforma automatycznie wdraża wystąpienia planu usługi aplikacja systemu Azure w trzech strefach w wybranym regionie. W związku z tym minimalna liczba wystąpień planu usługi App Service to zawsze trzy.

Usługi platformy Azure obsługujące strefy dostępności mogą być strefowe, strefowo nadmiarowe lub oba. Usługi strefowe można wdrożyć w określonej strefie. Usługi strefowo nadmiarowe można automatycznie wdrażać w różnych strefach. Aby uzyskać szczegółowe wskazówki i zalecenia, zobacz Obsługa stref dostępności. Poprzednia wersja środowiska App Service Environment (wersja 2) obsługiwała tylko wdrożenia strefowe, ale bieżąca wersja (wersja 3) obsługuje wdrożenia strefowo nadmiarowe.

Implementacja referencyjna dla tej architektury jest dostępna w usłudze GitHub.

Architektura

Pobierz plik programu Visio z tą architekturą.

Zasoby w podsieciach środowiska App Service Environment w tej implementacji referencyjnej są takie same jak w standardowej architekturze wdrażania środowiska App Service Environment. Ta implementacja referencyjna używa strefowo nadmiarowych funkcji środowiska App Service Environment w wersji 3 i usługi Azure Cache for Redis w celu zapewnienia wyższej dostępności. Należy pamiętać, że zakres tej architektury referencyjnej jest ograniczony do jednego regionu.

Przepływ pracy

W tej sekcji opisano charakter dostępności usług używanych w tej architekturze:

• Środowisko App Service Environment w wersji 3 można skonfigurować pod kątem nadmiarowości strefy. Nadmiarowość stref można skonfigurować tylko podczas tworzenia środowiska App Service Environment i tylko w regionach, które obsługują wszystkie zależności środowiska App Service Environment w wersji 3. Każdy plan usługi App Service w strefowo nadmiarowym środowisku App Service Environment musi mieć co najmniej trzy wystąpienia, aby można je było wdrożyć w trzech strefach. Minimalna opłata dotyczy dziewięciu wystąpień. Aby uzyskać więcej informacji, zobacz te wskazówki dotyczące cen. Aby uzyskać szczegółowe wskazówki i zalecenia, zobacz Obsługa środowiska App Service Environment dla Strefy dostępności.

• Usługa Azure Virtual Network obejmuje wszystkie strefy dostępności, które znajdują się w jednym regionie. Podsieci w sieci wirtualnej również między strefami dostępności. Aby uzyskać więcej informacji, zobacz wymagania dotyczące sieci dla środowiska App Service Environment.

• Usługa Application Gateway w wersji 2 jest strefowo nadmiarowa. Podobnie jak sieć wirtualna, obejmuje wiele stref dostępności na region. W związku z tym jedna brama aplikacji jest wystarczająca dla systemu o wysokiej dostępności, jak pokazano w architekturze referencyjnej. Architektura referencyjna używa jednostki SKU zapory aplikacji internetowej usługi Application Gateway, która zapewnia zwiększoną ochronę przed typowymi zagrożeniami i lukami w zabezpieczeniach na podstawie implementacji podstawowego zestawu reguł (CRS) projektu Open Web Application Security Project (OWASP). Aby uzyskać więcej informacji, zobacz Scaling Application Gateway v2 and WAF v2 (Skalowanie usługi Application Gateway w wersji 2 i zapory aplikacji internetowej w wersji 2).

• Usługa Azure Firewall ma wbudowaną obsługę wysokiej dostępności. Może przekraczać wiele stref bez dodatkowej konfiguracji.

  Jeśli chcesz, możesz również skonfigurować określoną strefę dostępności podczas wdrażania zapory. Aby uzyskać więcej informacji, zobacz Azure Firewall i Strefy dostępności. (Ta konfiguracja nie jest używana w architekturze referencyjnej).

• Microsoft Entra ID to wysoce dostępna, wysoce nadmiarowa usługa globalna obejmująca strefy dostępności i regiony. Aby uzyskać więcej informacji, zobacz Postęp dostępności firmy Microsoft Entra.

• Funkcja GitHub Actions zapewnia funkcje ciągłej integracji i ciągłego wdrażania (CI/CD) w tej architekturze. Ponieważ środowisko App Service Environment znajduje się w sieci wirtualnej, maszyna wirtualna jest używana jako serwer przesiadkowy w sieci wirtualnej do wdrażania aplikacji w planach usługi App Service. Akcja kompiluje aplikacje poza siecią wirtualną. W celu zapewnienia zwiększonych zabezpieczeń i bezproblemowej łączności RDP/SSH rozważ użycie usługi Azure Bastion dla serwera przesiadkowego.

• Azure Cache for Redis to usługa strefowo nadmiarowa. Pamięć podręczna strefowo nadmiarowa jest uruchamiana na maszynach wirtualnych wdrożonych w wielu strefach dostępności. Ta usługa zapewnia większą odporność i dostępność.

Kwestie wymagające rozważenia

Te zagadnienia implementują filary platformy Azure Well-Architected Framework, która jest zestawem wytycznych, których można użyć do poprawy jakości obciążenia. Aby uzyskać więcej informacji, zobacz Microsoft Azure Well-Architected Framework.

Dostępność

Środowisko usługi App Service

Środowisko App Service Environment można wdrożyć w różnych strefach dostępności, aby zapewnić odporność i niezawodność obciążeń o krytycznym znaczeniu dla działania firmy. Ta konfiguracja jest również nazywana nadmiarowością stref.

Podczas implementowania nadmiarowości strefy platforma automatycznie wdraża wystąpienia planu usługi App Service w trzech strefach w wybranym regionie. W związku z tym minimalna liczba wystąpień planu usługi App Service to zawsze trzy. Jeśli określisz pojemność większą niż trzy, a liczba wystąpień jest podzielna przez trzy, wystąpienia są wdrażane równomiernie. W przeciwnym razie pozostałe wystąpienia są dodawane do pozostałej strefy lub wdrażane w pozostałych dwóch strefach.

• Strefy dostępności można skonfigurować podczas tworzenia środowiska App Service Environment.
• Wszystkie plany usługi App Service utworzone w tym środowisku App Service Environment wymagają co najmniej trzech wystąpień. Będą one automatycznie strefowo nadmiarowe.
• Strefy dostępności można określić tylko podczas tworzenia nowego środowiska App Service Environment. Nie można przekonwertować istniejącego środowiska App Service Environment na strefy dostępności.
• Strefy dostępności są obsługiwane tylko w podzestawie regionów.

Aby uzyskać więcej informacji, zobacz Migrowanie środowiska App Service Environment do obsługi stref dostępności.

Odporność

Aplikacje uruchamiane w środowisku App Service Environment tworzą pulę zaplecza dla usługi Application Gateway. Gdy żądanie do aplikacji pochodzi z publicznego Internetu, brama przekazuje żądanie do aplikacji uruchomionej w środowisku App Service Environment. Ta architektura referencyjna implementuje kontrole kondycji w głównym frontonie internetowym. votingApp Ta sonda kondycji sprawdza, czy internetowy interfejs API i pamięć podręczna Redis cache są w dobrej kondycji. Kod implementujący tę sondę można zobaczyć w Startup.cs:

            var uriBuilder = new UriBuilder(Configuration.GetValue<string>("ConnectionStrings:VotingDataAPIBaseUri"))
            {
                Path = "/health"
            };

            services.AddHealthChecks()
                .AddUrlGroup(uriBuilder.Uri, timeout: TimeSpan.FromSeconds(15))
                .AddRedis(Configuration.GetValue<string>("ConnectionStrings:RedisConnectionString"));

Poniższy kod pokazuje, jak skrypt commands_ha.azcli konfiguruje pule zaplecza i sondę kondycji dla bramy aplikacji:

# Generates parameters file for appgw script
cat <<EOF > appgwApps.parameters.json
[
{
    "name": "votapp",
    "routingPriority": 100,
    "hostName": "${APPGW_APP1_URL}",
    "backendAddresses": [
      {
        "fqdn": "${INTERNAL_APP1_URL}"
      }
    ],
    "certificate": {
      "data": "${CERT_DATA_1}",
      "password": "${PFX_PASSWORD}"
    },
    "probePath": "/health"
  }
]

Jeśli którykolwiek ze składników (frontonu internetowego, interfejsu API lub pamięci podręcznej) zakończy się niepowodzeniem, usługa Application Gateway kieruje żądanie do innej aplikacji w puli zaplecza. Ta konfiguracja gwarantuje, że żądanie jest zawsze kierowane do aplikacji w całkowicie dostępnej podsieci środowiska App Service Environment.

Sonda kondycji jest również implementowana w standardowej implementacji referencyjnej. W tym miejscu brama po prostu zwraca błąd, jeśli sonda kondycji zakończy się niepowodzeniem. Jednak implementacja o wysokiej dostępności poprawia odporność aplikacji i jakość środowiska użytkownika.

Optymalizacja kosztów

Optymalizacja kosztów polega na zmniejszeniu niepotrzebnych wydatków i poprawie wydajności operacyjnej. Aby uzyskać więcej informacji, zobacz Omówienie filaru optymalizacji kosztów.

Zagadnienia dotyczące kosztów architektury wysokiej dostępności są podobne do tych dotyczących standardowego wdrożenia.

Następujące różnice mogą mieć wpływ na koszt:

• Opłaty są naliczane za co najmniej dziewięć wystąpień planu usługi App Service w środowisku App Service Environment strefowo nadmiarowym. Aby uzyskać więcej informacji, zobacz Cennik środowiska App Service Environment.
• Usługa Azure Cache for Redis jest również usługą strefowo nadmiarową. Pamięć podręczna strefowo nadmiarowa jest uruchamiana na maszynach wirtualnych wdrożonych w wielu strefach dostępności w celu zapewnienia większej odporności i dostępności.

Kompromis w przypadku systemu o wysokiej dostępności, odpornej i wysoce bezpiecznej jest zwiększony koszt. Skorzystaj z kalkulatora cen, aby ocenić swoje potrzeby w odniesieniu do cen.

Uwagi dotyczące wdrażania

Ta implementacja referencyjna używa tego samego potoku ciągłej integracji/ciągłego wdrażania na poziomie produkcyjnym co standardowe wdrożenie z tylko jedną maszyną wirtualną przesiadkową. Możesz jednak zdecydować się na użycie jednego serwera przesiadkowego dla każdej z trzech stref. Ta architektura używa tylko jednego serwera przesiadkowego, ponieważ serwer przesiadkowy nie ma wpływu na dostępność aplikacji. Serwer przesiadkowy jest używany tylko do wdrażania i testowania.

Wdrażanie tego scenariusza

Aby uzyskać informacje na temat wdrażania implementacji referencyjnej dla tej architektury, zobacz plik readme usługi GitHub. Użyj skryptu do wdrożenia o wysokiej dostępności.

Współautorzy

Ten artykuł jest obsługiwany przez firmę Microsoft. Pierwotnie został napisany przez następujących współautorów.

Autorzy zabezpieczeń:

• Deep Bhattacharya | Architekt rozwiązań w chmurze
• Suhas Rao | Architekt rozwiązań w chmurze

Aby wyświetlić niepubalne profile serwisu LinkedIn, zaloguj się do serwisu LinkedIn.

Następne kroki

Tę architekturę można zmodyfikować, skalując aplikacje w poziomie w tym samym regionie lub w kilku regionach na podstawie oczekiwanej pojemności szczytowego obciążenia. Replikowanie aplikacji w wielu regionach może pomóc zmniejszyć ryzyko wystąpienia szerszych awarii centrum danych geograficznych, takich jak te spowodowane trzęsieniami ziemi lub innymi klęskami żywiołowymi. Aby dowiedzieć się więcej na temat skalowania w poziomie, zobacz Geo Distributed Scale with App Service Environments (Skalowanie rozproszone geograficznie za pomocą środowisk App Service Environment). W przypadku globalnego i wysoce dostępnego rozwiązania do routingu rozważ użycie usługi Azure Front Door.