Edytuj

Wielowarstwowa aplikacja internetowa utworzona pod kątem wysokiej dostępności/odzyskiwania po awarii

Azure
Azure Arc
SQL Server
Windows

Ten przykładowy scenariusz ma zastosowanie do każdej branży, która musi wdrażać odporne aplikacje wielowarstwowe utworzone pod kątem wysokiej dostępności i odzyskiwania po awarii. W tym scenariuszu aplikacja składa się z trzech warstw.

  • Warstwa internetowa: górna warstwa, w tym interfejs użytkownika. Ta warstwa analizuje interakcje użytkowników i przekazuje akcje do następnej warstwy do przetwarzania.
  • Warstwa biznesowa: przetwarza interakcje użytkowników i podejmuje logiczne decyzje dotyczące następnych kroków. Ta warstwa łączy warstwę internetową i warstwę danych.
  • Warstwa danych: przechowuje dane aplikacji. Zwykle jest używana baza danych, magazyn obiektów lub magazyn plików.

Typowe scenariusze aplikacji obejmują dowolną aplikację o znaczeniu krytycznym działającą w systemie Windows lub Linux. Może to być aplikacja poza półki, taka jak SAP i SharePoint lub niestandardowa aplikacja biznesowa.

Potencjalne przypadki użycia

Inne istotne przypadki użycia to:

  • Wdrażanie wysoce odpornych aplikacji, takich jak SAP i SharePoint
  • Projektowanie planu ciągłości działania i odzyskiwania po awarii dla aplikacji biznesowych
  • Konfigurowanie odzyskiwania po awarii i wykonywanie powiązanych prób na potrzeby zgodności

Architektura

Diagram showing the architecture overview of a highly resilient multitier web application.

Pobierz plik programu Visio z tą architekturą.

Przepływ pracy

  • Dystrybuuj maszyny wirtualne w każdej warstwie w dwóch strefach dostępności w regionach obsługujących strefy. W innych regionach wdróż maszyny wirtualne w każdej warstwie w ramach jednego zestawu dostępności.
  • Warstwę bazy danych można skonfigurować do używania zawsze włączonych grup dostępności. W przypadku tej konfiguracji programu SQL Server jedna podstawowa replika odczytu/zapisu w grupie dostępności jest skonfigurowana z maksymalnie ośmioma pomocniczymi replikami tylko do odczytu. Jeśli wystąpi problem z repliką podstawową, grupa dostępności przełączy podstawową aktywność odczytu/zapisu w tryb failover do jednej z replik pomocniczych, umożliwiając aplikacji pozostanie dostępna. Aby uzyskać więcej informacji, zobacz Omówienie zawsze włączonych grup dostępności dla programu SQL Server.
  • W przypadku scenariuszy odzyskiwania po awarii można skonfigurować asynchroniczną asynchroniczną replikację natywną SQL do regionu docelowego używanego do odzyskiwania po awarii. Można również skonfigurować replikację usługi Azure Site Recovery do regionu docelowego, jeśli współczynnik zmian danych mieści się w obsługiwanych limitach usługi Azure Site Recovery.
  • Użytkownicy uzyskują dostęp do ASP.NET warstwy internetowej frontonu za pośrednictwem punktu końcowego usługi Traffic Manager.
  • Usługa Traffic Manager przekierowuje ruch do podstawowego publicznego punktu końcowego adresu IP w regionie źródłowym.
  • Publiczny adres IP przekierowuje wywołanie do jednego z wystąpień maszyn wirtualnych warstwy internetowej za pośrednictwem publicznego modułu równoważenia obciążenia. Wszystkie wystąpienia maszyn wirtualnych warstwy internetowej znajdują się w jednej podsieci.
  • Z poziomu maszyny wirtualnej warstwy internetowej każde wywołanie jest kierowane do jednego z wystąpień maszyn wirtualnych w warstwie biznesowej za pośrednictwem wewnętrznego modułu równoważenia obciążenia na potrzeby przetwarzania. Wszystkie maszyny wirtualne warstwy biznesowej znajdują się w oddzielnej podsieci.
  • Operacja jest przetwarzana w warstwie biznesowej, a aplikacja ASP.NET łączy się z klastrem programu Microsoft SQL Server w warstwie zaplecza za pośrednictwem wewnętrznego modułu równoważenia obciążenia platformy Azure. Te wystąpienia programu SQL Server zaplecza znajdują się w oddzielnej podsieci.
  • Pomocniczy punkt końcowy usługi Traffic Manager jest skonfigurowany jako publiczny adres IP w regionie docelowym używanym do odzyskiwania po awarii.
  • W przypadku zakłóceń w regionie podstawowym należy wywołać tryb failover usługi Azure Site Recovery, a aplikacja stanie się aktywna w regionie docelowym.
  • Punkt końcowy usługi Traffic Manager automatycznie przekierowuje ruch klienta do publicznego adresu IP w regionie docelowym.

Elementy

  • Zestawy dostępności zapewniają rozproszenie maszyn wirtualnych wdrożonych na platformie Azure pomiędzy wieloma izolowanymi węzłami sprzętowymi w klastrze. Jeśli na platformie Azure wystąpi awaria sprzętu lub oprogramowania, dotyczy to tylko podzestawu maszyn wirtualnych, a całe rozwiązanie pozostaje dostępne i operacyjne.
  • Strefy dostępności chronią aplikacje i dane przed awariami centrum danych. Strefy dostępności są oddzielnymi lokalizacjami fizycznymi w regionie świadczenia usługi Azure. Każda strefa składa się z co najmniej jednego centrum danych wyposażonego w niezależne zasilanie, chłodzenie i sieć.
  • Usługa Azure Site Recovery umożliwia replikowanie maszyn wirtualnych do innego regionu świadczenia usługi Azure w celu zapewnienia ciągłości działania i odzyskiwania po awarii. Możesz przeprowadzić okresowe próbne odzyskiwanie po awarii, aby upewnić się, że spełniasz wymagania dotyczące zgodności. Maszyna wirtualna zostanie zreplikowana z określonymi ustawieniami do wybranego regionu, dzięki czemu będzie można odzyskać aplikacje w razie awarii w regionie źródłowym.
  • Usługa Azure Traffic Manager to oparty na systemie DNS moduł równoważenia obciążenia ruchu, który optymalnie dystrybuuje ruch do usług w globalnych regionach świadczenia usługi Azure, zapewniając jednocześnie wysoką dostępność i czas odpowiedzi.
  • Usługa Azure Load Balancer dystrybuuje ruch przychodzący zgodnie ze zdefiniowanymi regułami i sondami kondycji. Moduł równoważenia obciążenia zapewnia małe opóźnienia i wysoką przepływność, skalując do milionów przepływów dla wszystkich aplikacji TCP i UDP. Publiczny moduł równoważenia obciążenia jest używany w tym scenariuszu do dystrybucji przychodzącego ruchu klienta do warstwy internetowej. Wewnętrzny moduł równoważenia obciążenia jest używany w tym scenariuszu do dystrybucji ruchu z warstwy biznesowej do klastra programu SQL Server zaplecza.

Alternatywy

  • System Windows może zostać zastąpiony przez inne systemy operacyjne, ponieważ nic w infrastrukturze nie zależy od systemu operacyjnego.
  • Program SQL Server dla systemu Linux może zastąpić magazyn danych zaplecza.
  • Bazę danych można zastąpić dowolną dostępną standardową aplikacją bazy danych.

Szczegóły scenariusza

W tym scenariuszu przedstawiono wielowarstwową aplikację korzystającą z ASP.NET i programu Microsoft SQL Server. W regionach świadczenia usługi Azure, które obsługują strefy dostępności, możesz wdrożyć maszyny wirtualne w regionie źródłowym w różnych strefach dostępności i replikować maszyny wirtualne do regionu docelowego używanego do odzyskiwania po awarii. W regionach świadczenia usługi Azure, które nie obsługują stref dostępności, możesz wdrożyć maszyny wirtualne w zestawie dostępności i replikować maszyny wirtualne do regionu docelowego.

Aby kierować ruch między regionami, potrzebny jest globalny moduł równoważenia obciążenia. Istnieją dwie główne oferty platformy Azure:

  • Azure Front Door
  • Azure Traffic Manager

Podczas wybierania modułu równoważenia obciążenia należy wziąć pod uwagę wymagania i zestaw funkcji tych dwóch ofert. Jak szybko chcesz przełączyć się w tryb failover? Czy możesz przejąć obciążenie związane z zarządzaniem protokołem TLS? Czy istnieją jakieś ograniczenia kosztów organizacji?

Usługa Front Door ma funkcje warstwy 7: odciążanie protokołu SSL, routing oparty na ścieżkach, szybkie przechodzenie w tryb failover, buforowanie i inne w celu zwiększenia wydajności i wysokiej dostępności aplikacji. Może wystąpić krótszy czas podróży pakietów, ponieważ infrastruktura jest dołączona do sieci platformy Azure wcześniej.

Ponieważ usługa Front Door dodaje nowy przeskok, istnieją dodatkowe operacje zabezpieczeń. Jeśli architektura spełnia wymagania prawne, mogą istnieć ograniczenia dotyczące dodatkowego punktu zakończenia protokołu TLS ruchu. Zestawy szyfrowania TLS wybrane przez usługę Front Door muszą spełniać pasek zabezpieczeń organizacji. Ponadto usługa Front Door oczekuje, że usługi zaplecza będą używać certyfikatów używanych przez firmę Microsoft.

Inną kwestią jest koszt. Architektura powinna korzystać z rozbudowanego zestawu funkcji (a nie tylko trybu failover), aby uzasadnić dodatkowy koszt.

Traffic Manager to usługa równoważenia obciążenia oparta na systemie DNS. Równoważy ona równoważenie i przełączanie w tryb failover tylko na poziomie DNS. Z tego powodu nie może przejść w tryb failover tak szybko, jak usługa Front Door, ze względu na typowe wyzwania związane z buforowaniem DNS i systemami, które nie honoruje TTLs DNS.

W razie potrzeby można połączyć oba moduły równoważenia obciążenia. Na przykład chcesz użyć trybu failover opartego na systemie DNS, ale chcesz dodać środowisko POP przed infrastrukturą zarządzaną ruchem.

Ta architektura używa usługi Traffic Manager, ponieważ jest uproszczona. Czas pracy w trybie failover jest wystarczający do celów ilustracyjnych.

Kwestie wymagające rozważenia

Skalowalność

Maszyny wirtualne można dodawać lub usuwać w każdej warstwie na podstawie wymagań dotyczących skalowania. Ponieważ w tym scenariuszu są używane moduły równoważenia obciążenia, można dodać więcej maszyn wirtualnych do warstwy bez wpływu na czas pracy aplikacji.

Aby zapoznać się z innymi tematami dotyczącymi skalowalności, zobacz listę kontrolną wydajności wydajności w Centrum architektury platformy Azure.

Zabezpieczenia

Cały ruch sieci wirtualnej do warstwy aplikacji frontonu jest chroniony przez sieciowe grupy zabezpieczeń. Reguły ograniczają przepływ ruchu, tak aby tylko wystąpienia maszyn wirtualnych warstwy aplikacji frontonu mogły uzyskiwać dostęp do warstwy bazy danych zaplecza. Wychodzący ruch internetowy nie jest dozwolony z warstwy biznesowej lub warstwy bazy danych. Aby zmniejszyć ślad ataku, nie są otwarte żadne bezpośrednie porty zarządzania zdalnego. Aby uzyskać więcej informacji, zobacz Sieciowe grupy zabezpieczeń platformy Azure.

Aby uzyskać ogólne wskazówki dotyczące projektowania bezpiecznych scenariuszy, zobacz dokumentację zabezpieczeń platformy Azure.

Cennik

Skonfigurowanie odzyskiwania po awarii dla maszyn wirtualnych platformy Azure przy użyciu usługi Azure Site Recovery spowoduje naliczenie następujących opłat na bieżąco.

  • Koszt licencjonowania usługi Azure Site Recovery na maszynę wirtualną.
  • Koszty ruchu wychodzącego sieci w celu replikowania zmian danych ze źródłowych dysków maszyn wirtualnych do innego regionu świadczenia usługi Azure. Usługa Azure Site Recovery używa wbudowanej kompresji, aby zmniejszyć wymagania dotyczące transferu danych o około 50%.
  • Koszty magazynowania w lokacji odzyskiwania. Jest to zwykle takie samo, jak magazyn w regionie źródłowym oraz wszelkie dodatkowe magazyny potrzebne do obsługi punktów odzyskiwania jako migawki na potrzeby odzyskiwania.

Udostępniliśmy przykładowy kalkulator kosztów na potrzeby konfigurowania odzyskiwania po awarii dla aplikacji trójwarstwowej przy użyciu sześciu maszyn wirtualnych. Wszystkie usługi są wstępnie skonfigurowane w kalkulatorze kosztów. Aby zobaczyć, w jaki sposób ceny zmienią się dla konkretnego przypadku użycia, zmień odpowiednie zmienne, aby oszacować koszt.

Współautorzy

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

Główny autor:

Następne kroki

Aby uzyskać dodatkowe architektury referencyjne dotyczące wysokiej dostępności i odzyskiwania po awarii, zobacz: