Udostępnij za pośrednictwem

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

  • Artykuł

Wdrożenie różnych warstw architektury SAP w usłudze Azure Strefy dostępności jest zalecaną architekturą wdrożeń obciążeń SAP na platformie Azure. 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. W artykule wymieniono regiony, które udostępniają Strefy dostępności. Większość regionów platformy Azure, które są wyposażone w obsługę większego obciążenia SAP, udostępnia Strefy dostępności. Nowe regiony platformy Azure udostępniają Strefy dostępności od samego początku. Niektóre ze starszych regionów były lub były w trakcie procesu modernizacji z 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ć od jednego 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 bazy danych, 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 bazy danych SAP, 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 centra danych strefy jako całości. W przypadku zestawów dostępności nie ma również wymuszonego wyrównania między maszyną wirtualną a jego dyskami. Oznacza to, że dyski mogą znajdować się w dowolnym centrum danych regionu świadczenia usługi Azure, niezależnie od struktury strefowej regionu. 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 bazy danych, 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 wpływają na centra danych strefy jako całość. Maszyny wirtualne i powiązane z nimi dyski również są kolokowane w tej samej strefie dostępności. 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 bazy danych, 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:

  • Więcej informacji o usłudze Azure Strefy dostępności znajduje się 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 między tymi różnymi centrami danych.
  • Jeśli używasz Strefy dostępności jako rozwiązania odzyskiwania po awarii w małej odległości, pamiętaj, że doświadczyliśmy klęsk żywiołowych powodujących powszechne szkody w różnych regionach świata, w tym ciężkie i powszechne szkody w infrastrukturze zasilania. Odległości między różnymi strefami mogą nie zawsze być wystarczająco duże, aby zrekompensować takie większe klęski żywiołowe.
  • Opóźnienie sieci w Strefy dostępności nie jest takie samo we wszystkich regionach świadczenia usługi Azure. Nawet w regionie świadczenia usługi Azure opóźnienia sieci między różnymi strefami mogą się różnić. Mimo że w najgorszym przypadku replikacja synchroniczna na poziomie bazy danych oparta na replikacji systemu HANA lub zawsze włączonego programu SQL Server będzie działać bez wpływu na skalowalność obciążenia.
  • 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 bazy danych, które muszą mieć replikację synchroniczną. W oparciu o bardzo udane operacje największych systemów NetWeaver i S/4HANA między strefami z większymi opóźnieniami sieci (mniej niż 1,5 milisekund) można pominąć tę kwestie
    • Różnica w opóźnieniu sieci między maszyną wirtualną z uruchomionym wystąpieniem okna dialogowego SAP w strefie z aktywnym wystąpieniem bazy danych i podobną maszyną wirtualną w innej strefie. W miarę zwiększania się tej różnicy wpływ na czas wykonywania procesów biznesowych i zadań wsadowych również wzrasta, zależnie od tego, czy działają w strefie z bazą danych, czy w innej strefie (zobacz w dalszej części tego artykułu).
  • Opóźnienie sieci za pomocą usługi Azure Strefy dostępności, nawet w największych strefach, jest wystarczająco niskie, aby uruchamiać procesy biznesowe SAP. Do tej pory widzieliśmy tylko kilka wyjątkowych przypadków, w których klienci musieli przenieść warstwę aplikacji SAP i warstwę bazy danych w ramach pojedynczego kręgosłupa sieci centrum danych.

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 bazy danych SAP i centralnych usług w różnych strefach i w tym samym czasie wdrażania warstwy aplikacji SAP przy użyciu zestawów dostępności i nadal osiąga bliskie sąsiedztwo 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.
  • Aby uzyskać potrzebną ochronę strefową, należy wdrożyć strefową wersję bramy usługi ExpressRoute, bramy VPN Gateway i standardowych publicznych adresów IP.

Idealna kombinacja Strefy dostępności

Jeśli nie skonfigurujesz przypisania procesów biznesowych z funkcjami SAP, takimi jak grupy logowania, grupy serwerów RFC, grupy serwerów usługi Batch i podobne, procesy biznesowe mogą być wykonywane w różnych wystąpieniach aplikacji w warstwie aplikacji SAP. Efektem ubocznym tego faktu 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 wystąpieniem bazy danych, 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ększa różnica opóźnienia sieci w strefie, w porównaniu z ruchem sieciowym w strefie, może mieć wpływ na czas wykonywania zadań wsadowych więcej, jeśli zadanie zostało wykonane w strefie, w której wystąpienie bazy danych 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. Wyłącznie z technicznego punktu widzenia opóźnienia sieci między platformą Azure Strefy dostępności w regionie świadczenia usługi Azure działają na potrzeby architektury oprogramowania NetWeaver, S/4HANA lub innych aplikacji SAP. Jest to również dla Ciebie potencjalnie klient, aby wyeliminować takie różnice przy użyciu pojęć sap grup logowania, grup serwerów RFC, grup serwerów usługi Batch i podobnych, gdy zdecydujesz się na jedną z koncepcji wdrażania, które wprowadzamy w tym artykule.

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ą bazy danych są rozproszone w dwóch strefach. Maszyny wirtualne z uruchomioną warstwą aplikacji SAP są wdrażane w liczbach parzysowych w tych samych dwóch strefach. Jeśli baza danych lub maszyna wirtualna ASCS/SCS zostanie 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 bazy danych i wystąpienia aplikacji. Ta architektura jest preferowaną architekturą do wdrożenia w różnych strefach. W przypadkach, gdy opóźnienia sieci między strefami powodują większe różnice podczas wykonywania procesów biznesowych, można użyć funkcji, takich jak grupy logowania SAP, grupy serwerów RFC, grupy serwerów usługi Batch i podobne do kierowania wykonywania procesów biznesowych do określonych wystąpień okien dialogowych, które znajdują się w tej samej strefie z aktywnym wystąpieniem bazy danych
  • Aktywne/pasywne: para maszyn wirtualnych z uruchomioną usługą ASCS/SCS i parą maszyn wirtualnych z uruchomioną warstwą bazy danych są rozproszone w dwóch strefach. Maszyny wirtualne z uruchomioną warstwą aplikacji SAP są wdrażane w jednym z Strefy dostępności. Warstwa aplikacji jest uruchamiana w tej samej strefie co aktywne wystąpienie usługi ASCS/SCS i bazy danych. Tę architekturę wdrażania można użyć, jeśli uważasz, że opóźnienie sieci w różnych strefach jest zbyt wysokie. Z tym powodu niedopuszczalne różnice w czasie wykonywania procesów biznesowych. Możesz też użyć wdrożeń strefy dostępności jako wdrożeń odzyskiwania po awarii z krótkim dystansem. strefy. Jeśli usługa ASCS/SCS lub maszyna wirtualna bazy danych przejdą w tryb failover do strefy 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.

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 bazy danych 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 bazy danych w dwóch wybranych strefach.
  • 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. Klasyfikacja opóźnień sieci w programie SAP Note #1100926 jako przybliżone wskazówki. Opóźnienia sieci większe niż 0,7 milisekund nie oznaczają, że system nie będzie działać technicznie lub że procesy biznesowe nie spełniają indywidualnych umów SLA. Uwaga nie jest przeznaczona do określenia, co jest obsługiwane lub nieobsługiwane przez oprogramowanie SAP i/lub Microsoft. 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 bazy danych.
  • 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).

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 zapewniają 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 w kolejce, jest wdrażane między dwiema strefami. To samo dotyczy warstwy bazy danych, która jest wdrażana w tych samych strefach co usługa SAP Central. 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. Należy również upewnić się, że różnica między opóźnieniem sieci w wybranych strefach a opóźnieniem sieci między strefami jest akceptowalna dla obciążenia.

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

Wdrożenie aktywne/aktywne strefy

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ą bazy danych SAP 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źć konfiguracji, która ogranicza potencjalną różnicę w czasie wykonywania procesów biznesowych SAP lub jeśli chcesz wdrożyć konfigurację odzyskiwania po awarii w niewielkiej odległości, możesz wdrożyć architekturę, która ma aktywny/pasywny znak z punktu widzenia warstwy aplikacji SAP. Należy zdefiniować aktywną strefę, która jest strefą, w której wdrażasz pełną warstwę aplikacji i gdzie próbujesz uruchomić zarówno aktywne wystąpienie bazy danych, 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 bazy danych, czy nie, w transakcjach biznesowych i zadaniach wsadowych.

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

Wdrażanie strefy aktywne/pasywnej

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 do połączonej konfiguracji wysokiej dostępności i odzyskiwania po awarii (w niewielkiej odległości), 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

Jeśli używasz Strefy dostępności jako rozwiązania odzyskiwania po awarii na małą odległość, pamiętaj, że doświadczyliśmy klęsk żywiołowych powodujących powszechne szkody w różnych regionach świata, w tym ciężkie i powszechne szkody w infrastrukturze zasilania. Odległości między różnymi strefami mogą nie zawsze być wystarczająco duże, aby zrekompensować takie większe klęski żywiołowe.

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

Połączone odzyskiwanie po awarii o wysokiej dostępności w strefach

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: