Rekomendacje do korzystania ze stref dostępności i regionów
Dotyczy tego zalecenia listy kontrolnej dotyczącej 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ść projektu | o wysokiej dostępności w wielu regionalach
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żysz w wielu strefach dostępności w regionie, czy 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.
Decyzja o najlepszych regionach świadczenia usługi Azure do użycia w twoim rozwiązaniu jest kluczowym wyborem. W przewodniku 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 dobrze zaprojektowanej struktury:
- Niezawodność: Wybrane 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, 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 dużej przepustowości i małych opóźnieniach, co jest wystarczające dla większości obciążeń w celu włączenia replikacji synchronicznej i komunikacji między strefami. Jeśli jednak obciążenie zostało przetestowane i jest wrażliwe na opóźnienie sieci w różnych strefach, może być konieczne rozważenie fizycznego zlokalizowania 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 zakresie wdrażania, konfigurowania i zarządzania nimi. Ponadto w przypadku rozwiązania o wysokiej dostępności może być 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.
Jednak projektujesz rozwiązanie, ma zastosowanie filar zabezpieczeń. 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.
Napiwek
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 związane z obciążeniem, gdy potrzebujesz konkretnych korzyści, jakie zapewniają te podejścia, ale pamiętaj o kompromisach.
Definicje
| Okres | Definicja |
|---|---|
| Aktywne/aktywne | Architektura, w której wiele wystąpień rozwiązania aktywnie przetwarza żądania jednocześnie. |
| Aktywne/pasywne | Architektura, w której jedno wystąpienie rozwiązania jest wyznaczone jako ruch podstawowy i przetwarza, 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 replikacji danych, w którym dane są zapisywane i zatwierdzane w jednej lokalizacji. W późniejszym czasie zmiany są replikowane do innej lokalizacji. |
| Availability zone | 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 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 (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. |
Kluczowe strategie projektowania
Platforma Azure ma duży globalny ślad. 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 są wystarczająco daleko od siebie, aby zmniejszyć prawdopodobieństwo, że więcej niż jeden będzie miało wpływ na lokalne awarie lub pogodę. 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.
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 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 staramy się wdrażać aktualizacje 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. Ponadto można rozważyć nadmierną 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 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 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 Ciebie. 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, które mogą nawet obejmować replikację danych, tryb failover, powrót po awarii i inne zadania związane z systemem rozproszonym.
Twój własny kod musi być zalecanymi rozwiązaniami i wzorcami projektowymi w celu bezproblemowego obsługi błędów. Te rozwiązania są jeszcze ważniejsze podczas operacji trybu failover, takich jak te, które mają miejsce w przypadku przejścia strefy dostępności lub regionu w tryb failover, 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 inna 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ęska żywiołowa w jednej części obszaru metropolitalnego. |
Śred. |
| 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. |
Niski |
Byłoby idealnym rozwiązaniem, aby ograniczyć każde możliwe ryzyko 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ć.
Napiwek
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ń należy podjąć świadomą decyzję o tym, które czynniki ryzyka są przygotowane 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 wykonać. Aby uzyskać więcej informacji, zobacz Target functional and nonfunctional requirements (Docelowe wymagania funkcjonalne i niefunkcjonalne).
Cele poziomu usług
Należy zrozumieć oczekiwany cel poziomu usług (SLO, uptime) rozwiązania. Na przykład może istnieć wymaganie biznesowe, które 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 wskazuje dostępność usługi, nie zawsze jest zgodna ze sposobem, w jaki należy wziąć pod uwagę kondycję 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 większa będzie 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 z usług platformy Azure, których używasz, aby upewnić się, że rozumiesz, jak zmaksymalizować odporność i umowę SLA usługi.
Przechowywanie 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 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 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 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 udostępniane 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ści
Dobrym rozwiązaniem jest unikanie niepotrzebnej złożoności w architekturze rozwiązania. Im większa złożoność jest wprowadzana, 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. Przestrzegaj zasady prostoty.
Ułatwienia platformy Azure
Udostępniają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żdy zapewnia korzyści i ponosi koszty.
Aby zilustrować metody wdrażania, których można użyć, rozważmy 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:
Ten przykład nie jest specyficzny dla żadnych konkretnych 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. Ta tabela zawiera podsumowanie niektórych zagadnień związanych z filarem:
| Filar | Lokalnie nadmiarowy | Strefowe (przypięte) | Strefowo nadmiarowy | 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 |
| Sprawność operacyjna | Niskie wymagania operacyjne | Wysokie wymagania operacyjne | Niskie wymagania operacyjne | Wysokie wymagania operacyjne |
W tej tabeli przedstawiono podsumowanie niektórych metod, których można użyć, oraz sposobu ich wpływu na architekturę:
| Kwestie dotyczące architektury | Lokalnie nadmiarowy | Strefowe (przypięte) | Strefowo nadmiarowy | 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 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 sytuacjach platforma Azure może również przenieść zasób między strefami 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ść. Nie jest to jednak problemem dla większości obciążeń.
Ta tabela zawiera podsumowanie niektórych zagadnień związanych z filarem:
| Filar | Wpływ |
|---|---|
| Niezawodność | Niska niezawodność. Usługi podlegają awarii, jeśli centrum danych ulegnie awarii. Można jednak skompilować aplikację tak, aby mogła być 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ść 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 wysokim opóźnieniu. |
| Sprawność 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:
| 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ść w regionach | 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. Oto jak wygląda:
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 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 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ć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órą może wystąpić (punkt odzyskiwania). Zazwyczaj można kontrolować częstotliwość tworzenia kopii zapasowych, aby można było spełnić cel punktu odzyskiwania.
Ta tabela zawiera podsumowanie niektórych zagadnień związanych z filarem:
| Filar | Wpływ |
|---|---|
| Niezawodność | 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ść 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 wysokim opóźnieniu. |
| Sprawność 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. |
Ta 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ść 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 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.
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 :
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 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 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, na przykład za pomocą 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.
Ta tabela zawiera podsumowanie niektórych zagadnień związanych z filarem:
| Filar | Wpływ |
|---|---|
| Niezawodność | 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. 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 jednej 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żdy jest rozliczany oddzielnie. |
| 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. |
| Sprawność 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ść. |
Ta 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ść 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.
Napiwek
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ę (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 uważana za ukończoną tylko po zakończeniu wszystkich tych zmian. Ten proces gwarantuje, ż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 w celu uzyskania dostępu do tych samych danych.
Podejście strefowo nadmiarowe zwiększa odporność rozwiązania na problemy, takie jak awarie centrum danych. Ponieważ dane są replikowane synchronicznie, aplikacja musi jednak 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żym opóźnieniem replikacja synchroniczna w różnych strefach dostępności może mieć wpływ na wydajność aplikacji.
Ta tabela zawiera podsumowanie niektórych 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. |
| 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. |
| Sprawność 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 odbywa się automatycznie. |
Ta 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ść 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, w tym usług Azure Virtual Machine Scale Sets, aplikacja systemu Azure 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 zminimalizowania bardzo mało prawdopodobnego wystąpienia awarii pełnego regionu.
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 z powrotem do stanu roboczego.
Punkt odzyskiwania: Częstotliwość tworzenia kopii zapasowych określa ilość utraty danych, którą może wystąpić (punkt odzyskiwania). Zazwyczaj można kontrolować częstotliwość tworzenia kopii zapasowych w celu spełnienia celu punktu odzyskiwania.
Napiwek
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.
Ta tabela zawiera podsumowanie niektórych 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ą 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ść 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. |
| Sprawność 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. |
Ta 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ść w regionach | 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ć, które regiony są używane w celu zapewnienia, że dane są przechowywane tylko w lokalizacjach, które spełniają 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ć informacje o rozwiązaniach z wieloma regionami aktywny-aktywny, zobacz Wzorzec sygnatur wdrożenia i wzorzec geode.
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 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ć. Zobacz Statystyki opóźnienia rundy sieci platformy Azure, aby uzyskać oczekiwane opóźnienie 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ść.
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.
Ta tabela zawiera podsumowanie niektórych 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, 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 wdrożeniem i utrzymaniem kosztów. 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 między regionami, więc ruch jest zwykle mały. |
| Sprawność 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. |
Ta 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ść 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 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.
Ta tabela zawiera podsumowanie niektórych 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 wdrożeniem i utrzymaniem kosztów. 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ń. |
| Sprawność 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. |
Ta 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ść 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 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 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 zaprojektuj aplikację do 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, a 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. 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 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
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ą w celu 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 twierdzą, że system musi spowodować jak najmniejszy przestój i jak najmniejszą utratę 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 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:
- Wdrożenie lokalnie nadmiarowe z kopiami zapasowymi w różnych regionach ma najniższy koszt, ale również ma znaczne ryzyko.
- Wdrożenie strefowo nadmiarowe z kopiami zapasowymi w różnych regionach zapewnia lepszą odporność, ale przy nieco wyższym koszcie.
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 czadowa.
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:
- Firma Fabrikan powinna najpierw wypróbować wdrożenie strefowo nadmiarowe. Powinni sprawdzić, czy wydajność spełnia ich wymagania.
- Jeśli wydajność rozwiązania strefowo nadmiarowego nie jest akceptowalna, rozważ wdrożenie strefowe (przypięte) z pasywnymi wdrożeniami w wielu strefach dostępności (dr w regionie).
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:
- Wdrożenie wieloregionowe obejmujące wiele stref, jeśli istnieje wiele regionów, które spełniają wymagania dotyczące przechowywania danych firmy Lamna.
- Jeśli istnieje tylko jeden region, który odpowiada ich potrzebom, rozważ wdrożenie strefowo nadmiarowe lub wdrożenie strefowo nadmiarowe z kopią zapasową w różnych regionach zapewnia rozwiązanie z jednym regionem
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ć 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 stref. Upewnij się, że regiony spełniają wymagania dotyczące rezydencji 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 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:
- Wdrożenie wieloregionowe jest zazwyczaj dobrym wyborem dla dostawcy SaaS, szczególnie w przypadku użycia go we wzorcu sygnatur wdrażania.
- Wdrożenie strefowo nadmiarowe z jednym regionem w połączeniu z globalnym rozwiązaniem przyspieszania ruchu, takiego jak usługa Azure Front Door.
Pokrewne łącza
Poniżej przedstawiono niektóre architektury referencyjne i przykładowe scenariusze dla rozwiązań obejmujących wiele stref i wielu regionów:
- Podstawowa aplikacja internetowa strefowo nadmiarowa o wysokiej dostępności
- Aplikacja internetowa o wysokiej dostępności w wielu regionach
- Wieloregionowa aplikacja N-warstwowa
- Wielowarstwowa aplikacja internetowa utworzona na potrzeby wysokiej dostępności/odzyskiwania po awarii
Wiele usług platformy Azure zawiera wskazówki dotyczące korzystania z wielu stref dostępności, w tym następujących przykładów:
- Azure Site Recovery: włączanie odzyskiwania po awarii maszyny wirtualnej platformy Azure między strefami dostępności
- Azure NetApp Files: Omówienie replikacji między strefami usługi Azure NetApp Files
- Nadmiarowość usługi Azure Storage
Lista kontrolna dotycząca niezawodności
Zapoznaj się z pełnym zestawem zaleceń.