Udostępnij za pośrednictwem

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

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

Podczas projektowania rozwiązania dla platformy Azure należy zdecydować, czy wdrożyć w wielu strefach dostępności w regionie, czy wdrożyć je w wielu regionach. Ta decyzja ma wpływ na niezawodność, koszty i wydajność rozwiązania oraz zdolność zespołu do obsługi rozwiązania. Ten przewodnik zawiera informacje o kluczowych wymaganiach biznesowych mających wpływ 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.

Regiony platformy Azure używane w twoim rozwiązaniu są kluczowym wyborem. W przewodniku Wybieranie regionów platformy Azure opisano sposób wybierania i działania w wielu regionach geograficznych. Sposób 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ść: Podejście 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 architektoniczne wymagają wdrożenia większej ilości zasobów niż inne podejścia, 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 często 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. Ten link jest wystarczający dla większości obciążeń w celu włączenia replikacji synchronicznej i komunikacji między strefami. Jeśli jednak przetestujesz obciążenie i określisz, że jest ona wrażliwa 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 nakładu pracy w celu wdrożenia, skonfigurowania i zarządzania nimi. W przypadku rozwiązania o wysokiej dostępności może być również konieczne zaplanowanie sposobu przełączania 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, zwłaszcza gdy wymagane są ręczne kroki. 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.

Filar zabezpieczeń ma zastosowanie niezależnie od sposobu projektowania rozwiązania. Zazwyczaj decyzje dotyczące tego, czy i jak używasz stref dostępności i regionów, nie zmieniają stanu zabezpieczeń. Platforma Azure stosuje tę samą platformę zabezpieczeń do każdego regionu i strefy dostępności.

Wskazówka

W przypadku wielu obciążeń produkcyjnych wdrożenie strefowo nadmiarowe zapewnia najlepszą równowagę kompromisów. 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 wybrać, zacznij od tego typu wdrożenia.

Rozważ inne podejścia do obciążeń, gdy potrzebujesz konkretnych korzyści, jakie zapewniają te podejścia, ale pamiętaj o kompromisach.

Definicje

Termin Definition
Active-active Architektura, w której wiele wystąpień rozwiązania aktywnie przetwarza żądania jednocześnie.
Active-passive Architektura, w której jedno wystąpienie rozwiązania jest wyznaczone jako ruch podstawowy i przetwarza ruch, a co najmniej jedno wystąpienie pomocnicze jest wdrażane w celu obsługi ruchu, jeśli wystąpienie podstawowe jest niedostępne.
Replikacja asynchroniczna Podejście 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 stref dostępności i ma własną infrastrukturę zasilania, chłodzenia i sieci. Wiele regionów obsługuje strefy dostępności.
Datacenter 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 dowolnych strefach 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 Obwód geograficzny zawierający 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 replikacji danych, w którym dane są zapisywane i zatwierdzane w wielu lokalizacjach. Każda lokalizacja musi potwierdzić ukończenie operacji zapisu przed ukończeniem ogólnej operacji 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.

Informacje o sposobie organizowania regionów i stref dostępności na platformie Azure

Platforma Azure ma wiele centrów danych na całym świecie. Region platformy Azure to obwód geograficzny, 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 wystarczająco daleko od siebie, aby zmniejszyć prawdopodobieństwo, że awarie lokalne lub pogoda będą miały wpływ na więcej niż jedną strefę. 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 pozostałe strefy mogły nadal obsługiwać usługi regionalne, pojemność i wysoką dostępność.

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.

Jeśli wdrażasz w regionie świadczenia usługi Azure zawierającym strefy dostępności, możesz użyć wielu stref dostępności razem. Korzystając z 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ą przypięte 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 w jednej strefie dostępności wystąpi awaria, 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 dystrybucją żądań 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. Rozwiązania typu platforma jako usługa (PaaS) zwykle obsługują wdrożenia strefowo nadmiarowe. Rozwiązania 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.

Firma Microsoft próbuje użyć metod, które są najmniej destrukcyjne podczas wdrożeń aktualizacji usługi. Na przykład firma Microsoft ma na celu wdrożenie aktualizacji w pojedynczej strefie dostępności naraz. 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 zespół ds. obciążeń ponosi odpowiedzialność za zapewnienie, ż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. Rozważ nadmierną aprowizowanie, która wdraża więcej wystąpień zasobu, aby niektóre wystąpienia pozostały dostępne podczas uaktualniania innych wystąpień. Aby uzyskać więcej informacji na temat wdrażania aktualizacji na platformie Azure, zobacz Zaawansowane rozwiązania dotyczące bezpiecznego wdrażania.

Wiele regionów ma również sparowany region. Sparowane regiony obsługują niektóre typy metod 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 Regiony platformy Azure i strefy dostępności.

Omówienie wspólnych obowiązków

Wspólna zasada odpowiedzialności opisuje sposób dzielenia obowiązków między dostawcą usług w chmurze a Tobą. W zależności od typu używanych usług 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. Te obowiązki mogą 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 postępować zgodnie z zalecanymi rozwiązaniami i wzorcami projektowymi, aby bezpiecznie obsługiwać błędy. Te rozwiązania są szczególnie ważne podczas operacji trybu failover, takich jak operacje wykonywane w przypadku przejścia strefy dostępności lub regionu w tryb failover, ponieważ przejście w tryb failover między strefami lub regionami często wymaga, aby aplikacja ponawiała próby nawiązania połączeń z usługami.

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. Dyskusje między projektantami rozwiązań a uczestnikami projektu biznesowego powinny kierować się tymi wymaganiami.

Tolerancja ryzyka

Różne organizacje mają różne stopnie tolerancji ryzyka. Nawet w ramach jednej organizacji tolerancja ryzyka często różni się w zależności od obciążenia. Większość obciążeń nie wymaga bardzo wysokiej dostępności. Jednak niektóre obciążenia są tak krytyczne, że warto zmniejszyć nawet mało prawdopodobne zagrożenia, takie jak poważne klęski żywiołowe wpływające na szeroki obszar geograficzny.

W poniższej 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 rozruchy 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ęska żywiołowa w jednej części obszaru metropolitalnego		 Średni
Awaria regionu - Poważne klęski żywiołowe, które wpływają 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		 Low

Najlepszym rozwiązaniem jest ograniczenie wszelkich możliwych zagrożeń dla każdego obciążenia. Jednak takie podejście nie jest 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ć.

Wskazówka

Niezależnie od celów dotyczących niezawodności wszystkie obciążenia muszą mieć pewne środki zaradcze na potrzeby odzyskiwania po awarii (DR). 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ń należy podjąć świadomą decyzję o tym, które zagrożenia są akceptowalne i które zagrożenia wymagają ograniczenia ryzyka.

Wymagania dotyczące niezawodności

Ważne jest, aby zrozumieć wymagania dotyczące niezawodności obciążenia, na przykład ustalając wskaźniki odzyskiwania, takie jak wskaźniki czasu odzyskiwania (RTO) i wskaźniki punktu odzyskiwania (RPO). Wymagania dotyczące niezawodności pomagają zdecydować, które podejścia mają być wykluczone. Jeśli nie masz jasnych wymagań, nie możesz podjąć świadomej decyzji o tym, które podejście należy wykonać. Aby uzyskać więcej informacji, zobacz Strategie architektury służące do identyfikowania i oceniania przepływów.

Cele poziomu usług

Należy zrozumieć oczekiwany cel poziomu usług (SLO, uptime) rozwiązania. Na przykład może istnieć wymaganie biznesowe, że rozwiązanie musi spełniać 99,9% czasu pracy.

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 i warunków, 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 definiuje dostępność usług, może nie zawsze być zgodna z sposobem oceniania kondycji obciążenia.

Decyzje dotyczące architektury wpływają na złożony cel slo rozwiązania. Ogólnie rzecz biorąc, im większa nadmiarowość, którą tworzysz w rozwiązaniu, tym wyższa wartość slo prawdopodobnie będzie. 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 z usług platformy Azure, których używasz, aby upewnić się, że rozumiesz, jak zmaksymalizować odporność i umowę SLA usługi.

