Ten artykuł zawiera najlepsze rozwiązania dotyczące tworzenia architektury całego środowiska SAP na platformie Azure. Środowisko SAP obejmuje wiele systemów SAP w środowiskach centrum, produkcji, nieprodukcyjnej i odzyskiwania po awarii. Udostępniamy zalecenia, które koncentrują się na projektowaniu sieci, a nie konkretnych systemach SAP. Celem jest przedstawienie naszych zaleceń dotyczących tworzenia architektury bezpiecznego, wydajnego i odpornego środowiska SAP.
Architektura
Pobierz plik programu Visio architektury.
Przepływ pracy
- Sieć lokalna: połączenie usługi ExpressRoute z sieci lokalnej do połączonych regionów platformy Azure.
- Regionalne centra subskrypcji platformy Azure: subskrypcja platformy Azure zawierająca usługi centralne dla całego przedsiębiorstwa, a nie tylko sap. Subskrypcja centrum zapewnia centralne usługi i łączność przez komunikację równorzędną z sieciami wirtualnymi szprych zawierającymi obciążenia SAP.
- Sieć wirtualna koncentratora: sieć wirtualna szprycha dla centralnego centrum w regionie podstawowym lub regionie A.
- Sieci wirtualnej centrum w regionie odzyskiwania po awarii (DR): sieć wirtualna szprycha dla centralnego centrum w regionie odzyskiwania po awarii. Dubluje projekt podsieci produkcyjnej sieci wirtualnej w regionie podstawowym.
- Subskrypcja platformy Azure SAP nieprodukcyjna: subskrypcja platformy Azure dla wszystkich nieprodukcyjnych obciążeń SAP. Obejmuje ona środowiska przedprodukcyjne, kontroli jakości, programowania i piaskownicy.
- Nieprodukcyjne sieci wirtualne będące szprychami SAP: oddzielne sieci wirtualne dla obciążeń nieprodukcyjnych SAP w regionie podstawowym. Każde środowisko SAP ma własną sieć wirtualną i podsieci.
- Produkcja sap subskrypcji platformy Azure: subskrypcja platformy Azure dla wszystkich produkcyjnych obciążeń SAP.
- Sieć wirtualna sap production spoke: sieć wirtualna dla środowiska produkcyjnego SAP z wieloma podsieciami. Ta sieć wirtualna znajduje się w regionie podstawowym.
- Sieć wirtualna odzyskiwania po awarii produkcyjnej (DR) sap: sieć wirtualna dla środowiska produkcyjnego SAP w regionie pomocniczym odzyskiwania po awarii. Dubluje projekt podsieci produkcyjnej sieci wirtualnej w regionie podstawowym.
- Usługi platformy Azure: próbkowanie usług platformy Azure, które można połączyć z oprogramowaniem SAP w poziomie.
- SAP Business Technology Platform (BTP): środowisko SAP uzyskuje dostęp do platformy SAP Business Technology Platform za pośrednictwem usługi Azure Private Link.
Subskrypcje platformy Azure
Zalecamy użycie projektu sieci piasty i szprych. W przypadku projektowania piasty i szprych potrzebne są co najmniej trzy subskrypcje do dzielenia środowisk SAP. Musisz mieć subskrypcję sieci wirtualnych (1) regionalnych centrów wirtualnych, (2) nieprodukcyjnych sieci wirtualnych i (3) produkcyjnych sieci wirtualnych. Subskrypcje zapewniają rozliczenia, zasady i granice zabezpieczeń. Nie ma poprawnej liczby subskrypcji. Liczba używanych subskrypcji zależy od potrzeb związanych z rozliczeniami, zasadami i zabezpieczeniami. Ogólnie rzecz biorąc, należy unikać używania zbyt wielu subskrypcji. Zbyt wiele subskrypcji może dodać niepotrzebne nakłady pracy związane z zarządzaniem i złożoność sieci. Na przykład nie potrzebujesz subskrypcji dla każdego systemu SAP. Nasza architektura korzysta z trzech subskrypcji:
Centra regionalne: subskrypcja koncentratora wirtualnego platformy Azure, w której istnieje sieć wirtualna koncentratora dla regionów podstawowych i pomocniczych. Ta subskrypcja jest dostępna dla wszystkich usług centralnych, a nie tylko sap.
SAP nieprodukcyjne: subskrypcja nieprodukcyjne platformy Azure, w której znajdują się systemy nieprodukcyjne, w tym piaskownica, programowanie, kontrola jakości lub systemy przedprodukcyjne.
Produkcja SAP: subskrypcja produkcyjna platformy Azure SAP, w której skonfigurowaliśmy systemy produkcyjne i odzyskiwania po awarii.
Aby uzyskać więcej informacji, zobacz:
Projekt sieci
Topologia piasty i szprych jest zalecanym projektem sieci dla środowiska SAP. W tej topologii sieć wirtualna centrum produkcyjnego działa jako centralny punkt łączności. Łączy się ona z siecią lokalną i różnymi sieciami wirtualnymi szprych oraz umożliwia użytkownikom i aplikacjom dostęp do obciążenia SAP. W tej topologii piasty i szprych poniżej przedstawiono nasze zalecenia dotyczące projektowania sieci SAP.
Użyj usługi ExpressRoute dla połączenia lokalnego. W przypadku obciążeń SAP zalecamy używanie usługi ExpressRoute do łączenia sieci lokalnej z siecią wirtualną Koncentratora i siecią wirtualną usługi Hub DR. Możesz użyć topologii wirtualnej sieci WAN platformy Azure, jeśli masz lokalizacje globalne. Rozważ skonfigurowanie sieci VPN typu lokacja-lokacja (S2S) jako kopii zapasowej usługi Azure ExpressRoute lub wymagań dotyczących tras innych firm.
Aby uzyskać więcej informacji, zobacz:
- Topologia sieci i łączność migracji sap
- Architektura piasty i szprych
- Wirtualna sieć WAN platformy Azure
- Sieć VPN typu lokacja-lokacja jako kopia zapasowa prywatnej komunikacji równorzędnej usługi ExpressRoute
Użyj jednej sieci wirtualnej na środowisko. Zalecamy używanie jednej sieci wirtualnej na środowisko (warstwa wdrażania SAP). Architektura używa innej sieci wirtualnej do produkcji, programowania, zapewniania jakości i piaskownicy. Ten projekt sieci jest idealny dla dużych architektur przedsiębiorstwa.
Użyj centralnej zapory. Cały ruch sieciowy do sieci wirtualnych szprych, w tym połączeń wywołania funkcji zdalnej (RFC), powinien przechodzić przez centralną zaporę w sieci wirtualnej Koncentratora. Komunikacja sieciowa między sieciami wirtualnymi będącej szprychą (komunikacja szprychy) przechodzi przez zaporę sieci wirtualnej piasty w podsieci usługi Azure Firewall sieci wirtualnej koncentratora. Podobnie komunikacja sieciowa między sieciami wirtualnymi szprych i siecią lokalną również przechodzi przez zaporę sieci wirtualnej koncentratora. Użyliśmy komunikacji równorzędnej sieci wirtualnych w celu połączenia różnych sieci wirtualnych szprych z siecią wirtualną piasty. Cała komunikacja między sieciami wirtualnymi szprych przechodzi przez zaporę sieci wirtualnej koncentratora. Można również użyć wirtualnego urządzenia sieciowego zamiast zapory. Aby uzyskać więcej informacji, zobacz wirtualne urządzenie sieciowe.
Ruch sieciowy, który pozostaje w sieci wirtualnej, nie powinien przechodzić przez zaporę. Na przykład nie umieszczaj zapory między podsiecią aplikacji SAP i podsiecią bazy danych SAP. Nie jest obsługiwane umieszczanie zapory ani wirtualnych urządzeń sieciowych (WUS) między aplikacją SAP a warstwą systemu zarządzania bazami danych (DBMS) systemów SAP z uruchomionym jądrem SAP. W ten sposób negatywnie wpłynie to na opóźnienie sieci dla wszystkich dostępu do bazy danych i ma duży wpływ na wydajność oprogramowania SAP.
Unikaj komunikacji równorzędnej sieci wirtualnych szprych. W miarę możliwości należy unikać komunikacji równorzędnej sieci wirtualnych sieci wirtualnych będącej szprychami. Komunikacja równorzędna sieci wirtualnej będącej szprychą umożliwia komunikację typu szprycha-szprycha w celu obejścia zapory sieci wirtualnej koncentratora. Należy skonfigurować komunikację równorzędną sieci wirtualnych będącej szprychą tylko wtedy, gdy masz wymagania dotyczące wysokiej przepustowości, na przykład z replikacją bazy danych między środowiskami SAP. Cały inny ruch sieciowy powinien być uruchamiany przez sieć wirtualną i zaporę koncentratora. Aby uzyskać więcej informacji, zobacz przychodzące i wychodzące połączenia internetowe dla oprogramowania SAP na platformie Azure.
Podsieci
Najlepszym rozwiązaniem jest podzielenie każdego środowiska SAP (produkcyjnego, przedprodukcyjnego, deweloperskiego, piaskownicy) na podsieci i używania podsieci do grupowania powiązanych usług. Poniżej przedstawiono nasze zalecenia dotyczące podsieci środowiska SAP.
Liczba podsieci
Produkcyjna sieć wirtualna w architekturze ma pięć podsieci. Ten projekt jest idealny dla dużych rozwiązań dla przedsiębiorstw. Liczba podsieci może być mniejsza lub większa. Liczba zasobów w sieci wirtualnej powinna określać liczbę podsieci w sieci wirtualnej.
Ustalanie rozmiaru podsieci
Upewnij się, że podsieci mają wystarczającą przestrzeń adresową sieci. Jeśli używasz nazw hostów wirtualnych SAP, potrzebujesz więcej przestrzeni adresowej w podsieciach SAP. Często każde wystąpienie SAP wymaga 2–3 adresów IP i zawiera jeden adres IP dla nazwy hosta maszyny wirtualnej. Inne usługi platformy Azure mogą wymagać własnej dedykowanej podsieci podczas wdrażania w sieciach wirtualnych obciążeń SAP.
Podsieć aplikacji
Podsieć aplikacji zawiera maszyny wirtualne z uruchomionymi serwerami aplikacji SAP, usługami SAP Central Services (ASCS), sap enqueue Replication Services (ERS) i wystąpieniami programu SAP Web Dispatcher. Podsieć zawiera również prywatny punkt końcowy w usłudze Azure Files. Na diagramie pogrupowaliśmy maszyny wirtualne według roli. Zalecamy używanie zestawów skalowania maszyn wirtualnych z elastyczną aranżacją w połączeniu ze strefami dostępności na potrzeby odpornego wdrożenia. Aby uzyskać więcej informacji, zobacz następne kroki.
Podsieć bazy danych
Podsieć bazy danych zawiera maszyny wirtualne z uruchomionymi bazami danych. Na diagramie para maszyn wirtualnych z replikacją synchroniczną reprezentuje wszystkie maszyny wirtualne bazy danych jednego środowiska SAP.
Podsieci obwodowe
Podsieci obwodowe są połączone z Internetem i obejmują podsieć obwodową SAP i podsieć usługi Application Gateway. Poniżej przedstawiono nasze zalecenia dotyczące projektowania tych dwóch podsieci.
Podsieć obwodowa SAP: podsieć obwodowa SAP jest siecią obwodową zawierającą aplikacje dostępne z Internetu, takie jak SAProuter, SAP Cloud Connector, SAP Analytics Cloud Agent i Application Gateway. Te usługi mają zależności od systemów SAP, które zespół SAP powinien wdrażać, zarządzać i konfigurować. Centralny zespół IT nie powinien zarządzać usługami w podsieci obwodowej SAP. Z tego powodu należy umieścić te usługi w sieci wirtualnej sap spoke, a nie w sieci wirtualnej Koncentratora. Diagram architektury przedstawia tylko produkcyjną sieć obwodową SAP. Nie ma podsieci obwodowej SAP w nieprodukcyjnych sieciach wirtualnych. Obciążenia w nieprodukcyjnej subskrypcji SAP używają usług w podsieci obwodowej SAP.
W subskrypcji nieprodukcyjnej można utworzyć oddzielną podsieć obwodową SAP. Zalecamy tylko takie podejście do obciążeń krytycznych lub obciążeń, które często się zmieniają. Dedykowany, nieprodukcyjny obwód SAP jest przydatny do testowania i wdrażania nowych funkcji. Mniej krytyczne aplikacje lub aplikacje, które będą mieć tylko kilka modyfikacji w czasie, nie wymagają oddzielnej nieprodukcyjnej podsieci obwodowej SAP.
Podsieć usługi Application Gateway: aplikacja systemu Azure Gateway wymaga własnej podsieci. Służy do zezwalania na ruch z Internetu, z którego mogą korzystać usługi SAP, takie jak SAP Fiori. Zalecana architektura umieszcza bramę aplikacja systemu Azure wraz z publicznym adresem IP frontonu w sieci wirtualnej koncentratora. Brama aplikacja systemu Azure wymaga co najmniej podsieci o rozmiarze /29. Zalecamy rozmiar /27 lub większy. Nie można używać obu wersji usługi Application Gateway (w wersji 1 i 2) w tej samej podsieci. Aby uzyskać więcej informacji, zobacz podsieć dla bramy aplikacja systemu Azure.
Umieść podsieci obwodowe w oddzielnej sieci wirtualnej w celu zwiększenia bezpieczeństwa: w celu zwiększenia bezpieczeństwa można umieścić podsieć obwodową SAP i podsieć usługi Application Gateway w oddzielnej sieci wirtualnej w ramach subskrypcji produkcyjnej SAP. Sieć wirtualna szprychy obwodowej SAP jest równorzędna z siecią wirtualną Koncentratora, a cały ruch sieciowy do sieci publicznych przepływa przez sieć wirtualną obwodu. Ta alternatywna metoda przedstawia aplikacja systemu Azure Gateway z publicznym adresem IP dla połączeń przychodzących umieszczonych w sieci wirtualnej będącej szprychą do wyłącznego użycia systemu SAP.
Pobierz plik programu Visio zawierający tę alternatywną architekturę.
Ten projekt sieci zapewnia lepsze możliwości reagowania na zdarzenia i szczegółową kontrolę dostępu do sieci. Zwiększa jednak również złożoność zarządzania, opóźnienie sieci i koszt wdrożenia. Omówimy każdy punkt.
Lepsza reakcja na zdarzenia: sieć wirtualna szprychy obwodowej SAP umożliwia szybką izolację naruszonych usług w przypadku wykrycia naruszenia zabezpieczeń. Komunikację równorzędną sieci wirtualnych można usunąć z sieci wirtualnej szprychy obwodowej SAP do centrum i natychmiast odizolować obciążenia obwodowe SAP oraz aplikacje sieci wirtualnej aplikacji SAP z Internetu. Nie chcesz polegać na zmianach reguł sieciowej grupy zabezpieczeń na potrzeby reagowania na zdarzenia. Zmiana lub usunięcie reguły sieciowej grupy zabezpieczeń dotyczy tylko nowych połączeń i nie spowoduje wycięcia istniejących złośliwych połączeń.
Szczegółowa kontrola dostępu do sieci: sieć wirtualna obwodowa SAP zapewnia bardziej rygorystyczną kontrolę dostępu do sieci i z sieci wirtualnej będącej szprychą produkcyjną SAP.
Zwiększona złożoność, opóźnienie i koszty: architektura zwiększa złożoność zarządzania, koszty i opóźnienia. Komunikacja wirtualna związana z Internetem z produkcyjnej sieci wirtualnej SAP jest dwukrotnie równorzędna, raz do sieci wirtualnej Koncentratora i ponownie do sieci wirtualnej obwodowej SAP do Internetu. Zapora w sieci wirtualnej koncentratora ma największy wpływ na opóźnienie. Zalecamy pomiar opóźnienia, aby sprawdzić, czy twój przypadek użycia może go obsługiwać.
Aby uzyskać więcej informacji, zobacz najlepsze rozwiązania dotyczące sieci obwodowej.
Podsieć usługi Azure NetApp Files
Jeśli używasz usługi NetApp Files, musisz mieć podsieć delegowana w celu zapewnienia sieciowego systemu plików (NFS) lub udziałów plików bloku komunikatów serwera (SMB) dla różnych scenariuszy oprogramowania SAP na platformie Azure. Podsieć /24 jest domyślnym rozmiarem podsieci NetApp Files, ale można zmienić rozmiar zgodnie z potrzebami. Użyj własnych wymagań, aby określić odpowiednie rozmiary. Aby uzyskać więcej informacji, zobacz podsieć delegowana.
Zabezpieczenia podsieci
Używanie podsieci do grupowania zasobów SAP, które mają te same wymagania dotyczące reguł zabezpieczeń, ułatwia zarządzanie zabezpieczeniami.
Sieciowe grupy zabezpieczeń: podsieci umożliwiają implementowanie sieciowych grup zabezpieczeń na poziomie podsieci. Grupowanie zasobów w tej samej podsieci, które wymagają różnych reguł zabezpieczeń, wymaga sieciowych grup zabezpieczeń na poziomie podsieci i interfejsu sieciowego. W przypadku tej konfiguracji dwupoziomowej reguły zabezpieczeń łatwo powodują konflikt i mogą powodować nieoczekiwane problemy z komunikacją, które są trudne do rozwiązania. Reguły sieciowej grupy zabezpieczeń wpływają również na ruch w podsieci. Aby uzyskać więcej informacji na temat sieciowych grup zabezpieczeń, zobacz sieciowe grupy zabezpieczeń.
Grupy zabezpieczeń aplikacji (ASG): zalecamy grupowanie interfejsów sieciowych maszyn wirtualnych przy użyciu grup zabezpieczeń aplikacji i odwoływanie się do grup zabezpieczeń aplikacji w regułach sieciowej grupy zabezpieczeń. Ta konfiguracja umożliwia łatwiejsze tworzenie reguł i zarządzanie nimi na potrzeby wdrożeń SAP. Każdy interfejs sieciowy może należeć do wielu grup zabezpieczeń aplikacji z różnymi regułami sieciowej grupy zabezpieczeń. Aby uzyskać więcej informacji, zobacz grupy zabezpieczeń aplikacji.
Link prywatny platformy Azure
Zalecamy użycie usługi Azure Private Link w celu zwiększenia bezpieczeństwa komunikacji sieciowej. Usługa Azure Private Link używa prywatnych punktów końcowych z prywatnymi adresami IP do komunikowania się z usługami platformy Azure. Usługa Azure Private Links unika wysyłania komunikacji sieciowej przez Internet do publicznych punktów końcowych. Aby uzyskać więcej informacji, zobacz prywatne punkty końcowe w usługach platformy Azure.
Użyj prywatnych punktów końcowych w podsieci aplikacji: zalecamy łączenie podsieci aplikacji z obsługiwanymi usługami platformy Azure przy użyciu prywatnych punktów końcowych. W architekturze istnieje prywatny punkt końcowy dla usługi Azure Files w podsieci Application każdej sieci wirtualnej. Tę koncepcję można rozszerzyć na dowolną obsługiwaną usługę platformy Azure.
Korzystanie z usługi Azure Private Link dla platformy SAP Business Technology Platform (BTP): usługa Azure Private Link dla platformy SAP Business Technology Platform (BTP) jest teraz ogólnie dostępna. Usługa SAP Private Link obsługuje połączenia z oprogramowania SAP BTP, środowiska uruchomieniowego Cloud Foundry i innych usług. Przykładowe scenariusze obejmują oprogramowanie SAP S/4HANA lub SAP ERP uruchomione na maszynie wirtualnej. Mogą łączyć się z usługami natywnymi platformy Azure, takimi jak Azure Database for MariaDB i Azure Database for MySQL.
Architektura przedstawia połączenie usługi SAP Private Link ze środowisk SAP BTP. Usługa SAP Private Link ustanawia prywatne połączenie między określonymi usługami SAP BTP i określonymi usługami w każdej sieci jako kontach dostawcy usług. Usługa Private Link umożliwia usługom BTP uzyskiwanie dostępu do środowiska SAP za pośrednictwem połączeń sieci prywatnych. Zwiększa bezpieczeństwo, nie używając publicznego Internetu do komunikowania się.
Aby uzyskać więcej informacji, zobacz:
- Zasoby usługi Azure Private Link
- Azure Database for MariaDB
- Azure Database for MySQL
- Połączenie internetowe dla oprogramowania SAP na platformie Azure
Udziały plików sieciowego systemu plików (NFS) i bloku komunikatów serwera (SMB)
Systemy SAP często zależą od woluminów systemu plików sieciowych lub udziałów bloków komunikatów serwera. Te udziały plików przenoszą pliki między maszynami wirtualnymi lub działają jako interfejs plików z innymi aplikacjami. Zalecamy używanie natywnych usług platformy Azure, takich jak Azure Premium Files i Azure NetApp Files, jako udziały plików sieciowego systemu plików (NFS) i udziałów plików bloku komunikatów serwera (SMB). Usługi platformy Azure mają lepszą dostępność, odporność i umowy dotyczące poziomu usług (SLA) niż narzędzia oparte na systemie operacyjnym.
Aby uzyskać więcej informacji, zobacz:
Podczas tworzenia architektury rozwiązania SAP należy odpowiednio rozmieścić poszczególne woluminy udziału plików i znać, z którym udziałem plików systemu SAP się łączy. Podczas planowania zachowaj cele dotyczące skalowalności i wydajności usługi platformy Azure. W poniższej tabeli przedstawiono typowe udziały plików SAP i przedstawiono krótki opis i zalecane użycie w całym środowisku SAP.
| Nazwa udziału plików | Użycie | Zalecenie |
|---|---|---|
sapmnt |
Rozproszony system SAP, profil i katalogi globalne | Dedykowany udział dla każdego systemu SAP, bez ponownego użycia |
cluster |
Udziały wysokiej dostępności dla usług ASCS, ERS i bazy danych zgodnie z odpowiednim projektem | Dedykowany udział dla każdego systemu SAP, bez ponownego użycia |
saptrans |
Katalog transportu SAP | Jeden udział dla jednego lub kilku środowisk SAP (ERP, Business Warehouse) |
interface |
Wymiana plików z aplikacjami innych niż SAP | Wymagania specyficzne dla klienta, oddzielne udziały plików na środowisko (produkcja, nieprodukcyjny) |
Można udostępniać saptrans tylko między różnymi środowiskami SAP, a w związku z tym należy dokładnie rozważyć jego rozmieszczenie. Unikaj konsolidowania zbyt wielu systemów SAP w jeden saptrans udział ze względu na skalowalność i wydajność.
Zasady zabezpieczeń firmy będą napędzać architekturę i separację woluminów między środowiskami. Katalog transportu z separacją na środowisko lub warstwę wymaga komunikacji RFC między środowiskami SAP, aby umożliwić grupom transportu SAP lub linkom domeny transportu. Aby uzyskać więcej informacji, zobacz:
Usługi danych
Architektura zawiera usługi danych platformy Azure, które ułatwiają rozszerzanie i ulepszanie platformy danych SAP. Aby ułatwić uzyskiwanie szczegółowych informacji biznesowych, zalecamy korzystanie z usług, takich jak Azure Synapse Analytics, Azure Data Factory i Azure Data Lake Storage. Te usługi danych ułatwiają analizowanie i wizualizowanie danych SAP i danych innych niż SAP.
W przypadku wielu scenariuszy integracji danych wymagany jest środowisko Integration Runtime. Środowisko Azure Integration Runtime to infrastruktura obliczeniowa używana przez potoki usługi Azure Data Factory i Azure Synapse Analytics w celu zapewnienia możliwości integracji danych. Zalecamy wdrożenie maszyn wirtualnych środowiska uruchomieniowego dla tych usług osobno dla każdego środowiska. Aby uzyskać więcej informacji, zobacz:
- Środowisko Azure Integration Runtime
- Konfigurowanie własnego środowiska Integration Runtime do użycia w rozwiązaniu SAP CDC
- Kopiowanie danych z platformy SAP HANA
- Kopiowanie danych z usługi SAP Business Warehouse za pośrednictwem usługi Open Hub
Usługi udostępnione
Rozwiązania SAP korzystają z usług udostępnionych. Moduł równoważenia obciążenia i bramy aplikacji to przykłady usług używanych przez wiele systemów SAP. Architektura, ale potrzeby organizacji powinny określać sposób tworzenia architektury usług udostępnionych. Poniżej przedstawiono ogólne wskazówki, które należy wykonać.
Moduły równoważenia obciążenia: zalecamy użycie jednego modułu równoważenia obciążenia dla systemu SAP. Ta konfiguracja pomaga zminimalizować złożoność. Chcesz uniknąć zbyt wielu pul i reguł w jednym module równoważenia obciążenia. Ta konfiguracja zapewnia również dopasowanie nazw i umieszczania do systemu SAP i grupy zasobów. Każdy system SAP z architekturą wysokiej dostępności klastra powinien mieć co najmniej jeden moduł równoważenia obciążenia. Architektura używa jednego modułu równoważenia obciążenia dla maszyn wirtualnych usługi ASCS i drugiego modułu równoważenia obciążenia dla maszyn wirtualnych bazy danych. Niektóre bazy danych mogą nie wymagać modułów równoważenia obciążenia w celu utworzenia wdrożenia o wysokiej dostępności. Oprogramowanie SAP HANA działa. Aby uzyskać więcej informacji, zapoznaj się z dokumentacją specyficzną dla bazy danych.
Application Gateway: zalecamy co najmniej jedną bramę aplikacji dla środowiska SAP (produkcyjnego, nieprodukcyjnego i piaskownicy), chyba że złożoność i liczba połączonych systemów jest zbyt wysoka. Bramę aplikacji dla wielu systemów SAP można użyć, aby zmniejszyć złożoność, ponieważ nie wszystkie systemy SAP w środowisku wymagają dostępu przychodzącego z Internetu. Jedna brama aplikacji może obsługiwać wiele portów dyspozytora sieci Web dla jednego systemu SAP S/4HANA lub być używana przez różne systemy SAP.
Maszyny wirtualne programu SAP Web Dispatcher: architektura przedstawia pulę co najmniej dwóch maszyn wirtualnych programu SAP Web Dispatcher. Zalecamy, aby nie używać ponownie maszyn wirtualnych SAP Web Dispatcher między różnymi systemami SAP. Ich oddzielenie umożliwia ustawianie rozmiaru maszyn wirtualnych programu Web Dispatcher w celu zaspokojenia potrzeb każdego systemu SAP. W przypadku mniejszych rozwiązań SAP zalecamy osadzanie usług Web Dispatcher w wystąpieniu usługi ASCS.
Usługi SAP: usługi SAP, takie jak SAProuter, Cloud Connector i Analytics Cloud Agent, są wdrażane w oparciu o wymagania aplikacji, centralnie lub podzielone. Brak rekomendacji dotyczących ponownego użycia między systemami SAP ze względu na zróżnicowane wymagania klientów. Główną decyzją o podjęciu decyzji jest w sekcji dotyczącej sieci, jeśli i kiedy należy użyć podsieci obwodowej SAP dla nieprodukcyjnej. W przeciwnym razie w przypadku tylko produkcyjnej podsieci obwodowej sap usługi obwodowe SAP są używane przez cały krajobraz SAP.
Odzyskiwanie po awarii
Odzyskiwanie po awarii (DR) eliminuje wymaganie ciągłości działania w przypadku niedostępności lub naruszenia zabezpieczeń podstawowego regionu platformy Azure. Z ogólnej perspektywy poziomej systemu SAP i pokazanej na diagramie przedstawiono nasze zalecenia dotyczące projektowania odzyskiwania po awarii.
Użyj różnych zakresów adresów IP Sieci wirtualne obejmują tylko jeden region świadczenia usługi Azure. Wszelkie rozwiązania odzyskiwania po awarii powinny używać innego regionu. Musisz utworzyć inną sieć wirtualną w regionie pomocniczym. Sieć wirtualna w środowisku odzyskiwania po awarii wymaga innego zakresu adresów IP, aby umożliwić synchronizację bazy danych za pomocą technologii natywnej dla bazy danych.
Usługi centralne i łączność z środowiskiem lokalnym: łączność z lokalnymi i kluczowymi usługami centralnymi (DNS lub zaporami) musi być dostępna w regionie odzyskiwania po awarii. Dostępność i zmiana konfiguracji centralnych usług IT muszą być częścią planu odzyskiwania po awarii. Centralne usługi IT to kluczowe składniki działającego środowiska SAP.
Usługa Azure Site Recovery służy do replikowania i ochrony dysków zarządzanych i konfiguracji maszyn wirtualnych dla serwerów aplikacji do regionu odzyskiwania po awarii.
Upewnij się, że dostępność udziału plików: system SAP zależy od dostępności kluczowych udziałów plików. Aby zapewnić dane w tych udziałach plików przy minimalnym utracie danych w scenariuszu odzyskiwania po awarii, konieczne jest utworzenie kopii zapasowej lub ciągłej replikacji udziału plików.
Replikacja bazy danych w usłudze Azure Site Recovery nie może chronić serwerów baz danych SAP ze względu na wysoki współczynnik zmian i brak obsługi bazy danych przez usługę. Należy skonfigurować ciągłą i asynchroniczną replikację bazy danych do regionu odzyskiwania po awarii.
Aby uzyskać więcej informacji, zobacz Omówienie odzyskiwania po awarii i wskazówki dotyczące infrastruktury dla obciążenia SAP.
Mniejsza architektura SAP
W przypadku mniejszych rozwiązań SAP korzystne może być uproszczenie projektu sieci. Sieć wirtualna każdego środowiska SAP byłaby wówczas podsieciami w takiej połączonej sieci wirtualnej. Każde uproszczenie potrzeb projektowych sieci i subskrypcji może mieć wpływ na bezpieczeństwo. Należy ponownie sprawdzić routing sieciowy, dostęp do i z sieci publicznych, dostęp do usług udostępnionych (udziałów plików) i uzyskać dostęp do innych usług platformy Azure. Poniżej przedstawiono kilka opcji zmniejszania architektury w celu lepszego zaspokojenia potrzeb organizacji.
Połącz podsieci aplikacji SAP i bazy danych w jedną. Możesz połączyć podsieci aplikacji i bazy danych, aby utworzyć jedną dużą sieć SAP. Ten projekt sieci odzwierciedla wiele lokalnych sieci SAP. Połączenie tych dwóch podsieci wymaga większej uwagi na zabezpieczenia podsieci i reguły sieciowej grupy zabezpieczeń. Grupy zabezpieczeń aplikacji są ważne w przypadku korzystania z jednej podsieci dla podsieci aplikacji SAP i bazy danych.
Połącz podsieć obwodu SAP i podsieć aplikacji. Możesz połączyć podsieć obwodu i podsieć aplikacji SAP. Należy zwrócić szczególną uwagę na reguły sieciowej grupy zabezpieczeń i użycie grupy zabezpieczeń aplikacji. Zalecamy tylko takie podejście upraszczające dla małych infrastruktur SAP.
Łączenie sieci wirtualnych sap spoke między różnymi środowiskami SAP Architektura używa różnych sieci wirtualnych dla każdego środowiska SAP (centrum, produkcji, nieprodukcyjnej i odzyskiwania po awarii). W zależności od rozmiaru środowiska SAP można połączyć sieci wirtualne SAP szprychy w mniej lub nawet jedną szprychę SAP. Nadal trzeba podzielić między środowiska produkcyjne i nieprodukcyjne. Każde środowisko produkcyjne SAP staje się podsiecią w jednej produkcyjnej sieci wirtualnej SAP. Każde środowisko nieprodukcyjne SAP staje się podsiecią w jednej nieprodukcyjnej sieci wirtualnej SAP.
Współautorzy
Firma Microsoft utrzymuje ten artykuł. Pierwotnie został napisany przez następujących współautorów.
Autorzy zabezpieczeń:
- Robert Biro | Starszy architekt
- Pankaj Meshram | Główny menedżer programu
Następne kroki
- Oprogramowanie SAP S/4HANA w systemie Linux na platformie Azure
- Uruchamianie oprogramowania SAP NetWeaver w systemie Windows na platformie Azure
- Uruchamianie oprogramowania SAP HANA w architekturze skalowanej w górę na platformie Azure
- Cloud Adoption Framework — scenariusz SAP
- Połączenia internetowe przychodzące i wychodzące dla oprogramowania SAP na platformie Azure
- Dokumentacja oprogramowania SAP na platformie Azure.
- Przewodnik planowania i implementacji platformy Azure dla obciążeń SAP
- Obciążenia SAP na platformie Azure: lista kontrolna planowania i wdrażania