Share via

Konfiguracje obciążenia SAP ze strefami dostępności platformy Azure

  • Artykuł

Ponadto do wdrażania różnych warstw architektury SAP w zestawach dostępności platformy Azure można również używać usługi Azure Strefy dostępności na potrzeby wdrożeń obciążeń SAP. Strefa dostępności platformy Azure jest definiowana jako "Unikatowe lokalizacje fizyczne w regionie. Każda strefa składa się z co najmniej jednego centrum danych wyposażonego w niezależne zasilanie, chłodzenie i sieć". Usługa Azure Strefy dostępności nie jest dostępna we wszystkich regionach. W przypadku regionów platformy Azure, które zapewniają Strefy dostępności, sprawdź mapę regionów platformy Azure. Ta mapa pokaże, które regiony udostępniają lub są ogłaszane w celu udostępnienia Strefy dostępności.

Zgodnie z typową architekturą SAP NetWeaver lub S/4HANA należy chronić trzy różne warstwy:

  • Warstwa aplikacji SAP, która może być jedną do kilkudziesięciu maszyn wirtualnych. Chcesz zminimalizować prawdopodobieństwo wdrożenia maszyn wirtualnych na tym samym serwerze hosta. Chcesz również, aby te maszyny wirtualne były w akceptowalnej odległości od warstwy DBMS, aby zapewnić opóźnienie sieci w akceptowalnym oknie
  • Warstwa SAP ASCS/SCS reprezentująca pojedynczy punkt awarii w architekturze SAP NetWeaver i S/4HANA. Zazwyczaj przyjrzyjmy się dwóm maszynom wirtualnym, które mają zostać omówione w strukturze trybu failover. W związku z tym te maszyny wirtualne powinny być przydzielane w różnych domenach błędów infrastruktury
  • Warstwa SYSTEMU SAP DBMS, która reprezentuje również pojedynczy punkt awarii. W zwykłych przypadkach składa się ona z dwóch maszyn wirtualnych objętych strukturą trybu failover. W związku z tym te maszyny wirtualne powinny być przydzielane w różnych domenach błędów infrastruktury. Wyjątki to wdrożenia skalowane w poziomie oprogramowania SAP HANA, w których można używać więcej niż dwóch maszyn wirtualnych

Główne różnice między wdrażaniem krytycznych maszyn wirtualnych za pośrednictwem zestawów dostępności lub Strefy dostępności są następujące:

  • Wdrażanie przy użyciu zestawu dostępności umożliwia tworzenie kolejek maszyn wirtualnych w zestawie w jednej strefie lub centrum danych (niezależnie od tego, co ma zastosowanie do określonego regionu). W związku z tym wdrożenie za pośrednictwem zestawu dostępności nie jest chronione przez problemy z zasilaniem, chłodzeniem ani siecią, które mają wpływ na moduły dataceter strefy jako całości. Po stronie plusa maszyny wirtualne są zgodne z domenami aktualizacji i błędów w tej strefie lub centrum danych. W szczególności w przypadku warstwy SAP ASCS lub DBMS, w której chronimy dwie maszyny wirtualne na zestaw dostępności, wyrównanie z domenami błędów zapobiega zakończeniu obu maszyn wirtualnych na tym samym sprzęcie hosta.
  • W przypadku wdrażania maszyn wirtualnych za pośrednictwem usługi Azure Strefy dostępności i wybierania różnych stref (maksymalnie trzech możliwych) zostanie wdrożona maszyny wirtualne w różnych lokalizacjach fizycznych i z tym zwiększa ochronę przed problemami z zasilaniem, chłodzeniem lub siecią, które mają wpływ na dane jako całość. Jednak podczas wdrażania więcej niż jednej maszyny wirtualnej z tej samej rodziny maszyn wirtualnych w tej samej strefie dostępności nie ma ochrony przed tymi maszynami wirtualnymi, które kończą się na tym samym hoście lub tej samej domenie błędów. W związku z tym wdrażanie za pomocą Strefy dostępności jest idealne dla warstwy SAP ASCS i DBMS, w której zwykle przyjrzymy się dwóm maszynom wirtualnym. W przypadku warstwy aplikacji SAP, która może być znacznie większa niż dwie maszyny wirtualne, może być konieczne powrót do innego modelu wdrażania (zobacz później)

