Zalecenia dotyczące używania stref dostępności i regionów

  • Artykuł

Dotyczy tego zalecenia dotyczącego listy kontrolnej niezawodności platformy Azure Well-Architected Framework:

RE:05 Dodaj nadmiarowość na różnych poziomach, szczególnie w przypadku przepływów krytycznych. Zastosuj nadmiarowość do warstw obliczeniowych, danych, sieci i innych warstw infrastruktury zgodnie ze zidentyfikowanymi celami niezawodności.

Powiązane przewodniki:Nadmiarowość projektowania | w wielu regionalach o wysokiej dostępności

W tym przewodniku opisano zalecenia dotyczące określania, kiedy należy wdrażać obciążenia w strefach dostępności lub regionach.

Podczas projektowania rozwiązania dla platformy Azure należy zdecydować, czy wdrożysz je w wielu strefach dostępności w regionie, czy w wielu regionach. Ta decyzja wpływa na niezawodność, koszty i wydajność rozwiązania oraz zdolność twojego zespołu do obsługi rozwiązania. Ten przewodnik zawiera informacje o kluczowych wymaganiach biznesowych, które wpływają na twoją decyzję, podejściach, które można wziąć pod uwagę, kompromisach związanych z każdym podejściem oraz wpływem każdego podejścia na podstawowe filary platformy Azure Well-Architected Framework.

Decyzja o najlepszych regionach świadczenia usługi Azure do użycia w twoim rozwiązaniu jest krytycznym wyborem. W przewodniku Select Azure Regions (Wybieranie regionów platformy Azure ) opisano sposób wybierania i działania w wielu regionach geograficznych. Wybór sposobu używania regionów i stref dostępności w rozwiązaniu ma również wpływ na kilka filarów struktury Well-Architected:

  • Niezawodność: Wybór podejścia do wdrażania może pomóc w ograniczeniu różnych typów zagrożeń. Ogólnie rzecz biorąc, rozkładając obciążenie w bardziej rozproszonym geograficznie obszarze, można osiągnąć większą odporność.
  • Optymalizacja kosztów: niektóre podejścia dotyczące architektury wymagają wdrożenia większej ilości zasobów niż inne, co może zwiększyć koszty zasobów. Inne podejścia obejmują wysyłanie danych między geograficznie oddzielonymi strefami dostępności lub regionami, co może spowodować naliczanie opłat za ruch sieciowy. Ważne jest również, aby wziąć pod uwagę bieżący koszt zarządzania zasobami, co jest zwykle wyższe, gdy masz kompleksowe wymagania biznesowe.
  • Wydajność: Strefy dostępności są połączone ze sobą za pośrednictwem połączenia sieciowego o wysokiej przepustowości i małych opóźnieniach, co jest wystarczające dla większości obciążeń, aby umożliwić synchroniczną replikację i komunikację między strefami. Jeśli jednak obciążenie zostało przetestowane i jest wrażliwe na opóźnienia sieci w różnych strefach, może być konieczne rozważenie fizycznego lokalizowania składników obciążenia blisko siebie, aby zminimalizować opóźnienia podczas komunikacji.
  • Doskonałość operacyjna: Złożona architektura wymaga większego wysiłku w zakresie wdrażania, konfigurowania i zarządzania nimi. Ponadto w przypadku rozwiązania o wysokiej dostępności może być konieczne zaplanowanie przejścia w tryb failover do pomocniczego zestawu zasobów. Przechodzenie w tryb failover, powrót po awarii i przezroczyste przekierowywanie ruchu może być złożone, szczególnie w przypadku konieczności ręcznego wykonania kroków. Dobrym rozwiązaniem jest zautomatyzowanie procesów wdrażania i zarządzania. Aby uzyskać więcej informacji, zobacz przewodniki filaru doskonałości operacyjnej, w tym infrastruktura OE:05 jako kod, automatyzacja zadań OE:09, projektowanie automatyzacji OE:10 i praktyki wdrażania OE:11.

Jednak projektujesz rozwiązanie, ma zastosowanie filar Zabezpieczenia. Zazwyczaj decyzje dotyczące tego, czy i jak używasz stref dostępności i regionów, nie zmieniają stanu zabezpieczeń. Platforma Azure stosuje ten sam zestaw zabezpieczeń do każdego regionu i strefy dostępności.

Porada

W przypadku wielu obciążeń produkcyjnych wdrożenie strefowo nadmiarowe zapewnia najlepszą równowagę między kompromisami. To podejście można rozszerzyć za pomocą asynchronicznej kopii zapasowej danych do innego regionu. Jeśli nie masz pewności, które podejście należy wybrać, zacznij od tego typu wdrożenia.

Rozważ inne podejścia związane z obciążeniem, gdy potrzebujesz konkretnych korzyści zapewnianych przez te podejścia, ale należy pamiętać o kompromisach.

Definicje

Okres Definicja
Aktywne/aktywne Architektura, w której wiele wystąpień rozwiązania aktywnie przetwarza żądania w tym samym czasie.
Aktywne/pasywne Architektura, w której jedno wystąpienie rozwiązania jest wyznaczone jako podstawowe i przetwarza ruch, a co najmniej jedno wystąpienie pomocnicze jest wdrażane w celu obsługi ruchu, jeśli podstawowy jest niedostępny.
Replikacja asynchroniczna Podejście do replikacji danych, w którym dane są zapisywane i zatwierdzane w jednej lokalizacji. W późniejszym czasie zmiany są replikowane do innej lokalizacji.
Strefa dostępności Oddzielona grupa centrów danych w regionie. Każda strefa dostępności jest niezależna od innych, z własną infrastrukturą zasilania, chłodzenia i sieci. Wiele regionów obsługuje strefy dostępności.
Centrum danych Obiekt, który zawiera serwery, sprzęt sieciowy i inny sprzęt do obsługi zasobów i obciążeń platformy Azure.
Wdrożenie lokalnie nadmiarowe Model wdrażania, w którym zasób jest wdrażany w jednym regionie bez odwołania do strefy dostępności. W regionie obsługującym strefy dostępności zasób może zostać wdrożony w dowolnej ze stref dostępności regionu.
Wdrażanie w wielu regionach Model wdrażania, w którym zasoby są wdrażane w wielu regionach świadczenia usługi Azure.
Sparowane regiony Relacja między dwoma regionami świadczenia usługi Azure. Niektóre regiony platformy Azure są połączone z innym zdefiniowanym regionem, aby umożliwić korzystanie z określonych typów rozwiązań w wielu regionach. Nowsze regiony platformy Azure nie są sparowane.
Region (Region) Obwód geograficzny, który zawiera zestaw centrów danych.
Architektura regionu Określona konfiguracja regionu świadczenia usługi Azure, w tym liczba stref dostępności i to, czy region jest sparowany z innym regionem.
Replikacja synchroniczna Podejście do replikacji danych, w którym dane są zapisywane i zatwierdzane w wielu lokalizacjach. Każda lokalizacja musi potwierdzić ukończenie operacji zapisu, zanim zostanie uznana za ukończoną ogólną operację zapisu.
Wdrożenie strefowe (przypięte) Model wdrażania, w którym zasób jest wdrażany w określonej strefie dostępności.
Wdrożenie strefowo nadmiarowe Model wdrażania, w którym zasób jest wdrażany w wielu strefach dostępności. Firma Microsoft zarządza synchronizacją danych, dystrybucją ruchu i trybem failover, jeśli strefa wystąpi awaria.