Miejsce przechowywania danych

Niektóre organizacje nakładają ograniczenia dotyczące lokalizacji fizycznych, w których mogą być przechowywane i przetwarzane ich dane. Czasami te wymagania są oparte na standardach prawnych lub regulacyjnych. W innych scenariuszach 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 / Notatka

Unikaj bezpodstawnych założeń dotyczących wymagań dotyczących rezydencji danych. Jeśli musisz przestrzegać określonych standardów regulacyjnych, sprawdź, jakie normy faktycznie określają.

Lokalizacja użytkownika

Dzięki zrozumieniu, gdzie znajdują się użytkownicy, możesz podjąć świadomą decyzję o sposobie optymalizacji opóźnień i niezawodności 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ą współlokowani.

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, aby poprawić środowisko użytkownika i zbliżyć aplikacje 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 przyspieszania ruchu globalnego, takiego jak przyspieszenie zapewniane przez usługę Azure Front Door .

Budżet

Jeśli działasz 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 podejmować decyzje dotyczące architektury. Złożone architektury są trudniejsze do działania, trudniejsze do zabezpieczenia i często mniej wydajne. Upewnij się, że przestrzegasz zasady prostoty.

Przykładowy scenariusz

Udostępniając regiony i strefy dostępności, platforma Azure umożliwia wybranie podejścia do wdrażania, które odpowiada Twoim potrzebom. Każde podejście zapewnia konkretne korzyści i wiąże się z kosztami.

Aby zilustrować metody wdrażania, których można użyć, rozważmy przykładowy scenariusz. Załóżmy, że chcesz wdrożyć nowe rozwiązanie, które zawiera 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 przykładu ilustrujących podstawowe pojęcia.

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 . Poniższa tabela zawiera podsumowanie niektórych zagadnień związanych z filarem.

Filar Lokalnie nadmiarowy Strefowe (przypięte) Zone-redundant Wiele regionów
Reliability 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ść operacyjna 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 Wysokie wymagania operacyjne Niskie wymagania operacyjne Wysokie wymagania operacyjne

Poniższa tabela zawiera podsumowanie niektórych metod, których można użyć i sposobu ich wpływu na architekturę.

Kwestie dotyczące architektury Lokalnie nadmiarowy Strefowe (przypięte) Zone-redundant Wiele regionów
Zgodność z miejscem przechowywania danych High High High Zależy od regionu
Dostępność regionalna 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 podejść w różnych częściach rozwiązania.

Podejście 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 scenariuszach 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, że obciążenie może mieć wpływ. Jeśli tak jest, twoje rozwiązanie może być niedostępne lub dane mogą zostać utracone.

W przypadku obciążeń z dużymi opóźnieniami takie podejście może również spowodować obniżenie wydajności. Składniki obciążenia mogą nie być kolokowane 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 przenieść wystąpienia usługi między strefami dostępności, co może nieco wpłynąć na wydajność. Jednak ten spadek wydajności nie jest problemem dla większości obciążeń.

Poniższa tabela zawiera podsumowanie niektórych zagadnień związanych z filarem.

Filar Wpływ
Reliability Niska niezawodność. Usługi podlegają awarii, jeśli centrum danych ulegnie awarii. Można jednak utworzyć aplikację, która będzie odporna na inne typy awarii.
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 regionami.
Efektywność operacyjna - 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 mogą znajdować się w różnych strefach dostępności, więc składniki wrażliwe na opóźnienia mogą mieć niższą wydajność.
Doskonałość operacyjna Wysoka wydajność operacyjna. Wystarczy wdrożyć pojedyncze wystąpienie każdego zasobu i zarządzać nim.

Poniższa tabela zawiera podsumowanie niektórych problemów z perspektywy architektury.

Kwestie dotyczące architektury 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ść regionalna Wysoka. Tego podejścia można użyć w dowolnym regionie świadczenia usługi Azure.

Wdrożenia lokalnie nadmiarowe z kopiami zapasowymi 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 wyeliminowania awarii w regionie podstawowym.

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

Podczas wdrażania 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 szybko ponownie wdrożyć rozwiązanie w innym regionie, jeśli wystąpi poważna awaria. Upewnij się, że narzędzia i procesy wdrażania są tak 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ćmij kroki wymagane do przywrócenia rozwiązania z powrotem do stanu roboczego.

  • Punkt odzyskiwania: Częstotliwość tworzenia kopii zapasowych określa ilość utraty danych, która jest znana jako punkt odzyskiwania. Zazwyczaj można kontrolować częstotliwość tworzenia kopii zapasowych, aby można było spełnić cel punktu odzyskiwania.

Poniższa tabela zawiera podsumowanie niektórych zagadnień związanych z filarem.

Filar Wpływ
Reliability Umiarkowana niezawodność. Usługi podlegają awarii, jeśli centrum danych ulegnie awarii. Kopie zapasowe danych są asynchroniczne 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 dodawanie kopii zapasowej do innego regionu kosztuje tylko nieco więcej niż wdrażanie lokalnie nadmiarowego zasobu.
Efektywność operacyjna - 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 mogą znajdować się w różnych strefach dostępności, więc składniki wrażliwe na opóźnienia mogą mieć niższą wydajność.
Doskonałość operacyjna Podczas awarii w regionie:Niska wydajność operacyjna. Praca w trybie failover to Twoja odpowiedzialność i może wymagać ręcznego wykonywania i ponownego wdrażania.

Poniższa tabela zawiera podsumowanie niektórych problemów z perspektywy architektury.

Kwestie dotyczące architektury 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 zgodny z wymaganiami dotyczącymi rezydencji danych.
Dostępność regionalna 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 ramach 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 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 aktywnego pasywnego .

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

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 w ogóle nie została wdrożona w regionie.

W przypadku korzystania z modelu wdrażania strefowego zakładasz wiele obowiązków:

  • Musisz wdrożyć zasoby w każdej strefie dostępności i skonfigurować te zasoby i zarządzać nimi indywidualnie.

  • 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, takich jak użycie modułu równoważenia obciążenia. Należy upewnić się, że moduł równoważenia obciążenia spełnia wymagania dotyczące odporności. Należy również zdecydować, czy używać 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 metro dr.

Poniższa tabela zawiera podsumowanie niektórych zagadnień związanych z filarem.

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

- Po wdrożeniu 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 jednej strefie dostępności:niski koszt. Wdrożenie jednostrefowe wymaga tylko jednego wystąpienia każdego zasobu.

- Po wdrożeniu w wielu strefach dostępności:wysoki koszt. Wdrażasz wiele wystąpień zasobów, z których każdy jest rozliczany oddzielnie.
Efektywność operacyjna 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. Musisz 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 tryb failover odpowiada za Twoją odpowiedzialność.

Poniższa tabela zawiera podsumowanie niektórych problemów z perspektywy architektury.

Kwestie dotyczące architektury 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ść regionalna 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óre mają być używane. Aby 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.

Wskazówka

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.

Podejście 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ę rozprasza żądania między wystąpieniami w każdej strefie dostępności. Sama usługa obejmuje strefy 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. Transakcja jest uważana za ukończoną tylko wtedy, gdy wszystkie te zmiany zostaną ukończone. Ten proces gwarantuje, że każda strefa dostępności zawsze ma up-to-date kopię danych. Jeśli strefa dostępności wystąpi awaria, można użyć innej strefy dostępności w celu uzyskania dostępu 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. Jednak ze względu na to, że dane są replikowane synchronicznie, 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 komunikacji między strefami jest niewielkie. Jednak w przypadku niektórych obciążeń z dużym opóźnieniem replikacja synchroniczna w różnych strefach dostępności może mieć wpływ na wydajność aplikacji.

Poniższa tabela zawiera podsumowanie niektórych zagadnień związanych z filarem.

Filar Wpływ
Reliability Wysoka niezawodność. Usługi są odporne na awarię centrum danych lub strefy dostępności. Dane są synchronicznie replikowane w strefach dostępności bez opóźnień.
Optymalizacja kosztów Umiarkowany koszt. W zależności od używanych usług może być naliczane pewne koszty dla wyższych warstw usług w celu włączenia nadmiarowości strefy.
Efektywność operacyjna - 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 ze względu na ruch między strefami lub czas replikacji danych.
Doskonałość operacyjna Wysoka wydajność operacyjna. Zazwyczaj trzeba zarządzać tylko jednym 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 występuje automatycznie.

Poniższa tabela zawiera podsumowanie niektórych problemów z perspektywy architektury.

Kwestie dotyczące architektury 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ść regionalna 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, w tym usług Azure Virtual Machine Scale Sets, Azure App Service, Azure Functions, Azure Kubernetes Service (AKS), Azure Storage, Azure SQL, Azure Service Bus i wielu innych usług. 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 zminimalizowania 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 wdrażania 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 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 z powrotem do stanu roboczego.

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

Wskazówka

Takie podejście często zapewnia dobrą równowagę dla wszystkich zagadnień dotyczących architektury. Jeśli nie masz pewności, którego podejścia użyć, zacznij od tego typu wdrożenia.

Poniższa tabela zawiera podsumowanie niektórych zagadnień związanych z filarem.

Filar Wpływ
Reliability 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 między strefami bez opóźnień. Kopie zapasowe danych są asynchroniczne w regionie rozdzielanym geograficznie. Ta kopia zapasowa zmniejsza wpływ awarii pełnego 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ść operacyjna - 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 ze względu na ruch między strefami lub czas 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. Praca w trybie failover to Twoja odpowiedzialność i może wymagać ręcznego wykonywania i ponownego wdrażania.

Poniższa tabela zawiera podsumowanie niektórych problemów z perspektywy architektury.

Kwestie dotyczące architektury 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 zgodny z wymaganiami dotyczącymi rezydencji danych.
Dostępność regionalna Regiony ze strefami dostępności. Takie podejście jest dostępne w dowolnym regionie obsługującym strefy dostępności.

Podejście wdrażania 4: wdrożenia w wielu regionach

Możesz użyć wielu regionów platformy Azure razem, aby dystrybuować rozwiązanie w szerokim obszarze geograficznym. Możesz użyć tego podejścia obejmującego wiele regionów, aby zwiększyć niezawodność rozwiązania lub obsługiwać geograficznie rozproszonych użytkowników. 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.

Aktywne i pasywne regiony

Architektury obejmujące wiele regionów są złożone i istnieje wiele sposobów projektowania rozwiązania obejmującego wiele regionów. 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 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ć więcej informacji na temat rozwiązań aktywnych-aktywnych w wielu regionach, zobacz Wzorzec sygnatur wdrażania i wzorzec geode.

Replikacja danych

Komunikacja między regionami jest znacznie wolniejsza niż komunikacja między regionami. Ogólnie rzecz biorąc, większa odległość geograficzna między dwoma regionami wiąże się z większym opóźnieniem sieci ze względu na dłuższą odległość fizyczną, którą dane muszą podróżować. Aby uzyskać więcej informacji na temat oczekiwanego opóźnienia sieci podczas nawiązywania połączenia między dwoma regionami, zobacz Statystyki opóźnienia rundy sieci platformy Azure.

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ść.

Replikacja danych asynchronicznych

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ż w regionie 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.

Poniższa tabela zawiera podsumowanie niektórych zagadnień związanych z filarem.

Filar Wpływ
Reliability 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, więc w scenariuszu trybu failover może wystąpić utrata 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 wdrażania i konserwacji. Replikacja danych w różnych regionach może również wiązać się ze znacznymi kosztami.
Efektywność operacyjna Wysoka wydajność. Żądania aplikacji nie wymagają ruchu między regionami, więc ruch jest zwykle mały.
Doskonałość operacyjna Niska wydajność operacyjna. Musisz wdrożyć zasoby w wielu regionach i zarządzać nimi. Odpowiadasz również za przejście w tryb failover między regionami podczas awarii regionalnej.

Poniższa tabela zawiera podsumowanie niektórych problemów z perspektywy architektury.

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

Synchroniczna replikacja danych

Jeśli zaimplementujesz rozwiązanie synchroniczne z wieloma regionami, aplikacja musi poczekać 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.

Poniższa tabela zawiera podsumowanie niektórych zagadnień związanych z filarem.

Filar Wpływ
Reliability 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. Nawet jeśli cały region ulegnie awarii, dane pozostają kompletne i dostępne 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 wdrażania i konserwacji. Replikacja danych w różnych regionach może również wiązać się ze znacznymi kosztami.
Efektywność operacyjna 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 w wielu regionach i zarządzać nimi. Odpowiadasz również za przejście w tryb failover między regionami podczas awarii regionalnej.

Poniższa tabela zawiera podsumowanie niektórych problemów z perspektywy architektury.

Kwestie dotyczące architektury Wpływ
Zgodność z miejscem przechowywania danych Zależy od wyboru regionu. Takie podejście wymaga wybrania wielu regionów, w których ma być uruchamiane obciążenie. Wybierz regiony zgodne z wymaganiami dotyczącymi rezydencji danych.
Dostępność regionalna Wiele regionów platformy Azure jest sparowanych. Niektóre usługi platformy Azure używają sparowanych regionów do automatycznego replikowania danych. Jeśli uruchamiasz obciążenie 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 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 magazynu, lub zaprojektuj aplikację w celu zapisu w wielu regionach.

Łączenie metod obejmujących wiele stref i wielu regionów

Jeśli wymagania biznesowe wymagają takiego rozwiązania, należy połączyć instrukcje obejmujące wiele stref i wielu 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 i takie podejście może być kosztowne.

Ważne

Obciążenia o krytycznym znaczeniu powinny używać zarówno wielu stref dostępności , jak i wielu regionów.

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 usługi obsługują zmianę podejścia wdrażania później. Podobnie niektóre funkcje usługi mogą nie być dostępne w każdym podejściu 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 przypadków użycia

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., jest dużą firmą produkcyjną. Firma wdraża aplikację biznesową (LOB) do zarządzania niektórymi składnikami procesów finansowych.

Wymagania biznesowe: Informacje, którymi zarządza system, są trudne do zastąpienia, więc dane muszą być utrwalane niezawodnie. Architekci potrzebują systemu, aby wywłaszczał jak najmniejszy przestój i utratę danych. Pracownicy firmy Contoso korzystają z systemu w całym dniu roboczym, więc 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 z wysoką 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 lub regionie platformy Azure 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. Planują użyć podejścia IaaS opartego na maszynach wirtualnych. Aplikacja nie jest przeznaczona dla środowiska chmury, a komunikacja między warstwą aplikacji a bazą danych jest bardzo rozmowna.

Wymagania biznesowe: Wydajność jest priorytetem dla tej aplikacji. Odporność jest również ważna, a aplikacja musi nadal działać, nawet jeśli 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 miejsce przechowywania danych jest niezwykle ważne. Firma Lamna działa zgodnie z ścisłymi 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: Ten system ma krytyczne znaczenie. Wszelkie awarie mogą spowodować duży wpływ finansowy na klientów. W rezultacie Woodgrove Bank ma bardzo niską tolerancję ryzyka. System potrzebuje najwyższego możliwego poziomu niezawodności, a architektura musi ograniczyć ryzyko wystąpienia błędów, które mogą zostać złagodzone.

Sugerowane podejście: W przypadku systemu o znaczeniu krytycznym należy użyć wdrożenia obejmującego wiele regionów wielostrefowych i zapewnić, że regiony spełniają wymagania dotyczące przechowywania danych firmy.

Oprogramowanie jako usługa

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 klientowi wybranie regionu wdrożenia, który znajduje się blisko klienta. Włączenie tego wyboru jest ważne w przypadku opóźnień i wymagań dotyczących rezydencji danych klientów.

Sugerowane podejścia:

Dalsze kroki

Następujące architektury referencyjne i przykładowe scenariusze dotyczą rozwiązań obejmujących wiele stref i wielu regionów:

Aby zaimplementować rozwiązania w wielu strefach dostępności, użyj następujących usług platformy Azure:

  • Last updated on