Motywacją do wdrożenia w usłudze Azure Strefy dostępności powinno być to, że w oparciu o awarię jednej krytycznej maszyny wirtualnej lub możliwość zmniejszenia przestojów związanych z stosowaniem poprawek oprogramowania w krytycznym znaczeniu chcesz chronić przed większymi problemami z infrastrukturą, które mogą mieć wpływ na dostępność jednego lub wielu centrów danych platformy Azure.

W ramach innej funkcji wdrażania odporności platforma Azure wprowadziła zestawy skalowania maszyn wirtualnych z elastyczną aranżacją obciążenia SAP. Zestaw skalowania maszyn wirtualnych zapewnia logiczne grupowanie maszyn wirtualnych zarządzanych przez platformę. Elastyczna aranżacja zestawu skalowania maszyn wirtualnych umożliwia utworzenie zestawu skalowania w regionie lub użycie go w różnych strefach dostępności. Podczas tworzenia elastycznego zestawu skalowania w regionie z platformąFaultDomainCount>1 (FD>1) maszyny wirtualne wdrożone w zestawie skalowania będą dystrybuowane między określoną liczbę domen błędów w tym samym regionie. Z drugiej strony utworzenie elastycznego zestawu skalowania w różnych strefach dostępności przy użyciu platformFaultDomainCount=1 (FD=1) spowoduje dystrybucję maszyn wirtualnych w różnych strefach, a zestaw skalowania będzie również dystrybuować maszyny wirtualne między różne domeny błędów w każdej strefie w oparciu o najlepsze wysiłki. W przypadku obciążeń SAP obsługiwany jest tylko elastyczny zestaw skalowania z FD=1. Zaletą korzystania z elastycznych zestawów skalowania z funkcją FD=1 w przypadku wdrożenia między strefami zamiast tradycyjnego wdrożenia strefy dostępności jest to, że maszyny wirtualne wdrożone z zestawem skalowania będą dystrybuowane między różne domeny błędów w strefie w optymalny sposób. Aby uzyskać więcej informacji, zobacz Przewodnik wdrażania elastycznego zestawu skalowania dla obciążenia SAP.

Zagadnienia dotyczące wdrażania w Strefy dostępności

Podczas korzystania z Strefy dostępności należy wziąć pod uwagę następujące kwestie:

  • Maksymalne opóźnienie między sieciami między usługą Azure Strefy dostępności jest określone w dokumencie Regiony i strefy dostępności.
  • Doświadczane opóźnienie dwukierunkowe sieci niekoniecznie wskazuje na rzeczywistą odległość geograficzną centrów danych, które tworzą różne strefy. Opóźnienie komunikacji dwukierunkowej sieci ma również wpływ na połączenia kablowe i routing kabli między tymi różnymi centrami danych.
  • Strefy dostępności nie są idealnym rozwiązaniem odzyskiwania po awarii. Klęski żywiołowe mogą spowodować powszechne szkody w regionach świata, w tym duże szkody w infrastrukturze energetycznej. Odległości między różnymi strefami mogą nie być wystarczająco duże, aby stanowić właściwe rozwiązanie odzyskiwania po awarii.
  • Opóźnienie sieci w Strefy dostępności nie jest takie samo we wszystkich regionach świadczenia usługi Azure. W niektórych przypadkach można wdrożyć i uruchomić warstwę aplikacji SAP w różnych strefach, ponieważ opóźnienie sieci z jednej strefy do aktywnej maszyny wirtualnej SYSTEMU DBMS jest akceptowalne. Jednak w niektórych regionach platformy Azure opóźnienie między aktywną maszyną wirtualną DBMS a wystąpieniem aplikacji SAP, gdy jest wdrażane w różnych strefach, może nie być akceptowalne dla procesów biznesowych SAP. W takich przypadkach architektura wdrażania musi być inna, z aktywną/aktywną architekturą aplikacji lub architekturą aktywną/pasywną, w której opóźnienie sieci między strefami jest zbyt wysokie.
  • Podejmując decyzję o tym, gdzie należy używać Strefy dostępności, należy podjąć decyzję o opóźnieniu sieci między strefami. Opóźnienie sieci odgrywa ważną rolę w dwóch obszarach:
    • Opóźnienie między dwoma wystąpieniami systemu DBMS, które muszą mieć replikację synchroniczną. Im większe opóźnienie sieci, tym bardziej prawdopodobne jest, że ma to wpływ na skalowalność obciążenia.
    • Różnica w opóźnieniu sieci między maszyną wirtualną z uruchomionym wystąpieniem okna dialogowego SAP w strefie z aktywnym wystąpieniem systemu DBMS i podobną maszyną wirtualną w innej strefie. W miarę zwiększania się tej różnicy wpływ na czas działania procesów biznesowych i zadań wsadowych zwiększa się również w zależności od tego, czy działają w strefie z systemem DBMS, czy w innej strefie.

Podczas wdrażania maszyn wirtualnych platformy Azure w Strefy dostępności i ustanawiania rozwiązań trybu failover w tym samym regionie świadczenia usługi Azure obowiązują pewne ograniczenia:

  • Podczas wdrażania w usłudze Azure Strefy dostępności należy użyć usługi Azure Dyski zarządzane.
  • Mapowanie wyliczenia stref fizycznych jest stałe na podstawie subskrypcji platformy Azure. Jeśli używasz różnych subskrypcji do wdrażania systemów SAP, musisz zdefiniować idealne strefy dla każdej subskrypcji. Jeśli chcesz porównać mapowanie logiczne różnych subskrypcji, rozważ użycie skryptu Avzone-Mapping
  • Nie można wdrożyć zestawów dostępności platformy Azure w strefie dostępności platformy Azure, chyba że używasz grupy umieszczania w pobliżu platformy Azure. Sposób wdrażania warstwy SYSTEMU SAP DBMS i centralnych usług w różnych strefach oraz w tym samym czasie wdrażania warstwy aplikacji SAP przy użyciu zestawów dostępności i nadal osiąga bliskie zbliżenie maszyn wirtualnych jest udokumentowany w artykule Grupy umieszczania w pobliżu platformy Azure w celu uzyskania optymalnego opóźnienia sieci w aplikacjach SAP. Jeśli nie używasz grup umieszczania w pobliżu platformy Azure, musisz wybrać jedną lub drugą jako platformę wdrażania dla maszyn wirtualnych.
  • Nie można użyć usługi Azure Load Balancer w warstwie Podstawowa do tworzenia rozwiązań klastra trybu failover opartych na klastrze trybu failover systemu Windows Server lub narzędziu Pacemaker systemu Linux. Zamiast tego należy użyć jednostki SKU usługi Azure usługa Load Balancer w warstwie Standardowa.

Idealna kombinacja Strefy dostępności

Jeśli chcesz wdrożyć system SAP NetWeaver lub S/4HANA w różnych strefach, możesz wdrożyć dwa wzorce architektury:

  • Aktywne/aktywne: para maszyn wirtualnych z uruchomioną usługą ASCS/SCS i parą maszyn wirtualnych z uruchomioną warstwą DBMS są rozproszone w dwóch strefach. Liczba maszyn wirtualnych z uruchomioną warstwą aplikacji SAP jest wdrażana w liczbach parzysowych w tych samych dwóch strefach. Jeśli maszyna wirtualna DBMS lub ASCS/SCS jest przełączona w tryb failover, niektóre otwarte i aktywne transakcje mogą zostać wycofane. Ale użytkownicy pozostają zalogowani. Nie ma znaczenia, w którym ze stref działa aktywna maszyna wirtualna DBMS i wystąpienia aplikacji. Ta architektura jest preferowaną architekturą do wdrożenia w różnych strefach.
  • Aktywne/pasywne: para maszyn wirtualnych z uruchomioną usługą ASCS/SCS i parą maszyn wirtualnych z uruchomioną warstwą DBMS są rozproszone w dwóch strefach. Liczba maszyn wirtualnych z uruchomioną warstwą aplikacji SAP jest wdrażana w jednym z Strefy dostępności. Warstwa aplikacji jest uruchamiana w tej samej strefie co aktywne wystąpienie usług ASCS/SCS i DBMS. Ta architektura wdrażania jest używana, jeśli opóźnienie sieci w różnych strefach jest zbyt wysokie, aby uruchomić warstwę aplikacji rozłożoną między strefy. Zamiast tego warstwa aplikacji SAP musi działać w tej samej strefie co aktywne wystąpienie usługi ASCS/SCS i/lub DBMS. Jeśli maszyna wirtualna USŁUGI ASCS/SCS lub DBMS ulegnie awarii w strefie pomocniczej, może wystąpić większe opóźnienie sieci i zmniejszenie przepływności. Aby wrócić do poprzednich poziomów przepływności, wymagane jest powrót po awarii wcześniej przełączonej maszyny wirtualnej w tryb failover. Jeśli wystąpi awaria strefowa, warstwa aplikacji musi zostać przełączona w tryb failover do strefy pomocniczej. Działanie, które użytkownicy doświadczają jako całkowitego zamknięcia systemu. W niektórych regionach świadczenia usługi Azure ta architektura jest jedyną opłacalną architekturą, jeśli chcesz użyć Strefy dostępności. Jeśli nie możesz zaakceptować potencjalnego wpływu trybu failover usługi ASCS/SCS lub usługi DBMS VMS do strefy pomocniczej, być może lepiej będzie korzystać z wdrożeń zestawu dostępności