Kluczowe strategie projektowania

Platforma Azure ma duży globalny ślad. Region świadczenia usługi Azure to geograficzny obwód, który zawiera zestaw centrów danych. Musisz mieć pełną wiedzę na temat regionów platformy Azure i stref dostępności.

Regiony platformy Azure mają różne konfiguracje, które są również nazywane architekturami regionów.

Wiele regionów platformy Azure zapewnia strefy dostępności, które są oddzielnymi grupami centrów danych. W obrębie regionu strefy dostępności są wystarczająco blisko, aby mieć połączenia o małych opóźnieniach z innymi strefami dostępności, ale są one wystarczająco duże, aby zmniejszyć prawdopodobieństwo, że awarie lub pogoda będą miały wpływ na więcej niż jedną strefę dostępności. Strefy dostępności mają niezależną infrastrukturę zasilania, chłodzenia i sieci. Są one zaprojektowane tak, aby w przypadku wystąpienia awarii w jednej strefie usługi regionalne, pojemność i wysoka dostępność były obsługiwane przez pozostałe strefy.

Na poniższym diagramie przedstawiono kilka przykładowych regionów świadczenia usługi Azure. Regiony 1 i 2 obsługują strefy dostępności.

Diagram przedstawiający centra danych, strefy dostępności i regiony.

W przypadku wdrożenia w regionie świadczenia usługi Azure, który zawiera strefy dostępności, możesz używać wielu stref dostępności razem. Używając wielu stref dostępności, można przechowywać oddzielne kopie aplikacji i danych w oddzielnych fizycznych centrach danych w dużym obszarze metropolitalnym.

Istnieją dwa sposoby używania stref dostępności w rozwiązaniu:

  • Zasoby strefowe są przypinane do określonej strefy dostępności. Można połączyć wiele wdrożeń strefowych w różnych strefach, aby spełnić wymagania dotyczące wysokiej niezawodności. Odpowiadasz za zarządzanie replikacją danych i dystrybucję żądań między strefami. Jeśli awaria występuje w jednej strefie dostępności, odpowiadasz za przejście w tryb failover do innej strefy dostępności.
  • Zasoby strefowo nadmiarowe są rozmieszczone w wielu strefach dostępności. Firma Microsoft zarządza rozpowszechnianiem żądań między strefami i replikacją danych między strefami. Jeśli awaria wystąpi w pojedynczej strefie dostępności, firma Microsoft automatycznie zarządza trybem failover.

Usługi platformy Azure obsługują jedno lub oba te podejścia. Usługi platformy jako usługi (PaaS) zwykle obsługują wdrożenia strefowo nadmiarowe. Usługi infrastruktury jako usługi (IaaS) zwykle obsługują wdrożenia strefowe. Aby uzyskać więcej informacji na temat sposobu pracy usług platformy Azure ze strefami dostępności, zobacz Usługi platformy Azure z obsługą stref dostępności.

Gdy firma Microsoft wdraża aktualizacje usług, staramy się użyć metod, które są najmniej uciążliwe dla Ciebie. Na przykład chcemy wdrożyć aktualizacje w pojedynczej strefie dostępności w danym momencie. Takie podejście może zmniejszyć wpływ aktualizacji na aktywne obciążenie, ponieważ obciążenie może nadal działać w innych strefach podczas procesu aktualizacji. Jednak ostatecznie jest to odpowiedzialność zespołu ds. obciążeń w celu zapewnienia, że obciążenie będzie nadal działać podczas uaktualniania platformy. Na przykład w przypadku korzystania z zestawów skalowania maszyn wirtualnych z trybem elastycznej aranżacji lub większości usług PaaS platformy Azure platforma Azure inteligentnie umieszcza zasoby w celu zmniejszenia wpływu aktualizacji platformy. Ponadto można rozważyć nadmierne aprowizowanie — wdrażanie większej liczby wystąpień zasobu — dzięki czemu niektóre wystąpienia pozostaną dostępne podczas uaktualniania innych wystąpień. Aby uzyskać więcej informacji na temat wdrażania aktualizacji na platformie Azure, zobacz Zaawansowane bezpieczne praktyki wdrażania.

Wiele regionów ma również sparowany region. Sparowane regiony obsługują niektóre typy podejść wdrażania w wielu regionach. Niektóre nowsze regiony mają wiele stref dostępności i nie mają sparowanego regionu. Nadal można wdrażać rozwiązania z wieloma regionami w tych regionach, ale używane metody mogą być inne.

Aby uzyskać więcej informacji na temat korzystania z regionów i stref dostępności platformy Azure, zobacz Co to są regiony platformy Azure i strefy dostępności?

Omówienie wspólnych obowiązków

Wspólna zasada odpowiedzialności opisuje sposób podziału obowiązków między dostawcę usług w chmurze (Microsoft) i Użytkownika. W zależności od typu usług, z których korzystasz, możesz podjąć większą lub mniejszą odpowiedzialność za obsługę usługi.

Firma Microsoft udostępnia strefy dostępności i regiony, aby zapewnić elastyczność projektowania rozwiązania w celu spełnienia wymagań. W przypadku korzystania z usług zarządzanych firma Microsoft przejmuje więcej obowiązków związanych z zarządzaniem zasobami, które mogą nawet obejmować replikację danych, tryb failover, powrót po awarii i inne zadania związane z działaniem systemu rozproszonego.

Twój własny kod musi być zalecanymi rozwiązaniami i wzorcami projektowymi, aby bezpiecznie obsługiwać błędy. Te rozwiązania są jeszcze ważniejsze podczas operacji trybu failover, takich jak te, które mają miejsce w przypadku wystąpienia strefy dostępności lub trybu failover regionu, ponieważ przejście w tryb failover między strefami lub regionami zwykle wymaga ponownego nawiązania połączeń z usługami przez aplikację.

Identyfikowanie kluczowych wymagań biznesowych i obciążeń

Aby podjąć świadomą decyzję o sposobie korzystania ze stref dostępności i regionów w rozwiązaniu, musisz zrozumieć wymagania. Te wymagania powinny być prowadzone przez dyskusje między projektantami rozwiązań a uczestnikami projektu biznesowego.

Tolerancja ryzyka

Różne organizacje mają różne stopnie tolerancji ryzyka. Nawet w organizacji tolerancja ryzyka jest często różna dla każdego obciążenia. Większość obciążeń nie wymaga bardzo wysokiej dostępności. Jednak niektóre obciążenia są tak ważne, że warto nawet zmniejszyć ryzyko, które jest mało prawdopodobne, jak poważne klęski żywiołowe wpływające na szeroki obszar geograficzny.

W tej tabeli wymieniono kilka typowych zagrożeń, które należy wziąć pod uwagę w środowisku chmury:

Ryzyko Przykłady Prawdopodobieństwo
Awaria sprzętu Problem z dyskiem twardym lub sprzętem sieciowym.

Ponowne uruchomienie hosta.		 Wysoka. Każda strategia odporności powinna uwzględniać te zagrożenia.
Awaria centrum danych Awaria zasilania, chłodzenia lub sieci w całym centrum danych.

Klęski żywiołowe w jednej części obszaru metropolitalnego.		 Śred.
Awaria regionu Poważna klęska żywiołowa, która ma wpływ na szeroki obszar geograficzny.

Problem z siecią lub usługą, który sprawia, że co najmniej jedna usługa platformy Azure jest niedostępna w całym regionie.		 Niski

Byłoby idealnym rozwiązaniem dla każdego możliwego ryzyka dla każdego obciążenia, ale nie jest to praktyczne ani ekonomiczne. Ważne jest, aby mieć otwartą dyskusję z osobami biorącymi udział w projekcie biznesowym, aby móc podejmować świadome decyzje dotyczące ryzyka, które należy ograniczyć.

Porada

Niezależnie od celów dotyczących niezawodności wszystkie obciążenia muszą mieć pewne środki zaradcze na potrzeby odzyskiwania po awarii. Jeśli obciążenie wymaga celów dotyczących wysokiej niezawodności, strategie ograniczania ryzyka powinny być kompleksowe i należy zmniejszyć ryzyko nawet zdarzeń o niskim prawdopodobieństwie. W przypadku innych obciążeń podejmij świadomą decyzję o tym, które czynniki ryzyka są gotowe do zaakceptowania i które należy ograniczyć.

Wymagania dotyczące odporności

Ważne jest, aby zrozumieć wymagania dotyczące odporności obciążenia, w tym cel czasu odzyskiwania (RTO) i cel punktu odzyskiwania (RPO). Te cele pomagają zdecydować, które podejścia do wykluczenia. Jeśli nie masz jasnych wymagań, nie możesz podjąć świadomej decyzji o tym, które podejście należy zastosować. Aby uzyskać więcej informacji, zobacz Target functional and nonfunctional requirements (Wymagania funkcjonalne i niefunkcjonalne).

Cele poziomu usług

Należy zrozumieć oczekiwany cel poziomu usług (SLO, uptime) rozwiązania. Możesz na przykład mieć wymaganie biznesowe, że rozwiązanie musi spełniać czas pracy na 99,9%.

Platforma Azure udostępnia umowy dotyczące poziomu usług (SLA) dla każdej usługi. Umowa SLA wskazuje poziom czasu pracy, którego należy oczekiwać od usługi, oraz warunki, które należy spełnić, aby osiągnąć oczekiwaną umowę SLA. Należy jednak pamiętać, że sposób, w jaki umowa SLA platformy Azure wskazuje dostępność usługi, nie zawsze jest zgodna ze sposobem, w jaki rozważasz kondycję obciążenia.

Decyzje dotyczące architektury wpływają na złożone cele slo rozwiązania. Ogólnie rzecz biorąc, im większa nadmiarowość, którą tworzysz w rozwiązaniu, tym wyższa jest wartość slo. Wiele usług platformy Azure zapewnia wyższe umowy SLA podczas wdrażania usług w konfiguracji strefowo nadmiarowej lub wieloregionowej. Zapoznaj się z umowami SLA dla każdej używanej usługi platformy Azure, aby upewnić się, że rozumiesz, jak zmaksymalizować odporność i umowę SLA usługi.

Rezydencja danych

Niektóre organizacje nakładają ograniczenia dotyczące lokalizacji fizycznych, w których można przechowywać i przetwarzać ich dane. Czasami te wymagania są oparte na standardach prawnych lub regulacyjnych. W innych sytuacjach organizacja może zdecydować się na przyjęcie zasad rezydencji danych, aby uniknąć problemów klientów. Jeśli masz ścisłe wymagania dotyczące rezydencji danych, może być konieczne użycie wdrożenia w jednym regionie lub użycie podzbioru regionów i usług platformy Azure.

Uwaga

Unikaj bezpodstawnych założeń dotyczących wymagań dotyczących rezydencji danych. Jeśli musisz spełnić określone standardy prawne, sprawdź, jakie faktycznie określają te standardy.

Lokalizacja użytkownika

Dzięki zrozumieniu, gdzie znajdują się użytkownicy, możesz podjąć świadomą decyzję o tym, jak zoptymalizować opóźnienia i niezawodność zgodnie z potrzebami. Platforma Azure oferuje wiele opcji obsługi rozproszonej geograficznie bazy użytkowników.

Jeśli użytkownicy są skoncentrowani w jednym obszarze, wdrożenie w jednym regionie może uprościć wymagania operacyjne i zmniejszyć koszty. Należy jednak rozważyć, czy wdrożenie w jednym regionie spełnia wymagania dotyczące niezawodności. W przypadku aplikacji o znaczeniu krytycznym nadal należy używać wdrożenia w wielu regionach, nawet jeśli użytkownicy są kolokowani.

Jeśli użytkownicy są rozproszeni geograficznie, warto wdrożyć obciążenie w wielu regionach. Usługi platformy Azure zapewniają różne możliwości obsługi wdrożenia w wielu regionach i można użyć globalnego śladu platformy Azure w celu poprawy środowiska użytkownika i zbliżenia aplikacji do bazy użytkowników. Możesz użyć wzorca sygnatur wdrożenia lub wzorca Geodes albo zreplikować zasoby w wielu regionach.

Nawet jeśli użytkownicy znajdują się w różnych obszarach geograficznych, zastanów się, czy potrzebujesz wdrożenia w wielu regionach. Zastanów się, czy możesz spełnić wymagania w jednym regionie przy użyciu globalnego przyspieszenia ruchu, takiego jak przyspieszenie zapewniane przez usługę Azure Front Door.

Budżet

Jeśli pracujesz w ramach ograniczonego budżetu, ważne jest, aby wziąć pod uwagę koszty związane z wdrażaniem nadmiarowych składników obciążenia. Te koszty mogą obejmować dodatkowe opłaty za zasoby, koszty sieci i koszty operacyjne zarządzania większą ilością zasobów i bardziej złożone środowisko.

Złożoność

Dobrym rozwiązaniem jest unikanie niepotrzebnej złożoności w architekturze rozwiązania. Im większa złożoność, tym trudniej jest podjąć decyzje dotyczące architektury. Złożone architektury są trudniejsze do działania, trudniejsze do zabezpieczenia i często mniej wydajne. Postępuj zgodnie z zasadą prostoty.

Ułatwienia dla platformy Azure

Zapewniając regiony i strefy dostępności, platforma Azure umożliwia wybranie podejścia do wdrażania, które odpowiada Twoim potrzebom. Istnieje wiele metod, które można wybrać, z których każda zapewnia korzyści i ponosi koszty.

Aby zilustrować metody wdrażania, których można użyć, rozważ przykładowy scenariusz. Załóżmy, że myślisz o wdrożeniu nowego rozwiązania, które obejmuje aplikację, która zapisuje dane w jakimś magazynie:

Diagram przedstawiający użytkownika łączącego się z aplikacją łączącą się z magazynem.

Ten przykład nie jest specyficzny dla żadnych określonych usług platformy Azure. Ma na celu przedstawienie prostego przykładu ilustrowania podstawowych pojęć.

Istnieje wiele sposobów wdrażania tego rozwiązania. Każde podejście zapewnia inny zestaw korzyści i wiąże się z różnymi kosztami. Na wysokim poziomie można rozważyć wdrożenie lokalnie nadmiarowe, strefowe (przypięte), strefowo nadmiarowe lub wieloregionowe . W tej tabeli przedstawiono podsumowanie niektórych zagadnień związanych z filarem:

Filar Lokalnie nadmiarowe Strefowy (przypięty) Strefowo nadmiarowe Wiele regionów
Niezawodność Niska niezawodność Zależy od podejścia Wysoka lub bardzo wysoka niezawodność Wysoka lub bardzo wysoka niezawodność
Optymalizacja kosztów Niski koszt Zależy od podejścia Umiarkowany koszt Wysoki koszt
Efektywność wydajności Akceptowalna wydajność (w przypadku większości obciążeń) Wysoka wydajność Akceptowalna wydajność (w przypadku większości obciążeń) Zależy od podejścia
Doskonałość operacyjna Niskie wymagania operacyjne Wymagania operacyjne o wysokim poziomie Niskie wymagania operacyjne Wymagania operacyjne o wysokim poziomie

W tej tabeli przedstawiono podsumowanie niektórych metod, których można użyć i sposobu ich wpływu na architekturę:

Problem z architekturą Lokalnie nadmiarowe Strefowy (przypięty) Strefowo nadmiarowe Wiele regionów
Zgodność z miejscem przechowywania danych Wys. Wys. Wys. Zależy od regionu
Dostępność w regionach Wszystkie regiony Regiony ze strefami dostępności Regiony ze strefami dostępności Zależy od regionu

W pozostałej części tego artykułu opisano poszczególne podejścia wymienione w poprzedniej tabeli. Lista podejść nie jest wyczerpująca. Możesz zdecydować się na połączenie wielu podejść lub użycie różnych metod w różnych częściach rozwiązania.

Metoda wdrażania 1: wdrożenia lokalnie nadmiarowe

Jeśli nie określisz wielu stref dostępności lub regionów podczas wdrażania zasobów, platforma Azure nie gwarantuje, czy zasoby są wdrażane w jednym centrum danych, czy podzielone na wiele centrów danych w regionie. W niektórych sytuacjach platforma Azure może również przenieść zasób między strefami dostępności.

Diagram przedstawiający rozwiązanie wdrożone w jednym centrum danych w jednej strefie dostępności.

Większość zasobów platformy Azure jest domyślnie wysoce dostępna, z wysokimi umowami SLA i wbudowaną nadmiarowością w centrum danych zarządzanym przez platformę. Jednak z perspektywy niezawodności, jeśli w jakiejkolwiek części regionu wystąpi awaria, istnieje prawdopodobieństwo wystąpienia awarii obciążenia. Jeśli tak jest, twoje rozwiązanie może być niedostępne lub dane mogą zostać utracone.

W przypadku obciążeń z dużym opóźnieniem takie podejście może również spowodować obniżenie wydajności. Składniki obciążenia mogą nie być współlokowane w tym samym centrum danych, więc może wystąpić pewne opóźnienie ruchu wewnątrz regionu. Platforma Azure może również w sposób niewidoczny przenosić wystąpienia usługi między strefami dostępności, co może nieznacznie wpłynąć na wydajność. Nie jest to jednak problemem dla większości obciążeń.

W tej tabeli przedstawiono podsumowanie niektórych zagadnień związanych z filarem:

Filar Wpływ
Niezawodność Niska niezawodność. Usługi podlegają awarii, jeśli centrum danych zakończy się niepowodzeniem. Aplikację można jednak utworzyć tak, aby mogła być odporna na inne typy błędów.
Optymalizacja kosztów Najniższy koszt. Musisz mieć tylko jedno wystąpienie każdego zasobu i nie ponosisz żadnych kosztów przepustowości między strefami ani między regionami.
Efektywność wydajności W przypadku większości obciążeń:akceptowalna wydajność. Takie podejście może zapewnić zadowalającą wydajność.

W przypadku obciążeń z dużym opóźnieniem:niska wydajność. Składniki nie mają gwarancji, że znajdują się w tej samej strefie dostępności, więc może być widoczna niższa wydajność dla składników o wysokim opóźnieniu.
Doskonałość operacyjna Wysoka wydajność operacyjna. Wystarczy wdrożyć pojedyncze wystąpienie każdego zasobu i zarządzać nim.

Ta tabela zawiera podsumowanie niektórych problemów z perspektywy architektury:

Problem z architekturą Wpływ
Zgodność z miejscem przechowywania danych Wysoka. Podczas wdrażania rozwiązania korzystającego z tego podejścia dane są przechowywane w wybranym regionie świadczenia usługi Azure.
Dostępność w regionach Wysoka. To podejście może być używane w dowolnym regionie świadczenia usługi Azure.

Wdrożenia lokalnie nadmiarowe z kopią zapasową w różnych regionach

Wdrożenie lokalnie nadmiarowe można rozszerzyć, wykonując regularne kopie zapasowe infrastruktury i danych w regionie pomocniczym. Takie podejście dodaje dodatkową warstwę ochrony w celu ograniczenia awarii w regionie podstawowym. Oto jak wygląda:

Diagram przedstawiający rozwiązanie wdrożone w jednym centrum danych z kopiami zapasowymi w innym regionie.

W przypadku zaimplementowania tego podejścia należy dokładnie rozważyć cel czasu odzyskiwania i cel punktu odzyskiwania:

  • Czas odzyskiwania: jeśli wystąpi awaria regionalna, może być konieczne ponowne skompilowanie rozwiązania w innym regionie świadczenia usługi Azure, co wpływa na czas odzyskiwania. Rozważ utworzenie rozwiązania przy użyciu podejścia infrastruktury jako kodu (IaC), aby umożliwić szybkie ponowne wdrożenie w innym regionie w przypadku wystąpienia poważnej awarii. Upewnij się, że narzędzia i procesy wdrażania są tak samo odporne, jak aplikacje, dzięki czemu można ich użyć do ponownego wdrożenia rozwiązania, nawet jeśli wystąpi awaria. Zaplanuj i przetwróć kroki wymagane do przywrócenia rozwiązania do stanu roboczego.
  • Punkt odzyskiwania: Częstotliwość tworzenia kopii zapasowej określa ilość utraty danych, które mogą wystąpić (punkt odzyskiwania). Zazwyczaj można kontrolować częstotliwość tworzenia kopii zapasowych, aby można było spełnić cel punktu odzyskiwania.

W tej tabeli przedstawiono podsumowanie niektórych zagadnień związanych z filarem:

Filar Wpływ
Niezawodność Umiarkowana niezawodność. Usługi podlegają awarii, jeśli centrum danych zakończy się niepowodzeniem. Dane są tworzone asynchronicznie w regionie rozdzielanym geograficznie, co zmniejsza wpływ awarii pełnego regionu przez zminimalizowanie utraty danych. W przypadku awarii pełnego regionu można ręcznie przywrócić operacje do innego regionu. Jednak procesy odzyskiwania mogą być złożone i ręczne przywracanie do innego regionu może zająć trochę czasu.
Optymalizacja kosztów Niski koszt. Zazwyczaj dodanie kopii zapasowej do innego regionu kosztuje tylko nieco więcej niż wdrożenie zasobu lokalnie nadmiarowego.
Efektywność wydajności W przypadku większości obciążeń:akceptowalna wydajność. Takie podejście może zapewnić zadowalającą wydajność.

W przypadku obciążeń z dużymi opóźnieniami:niska wydajność. Składniki nie mają gwarancji, że znajdują się w tej samej strefie dostępności, więc może być widoczna niższa wydajność składników o dużym opóźnieniu.
Doskonałość operacyjna Podczas awarii w regionie:Niska wydajność operacyjna. Tryb failover to Twoja odpowiedzialność i może wymagać ręcznego wykonywania operacji i ponownego wdrażania.

Ta tabela zawiera podsumowanie niektórych zagadnień z perspektywy architektury:

Problem z architekturą Wpływ
Zgodność z miejscem przechowywania danych Zależy od wyboru regionu. Dane są przechowywane głównie w określonym regionie świadczenia usługi Azure. Należy jednak wybrać inny region do przechowywania kopii zapasowych, dlatego ważne jest, aby wybrać region, który jest zgodny z wymaganiami dotyczącymi przechowywania danych.
Dostępność w regionach Wysoka. Tego podejścia można użyć w dowolnym regionie świadczenia usługi Azure.

Metoda wdrażania 2: wdrożenia strefowe (przypięte)

W przypadku wdrożenia strefowego należy określić, że zasoby powinny być wdrażane w określonej strefie dostępności. Takie podejście jest czasami nazywane wdrożeniem przypiętym do strefy .

Diagram przedstawiający rozwiązanie wdrożone w określonej strefie dostępności. Jest używane podejście do wdrażania strefowego.

Podejście strefowe zmniejsza opóźnienie między składnikami. Jednak samo w sobie nie zwiększa odporności rozwiązania. Aby zwiększyć odporność, należy wdrożyć wiele wystąpień składników w wielu strefach dostępności i zdecydować, jak kierować ruch między poszczególnymi wystąpieniami. W tym przykładzie przedstawiono podejście do routingu ruchu aktywne-pasywne :

Diagram przedstawiający rozwiązanie wdrożone w wielu strefach dostępności. Jest używane podejście do routingu ruchu aktywne-pasywne.

W poprzednim przykładzie moduł równoważenia obciążenia jest wdrażany w wielu strefach dostępności. Ważne jest, aby wziąć pod uwagę sposób kierowania ruchu między wystąpieniami w różnych strefach dostępności, ponieważ awaria strefy może również mieć wpływ na zasoby sieciowe wdrożone w tej strefie. Możesz również rozważyć użycie globalnego modułu równoważenia obciążenia, takiego jak usługa Azure Front Door lub Azure Traffic Manager, która nie jest w ogóle wdrożona w regionie.

W przypadku korzystania z modelu wdrażania strefowego należy wziąć pod uwagę wiele obowiązków:

  • Musisz wdrożyć zasoby w każdej strefie dostępności i skonfigurować te zasoby i zarządzać nimi osobno.
  • Musisz zdecydować, jak i kiedy replikować dane między strefami dostępności, a następnie skonfigurować replikację i zarządzać nią.
  • Odpowiadasz za dystrybucję żądań do odpowiednich zasobów przy użyciu na przykład modułu równoważenia obciążenia. Należy się upewnić, że moduł równoważenia obciążenia spełnia wymagania dotyczące odporności. Należy również zdecydować, czy należy użyć modelu dystrybucji żądań aktywny-pasywny, czy aktywny-aktywny.
  • Jeśli strefa dostępności wystąpi awaria, musisz obsłużyć tryb failover, aby wysyłać ruch do zasobów w innej strefie dostępności.

Wdrożenie aktywne-pasywne w wielu strefach dostępności jest czasami nazywane odzyskiwaniem po awarii w regionie lub odzyskiwaniem po awarii metro.

W tej tabeli podsumowano niektóre z zagadnień związanych z filarem:

Filar Wpływ
Niezawodność W przypadku wdrożenia w pojedynczej strefie dostępności:Niska niezawodność. Wdrożenie strefowe nie zapewnia odporności na awarię w centrum danych lub strefie dostępności. Aby zapewnić wysoką odporność, należy wdrożyć nadmiarowe zasoby w wielu strefach dostępności.

W przypadku wdrożenia w wielu strefach dostępności:wysoka niezawodność. Usługi mogą być odporne na awarię centrum danych lub strefy dostępności.
Optymalizacja kosztów W przypadku wdrożenia w pojedynczej strefie dostępności:Niski koszt. Wdrożenie jednostrefowe wymaga tylko jednego wystąpienia każdego zasobu.

W przypadku wdrożenia w wielu strefach dostępności:wysoki koszt. Wdrażasz wiele wystąpień zasobów, z których każda jest rozliczana oddzielnie. Musisz również płacić za ruch między strefami w przypadku replikacji danych.
Efektywność wydajności Wysoka wydajność. Opóźnienie może być bardzo niskie, gdy składniki obsługujące żądanie znajdują się w tej samej strefie dostępności.
Doskonałość operacyjna Niska wydajność operacyjna. Należy skonfigurować wiele wystąpień usługi i zarządzać nimi. Musisz replikować dane między strefami dostępności. Podczas awarii strefy dostępności Odpowiedzialność za przejście w tryb failover odpowiada Twoja odpowiedzialność.

Ta tabela zawiera podsumowanie niektórych zagadnień z perspektywy architektury:

Problem z architekturą Wpływ
Zgodność z miejscem przechowywania danych Wysoka. Podczas wdrażania rozwiązania, które korzysta z tego podejścia, dane są przechowywane w wybranym regionie świadczenia usługi Azure.
Dostępność w regionach Regiony ze strefami dostępności. Takie podejście jest dostępne w dowolnym regionie obsługującym strefy dostępności.

Takie podejście jest zwykle używane w przypadku obciążeń opartych na maszynach wirtualnych. Aby uzyskać pełną listę usług, które obsługują wdrożenia strefowe, zobacz Usługa strefy dostępności i obsługa regionalna.

Podczas planowania wdrożenia strefowego sprawdź, czy używane usługi platformy Azure są obsługiwane w strefach dostępności, których planujesz używać. Aby na przykład wyświetlić listę dostępnych jednostek SKU maszyn wirtualnych w każdej strefie dostępności, zobacz Sprawdzanie dostępności jednostki SKU maszyny wirtualnej.

Porada

Podczas wdrażania zasobu w określonej strefie dostępności należy wybrać numer strefy. Sekwencja numerów stref jest inna dla każdej subskrypcji platformy Azure. Jeśli wdrażasz zasoby w wielu subskrypcjach platformy Azure, sprawdź numery stref, których należy użyć w każdej subskrypcji. Aby uzyskać więcej informacji, zobacz Strefy dostępności fizycznej i logicznej.

Metoda wdrażania 3: wdrożenia strefowo nadmiarowe

W przypadku korzystania z tej metody warstwa aplikacji jest rozłożona na wiele stref dostępności. Po odebraniu żądań moduł równoważenia obciążenia wbudowany w usługę (która obejmuje strefy dostępności) rozprasza żądania między wystąpieniami w każdej strefie dostępności. Jeśli strefa dostępności wystąpi awaria, moduł równoważenia obciążenia kieruje ruch do wystąpień w strefach dostępności w dobrej kondycji.

Warstwa magazynowania jest również rozłożona na wiele stref dostępności. Kopie danych aplikacji są dystrybuowane w wielu strefach dostępności za pośrednictwem replikacji synchronicznej. Gdy aplikacja wprowadza zmiany w danych, usługa magazynu zapisuje zmianę w wielu strefach dostępności, a transakcja jest uznawana za ukończoną tylko po zakończeniu wszystkich tych zmian. Ten proces zapewnia, że każda strefa dostępności zawsze ma aktualną kopię danych. Jeśli strefa dostępności wystąpi awaria, można użyć innej strefy dostępności, aby uzyskać dostęp do tych samych danych.

Diagram przedstawiający rozwiązanie wdrożone w wielu strefach dostępności. Jest używane podejście do wdrażania strefowo nadmiarowego.

Podejście strefowo nadmiarowe zwiększa odporność rozwiązania na problemy, takie jak awarie centrum danych. Ponieważ dane są replikowane synchronicznie, jednak aplikacja musi czekać na zapisanie danych w wielu oddzielnych lokalizacjach, które mogą znajdować się w różnych częściach obszaru metropolitalnego. W przypadku większości aplikacji opóźnienie związane z komunikacją między strefami jest niewielkie. Jednak w przypadku niektórych obciążeń z dużymi opóźnieniami replikacja synchroniczna w różnych strefach dostępności może mieć wpływ na wydajność aplikacji.

W tej tabeli podsumowano niektóre z zagadnień związanych z filarem:

Filar Wpływ
Niezawodność Wysoka niezawodność. Usługi są odporne na awarię centrum danych lub strefy dostępności. Dane są synchronicznie replikowane w strefach dostępności i bez opóźnień.
Optymalizacja kosztów Umiarkowany koszt. W zależności od używanych usług możesz ponieść pewne koszty dla wyższych warstw usług w celu włączenia nadmiarowości strefy lub niektórych kosztów sieci między strefami.
Efektywność wydajności W przypadku większości obciążeń:akceptowalna wydajność. Takie podejście może zapewnić zadowalającą wydajność.

W przypadku obciążeń z dużymi opóźnieniami:niska wydajność. Niektóre składniki mogą być wrażliwe na opóźnienia spowodowane ruchem między strefami lub czasem replikacji danych.
Doskonałość operacyjna Wysoka wydajność operacyjna. Zazwyczaj trzeba zarządzać tylko pojedynczym wystąpieniem logicznym każdego zasobu. W przypadku większości usług podczas awarii strefy dostępności tryb failover jest odpowiedzialny za firmę Microsoft i odbywa się automatycznie.

Ta tabela zawiera podsumowanie niektórych zagadnień z perspektywy architektury:

Problem z architekturą Wpływ
Zgodność z miejscem przechowywania danych Wysoka. Podczas wdrażania rozwiązania, które korzysta z tego podejścia, dane są przechowywane w wybranym regionie świadczenia usługi Azure.
Dostępność w regionach Regiony ze strefami dostępności. Takie podejście jest dostępne w dowolnym regionie obsługującym strefy dostępności.

Takie podejście jest możliwe w przypadku wielu usług platformy Azure, takich jak Azure Virtual Machine Scale Sets, Azure App Service, Azure Functions, Azure Kubernetes Service, Azure Storage, Azure SQL, Azure Service Bus i wielu innych. Aby uzyskać pełną listę usług, które obsługują nadmiarowość strefy, zobacz Usługa strefy dostępności i obsługa regionalna.

Wdrożenia strefowo nadmiarowe z kopiami zapasowymi w różnych regionach

Wdrożenie strefowo nadmiarowe można rozszerzyć, wykonując regularne kopie zapasowe infrastruktury i danych w regionie pomocniczym. Takie podejście zapewnia korzyści wynikające z podejścia strefowo nadmiarowego i dodaje warstwę ochrony w celu ograniczenia bardzo mało prawdopodobnego wystąpienia awarii pełnego regionu.

Diagram przedstawiający rozwiązanie wdrożone w wielu strefach dostępności we wdrożeniu strefowo nadmiarowym z kopiami zapasowymi znajdującymi się w innym regionie.

Podczas implementowania tego podejścia należy dokładnie rozważyć cel czasu odzyskiwania i cel punktu odzyskiwania:

  • Czas odzyskiwania: jeśli wystąpi awaria regionalna, może być konieczne ponowne skompilowanie rozwiązania w innym regionie świadczenia usługi Azure, co wpływa na czas odzyskiwania. Rozważ utworzenie rozwiązania przy użyciu podejścia IaC, aby umożliwić szybkie ponowne wdrożenie w innym regionie podczas poważnej awarii. Upewnij się, że narzędzia i procesy wdrażania są tak samo odporne, jak aplikacje, dzięki czemu można ich użyć do ponownego wdrożenia rozwiązania, nawet jeśli wystąpi awaria. Zaplanuj i przećwiaj kroki wymagane do przywrócenia rozwiązania do stanu roboczego.

  • Punkt odzyskiwania: Częstotliwość tworzenia kopii zapasowych określa ilość utraty danych, która może wystąpić (punkt odzyskiwania). Zazwyczaj można kontrolować częstotliwość tworzenia kopii zapasowych w celu spełnienia celu punktu odzyskiwania.

Porada

Takie podejście często zapewnia dobrą równowagę dla wszystkich zagadnień związanych z architekturą. Jeśli nie masz pewności, które podejście ma być używane, zacznij od tego typu wdrożenia.

W tej tabeli podsumowano niektóre z zagadnień związanych z filarem:

Filar Wpływ
Niezawodność Bardzo wysoka niezawodność. Usługi są odporne na awarię centrum danych lub strefy dostępności. W przypadku większości usług dane są replikowane automatycznie w różnych strefach i bez opóźnień. Kopie zapasowe danych są tworzone asynchronicznie w regionie rozdzielanym geograficznie. Ta kopia zapasowa zmniejsza wpływ awarii całego regionu przez zminimalizowanie utraty danych. Po awarii pełnego regionu można ręcznie przywrócić operacje do innego regionu. Jednak procesy odzyskiwania mogą być złożone i ręczne przywracanie do innego regionu może zająć trochę czasu.
Optymalizacja kosztów Umiarkowany koszt. Zazwyczaj dodanie kopii zapasowej do innego regionu kosztuje tylko nieco więcej niż implementowanie nadmiarowości strefy.
Efektywność wydajności W przypadku większości obciążeń:akceptowalna wydajność. Takie podejście może zapewnić zadowalającą wydajność.

W przypadku obciążeń z dużymi opóźnieniami:niska wydajność. Niektóre składniki mogą być wrażliwe na opóźnienia spowodowane ruchem między strefami lub czasem replikacji danych.
Doskonałość operacyjna Podczas awarii strefy dostępności:wysoka wydajność operacyjna. Tryb failover to odpowiedzialność firmy Microsoft i odbywa się automatycznie.

Podczas awarii regionalnej:niska wydajność operacyjna. Tryb failover to Twoja odpowiedzialność i może wymagać ręcznego wykonywania operacji i ponownego wdrażania.

Ta tabela zawiera podsumowanie niektórych zagadnień z perspektywy architektury:

Problem z architekturą Wpływ
Zgodność z miejscem przechowywania danych Zależy od wyboru regionu. Dane są przechowywane głównie w określonym regionie świadczenia usługi Azure, ale musisz wybrać inny region do przechowywania kopii zapasowych. Wybierz region, który jest zgodny z wymaganiami dotyczącymi przechowywania danych.
Dostępność w regionach Regiony ze strefami dostępności. Takie podejście jest dostępne w dowolnym regionie obsługującym strefy dostępności.

Metoda wdrażania 4: wdrożenia w wielu regionach

Rozwiązanie można dystrybuować w szerokim obszarze geograficznym za pomocą wielu regionów platformy Azure. Możesz użyć tego podejścia obejmującego wiele regionów, aby zwiększyć niezawodność rozwiązania lub obsługiwać użytkowników rozproszonych geograficznie. Wdrożenie w wielu regionach zmniejsza również ryzyko wystąpienia tymczasowego ograniczenia pojemności zasobów w jednym regionie. Jeśli rezydencja danych jest ważną kwestią dla twojego rozwiązania, należy dokładnie rozważyć regiony, których używasz, aby upewnić się, że dane są przechowywane tylko w lokalizacjach spełniających Twoje wymagania.

Regiony aktywne i pasywne

Architektury obejmujące wiele regionów są złożone i istnieje wiele sposobów projektowania rozwiązania w wielu regionach. W przypadku niektórych obciążeń warto mieć wiele regionów aktywnie przetwarzać żądania jednocześnie (wdrożenia aktywne-aktywne). W przypadku innych obciążeń lepiej jest wyznaczyć jeden region podstawowy i użyć co najmniej jednego regionu pomocniczego do pracy w trybie failover (wdrożenia aktywne-pasywne). Ta sekcja koncentruje się na drugim scenariuszu, w którym jeden region jest aktywny, a drugi jest pasywny. Aby uzyskać informacje o rozwiązaniach z wieloma regionami aktywny-aktywny, zobacz Wzorzec sygnatur wdrażania i wzorzec geodei.

Replikacja danych

Komunikacja między regionami jest znacznie wolniejsza niż komunikacja w regionie. Ogólnie rzecz biorąc, większa odległość geograficzna między dwoma regionami powoduje większe opóźnienie sieci ze względu na dłuższą odległość fizyczną, którą dane muszą podróżować. Zobacz Statystyki opóźnień rundy sieci platformy Azure dla oczekiwanego opóźnienia sieci podczas nawiązywania połączenia między dwoma regionami.

Opóźnienie sieci między regionami może znacząco wpłynąć na projekt rozwiązania, ponieważ należy dokładnie rozważyć, w jaki sposób dodatkowe opóźnienie wpływa na replikację danych i inne transakcje. W przypadku wielu rozwiązań architektura między regionami wymaga replikacji asynchronicznej , aby zminimalizować wpływ ruchu między regionami na wydajność.

Asynchroniczna replikacja danych

Podczas implementowania replikacji asynchronicznej w różnych regionach aplikacja nie czeka na potwierdzenie zmiany we wszystkich regionach. Po zatwierdzeniu zmiany w regionie podstawowym transakcja jest uznawana za ukończoną. Zmiana jest replikowana do regionów pomocniczych w późniejszym czasie. Takie podejście zapewnia, że opóźnienie połączenia między regionami nie ma bezpośredniego wpływu na wydajność aplikacji. Jednak ze względu na opóźnienie replikacji awaria całego regionu może spowodować utratę danych. Ta utrata danych może wystąpić, ponieważ region może wystąpić awaria po zakończeniu zapisu w regionie podstawowym, ale zanim zmiana zostanie zreplikowana do innego regionu.

Diagram przedstawiający rozwiązanie wdrożone w wielu regionach. Replikacja danych odbywa się asynchronicznie.

W tej tabeli podsumowano niektóre z zagadnień związanych z filarem:

Filar Wpływ
Niezawodność Wysoka niezawodność. Rozwiązanie jest odporne na awarię centrum danych, strefę dostępności lub cały region. Dane są replikowane, ale mogą nie być synchroniczne, dlatego w scenariuszu przełączania w tryb failover istnieje możliwość utraty danych.
Optymalizacja kosztów Wysoki koszt. Musisz wdrożyć oddzielne zasoby w każdym regionie, a każdy zasób wiąże się z kosztami wdrożenia i utrzymania. Replikacja danych w różnych regionach może również wiązać się ze znacznymi kosztami.
Efektywność wydajności Wysoka wydajność. Żądania aplikacji nie wymagają ruchu w wielu regionach, dlatego ruch jest zwykle mały.
Doskonałość operacyjna Niska wydajność operacyjna. Musisz wdrożyć zasoby i zarządzać nimi w wielu regionach. Odpowiadasz również za przełączanie w tryb failover między regionami podczas awarii regionalnej.

Ta tabela zawiera podsumowanie niektórych zagadnień z perspektywy architektury:

Problem z architekturą Wpływ
Zgodność z miejscem przechowywania danych Zależy od wyboru regionu. Takie podejście wymaga wybrania wielu regionów do uruchomienia obciążenia. Wybierz regiony, które są zgodne z wymaganiami dotyczącymi przechowywania danych.
Dostępność w regionach Wiele regionów platformy Azure jest sparowanych. Niektóre usługi platformy Azure używają sparowanych regionów do automatycznego replikowania danych. Jeśli obciążenie jest uruchamiane w regionie, który nie ma pary, może być konieczne użycie innego podejścia do replikowania danych.
Synchroniczna replikacja danych

W przypadku zaimplementowania synchronicznego rozwiązania z wieloma regionami aplikacja musi czekać na ukończenie operacji zapisu w każdym regionie świadczenia usługi Azure, zanim transakcja zostanie uznana za ukończoną. Opóźnienie poniesione przez oczekiwanie na operacje zapisu zależy od odległości między regionami. W przypadku wielu obciążeń opóźnienie między regionami może sprawić, że replikacja synchroniczna będzie zbyt niska, aby być przydatna.

Diagram przedstawiający rozwiązanie wdrożone w wielu regionach. Replikacja danych odbywa się synchronicznie.

W tej tabeli podsumowano niektóre z zagadnień związanych z filarem:

Filar Wpływ
Niezawodność Bardzo wysoka niezawodność. Rozwiązanie jest odporne na awarię centrum danych, strefę dostępności lub cały region. Dane są zawsze synchronizowane między regionami, więc nawet w przypadku całkowitej utraty regionu dane są dostępne i kompletne w innym regionie.
Optymalizacja kosztów Wysoki koszt. Musisz wdrożyć oddzielne zasoby w każdym regionie, a każdy zasób wiąże się z kosztami wdrożenia i utrzymania. Replikacja danych w różnych regionach może również wiązać się ze znacznymi kosztami.
Efektywność wydajności Niska wydajność. Żądania aplikacji wymagają ruchu między regionami. W zależności od odległości między regionami replikacja synchroniczna może spowodować znaczne opóźnienie żądań.
Doskonałość operacyjna Niska wydajność operacyjna. Musisz wdrożyć zasoby i zarządzać nimi w wielu regionach. Odpowiadasz również za przełączanie w tryb failover między regionami podczas awarii regionalnej.

Ta tabela zawiera podsumowanie niektórych zagadnień z perspektywy architektury:

Problem z architekturą Wpływ
Zgodność z miejscem przechowywania danych Zależy od wyboru regionu. Takie podejście wymaga wybrania wielu regionów do uruchomienia obciążenia. Wybierz regiony, które są zgodne z wymaganiami dotyczącymi przechowywania danych.
Dostępność w regionach Wiele regionów platformy Azure jest sparowanych. Niektóre usługi platformy Azure używają sparowanych regionów do automatycznego replikowania danych. Jeśli obciążenie jest uruchamiane w regionie, który nie ma pary, może być konieczne użycie innego podejścia do replikowania danych.

Architektury regionów

Podczas projektowania rozwiązania z wieloma regionami należy wziąć pod uwagę, czy regiony platformy Azure, których planujesz używać, są sparowane.

Rozwiązanie z wieloma regionami można utworzyć nawet wtedy, gdy regiony nie są sparowane. Jednak podejścia używane do implementowania architektury obejmującej wiele regionów mogą się różnić. Na przykład w usłudze Azure Storage można użyć magazynu geograficznie nadmiarowego (GRS) z sparowanymi regionami. Jeśli magazyn GRS nie jest dostępny, rozważ użycie funkcji, takich jak replikacja obiektów usługi Azure Storage, lub zaprojektowanie aplikacji do zapisywania w wielu regionach.

Łączenie metod wielostrefowych i wieloregionowych

Jeśli wymagania biznesowe wymagają takiego rozwiązania, należy połączyć instrukcje obejmujące wiele stref i wiele regionów. Można na przykład wdrożyć składniki strefowo nadmiarowe w każdym regionie, a także skonfigurować replikację między regionami. W przypadku niektórych rozwiązań takie podejście zapewnia bardzo wysoki stopień niezawodności. Jednak skonfigurowanie tego typu podejścia może być skomplikowane, a takie podejście może być kosztowne.

Ważne

Obciążenia o znaczeniu krytycznym powinny używać zarówno wielu stref dostępności , jak i wielu regionów. Aby uzyskać więcej informacji na temat zagadnień, które należy wziąć pod uwagę podczas projektowania obciążeń o znaczeniu krytycznym, zobacz dokumentację obciążenia o znaczeniu krytycznym.

Jak usługi platformy Azure obsługują metody wdrażania

Ważne jest, aby zrozumieć szczegółowe informacje o używanych usługach platformy Azure. Na przykład niektóre usługi platformy Azure wymagają skonfigurowania konfiguracji strefy dostępności podczas pierwszego wdrożenia zasobu, podczas gdy inne obsługują zmianę podejścia do wdrażania później. Podobnie niektóre funkcje usługi mogą nie być dostępne w przypadku każdego podejścia do wdrażania.

Aby dowiedzieć się więcej o konkretnych opcjach wdrażania i podejściach do rozważenia dla każdej usługi platformy Azure, odwiedź centrum niezawodności.

Przykłady

W tej sekcji opisano niektóre typowe przypadki użycia i kluczowe wymagania, które zwykle należy wziąć pod uwagę dla każdego obciążenia. Dla każdego obciążenia podano co najmniej jedno sugerowane podejście wdrażania na podstawie wymagań i podejść opisanych w tym artykule.

Aplikacja biznesowa dla przedsiębiorstwa

Contoso, Ltd., to duża firma produkcyjna. Firma wdraża aplikację biznesową w celu zarządzania niektórymi składnikami swoich procesów finansowych.

Wymagania biznesowe: informacje, którymi zarządza system, są trudne do zastąpienia, dlatego dane muszą być utrwalane niezawodnie. Architekci twierdzą, że system musi spowodować jak najmniejszy przestój i jak najmniej utraty danych. Pracownicy firmy Contoso korzystają z systemu w całym dniu roboczym, dlatego wysoka wydajność jest ważna, aby uniknąć oczekiwania członków zespołu. Koszt jest również problemem, ponieważ zespół finansowy musi zapłacić za rozwiązanie.

Sugerowane podejście: wdrożenie strefowo nadmiarowe z kopiami zapasowymi w różnych regionach zapewnia wiele warstw odporności o wysokiej wydajności.

Aplikacja wewnętrzna

Czwarta kawa to mała firma. Firma opracowuje nową aplikację wewnętrzną, która umożliwia pracownikom przesyłanie grafików.

Wymagania biznesowe: w przypadku tego obciążenia głównym problemem jest efektywność kosztowa. Czwarta kawa oceniła wpływ przestoju na działalność biznesową i zdecydowała, że aplikacja nie musi określać priorytetów odporności ani wydajności. Firma akceptuje ryzyko, że awaria w strefie dostępności platformy Azure lub regionie może spowodować, że aplikacja będzie tymczasowo niedostępna.

Sugerowane podejścia:

Starsza migracja aplikacji

Firma Fabrikam, Inc., migruje starszą aplikację z lokalnego centrum danych na platformę Azure. Implementacja będzie używać podejścia IaaS opartego na maszynach wirtualnych. Aplikacja nie została zaprojektowana dla środowiska chmury, a komunikacja między warstwą aplikacji a bazą danych jest bardzo czady.

Wymagania biznesowe: Wydajność jest priorytetem dla tej aplikacji. Odporność jest również ważna, a aplikacja musi nadal działać, nawet jeśli w centrum danych platformy Azure wystąpi awaria.

Sugerowane podejście:

Aplikacja opieki zdrowotnej

Firma Lamna Healthcare wdraża nowy elektroniczny system rejestrowania zdrowia na platformie Azure.

Wymagania biznesowe: ze względu na charakter danych przechowywanych w tym rozwiązaniu rezydencja danych jest niezwykle ważna. Firma Lamna działa zgodnie z rygorystycznymi ramami regulacyjnymi, które nakazują, aby dane pozostały w określonej lokalizacji.

Sugerowane podejścia:

System bankowy

Woodgrove Bank prowadzi podstawowe operacje bankowe z dużego rozwiązania wdrożonego na platformie Azure.

Wymagania biznesowe: jest to system o znaczeniu krytycznym. Wszelkie awarie mogą spowodować poważny wpływ finansowy dla klientów. W rezultacie Woodgrove Bank ma bardzo niską tolerancję ryzyka. System wymaga najwyższego możliwego poziomu niezawodności, a architektura musi ograniczyć ryzyko wystąpienia błędów, które można ograniczyć.

Sugerowane podejście: w przypadku systemu o znaczeniu krytycznym należy użyć wdrożenia w wielu regionach z wieloma strefami. Upewnij się, że regiony spełniają wymagania dotyczące przechowywania danych firmy.

Oprogramowanie jako usługa (SaaS)

Proseware, Inc., tworzy oprogramowanie używane przez firmy na całym świecie. Baza użytkowników firmy jest szeroko dystrybuowana geograficznie.

Wymagania biznesowe: Firma Proseware musi umożliwić każdemu z klientów wybranie regionu wdrożenia, który jest blisko klienta. Włączenie tego wyboru jest ważne w przypadku opóźnień i wymagań dotyczących rezydencji danych klientów.

Sugerowane podejścia:

Poniżej przedstawiono niektóre architektury referencyjne i przykładowe scenariusze dla rozwiązań wielostrefowych i wieloregionowych:

Wiele usług platformy Azure udostępnia wskazówki dotyczące korzystania z wielu stref dostępności, w tym następujące przykłady:

Lista kontrolna dotycząca niezawodności

Zapoznaj się z pełnym zestawem zaleceń.

Lista kontrolna dotycząca niezawodności