Dlatego przed podjęciem decyzji, jak używać Strefy dostępności, należy określić:

  • Opóźnienie sieci między trzema strefami regionu świadczenia usługi Azure. Znajomość opóźnienia sieci między strefami regionu umożliwi wybranie stref z najmniejszym opóźnieniem sieci w ruchu sieciowym między strefami.
  • Różnica między opóźnieniem między maszynami wirtualnymi w jednej z wybieranych stref i opóźnieniem sieci w dwóch strefach wyboru.
  • Określenie, czy typy maszyn wirtualnych, które należy wdrożyć, są dostępne w dwóch wybranych strefach. W przypadku niektórych jednostek SKU maszyn wirtualnych mogą wystąpić sytuacje, w których niektóre jednostki SKU są dostępne tylko w dwóch z trzech stref.

Opóźnienie sieci między strefami i w obrębie stref

Aby określić opóźnienie między różnymi strefami, należy:

  • Wdróż jednostkę SKU maszyny wirtualnej, której chcesz użyć dla wystąpienia usługi DBMS we wszystkich trzech strefach. Upewnij się, że przyspieszona sieć platformy Azure jest włączona podczas podejmowania tego pomiaru. Przyspieszona sieć jest ustawieniem domyślnym od kilku lat. Niemniej jednak sprawdź, czy jest włączona i działa
  • Po znalezieniu dwóch stref z najmniejszym opóźnieniem sieci wdróż kolejne trzy maszyny wirtualne jednostki SKU maszyny wirtualnej, które mają być używane jako maszyna wirtualna warstwy aplikacji w trzech Strefy dostępności. Zmierz opóźnienie sieci względem dwóch maszyn wirtualnych DBMS w dwóch wybranych strefach DBMS.
  • Użyj niping jako narzędzia do pomiaru. To narzędzie w oprogramowaniu SAP zostało opisane w informacjach o obsłudze oprogramowania SAP #500235 i #1100926. Skoncentruj się na poleceniach udokumentowanych na potrzeby pomiarów opóźnień. Ponieważ polecenie ping nie działa przez ścieżki kodu przyspieszonej sieci platformy Azure, nie zalecamy używania go.

Nie trzeba wykonywać tych testów ręcznie. Możesz znaleźć procedurę testu opóźnienia strefy dostępności programu PowerShell, który automatyzuje opisane testy opóźnienia.

Na podstawie pomiarów i dostępności jednostek SKU maszyny wirtualnej w Strefy dostępności należy podjąć pewne decyzje:

  • Zdefiniuj idealne strefy dla warstwy DBMS.
  • Ustal, czy chcesz dystrybuować aktywną warstwę aplikacji SAP między jedną, dwie lub wszystkie trzy strefy, na podstawie różnic opóźnienia sieci w strefie, a między strefami.
  • Ustal, czy chcesz wdrożyć konfigurację aktywną/pasywną, czy aktywną/aktywną konfigurację z punktu widzenia aplikacji. (Te konfiguracje zostały wyjaśnione w dalszej części tego artykułu).

W podejmowaniu tych decyzji należy również wziąć pod uwagę zalecenia dotyczące opóźnień sieci sap, jak opisano w notatce SAP #1100926.

Ważne

Miary i decyzje, które podejmujesz, są prawidłowe dla subskrypcji platformy Azure użytej podczas wykonywania pomiarów. Jeśli używasz innej subskrypcji platformy Azure, mapowanie wyliczonych stref może być inne dla innej subskrypcji platformy Azure. W związku z tym należy powtórzyć pomiary lub sprawdzić mapowanie nowej subskrypcji na starą subskrypcję za pomocą skryptu Avzone-Mapping narzędzia.

Ważne

Oczekuje się, że opisane wcześniej pomiary zapewnią różne wyniki w każdym regionie świadczenia usługi Azure, który obsługuje Strefy dostępności. Nawet jeśli wymagania dotyczące opóźnienia sieci są takie same, może być konieczne wdrożenie różnych strategii wdrażania w różnych regionach świadczenia usługi Azure, ponieważ opóźnienie sieci między strefami może być inne. W niektórych regionach świadczenia usługi Azure opóźnienie sieci między trzema różnymi strefami może być znacznie różne. W innych regionach opóźnienie sieci między trzema różnymi strefami może być bardziej jednolite. Twierdzenie, że zawsze występuje opóźnienie sieci z zakresu od 1 do 2 milisekund, nie jest poprawne. Nie można uogólnić opóźnienia sieci między Strefy dostępności w regionach świadczenia usługi Azure.

Aktywne/aktywne wdrożenie

Ta architektura wdrażania jest nazywana aktywna/aktywna, ponieważ wdrażasz aktywne serwery aplikacji SAP w dwóch lub trzech strefach. Wystąpienie usług SAP Central Services, które używa replikacji kolejki, zostanie wdrożone między dwiema strefami. To samo dotyczy warstwy DBMS, która zostanie wdrożona w tych samych strefach co usługa SAP Central Service. Biorąc pod uwagę tę konfigurację, należy znaleźć dwa Strefy dostępności w regionie, które oferują opóźnienie sieci między strefami, które są akceptowalne dla obciążenia i synchronicznej replikacji systemu DBMS. Należy również upewnić się, że różnica między opóźnieniem sieci w wybranych strefach a opóźnieniem sieci między strefami nie jest zbyt duża.

Charakter architektury SAP polega na tym, że jeśli nie skonfigurowano jej inaczej, użytkownicy i zadania wsadowe mogą być wykonywane w różnych wystąpieniach aplikacji. Skutkiem ubocznym tego faktu z aktywnym/aktywnym wdrożeniem jest to, że zadania wsadowe mogą być wykonywane przez dowolne wystąpienia aplikacji SAP niezależnie od tego, czy są one uruchamiane w tej samej strefie z aktywnym systemem DBMS, czy nie. Jeśli różnica w opóźnieniu sieci między strefami różnicy jest niewielka w porównaniu z opóźnieniem sieci w strefie, różnica w czasie wykonywania zadań wsadowych może nie być znacząca. Jednak większe różnice opóźnienia sieci w strefie, w porównaniu z ruchem sieciowym w strefie, to czas wykonywania zadań wsadowych może mieć wpływ na więcej, jeśli zadanie zostało wykonane w strefie, w której wystąpienie usługi DBMS nie jest aktywne. To ty jesteś klientem, aby zdecydować, jakie dopuszczalne różnice w czasie wykonywania są. A wraz z tym, jakie jest tolerowane opóźnienie sieci dla ruchu między strefami dla obciążenia.

Regiony platformy Azure, w których takie aktywne/aktywne wdrożenie może być możliwe bez znaczących różnic w czasie wykonywania i przepływności w warstwie aplikacji wdrożonej w różnych Strefy dostępności, na liście takich jak:

  • Australia Wschodnia (dwie z trzech stref)
  • Brazylia Południowa (wszystkie trzy strefy)
  • Indie Środkowe (wszystkie trzy strefy)
  • Środkowe stany USA (wszystkie trzy strefy)
  • Azja Wschodnia (wszystkie trzy strefy)
  • Wschodnie stany USA (dwa z trzech stref)
  • Wschodnie stany USA2 (wszystkie trzy strefy)
  • Niemcy Zachodnio-środkowe (wszystkie trzy strefy)
  • Izrael Środkowy (wszystkie trzy strefy)
  • Włochy Północne (dwie z trzech stref)
  • Korea Środkowa (wszystkie trzy strefy)
  • Polska Środkowa (wszystkie trzy strefy)
  • Katar Środkowy (wszystkie trzy strefy)
  • Europa Północna (wszystkie trzy strefy)
  • Norwegia Wschodnia (dwie z trzech stref)
  • Republika Południowej Afryki Północnej (dwa z trzech)
  • Południowo-środkowe stany USA (wszystkie trzy strefy)
  • Azja Południowo-Wschodnia (wszystkie trzy strefy)
  • Szwecja Środkowa (wszystkie trzy strefy)
  • Szwajcaria Północna (wszystkie trzy strefy)
  • Północ ZEA (wszystkie trzy strefy)
  • Zjednoczone Królestwo Południowe (dwie z trzech stref)
  • Europa Zachodnia (dwie z trzech stref)
  • Zachodnie stany USA2 (wszystkie trzy strefy)
  • Zachodnie stany USA3 (wszystkie trzy strefy)

Podana lista regionów nie ułatwia klientowi testowania obciążenia w celu określenia, czy jest możliwa architektura aktywnego/aktywnego wdrażania.

Regiony platformy Azure, w których aktywna/aktywna architektura wdrażania SAP w różnych strefach może nie być możliwa, lista:

  • Kanada Środkowa
  • Francja Środkowa
  • Japonia Wschodnia

Mimo że w przypadku poszczególnych obciążeń może to zadziałać. W związku z tym należy przetestować przed podjęciem decyzji o architekturze. Platforma Azure stale pracuje nad poprawą jakości i opóźnieniami sieci. Pomiary przeprowadzone od lat mogą już nie odzwierciedlać bieżących warunków.

Zależne od tego, co chcesz tolerować w przypadku różnic w czasie wykonywania innych regionów, które nie zostały wymienione, również mogą kwalifikować się.

Uproszczony schemat aktywnego/aktywnego wdrożenia w dwóch strefach może wyglądać następująco:

Active/Active zone deployment

W przypadku tej konfiguracji należy wziąć pod uwagę następujące zagadnienia:

Ważne

W tym aktywnym/aktywnym scenariuszu są naliczane opłaty za ruch między strefami. Sprawdź szczegóły cennika przepustowości dokumentu. Transfer danych między warstwą aplikacji SAP a warstwą SAP DBMS jest dość intensywny. W związku z tym aktywny/aktywny scenariusz może przyczynić się do kosztów.

Wdrażanie aktywne/pasywne

Jeśli nie możesz znaleźć akceptowalnej różnicy między opóźnieniem sieci w jednej strefie a opóźnieniem ruchu sieciowego między strefami, możesz wdrożyć architekturę, która ma aktywny/pasywny znak z punktu widzenia warstwy aplikacji SAP. Należy zdefiniować aktywną strefę, czyli strefę, w której wdrażasz pełną warstwę aplikacji i próbujesz uruchomić zarówno aktywne usługi DBMS, jak i wystąpienie usług SAP Central Services. W przypadku takiej konfiguracji należy upewnić się, że nie masz ekstremalnych zmian czasu wykonywania, w zależności od tego, czy zadanie jest uruchamiane w strefie z aktywnym wystąpieniem systemu DBMS, czy nie, w transakcjach biznesowych i zadaniach wsadowych.

Regiony platformy Azure, w których ten typ architektury wdrażania w różnych strefach mogą być preferowane:

  • Kanada Środkowa
  • Francja Środkowa
  • Japonia Wschodnia
  • Norwegia Wschodnia
  • Północna Republika Południowej Afryki

Podstawowy układ architektury wygląda następująco:

Active/Passive zone deployment

W przypadku tej konfiguracji należy wziąć pod uwagę następujące zagadnienia:

Połączona konfiguracja wysokiej dostępności i odzyskiwania po awarii

Firma Microsoft nie udostępnia żadnych informacji na temat odległości geograficznych między obiektami hostujących różne Strefy dostępności Azure w regionie świadczenia usługi Azure. Mimo to niektórzy klienci używają stref dla połączonej konfiguracji wysokiej dostępności i odzyskiwania po awarii, która obiecuje cel punktu odzyskiwania (RPO) zera. Cel punktu odzyskiwania równy zero oznacza, że nie należy tracić żadnych zatwierdzonych transakcji bazy danych nawet w przypadkach odzyskiwania po awarii.

Uwaga

Zalecamy używanie takiej konfiguracji tylko w określonych okolicznościach. Możesz na przykład użyć go, gdy dane nie mogą opuścić regionu świadczenia usługi Azure ze względów bezpieczeństwa lub zgodności.

Oto jeden przykład sposobu, w jaki taka konfiguracja może wyglądać:

Combined high-availability DR in zones

W przypadku tej konfiguracji należy wziąć pod uwagę następujące zagadnienia:

Następne kroki

Poniżej przedstawiono kilka następnych kroków wdrażania w usłudze Azure Strefy dostępności: