Udostępnij za pośrednictwem

Planowanie i implementowanie wdrożenia sap na platformie Azure

  • Artykuł

Na platformie Azure organizacje mogą uzyskiwać potrzebne zasoby i usługi w chmurze bez ukończenia długiego cyklu zaopatrzenia. Jednak uruchomienie obciążenia SAP na platformie Azure wymaga wiedzy na temat dostępnych opcji i starannego planowania wyboru składników i architektury platformy Azure w celu zasilania rozwiązania.

Platforma Azure oferuje kompleksową platformę do uruchamiania aplikacji SAP. Oferty infrastruktury jako usługi (IaaS) i platformy jako usługi (PaaS) platformy Azure łączą się w celu zapewnienia optymalnych wyborów w celu pomyślnego wdrożenia całego środowiska sap enterprise.

Ten artykuł uzupełnia dokumentację sap i uwagi SAP, podstawowe źródła informacji na temat sposobu instalowania i wdrażania oprogramowania SAP na platformie Azure i innych platformach.

Definicje

W tym artykule używamy następujących terminów:

  • Składnik SAP: pojedyncza aplikacja SAP, na przykład SAP S/4HANA, SAP ECC, SAP BW lub SAP Solution Manager. Składnik SAP może być oparty na tradycyjnych technologiach ADVANCED Business Application Programming (ABAP) lub Java albo może to być aplikacja, która nie jest oparta na oprogramowaniu SAP NetWeaver, takim jak SAP BusinessObjects.
  • Środowisko SAP: wiele składników SAP, które są logicznie zgrupowane w celu wykonywania funkcji biznesowej, takich jak programowanie, kontrola jakości, szkolenie, odzyskiwanie po awarii lub produkcja.
  • Środowisko SAP: cały zestaw zasobów SAP w środowisku IT organizacji. Środowisko SAP obejmuje wszystkie środowiska produkcyjne i nieprodukcyjne.
  • System SAP: połączenie warstwy systemu zarządzania bazami danych (DBMS) i warstwy aplikacji. Dwa przykłady to system deweloperów SAP ERP i system testowy SAP BW. W przypadku wdrożenia platformy Azure te dwie warstwy nie mogą być dystrybuowane między środowiskiem lokalnym i platformą Azure. System SAP musi być wdrożony lokalnie lub wdrożony na platformie Azure. Można jednak obsługiwać różne systemy w środowisku SAP na platformie Azure lub lokalnie.

Zasoby

Punkt wejścia dokumentacji opisujący sposób hostowania i uruchamiania obciążenia SAP na platformie Azure to Wprowadzenie do oprogramowania SAP na maszynie wirtualnej platformy Azure. W tym artykule znajdziesz linki do innych artykułów, które obejmują:

  • Specyfika obciążenia SAP dla opcji magazynu, sieci i obsługiwanych.
  • Przewodniki sap DBMS dla różnych systemów DBMS na platformie Azure.
  • Przewodniki wdrażania sap, zarówno ręczne, jak i zautomatyzowane.
  • Szczegóły wysokiej dostępności i odzyskiwania po awarii dla obciążenia SAP na platformie Azure.
  • Integracja z oprogramowaniem SAP na platformie Azure z innymi usługami i aplikacjami innych firm.

Ważne

W przypadku wymagań wstępnych, procesu instalacji i szczegółowych informacji na temat określonych funkcji sap ważne jest, aby uważnie przeczytać dokumentację i przewodniki sap. W tym artykule opisano tylko określone zadania dotyczące oprogramowania SAP zainstalowanego i obsługiwanego na maszynie wirtualnej platformy Azure.

Następujące uwagi SAP stanowią podstawę wskazówek dotyczących platformy Azure dla wdrożeń SAP:

Numer notatki Tytuł
1928533 Aplikacje SAP na platformie Azure: obsługiwane produkty i ustalanie rozmiaru
2015553 OPROGRAMOWANIE SAP na platformie Azure: wymagania wstępne dotyczące obsługi
2039619 Aplikacje SAP na platformie Azure przy użyciu bazy danych Oracle Database
2233094 DB6: Aplikacje SAP na platformie Azure przy użyciu programu IBM Db2 dla systemów Linux, UNIX i Windows
1999351 Rozwiązywanie problemów z rozszerzonym monitorowaniem platformy Azure dla oprogramowania SAP
1409604 Wirtualizacja w systemie Windows: rozszerzone monitorowanie
2191498 Oprogramowanie SAP w systemie Linux z platformą Azure: rozszerzone monitorowanie
2731110 Obsługa wirtualnych urządzeń sieciowych (WUS) dla oprogramowania SAP na platformie Azure

Aby uzyskać ogólne domyślne i maksymalne ograniczenia subskrypcji i zasobów platformy Azure, zobacz Azure subscription and service limits, quotas, and constraints (Limity, limity przydziału i ograniczenia usługi platformy Azure).

Scenariusze

Usługi SAP są często uważane za jedne z najbardziej krytycznych aplikacji w przedsiębiorstwie. Architektura i operacje aplikacji są złożone i ważne jest, aby zapewnić spełnienie wszystkich wymagań dotyczących dostępności i wydajności. Przedsiębiorstwo zazwyczaj uważnie myśli o tym, który dostawca usług w chmurze decyduje się na uruchamianie takich procesów biznesowych o krytycznym znaczeniu dla działania firmy.

Platforma Azure to idealna platforma chmury publicznej dla aplikacji SAP i procesów biznesowych o krytycznym znaczeniu dla działania firmy. Najnowsze oprogramowanie SAP, w tym systemy SAP NetWeaver i SAP S/4HANA, może być obecnie hostowane w infrastrukturze platformy Azure. Platforma Azure oferuje ponad 800 typów procesora CPU i maszyn wirtualnych, które mają wiele terabajtów pamięci.

Opisy obsługiwanych scenariuszy i niektórych scenariuszy, które nie są obsługiwane, zobacz Scenariusze obsługiwane przez oprogramowanie SAP na maszynach wirtualnych platformy Azure. Sprawdź te scenariusze i warunki, które nie są obsługiwane, ponieważ planujesz architekturę, którą chcesz wdrożyć na platformie Azure.

Aby pomyślnie wdrożyć systemy SAP w usłudze Azure IaaS lub IaaS, ważne jest, aby zrozumieć istotne różnice między ofertami tradycyjnych chmur prywatnych i ofert IaaS. Tradycyjny host lub outsourcer dostosowuje infrastrukturę (sieć, magazyn i typ serwera) do obciążenia, które klient chce hostować. We wdrożeniu IaaS jest to odpowiedzialność klienta lub partnera za ocenę potencjalnego obciążenia i wybranie odpowiednich składników platformy Azure maszyn wirtualnych, magazynu i sieci.

Aby zebrać dane dotyczące planowania wdrożenia na platformie Azure, ważne jest:

  • Ustal, jakie produkty i wersje SAP są obsługiwane na platformie Azure.
  • Oceń, czy wersje systemu operacyjnego, których planujesz używać, są obsługiwane na maszynach wirtualnych platformy Azure, które należy wybrać dla produktów SAP.
  • Ustal, jakie wersje systemu DBMS na określonych maszynach wirtualnych są obsługiwane dla produktów SAP.
  • Oceń, czy uaktualnienie lub zaktualizowanie środowiska SAP jest niezbędne do dostosowania do wymaganego systemu operacyjnego i wydań systemu DBMS w celu uzyskania obsługiwanej konfiguracji.
  • Oceń, czy chcesz przejść do różnych systemów operacyjnych w celu wdrożenia na platformie Azure.

Szczegółowe informacje o obsługiwanych składnikach SAP na platformie Azure, jednostkach infrastruktury platformy Azure i powiązanych wersjach systemu operacyjnego i wydaniach systemu operacyjnego DBMS są objaśnione w oprogramowaniu SAP obsługiwanym w przypadku wdrożeń platformy Azure. Wiedza na temat oceny pomocy technicznej i zależności między wersjami sap, wydaniami systemu operacyjnego i wydaniami systemu operacyjnego DBMS ma znaczący wpływ na nakłady pracy związane z przenoszeniem systemów SAP na platformę Azure. Dowiesz się, czy są zaangażowane znaczne nakłady pracy związane z przygotowaniem, na przykład niezależnie od tego, czy konieczne jest uaktualnienie wersji SAP, czy przejście do innego systemu operacyjnego.

Pierwsze kroki planowania wdrożenia

Pierwszym krokiem planowania wdrożenia nie jest wyszukanie maszyn wirtualnych, które są dostępne do uruchamiania aplikacji SAP.

Pierwszymi krokami planowania wdrożenia jest praca z zespołami ds. zgodności i zabezpieczeń w organizacji w celu określenia, jakie warunki granic dotyczą wdrażania typu obciążenia SAP lub procesu biznesowego w chmurze publicznej. Proces może być czasochłonny, ale ma kluczowe znaczenie dla ukończenia.

Jeśli Twoja organizacja wdrożyła już oprogramowanie na platformie Azure, proces może być łatwy. Jeśli twoja firma jest bardziej na początku podróży, większe dyskusje mogą być konieczne do opracowania warunków granic, warunków zabezpieczeń i architektury przedsiębiorstwa, która umożliwia hostowanie niektórych danych SAP i procesów biznesowych SAP w chmurze publicznej.

Planowanie zgodności

Aby uzyskać listę ofert zgodności firmy Microsoft, które mogą pomóc w planowaniu potrzeb dotyczących zgodności, zobacz Oferty zgodności firmy Microsoft.

Planowanie pod kątem zabezpieczeń

Aby uzyskać informacje o problemach dotyczących zabezpieczeń specyficznych dla oprogramowania SAP, takich jak szyfrowanie danych magazynowanych lub inne szyfrowanie w usłudze platformy Azure, zobacz Omówienie szyfrowania platformy Azure i Zabezpieczenia dla środowiska SAP.

Organizowanie zasobów platformy Azure

Wraz z przeglądem zabezpieczeń i zgodności, jeśli jeszcze nie wykonano tego zadania, zaplanuj sposób organizowania zasobów platformy Azure. Proces obejmuje podejmowanie decyzji dotyczących:

  • Konwencja nazewnictwa używana dla każdego zasobu platformy Azure, taka jak dla maszyn wirtualnych i grup zasobów.
  • Projekt subskrypcji i grupy zarządzania dla obciążenia SAP, taki jak tworzenie wielu subskrypcji na obciążenie, warstwę wdrożenia lub dla każdej jednostki biznesowej.
  • Użycie usługi Azure Policy dla całej przedsiębiorstwa dla subskrypcji i grup zarządzania.

Aby ułatwić podejmowanie odpowiednich decyzji, wiele szczegółów architektury przedsiębiorstwa opisano w przewodniku Azure Cloud Adoption Framework.

Nie lekceważ początkowej fazy projektu w planowaniu. Tylko wtedy, gdy masz umowy i reguły dotyczące zgodności, zabezpieczeń i organizacji zasobów platformy Azure, należy przyspieszyć planowanie wdrożenia.

Następne kroki to planowanie położenia geograficznego i architektury sieci wdrożonej na platformie Azure.

Obszary geograficzne i regiony platformy Azure

Usługi platformy Azure są dostępne w oddzielnych regionach świadczenia usługi Azure. Region platformy Azure to kolekcja centrów danych. Centra danych zawierają sprzęt i infrastrukturę, która hostuje i uruchamia usługi platformy Azure, które są dostępne w regionie. Infrastruktura obejmuje dużą liczbę węzłów, które działają jako węzły obliczeniowe lub węzły magazynu lub które uruchamiają funkcje sieciowe.

Aby uzyskać listę regionów świadczenia usługi Azure, zobacz Lokalizacje geograficzne platformy Azure. Aby zapoznać się z interaktywną mapą, zobacz Infrastruktura globalna platformy Azure.

Nie wszystkie regiony świadczenia usługi Azure oferują te same usługi. W zależności od produktu SAP, który chcesz uruchomić, wymagania dotyczące ustalania rozmiaru oraz wymagany system operacyjny i system DBMS, możliwe, że określony region nie oferuje typów maszyn wirtualnych wymaganych w danym scenariuszu. Jeśli na przykład korzystasz z platformy SAP HANA, zwykle potrzebujesz maszyn wirtualnych różnych rodzin maszyn wirtualnych z serii M. Te rodziny maszyn wirtualnych są wdrażane tylko w podzestawie regionów platformy Azure.

Gdy zaczniesz planować i myśleć o regionach, które należy wybrać jako region podstawowy i ostatecznie region pomocniczy, musisz zbadać, czy usługi potrzebne w scenariuszach są dostępne w regionach, które rozważasz. Możesz dowiedzieć się dokładnie, które typy maszyn wirtualnych, typy magazynu platformy Azure i inne usługi platformy Azure są dostępne w każdym regionie w obszarze Produkty dostępne według regionów.

Sparowane regiony platformy Azure

W sparowanym regionie platformy Azure replikacja niektórych danych jest domyślnie włączona między dwoma regionami. Aby uzyskać więcej informacji, zobacz Replikacja między regionami na platformie Azure: ciągłość działania i odzyskiwanie po awarii.

Replikacja danych w parze regionów jest powiązana z typami usługi Azure Storage, które można skonfigurować do replikacji w sparowanym regionie. Aby uzyskać szczegółowe informacje, zobacz Nadmiarowość magazynu w regionie pomocniczym.

Typy magazynów, które obsługują replikację danych w sparowanym regionie, to typy magazynów, które nie są odpowiednie dla składników SAP i obciążenia systemu DBMS. Użyteczność replikacji usługi Azure Storage jest ograniczona do usługi Azure Blob Storage (do celów kopii zapasowych), udziałów plików i woluminów oraz innych scenariuszy magazynu o dużym opóźnieniu.

Podczas sprawdzania sparowanych regionów i usług, które mają być używane w regionach podstawowych lub pomocniczych, możliwe jest, że usługi platformy Azure lub typy maszyn wirtualnych, które mają być używane w regionie podstawowym, nie są dostępne w sparowanym regionie, którego chcesz użyć jako regionu pomocniczego. Możesz też określić, że sparowany region platformy Azure nie jest akceptowalny dla danego scenariusza ze względu na zgodność danych. W tych scenariuszach należy użyć regionu innego niż region pomocniczy lub odzyskiwania po awarii, a następnie samodzielnie skonfigurować część replikacji danych.

Strefy dostępności

Wiele regionów platformy Azure używa stref dostępności do fizycznego oddzielenia lokalizacji w regionie świadczenia usługi Azure. Każda strefa dostępności składa się z co najmniej jednego centrum danych wyposażonego w niezależne zasilanie, chłodzenie i sieć. Przykładem użycia strefy dostępności w celu zwiększenia odporności jest wdrożenie dwóch maszyn wirtualnych w dwóch oddzielnych strefach dostępności na platformie Azure. Innym przykładem jest zaimplementowanie platformy wysokiej dostępności dla systemu SAP DBMS w jednej strefie dostępności i wdrożenie programu SAP (A)SCS w innej strefie dostępności, dzięki czemu uzyskasz najlepszą umowę SLA na platformie Azure.

Aby uzyskać więcej informacji na temat umów SLA maszyn wirtualnych na platformie Azure, zapoznaj się z najnowszą wersją umów SLA maszyn wirtualnych. Ponieważ regiony platformy Azure rozwijają się i rozszerzają szybko, topologia regionów platformy Azure, liczba fizycznych centrów danych, odległość między centrami danych i odległość między strefami dostępności platformy Azure ewoluuje. Opóźnienie sieci zmienia się w miarę zmian infrastruktury.

Postępuj zgodnie ze wskazówkami w temacie Konfiguracje obciążeń SAP ze strefami dostępności platformy Azure po wybraniu regionu z strefami dostępności. Określ również, który model wdrażania strefowego najlepiej nadaje się do Twoich wymagań, wybranego regionu i obciążenia.

Domeny błędów

Domeny błędów reprezentują fizyczną jednostkę awarii. Domena błędów jest ściśle powiązana z infrastrukturą fizyczną zawartą w centrach danych. Mimo że blok fizyczny lub stojak można uznać za domenę błędów, nie istnieje bezpośrednie mapowanie "jeden do jednego" między fizycznym elementem obliczeniowym a domeną błędów.

Podczas wdrażania wielu maszyn wirtualnych w ramach jednego systemu SAP można pośrednio wpłynąć na kontroler sieci szkieletowej platformy Azure w celu wdrożenia maszyn wirtualnych w różnych domenach błędów, dzięki czemu można spełnić wymagania dotyczące umów SLA dotyczących dostępności. Nie masz jednak bezpośredniej kontroli nad dystrybucją domen błędów za pośrednictwem jednostki skalowania platformy Azure (kolekcji setek węzłów obliczeniowych lub węzłów magazynu i sieci) ani przypisania maszyn wirtualnych do określonej domeny błędów. Aby manewrować kontrolerem sieci szkieletowej platformy Azure w celu wdrożenia zestawu maszyn wirtualnych w różnych domenach błędów, należy przypisać zestaw dostępności platformy Azure do maszyn wirtualnych w czasie wdrażania. Aby uzyskać więcej informacji, zobacz Zestawy dostępności.

Domeny aktualizacji

Domeny aktualizacji reprezentują jednostkę logiczną, która ustawia sposób aktualizowania maszyny wirtualnej w systemie SAP składającym się z wielu maszyn wirtualnych. W przypadku aktualizacji platformy platforma Azure przechodzi przez proces aktualizowania tych domen aktualizacji jeden po drugim. Rozpowszechniając maszyny wirtualne w czasie wdrażania w różnych domenach aktualizacji, można chronić system SAP przed potencjalnym przestojem. Podobnie jak w przypadku domen błędów jednostka skalowania platformy Azure jest podzielona na wiele domen aktualizacji. Aby manewrować kontrolerem sieci szkieletowej platformy Azure w celu wdrożenia zestawu maszyn wirtualnych w różnych domenach aktualizacji, należy przypisać zestaw dostępności platformy Azure do maszyn wirtualnych w czasie wdrażania. Aby uzyskać więcej informacji, zobacz Zestawy dostępności.

Diagram przedstawiający domeny aktualizacji i domeny błędów.

Zestawy dostępności

Maszyny wirtualne platformy Azure w ramach jednego zestawu dostępności platformy Azure są dystrybuowane przez kontroler sieci szkieletowej platformy Azure w różnych domenach błędów. Dystrybucja w różnych domenach błędów polega na zapobieganiu zamykaniu wszystkich maszyn wirtualnych systemu SAP podczas konserwacji infrastruktury lub awarii w jednej domenie błędów. Domyślnie maszyny wirtualne nie są częścią zestawu dostępności. Maszynę wirtualną można dodać w zestawie dostępności tylko w czasie wdrażania lub po ponownym wdrożeniu maszyny wirtualnej.

Aby dowiedzieć się więcej na temat zestawów dostępności platformy Azure i sposobu, w jaki zestawy dostępności odnoszą się do domen błędów, zobacz Zestawy dostępności platformy Azure.

Ważne

Strefy dostępności i zestawy dostępności na platformie Azure wzajemnie się wykluczają. Można wdrożyć wiele maszyn wirtualnych w określonej strefie dostępności lub w zestawie dostępności. Nie można jednak przypisać zarówno strefy dostępności, jak i zestawu dostępności do maszyny wirtualnej.

Zestawy dostępności i strefy dostępności można połączyć, jeśli używasz grup umieszczania w pobliżu.

Podczas definiowania zestawów dostępności i próby połączenia różnych maszyn wirtualnych z różnych rodzin maszyn wirtualnych w jednym zestawie dostępności mogą wystąpić problemy, które uniemożliwiają dołączenie określonego typu maszyny wirtualnej do zestawu dostępności. Przyczyną jest to, że zestaw dostępności jest powiązany z jednostką skalowania zawierającą określony typ hosta obliczeniowego. Określony typ hosta obliczeniowego może działać tylko w przypadku niektórych typów rodzin maszyn wirtualnych.

Na przykład utworzysz zestaw dostępności i wdrożysz pierwszą maszynę wirtualną w zestawie dostępności. Pierwsza maszyna wirtualna dodana do zestawu dostępności znajduje się w rodzinie maszyn wirtualnych Edsv5. Podczas próby wdrożenia drugiej maszyny wirtualnej maszyna wirtualna, która znajduje się w rodzinie M, to wdrożenie kończy się niepowodzeniem. Powodem jest to, że maszyny wirtualne rodziny Edsv5 nie działają na tym samym sprzęcie hosta co maszyny wirtualne w rodzinie M.

Ten sam problem może wystąpić, jeśli zmieniasz rozmiar maszyn wirtualnych. Jeśli spróbujesz przenieść maszynę wirtualną z rodziny Edsv5 i do typu maszyny wirtualnej, który znajduje się w rodzinie M, wdrożenie zakończy się niepowodzeniem. Jeśli zmieniasz rozmiar na rodzinę maszyn wirtualnych, które nie mogą być hostowane na tym samym sprzęcie hosta, musisz zamknąć wszystkie maszyny wirtualne, które znajdują się w zestawie dostępności i zmienić ich rozmiar, aby można je było uruchomić na innym typie maszyny hosta. Aby uzyskać informacje na temat umów SLA maszyn wirtualnych wdrożonych w zestawie dostępności, zobacz Umowy SLA dotyczące maszyn wirtualnych.

Zestawy skalowania maszyn wirtualnych z elastyczną aranżacją

Zestawy skalowania maszyn wirtualnych z elastyczną aranżacją zapewniają logiczne grupowanie maszyn wirtualnych zarządzanych przez platformę. Istnieje możliwość utworzenia zestawu skalowania w regionie lub rozszerzenia 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 określonej strefie, a zestaw skalowania będzie również dystrybuować maszyny wirtualne między różne domeny błędów w strefie na podstawie najlepszych wysiłków.

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 dowiedzieć się więcej na temat wdrażania obciążeń SAP za pomocą zestawu skalowania, zobacz przewodnik wdrażania elastycznej skalowania maszyn wirtualnych.

Podczas wdrażania obciążenia SAP o wysokiej dostępności na platformie Azure należy wziąć pod uwagę różne dostępne typy wdrożeń oraz sposób ich stosowania w różnych regionach platformy Azure (na przykład między strefami, w jednej strefie lub w regionie bez stref). Aby uzyskać więcej informacji, zobacz Opcje wdrażania o wysokiej dostępności dla obciążenia SAP.

Napiwek

Obecnie nie ma bezpośredniego sposobu migracji obciążenia SAP wdrożonego w zestawach dostępności lub strefach dostępności w celu elastycznej skali przy użyciu FD=1. Aby przełączyć, należy ponownie utworzyć maszynę wirtualną i dysk z ograniczeniami strefy z istniejących zasobów. Projekt typu open source zawiera funkcje programu PowerShell, których można użyć jako przykładu do zmiany maszyny wirtualnej wdrożonej w zestawie dostępności lub strefie dostępności na elastyczny zestaw skalowania z FD=1. W wpisie w blogu pokazano, jak zmodyfikować system SAP wysokiej dostępności lub nienależące do wysokiej dostępności wdrożony w zestawie dostępności lub strefie dostępności w celu elastycznego zestawu skalowania przy użyciu FD=1.

Grupy umieszczania w pobliżu

Opóźnienie sieci między poszczególnymi maszynami wirtualnymi SAP może mieć znaczący wpływ na wydajność. Czas rundy sieci między serwerami aplikacji SAP a usługą DBMS może mieć znaczący wpływ na aplikacje biznesowe. Optymalnie wszystkie elementy obliczeniowe z uruchomionymi maszynami wirtualnymi SAP znajdują się tak blisko, jak to możliwe. Ta opcja nie jest możliwa w każdej kombinacji, a platforma Azure może nie wiedzieć, które maszyny wirtualne mają być ze sobą połączone. W większości sytuacji i regionów domyślne umieszczanie spełnia wymagania dotyczące opóźnienia rundy w sieci.

Jeśli domyślne umieszczanie nie spełnia wymagań dotyczących dwukierunkowości sieci w systemie SAP, grupy umieszczania w pobliżu mogą rozwiązać ten problem. Możesz użyć grup umieszczania w pobliżu z ograniczeniami lokalizacji regionu platformy Azure, strefy dostępności i zestawu dostępności, aby zwiększyć odporność. W przypadku grupy umieszczania w pobliżu możliwe jest połączenie zarówno strefy dostępności, jak i zestawu dostępności podczas ustawiania różnych domen aktualizacji i awarii. Grupa umieszczania w pobliżu powinna zawierać tylko jeden system SAP.

Mimo że wdrożenie w grupie umieszczania w pobliżu może spowodować najbardziej zoptymalizowane pod kątem opóźnień umieszczanie, wdrożenie przy użyciu grupy umieszczania w pobliżu ma również wady. Niektóre rodziny maszyn wirtualnych nie mogą być połączone w jednej grupie umieszczania w pobliżu lub mogą wystąpić problemy w przypadku zmiany rozmiaru między rodzinami maszyn wirtualnych. Ograniczenia rodzin maszyn wirtualnych, regionów i stref dostępności mogą nie obsługiwać kolokacji. Aby uzyskać szczegółowe informacje i dowiedzieć się więcej o zaletach i potencjalnych wyzwaniach związanych z używaniem grupy umieszczania w pobliżu, zobacz Scenariusze grup umieszczania w pobliżu.

Maszyny wirtualne, które nie korzystają z grup umieszczania w pobliżu, powinny być domyślną metodą wdrażania w większości sytuacji dla systemów SAP. Ta wartość domyślna jest szczególnie stosowana w przypadku strefowych (pojedynczej strefy dostępności) i między strefami (maszyn wirtualnych, które są dystrybuowane między dwiema strefami dostępności) wdrożeń systemu SAP. Używanie grup umieszczania w pobliżu powinno być ograniczone do systemów SAP i regionów platformy Azure, jeśli są wymagane tylko ze względu na wydajność.

Sieć platformy Azure

Platforma Azure ma infrastrukturę sieciową, która mapuje się na wszystkie scenariusze, które można zaimplementować we wdrożeniu sap. Na platformie Azure masz następujące możliwości:

  • Dostęp do usług platformy Azure i dostęp do określonych portów na maszynach wirtualnych używanych przez aplikacje.
  • Bezpośredni dostęp do maszyn wirtualnych za pośrednictwem protokołu Secure Shell (SSH) lub pulpitu zdalnego systemu Windows (RDP) na potrzeby zarządzania i administrowania.
  • Komunikacja wewnętrzna i rozpoznawanie nazw między maszynami wirtualnymi a usługami platformy Azure.
  • Łączność lokalna między siecią lokalną a sieciami platformy Azure.
  • Komunikacja między usługami wdrożonym w różnych regionach świadczenia usługi Azure.

Aby uzyskać szczegółowe informacje na temat sieci, zobacz Azure Virtual Network.

Projektowanie sieci zwykle jest pierwszą czynnością techniczną, którą podejmujesz podczas wdrażania na platformie Azure. Obsługa centralnej architektury przedsiębiorstwa, takiej jak SAP, często jest częścią ogólnych wymagań dotyczących sieci. Na etapie planowania należy udokumentować proponowaną architekturę sieci tak szczegółowo, jak to możliwe. Jeśli wprowadzisz zmianę w późniejszym momencie, na przykład zmieniając adres sieciowy podsieci, może być konieczne przeniesienie lub usunięcie wdrożonych zasobów.

Sieci wirtualne platformy Azure

Sieć wirtualna to podstawowy blok konstrukcyjny dla sieci prywatnej na platformie Azure. Zakres adresów sieci można zdefiniować i oddzielić zakres od podsieci sieci. Podsieć sieci może być dostępna dla maszyny wirtualnej SAP do użycia lub może być przeznaczona dla określonej usługi lub celu. Niektóre usługi platformy Azure, takie jak Azure Virtual Network i aplikacja systemu Azure Gateway, wymagają dedykowanej podsieci.

Sieć wirtualna działa jako granica sieci. Częścią projektu wymaganego podczas planowania wdrożenia jest zdefiniowanie sieci wirtualnej, podsieci i zakresów adresów sieci prywatnej. Po wdrożeniu maszyn wirtualnych nie można zmienić przypisania sieci wirtualnej dla zasobów, takich jak karty interfejsu sieciowego (karty sieciowe) dla maszyn wirtualnych. Wprowadzenie zmiany w sieci wirtualnej lub w zakresie adresów podsieci może wymagać przeniesienia wszystkich wdrożonych zasobów do innej podsieci.

Projekt sieci powinien spełniać kilka wymagań dotyczących wdrażania oprogramowania SAP:

  • Żadne wirtualne urządzenia sieciowe, takie jak zapora, nie są umieszczane w ścieżce komunikacji między aplikacją SAP i warstwą DBMS produktów SAP za pośrednictwem jądra SAP, takiego jak S/4HANA lub SAP NetWeaver.
  • Ograniczenia routingu sieciowego są wymuszane przez sieciowe grupy zabezpieczeń na poziomie podsieci . Grupuj adresy IP maszyn wirtualnych w grupach zabezpieczeń aplikacji (ASG), które są przechowywane w regułach sieciowej grupy zabezpieczeń, i udostępniaj role, warstwy i grupowanie identyfikatorów SID uprawnień.
  • Maszyny wirtualne aplikacji SAP i bazy danych działają w tej samej sieci wirtualnej w tej samej lub różnych podsieciach pojedynczej sieci wirtualnej. Użyj różnych podsieci dla maszyn wirtualnych aplikacji i bazy danych. Alternatywnie należy użyć dedykowanej aplikacji i grup asg usługi DBMS do grupowania reguł, które mają zastosowanie do każdego typu obciążenia w ramach tej samej podsieci.
  • Przyspieszona sieć jest włączona na wszystkich kartach sieciowych wszystkich maszyn wirtualnych dla obciążeń SAP, jeśli jest to technicznie możliwe.
  • Zapewnij bezpieczny dostęp do zależności od usług centralnych, w tym dla rozpoznawania nazw (DNS), zarządzania tożsamościami (domeny usługi Active Directory systemu Windows Server/identyfikator entra firmy Microsoft) i dostępu administracyjnego.
  • Zapewnij dostęp do publicznych punktów końcowych i zgodnie z potrzebami. Przykłady obejmują zarządzanie platformą Azure dla operacji ClusterLabs Pacemaker w wysokiej dostępności lub dla usług platformy Azure, takich jak Azure Backup.
  • Używaj wielu kart sieciowych tylko wtedy, gdy są one niezbędne do utworzenia wyznaczonych podsieci, które mają własne trasy i reguły sieciowej grupy zabezpieczeń.

Przykłady architektury sieci dla wdrożenia sap można znaleźć w następujących artykułach:

Zagadnienia dotyczące sieci wirtualnej

Niektóre konfiguracje sieci wirtualnej mają konkretne zagadnienia, o których należy pamiętać.

  • Konfigurowanie wirtualnych urządzeń sieciowych w ścieżce komunikacji między warstwą aplikacji SAP a warstwą systemu DBMS składników SAP przy użyciu jądra SAP, takiego jak S/4HANA lub SAP NetWeaver, nie jest obsługiwane.

    Wirtualne urządzenia sieciowe w ścieżkach komunikacyjnych mogą łatwo podwoić opóźnienie sieci między dwoma partnerami komunikacyjnymi. Mogą również ograniczyć przepływność w ścieżkach krytycznych między warstwą aplikacji SAP i warstwą DBMS. W niektórych scenariuszach wirtualne urządzenia sieciowe mogą spowodować niepowodzenie klastrów pacemaker systemu Linux.

    Ścieżka komunikacji między warstwą aplikacji SAP a warstwą DBMS musi być ścieżką bezpośrednią. Ograniczenie nie obejmuje reguł asg i sieciowej grupy zabezpieczeń, jeśli reguły grupy zabezpieczeń i grupy zabezpieczeń grupy zabezpieczeń zezwalają na bezpośrednią ścieżkę komunikacji.

    Inne scenariusze, w których wirtualne urządzenia sieciowe nie są obsługiwane, to:

  • Oddzielenie warstwy aplikacji SAP i warstwy DBMS na różne sieci wirtualne platformy Azure nie jest obsługiwane. Zalecamy segregowanie warstwy aplikacji SAP i warstwy DBMS przy użyciu podsieci w tej samej sieci wirtualnej platformy Azure, a nie przy użyciu różnych sieci wirtualnych platformy Azure.

    Jeśli skonfigurowano nieobsługiwany scenariusz, który segreguje dwie warstwy systemu SAP w różnych sieciach wirtualnych, te dwie sieci wirtualne muszą być równorzędne.

    Ruch sieciowy między dwiema równorzędną sieciami wirtualnymi platformy Azure podlega kosztom transferu. Każdego dnia duża ilość danych składających się z wielu terabajtów jest wymieniana między warstwą aplikacji SAP a warstwą DBMS. W przypadku podziału warstwy aplikacji SAP i warstwy DBMS między dwie równorzędne sieci wirtualne platformy Azure można ponieść znaczne koszty .

Rozpoznawanie nazw i usługi domenowe

Rozpoznawanie nazwy hosta na adres IP za pośrednictwem systemu DNS jest często kluczowym elementem sieci SAP. Istnieje wiele opcji konfigurowania nazw i rozpoznawania adresów IP na platformie Azure.

Często przedsiębiorstwo ma centralne rozwiązanie DNS, które jest częścią ogólnej architektury. Kilka opcji implementowania rozpoznawania nazw na platformie Azure natywnie, zamiast konfigurowania własnych serwerów DNS, opisano w temacie Rozpoznawanie nazw dla zasobów w sieciach wirtualnych platformy Azure.

Podobnie jak w przypadku usług DNS, może istnieć wymóg, aby usługa Active Directory systemu Windows Server była dostępna dla maszyn wirtualnych lub usług SAP.

Przypisanie adresu IP

Adres IP karty sieciowej pozostaje zgłaszany i używany przez cały okres istnienia karty sieciowej maszyny wirtualnej. Reguła ma zastosowanie zarówno do dynamicznego, jak i statycznego przypisania adresu IP. Pozostaje prawdą, czy maszyna wirtualna jest uruchomiona, czy jest zamknięta. Dynamiczne przypisanie adresu IP jest zwalniane, jeśli karta sieciowa zostanie usunięta, jeśli podsieć ulegnie zmianie lub jeśli metoda alokacji zmieni się na statyczną.

Istnieje możliwość przypisania stałych adresów IP do maszyn wirtualnych w sieci wirtualnej platformy Azure. Adresy IP często są ponownie przypisywane dla systemów SAP, które zależą od zewnętrznych serwerów DNS i wpisów statycznych. Adres IP pozostaje przypisany, dopóki maszyna wirtualna i jego karta sieciowa nie zostaną usunięte lub dopóki adres IP nie zostanie przypisany. Podczas definiowania zakresu adresów IP dla sieci wirtualnej należy wziąć pod uwagę ogólną liczbę maszyn wirtualnych (uruchomionych i zatrzymanych).

Aby uzyskać więcej informacji, zobacz Tworzenie maszyny wirtualnej, która ma statyczny prywatny adres IP.

Uwaga

Należy zdecydować między alokacją statycznych i dynamicznych adresów IP dla maszyn wirtualnych platformy Azure i ich kart sieciowych. System operacyjny gościa maszyny wirtualnej uzyska adres IP przypisany do karty sieciowej podczas rozruchu maszyny wirtualnej. Nie należy przypisywać statycznych adresów IP w systemie operacyjnym gościa do karty sieciowej. Niektóre usługi platformy Azure, takie jak Azure Backup, polegają na tym, że co najmniej podstawowa karta sieciowa ma wartość DHCP, a nie statyczne adresy IP wewnątrz systemu operacyjnego. Aby uzyskać więcej informacji, zobacz Rozwiązywanie problemów z kopią zapasową maszyny wirtualnej platformy Azure.

Pomocnicze adresy IP dla wirtualizacji nazw hostów SAP

Każda karta sieciowa maszyny wirtualnej platformy Azure może mieć przypisane wiele adresów IP. Pomocniczy adres IP może służyć do nazwy hosta wirtualnego SAP, który jest mapowany na rekord DNS A lub rekord DNS PTR. Pomocniczy adres IP musi być przypisany do konfiguracji adresu IP karty sieciowej platformy Azure. Pomocniczy adres IP musi być również skonfigurowany w systemie operacyjnym statycznie, ponieważ pomocnicze adresy IP często nie są przypisywane za pośrednictwem protokołu DHCP. Każdy pomocniczy adres IP musi pochodzić z tej samej podsieci, z którą jest powiązana karta sieciowa. Pomocniczy adres IP można dodać i usunąć z karty sieciowej platformy Azure bez zatrzymywania lub cofania przydziału maszyny wirtualnej. Aby dodać lub usunąć podstawowy adres IP karty sieciowej, należy cofnąć przydział maszyny wirtualnej.

Moduł równoważenia obciążenia platformy Azure jest używany przez architektury wysokiej dostępności SAP z klastrami Pacemaker. W tym scenariuszu moduł równoważenia obciążenia włącza nazwy hostów wirtualnych SAP. Aby uzyskać ogólne wskazówki dotyczące używania nazw hostów wirtualnych, zobacz Sap Note 962955.

Usługa Azure Load Balancer z maszynami wirtualnymi z systemem SAP

Moduł równoważenia obciążenia jest zwykle używany w architekturach wysokiej dostępności w celu zapewnienia pływających adresów IP między aktywnymi i pasywnymi węzłami klastra. Możesz również użyć modułu równoważenia obciążenia dla pojedynczej maszyny wirtualnej do przechowywania wirtualnego adresu IP dla nazwy hosta wirtualnego SAP. Użycie modułu równoważenia obciążenia dla pojedynczej maszyny wirtualnej jest alternatywą dla użycia pomocniczego adresu IP na karcie sieciowej lub używania wielu kart sieciowych w tej samej podsieci.

Standardowy moduł równoważenia obciążenia modyfikuje domyślną ścieżkę dostępu wychodzącego, ponieważ jego architektura jest domyślnie bezpieczna. Maszyny wirtualne, które znajdują się za standardowym modułem równoważenia obciążenia, mogą nie być już w stanie uzyskać dostępu do tych samych publicznych punktów końcowych. Niektóre przykłady to punkt końcowy repozytorium aktualizacji systemu operacyjnego lub publiczny punkt końcowy usług platformy Azure. Aby uzyskać opcje zapewnienia łączności wychodzącej, zobacz Publiczna łączność punktów końcowych dla maszyn wirtualnych przy użyciu standardowego modułu równoważenia obciążenia platformy Azure.

Napiwek

Podstawowy moduł równoważenia obciążenia nie powinien być używany z żadną architekturą SAP na platformie Azure. Podstawowy moduł równoważenia obciążenia ma zostać wycofany.

Wiele wirtualnych kart sieciowych na maszynę wirtualną

Dla maszyny wirtualnej platformy Azure można zdefiniować wiele wirtualnych kart interfejsu sieciowego (vNICs) z każdą wirtualną kartą sieciową przypisaną do dowolnej podsieci w tej samej sieci wirtualnej co podstawowa wirtualna karta sieciowa. Dzięki możliwości posiadania wielu wirtualnych kart sieciowych można w razie potrzeby skonfigurować separację ruchu sieciowego. Na przykład ruch klienta jest kierowany przez podstawową wirtualną sieć sieciową, a część ruchu administracyjnego lub zaplecza jest kierowana przez drugą wirtualnąnicę. W zależności od używanego systemu operacyjnego i obrazu trasy ruchu dla kart sieciowych wewnątrz systemu operacyjnego mogą wymagać skonfigurowania prawidłowego routingu.

Typ i rozmiar maszyny wirtualnej określa, ile wirtualnych kart sieciowych może przypisać maszyna wirtualna. Aby uzyskać informacje na temat funkcji i ograniczeń, zobacz Przypisywanie wielu adresów IP do maszyn wirtualnych przy użyciu witryny Azure Portal.

Dodanie wirtualnych kart sieciowych do maszyny wirtualnej nie zwiększa dostępnej przepustowości sieci. Wszystkie interfejsy sieciowe mają taką samą przepustowość. Zalecamy używanie wielu kart sieciowych tylko wtedy, gdy maszyny wirtualne muszą uzyskiwać dostęp do podsieci prywatnych. Zalecamy wzorzec projektowania, który opiera się na funkcjonalności sieciowej grupy zabezpieczeń i upraszcza wymagania dotyczące sieci i podsieci. Projekt powinien używać jak najmniejszej liczby interfejsów sieciowych i optymalnie tylko jeden. Wyjątkiem jest skalowanie w poziomie platformy HANA, w którym dodatkowa wirtualna sieć wirtualna jest wymagana dla sieci wewnętrznej HANA.

Ostrzeżenie

Jeśli używasz wielu wirtualnych kart sieciowych na maszynie wirtualnej, zalecamy użycie podsieci podstawowej karty sieciowej do obsługi ruchu sieciowego użytkownika.

Przyspieszona sieć

Aby jeszcze bardziej zmniejszyć opóźnienie sieci między maszynami wirtualnymi platformy Azure, zalecamy potwierdzenie włączenia przyspieszonej sieci platformy Azure na każdej maszynie wirtualnej, na której działa obciążenie SAP. Mimo że przyspieszona sieć jest domyślnie włączona dla nowych maszyn wirtualnych, na listę kontrolną wdrożenia należy sprawdzić stan. Zalety przyspieszonej sieci są znacznie lepsze wydajność i opóźnienia sieci. Użyj jej podczas wdrażania maszyn wirtualnych platformy Azure dla obciążeń SAP na wszystkich obsługiwanych maszynach wirtualnych, zwłaszcza w przypadku warstwy aplikacji SAP i warstwy SAP DBMS. Połączona dokumentacja zawiera zależności pomocy technicznej dotyczące wersji systemu operacyjnego i wystąpień maszyn wirtualnych.

Łączność lokalna

Wdrożenie sap na platformie Azure zakłada, że centralna architektura sieci dla całego przedsiębiorstwa i centrum komunikacji są wdrażane w celu włączenia łączności lokalnej. Lokalna łączność sieciowa jest niezbędna, aby umożliwić użytkownikom i aplikacjom dostęp do środowiska SAP na platformie Azure w celu uzyskania dostępu do innych centralnych usług organizacji, takich jak centralny system DNS, domena oraz infrastruktura zarządzania zabezpieczeniami i poprawkami.

Istnieje wiele opcji zapewniania łączności lokalnej dla wdrożenia oprogramowania SAP na platformie Azure. Wdrożenie sieci najczęściej jest topologią sieci piasty i szprych lub rozszerzeniem topologii piasty i szprych, globalnej wirtualnej sieci WAN.

W przypadku lokalnych wdrożeń SAP zalecamy użycie połączenia prywatnego za pośrednictwem usługi Azure ExpressRoute. W przypadku mniejszych obciążeń SAP, regionów zdalnych lub mniejszych biur dostępna jest łączność lokalna sieci VPN. Użycie usługi ExpressRoute z połączeniem typu lokacja-lokacja sieci VPN jako ścieżką trybu failover jest możliwą kombinacją obu usług.

Łączność wychodząca i przychodząca z Internetem

Środowisko SAP wymaga łączności z Internetem, niezależnie od tego, czy jest to odbieranie aktualizacji repozytorium systemu operacyjnego, nawiązywanie połączenia z aplikacjami SAP SaaS w publicznych punktach końcowych lub uzyskiwanie dostępu do usługi platformy Azure za pośrednictwem publicznego punktu końcowego. Podobnie może być konieczne zapewnienie klientom dostępu do aplikacji SAP Fiori, a użytkownicy internetu uzyskują dostęp do usług udostępnianych przez środowisko SAP. Architektura sieci SAP wymaga zaplanowanie ścieżki do Internetu i wszystkich żądań przychodzących.

Zabezpiecz sieć wirtualną przy użyciu reguł sieciowej grupy zabezpieczeń, używając tagów usług sieciowych dla znanych usług oraz ustanawiając routing i adresowanie IP zapory lub innego wirtualnego urządzenia sieciowego. Wszystkie te zadania lub zagadnienia są częścią architektury. Zasoby w sieciach prywatnych muszą być chronione przez zapory warstwy 4 i warstwy 7 sieci.

Ścieżki komunikacyjne z Internetem koncentrują się na architekturze najlepszych rozwiązań.

Maszyny wirtualne platformy Azure dla obciążeń SAP

Niektóre rodziny maszyn wirtualnych platformy Azure są szczególnie odpowiednie dla obciążeń SAP, a niektóre bardziej szczegółowe dla obciążenia SAP HANA. Sposób znajdowania poprawnego typu maszyny wirtualnej i jego możliwości obsługi obciążenia SAP opisano w temacie What SAP software is supported for Azure deployments (Jakie oprogramowanie SAP jest obsługiwane w przypadku wdrożeń platformy Azure). Ponadto program SAP Note 1928533 zawiera listę wszystkich certyfikowanych maszyn wirtualnych platformy Azure oraz ich możliwości wydajności mierzonych w testach porównawczych i ograniczeniach oprogramowania SAP Application Performance Standard (SAPS). Typy maszyn wirtualnych, które są certyfikowane dla obciążenia SAP, nie używają nadmiernej aprowizacji dla zasobów procesora CPU i pamięci.

Nie patrząc tylko na wybór obsługiwanych typów maszyn wirtualnych, należy sprawdzić, czy te typy maszyn wirtualnych są dostępne w określonym regionie na podstawie produktów dostępnych według regionów. Co najmniej tak ważne jest ustalenie, czy następujące możliwości maszyny wirtualnej pasują do danego scenariusza:

  • Zasoby procesora CPU i pamięci
  • Przepustowość operacji wejścia/wyjścia na sekundę (IOPS)
  • Możliwości sieci
  • Liczba dysków, które można dołączyć
  • Możliwość korzystania z niektórych typów magazynu platformy Azure

Aby uzyskać te informacje dla określonej rodziny i typu FM, zobacz Rozmiary maszyn wirtualnych na platformie Azure.

Modele cenowe dla maszyn wirtualnych platformy Azure

W przypadku modelu cen maszyny wirtualnej możesz wybrać opcję, której chcesz użyć:

  • Model cen płatności zgodnie z rzeczywistym użyciem
  • Roczny plan zarezerwowany lub oszczędnościowy
  • Trzyletni plan zarezerwowany lub oszczędnościowy
  • Model cen typu spot

Aby uzyskać szczegółowe informacje o cenach maszyn wirtualnych dla różnych usług platformy Azure, systemów operacyjnych i regionów, zobacz Cennik maszyn wirtualnych.

Aby dowiedzieć się więcej na temat cen i elastyczności planów oszczędnościowych i wystąpień zarezerwowanych w ciągu jednego roku i trzech lat, zobacz następujące artykuły:

Aby uzyskać więcej informacji na temat cen typu spot, zobacz Maszyny wirtualne typu spot platformy Azure.

Ceny dla tego samego typu maszyny wirtualnej mogą się różnić w zależności od regionów świadczenia usługi Azure. Niektórzy klienci korzystają z wdrażania w mniej kosztownym regionie świadczenia usługi Azure, więc informacje o cenach według regionów mogą być pomocne podczas planowania.

Platforma Azure oferuje również opcję użycia dedykowanego hosta. Użycie dedykowanego hosta zapewnia większą kontrolę nad cyklami stosowania poprawek dla usług platformy Azure. Możesz zaplanować stosowanie poprawek, aby obsługiwać własny harmonogram i cykle. Ta oferta jest przeznaczona specjalnie dla klientów, którzy mają obciążenie, które nie jest zgodne z normalnym cyklem obciążenia. Aby uzyskać więcej informacji, zobacz Dedykowane hosty platformy Azure.

Korzystanie z dedykowanego hosta platformy Azure jest obsługiwane w przypadku obciążenia SAP. Kilku klientów SAP, którzy chcą mieć większą kontrolę nad poprawkami infrastruktury i planami konserwacji, korzystają z dedykowanych hostów platformy Azure. Aby uzyskać więcej informacji na temat sposobu obsługi i stosowania poprawek infrastruktury platformy Azure hostujących maszyny wirtualne, zobacz Konserwacja maszyn wirtualnych na platformie Azure.

System operacyjny dla maszyn wirtualnych

Podczas wdrażania nowych maszyn wirtualnych dla środowiska SAP na platformie Azure w celu zainstalowania lub zmigrowania systemu SAP ważne jest wybranie prawidłowego systemu operacyjnego dla obciążenia. Platforma Azure oferuje duży wybór obrazów systemu operacyjnego dla systemów Linux i Windows oraz wiele odpowiednich opcji dla systemów SAP. Możesz również tworzyć lub przekazywać obrazy niestandardowe ze środowiska lokalnego albo używać lub uogólniać z galerii obrazów.

Aby uzyskać szczegółowe informacje o dostępnych opcjach i informacjach:

  • Znajdowanie obrazów witryny Azure Marketplace przy użyciu interfejsu wiersza polecenia platformy Azure lub programu Azure PowerShell.
  • Tworzenie niestandardowych obrazów dla systemu Linux lub Windows.
  • Użyj konstruktora obrazów maszyny wirtualnej.

W razie potrzeby zaplanuj infrastrukturę aktualizacji systemu operacyjnego i jej zależności dla obciążenia SAP. Rozważ użycie środowiska przejściowego repozytorium w celu zachowania synchronizacji wszystkich warstw środowiska SAP (piaskownicy, programowania, przedprodukcyjnego i produkcyjnego) przy użyciu tych samych wersji poprawek i aktualizacji w okresie aktualizacji.

Maszyny wirtualne generacji 1 i 2. generacji

Na platformie Azure można wdrożyć maszynę wirtualną jako generację 1 lub generację 2. Obsługa maszyn wirtualnych 2. generacji na platformie Azure zawiera listę rodzin maszyn wirtualnych platformy Azure , które można wdrożyć jako generację 2. W tym artykule wymieniono również różnice funkcjonalne między maszynami wirtualnymi generacji 1 i 2. generacji na platformie Azure.

Podczas wdrażania maszyny wirtualnej wybrany obraz systemu operacyjnego określa, czy maszyna wirtualna będzie maszyną wirtualną generacji 1, czy maszyną wirtualną 2. generacji. Najnowsze wersje wszystkich obrazów systemu operacyjnego sap, które są dostępne na platformie Azure (Red Hat Enterprise Linux, SuSE Enterprise Linux i Windows lub Oracle Enterprise Linux) są dostępne zarówno w generacji 1, jak i 2. Ważne jest, aby starannie wybrać obraz na podstawie opisu obrazu, aby wdrożyć poprawną generację maszyny wirtualnej. Podobnie można utworzyć niestandardowe obrazy systemu operacyjnego jako generację 1 lub 2. generacji i mieć wpływ na generację maszyny wirtualnej podczas wdrażania maszyny wirtualnej.

Uwaga

Zalecamy używanie maszyn wirtualnych generacji 2 we wszystkich wdrożeniach SAP na platformie Azure, niezależnie od rozmiaru maszyny wirtualnej. Wszystkie najnowsze maszyny wirtualne platformy Azure dla systemu SAP są z obsługą generacji 2 lub są ograniczone tylko do generacji 2. Niektóre rodziny maszyn wirtualnych obsługują obecnie tylko maszyny wirtualne generacji 2. Niektóre rodziny maszyn wirtualnych, które będą dostępne wkrótce, mogą obsługiwać tylko generację 2.

Można określić, czy maszyna wirtualna jest generacją 1, czy tylko generacją 2 na podstawie wybranego obrazu systemu operacyjnego. Nie można zmienić istniejącej maszyny wirtualnej z jednej generacji na inną generację.

Zmiana wdrożonej maszyny wirtualnej z generacji 1 na generację 2 nie jest możliwa na platformie Azure. Aby zmienić generację maszyny wirtualnej, należy wdrożyć nową maszynę wirtualną, która jest generacją, którą chcesz, i ponownie zainstalować oprogramowanie na nowej generacji maszyny wirtualnej. Ta zmiana dotyczy tylko podstawowego obrazu wirtualnego dysku twardego maszyny wirtualnej i nie ma wpływu na dyski danych ani dołączony system plików sieciowych (NFS) lub udziały bloku komunikatów serwera (SMB). Dyski danych, udziały NFS lub udziały SMB przypisane pierwotnie do maszyny wirtualnej generacji 1 mogą być dołączone do nowej maszyny wirtualnej generacji 2.

Niektóre rodziny maszyn wirtualnych, takie jak seria Mv2, obsługują tylko generację 2. To samo wymaganie może dotyczyć nowych rodzin maszyn wirtualnych w przyszłości. W tym scenariuszu nie można zmienić rozmiaru istniejącej maszyny wirtualnej generacji 1 w celu pracy z nową rodziną maszyn wirtualnych. Oprócz wymagań generacji 2 platformy Azure składniki SAP mogą mieć wymagania związane z generowaniem maszyny wirtualnej. Aby dowiedzieć się więcej o wszelkich wymaganiach generacji 2 dla wybranej rodziny maszyn wirtualnych, zobacz Sap Note 1928533.

Limity wydajności maszyn wirtualnych platformy Azure

Jako chmura publiczna platforma Azure zależy od udostępniania infrastruktury w bezpieczny sposób w całej bazie klientów. Aby włączyć skalowanie i pojemność, limity wydajności są definiowane dla każdego zasobu i usługi. Po stronie obliczeniowej infrastruktury platformy Azure należy wziąć pod uwagę limity zdefiniowane dla każdego rozmiaru maszyny wirtualnej.

Każda maszyna wirtualna ma inny limit przydziału przepływności dysku i sieci, liczbę dysków, które można dołączyć, niezależnie od tego, czy ma lokalny magazyn tymczasowy, który ma własną przepływność i limity liczby operacji we/wy na sekundę, rozmiar pamięci i liczbę dostępnych procesorów wirtualnych.

Uwaga

Podczas podejmowania decyzji dotyczących rozmiaru maszyny wirtualnej dla rozwiązania SAP na platformie Azure należy wziąć pod uwagę limity wydajności dla każdego rozmiaru maszyny wirtualnej. Przydziały opisane w dokumentacji reprezentują teoretycznie maksymalne możliwe do osiągnięcia wartości. Limit wydajności operacji we/wy na sekundę na dysk można osiągnąć przy użyciu małych wartości wejściowych/wyjściowych (na przykład 8 KB), ale może nie zostać osiągnięty przy użyciu dużych wartości we/wy (na przykład 1 MB).

Podobnie jak maszyny wirtualne, istnieją te same limity wydajności dla każdego typu magazynu dla obciążenia SAP i dla wszystkich innych usług platformy Azure.

Podczas planowania i wybierania maszyn wirtualnych do użycia we wdrożeniu sap należy wziąć pod uwagę następujące czynniki:

  • Zacznij od wymagań dotyczących pamięci i procesora CPU. Należy oddzielić wymagania sapS dotyczące zasilania procesora CPU w części DBMS i częściach aplikacji SAP. W przypadku istniejących systemów oprogramowanie SAPS związane ze sprzętem, którego używasz, często można określić lub oszacować na podstawie istniejących testów porównawczych aplikacji SAP Standard. W przypadku nowo wdrożonych systemów SAP wykonaj ćwiczenie dotyczące ustalania rozmiaru, aby określić wymagania systemu SAPS.

  • W przypadku istniejących systemów należy zmierzyć przepływność operacji we/wy i operacje we/wy na sekundę na serwerze DBMS. W przypadku nowych systemów ćwiczenie ustalania rozmiaru dla nowego systemu powinno również dać ogólne pojęcie wymagań we/wy po stronie systemu DBMS. Jeśli nie masz pewności, w końcu musisz przeprowadzić weryfikację koncepcji.

  • Porównaj wymagania systemu SAPS dla serwera DBMS z systemem SAPS, które mogą zapewnić różne typy maszyn wirtualnych platformy Azure. Informacje o systemie SAPS różnych typów maszyn wirtualnych platformy Azure są udokumentowane w artykule SAP Note 1928533. Najpierw należy skupić się na maszynie wirtualnej z systemem DBMS, ponieważ warstwa bazy danych jest warstwą w systemie SAP NetWeaver, który nie skaluje się w poziomie w większości wdrożeń. Natomiast warstwę aplikacji SAP można skalować w poziomie. Poszczególne przewodniki systemu DBMS opisują zalecane konfiguracje magazynu.

  • Podsumuj wyniki dla:

    • Liczba maszyn wirtualnych platformy Azure, które mają być używane.
    • Pojedyncza rodzina maszyn wirtualnych i jednostki SKU maszyn wirtualnych dla każdej warstwy SAP: DBMS, (A)SCS i serwer aplikacji.
    • Miary przepływności we/wy lub obliczone wymagania dotyczące pojemności magazynu.

Usługa dużych wystąpień platformy HANA

Platforma Azure oferuje możliwości obliczeniowe umożliwiające uruchamianie skalowanej w górę lub skalowanej w poziomie dużej bazy danych HANA w dedykowanej ofercie o nazwie SAP HANA w dużych wystąpieniach platformy Azure. Ta oferta rozszerza maszyny wirtualne, które są dostępne na platformie Azure.

Uwaga

Usługa HANA Large Instances jest w trybie zachodu słońca i nie akceptuje nowych klientów. Dostarczanie jednostek dla istniejących klientów dużych wystąpień HANA jest nadal możliwe.

Magazyn dla oprogramowania SAP na platformie Azure

Maszyny wirtualne platformy Azure używają różnych opcji magazynowania na potrzeby trwałości. Mówiąc prosto, maszyny wirtualne można podzielić na trwałe i tymczasowe lub nietrwale typy magazynów.

Możesz wybrać jedną z wielu opcji magazynowania dla obciążeń SAP i określonych składników SAP. Aby uzyskać więcej informacji, zobacz Azure Storage for SAP workloads (Usługa Azure Storage dla obciążeń SAP). W tym artykule opisano architekturę magazynu dla każdej części systemu operacyjnego SAP: system operacyjny, pliki binarne aplikacji, pliki konfiguracji, dane bazy danych, pliki dziennika i śledzenia oraz interfejsy plików z innymi aplikacjami, niezależnie od tego, czy są przechowywane na dysku, czy dostępne w udziałach plików.

Dysk tymczasowy na maszynach wirtualnych

Większość maszyn wirtualnych platformy Azure dla oprogramowania SAP oferuje dysk tymczasowy, który nie jest dyskiem zarządzanym. Użyj dysku tymczasowego tylko w przypadku danych, które można wydatnie. Dane na dysku tymczasowym mogą zostać utracone podczas nieprzewidzianych zdarzeń konserwacji lub podczas ponownego wdrażania maszyny wirtualnej. Cechy wydajności dysku tymczasowego sprawiają, że idealnie nadają się do plików wymiany/stronicowania systemu operacyjnego.

Na dysku tymczasowym nie powinny być przechowywane żadne niewytłumaczalne dane systemu operacyjnego. W środowiskach systemu Windows dysk tymczasowy jest zwykle uzyskiwany jako dysk D. W systemach Linux punkt instalacji często jest urządzeniem /dev/sdb, /mnt lub /mnt/resource.

Niektóre maszyny wirtualne nie oferują dysku tymczasowego. Jeśli planujesz używać tych rozmiarów maszyn wirtualnych dla oprogramowania SAP, może być konieczne zwiększenie rozmiaru dysku systemu operacyjnego. Aby uzyskać więcej informacji, zobacz sap Note 1928533. W przypadku maszyn wirtualnych, które mają dysk tymczasowy, uzyskaj informacje o tymczasowym rozmiarze dysku oraz limitach liczby operacji we/wy na sekundę i przepływności dla każdej serii maszyn wirtualnych w obszarze Rozmiary maszyn wirtualnych na platformie Azure.

Nie można bezpośrednio zmieniać rozmiaru między serią maszyn wirtualnych z dyskami tymczasowymi i serią maszyn wirtualnych, które nie mają dysków tymczasowych. Obecnie zmiana rozmiaru między dwiema takimi rodzinami maszyn wirtualnych kończy się niepowodzeniem. Rozwiązaniem jest ponowne utworzenie maszyny wirtualnej, która nie ma dysku tymczasowego w nowym rozmiarze przy użyciu migawki dysku systemu operacyjnego. Zachowaj wszystkie inne dyski danych i interfejs sieciowy. Dowiedz się, jak zmienić rozmiar maszyny wirtualnej z lokalnym dyskiem tymczasowym na rozmiar maszyny wirtualnej, który nie jest.

Udziały sieciowe i woluminy dla oprogramowania SAP

Systemy SAP zwykle wymagają co najmniej jednego sieciowego udziału plików. Udziały plików zazwyczaj są jedną z następujących opcji:

  • Katalog transportowy SAP (/usr/sap/trans lub TRANSDIR).
  • Woluminy SAP lub udostępnione woluminy sapmnt lub saploc w celu wdrożenia wielu serwerów aplikacji.
  • Woluminy architektury o wysokiej dostępności dla oprogramowania SAP (A)SCS, SAP ERS lub bazy danych (/hana/shared).
  • Interfejsy plików, które uruchamiają aplikacje innych firm na potrzeby importowania i eksportowania plików.

W tych scenariuszach zalecamy użycie usługi platformy Azure, takiej jak Azure Files lub Azure NetApp Files. Jeśli te usługi nie są dostępne w wybranym regionach lub jeśli nie są dostępne dla twojej architektury rozwiązania, alternatywą jest zapewnienie udziałów plików NFS lub SMB z aplikacji zarządzanych samodzielnie, aplikacji opartych na maszynach wirtualnych lub usług innych firm. Zobacz Sap Note 2015553 o ograniczeniach obsługi oprogramowania SAP, jeśli używasz usług innych firm na potrzeby warstw magazynowania w systemie SAP na platformie Azure.

Ze względu na często krytyczny charakter udziałów sieciowych i dlatego, że często są one pojedynczym punktem awarii w projekcie (w celu zapewnienia wysokiej dostępności) lub procesu (w przypadku interfejsu plików), zalecamy poleganie na każdej natywnej usłudze platformy Azure na potrzeby własnej dostępności, umowy SLA i odporności. W fazie planowania należy wziąć pod uwagę następujące czynniki:

  • Projekt udziału NFS lub SMB, w tym udziały używane na identyfikator systemu SAP (SID), poziome i region.
  • Ustalanie rozmiaru podsieci, w tym wymaganie dotyczące adresów IP dla prywatnych punktów końcowych lub dedykowanych podsieci dla usług, takich jak Azure NetApp Files.
  • Routing sieciowy do systemów SAP i połączonych aplikacji.
  • Korzystanie z publicznego lub prywatnego punktu końcowego dla usługi Azure Files.

Aby uzyskać informacje o wymaganiach i sposobie korzystania z udziału NFS lub SMB w scenariuszu wysokiej dostępności, zobacz Wysoka dostępność.

Uwaga

Jeśli używasz usługi Azure Files dla udziałów sieciowych, zalecamy użycie prywatnego punktu końcowego. W mało prawdopodobnym przypadku awarii strefowej klient systemu plików NFS automatycznie przekierowuje do strefy w dobrej kondycji. Nie musisz ponownie instalować udziałów NFS ani SMB na maszynach wirtualnych.

Zabezpieczenia środowiska SAP

Aby chronić obciążenie SAP na platformie Azure, należy zaplanować wiele aspektów zabezpieczeń:

  • Segmentacja sieci i zabezpieczenia każdej podsieci i interfejsu sieciowego.
  • Szyfrowanie w każdej warstwie w krajobrazie systemu SAP.
  • Rozwiązanie do obsługi tożsamości dla użytkowników końcowych i dostępu administracyjnego oraz usług logowania jednokrotnego.
  • Monitorowanie zagrożeń i operacji.

Tematy w tym rozdziale nie są wyczerpującą listą wszystkich dostępnych usług, opcji i alternatyw. Zawiera listę kilku najlepszych rozwiązań, które należy wziąć pod uwagę dla wszystkich wdrożeń SAP na platformie Azure. Istnieją inne aspekty, które należy uwzględnić w zależności od wymagań dotyczących przedsiębiorstwa lub obciążenia. Aby uzyskać więcej informacji na temat projektowania zabezpieczeń, zobacz następujące zasoby, aby uzyskać ogólne wskazówki dotyczące platformy Azure:

Zabezpieczanie sieci wirtualnych przy użyciu grup zabezpieczeń

Planowanie środowiska SAP na platformie Azure powinno obejmować pewien stopień segmentacji sieci z sieciami wirtualnymi i podsieciami przeznaczonymi tylko dla obciążeń SAP. Najlepsze rozwiązania dotyczące definicji podsieci opisano w temacie Sieć i inne przewodniki dotyczące architektury platformy Azure. Zalecamy używanie sieciowych grup zabezpieczeń z grupami zabezpieczeń w sieciowych grupach zabezpieczeń w celu zezwolenia na łączność przychodzącą i wychodzącą. Podczas projektowania grup ASG każda karta sieciowa na maszynie wirtualnej może być skojarzona z wieloma grupami ASG, dzięki czemu można tworzyć różne grupy. Na przykład utwórz grupę ASG dla maszyn wirtualnych DBMS, która zawiera wszystkie serwery baz danych w całym krajobrazie. Utwórz kolejną grupę ASG dla wszystkich maszyn wirtualnych (aplikacji i systemu DBMS) pojedynczego identyfikatora SID sap. W ten sposób można zdefiniować jedną regułę sieciowej grupy zabezpieczeń dla ogólnej grupy zabezpieczeń bazy danych i inną, bardziej szczegółową regułę tylko dla usługi ASG specyficznej dla identyfikatora SID.

Sieciowe grupy zabezpieczeń nie ograniczają wydajności za pomocą reguł zdefiniowanych dla sieciowej grupy zabezpieczeń. W celu monitorowania przepływu ruchu można opcjonalnie aktywować rejestrowanie przepływów sieciowej grupy zabezpieczeń z dziennikami ocenianymi przez zarządzanie zdarzeniami informacji (SIEM) lub system wykrywania włamań (IDS) wybranego do monitorowania i działania w przypadku podejrzanych działań sieciowych.

Napiwek

Aktywuj sieciowe grupy zabezpieczeń tylko na poziomie podsieci. Mimo że sieciowe grupy zabezpieczeń można aktywować zarówno na poziomie podsieci, jak i na poziomie karty sieciowej, aktywacja w obu grupach jest bardzo często przeszkodą w rozwiązywaniu problemów podczas analizowania ograniczeń ruchu sieciowego. Używaj sieciowych grup zabezpieczeń na poziomie karty sieciowej tylko w wyjątkowych sytuacjach i w razie potrzeby.

Prywatne punkty końcowe dla usług

Dostęp do wielu usług PaaS platformy Azure jest domyślnie uzyskiwany za pośrednictwem publicznego punktu końcowego. Mimo że punkt końcowy komunikacji znajduje się w sieci zaplecza platformy Azure, punkt końcowy jest udostępniany publicznemu Internetowi. Prywatne punkty końcowe to interfejs sieciowy wewnątrz własnej prywatnej sieci wirtualnej. Za pośrednictwem usługi Azure Private Link prywatny punkt końcowy projektuje usługę w sieci wirtualnej. Wybrane usługi PaaS są następnie prywatnie dostępne za pośrednictwem adresu IP wewnątrz sieci. W zależności od konfiguracji usługa może być potencjalnie ustawiona tak, aby komunikowała się tylko za pośrednictwem prywatnego punktu końcowego.

Użycie prywatnego punktu końcowego zwiększa ochronę przed wyciekiem danych i często upraszcza dostęp z sieci lokalnych i równorzędnych. W wielu sytuacjach routing sieciowy i proces otwierania portów zapory, które często są potrzebne dla publicznych punktów końcowych, jest uproszczony. Zasoby znajdują się już w sieci, ponieważ są one dostępne przez prywatny punkt końcowy.

Aby dowiedzieć się, które usługi platformy Azure oferują opcję korzystania z prywatnego punktu końcowego, zobacz Usługi dostępne w usłudze Private Link. W przypadku systemu plików NFS lub SMB z usługą Azure Files zalecamy, aby zawsze używać prywatnych punktów końcowych dla obciążeń SAP. Aby dowiedzieć się więcej o opłatach naliczanych za pomocą usługi, zobacz Cennik prywatnego punktu końcowego. Niektóre usługi platformy Azure mogą opcjonalnie obejmować koszt usługi. Te informacje są zawarte w informacjach o cenach usługi.

Szyfrowanie

W zależności od zasad firmy szyfrowanie poza opcjami domyślnymi na platformie Azure może być wymagane dla obciążeń SAP.

Szyfrowanie zasobów infrastruktury

Domyślnie dyski zarządzane i magazyn obiektów blob na platformie Azure są szyfrowane przy użyciu klucza zarządzanego przez platformę (PMK). Ponadto szyfrowanie byOK (Bring Your Own Key) dla dysków zarządzanych i magazynu obiektów blob jest obsługiwane w przypadku obciążeń SAP na platformie Azure. W przypadku szyfrowania dysków zarządzanych można wybrać jedną z różnych opcji, w zależności od wymagań dotyczących zabezpieczeń firmy. Opcje szyfrowania platformy Azure obejmują:

  • Szyfrowanie po stronie magazynu (SSE) PMK (SSE-PMK)
  • Klucz zarządzany przez klienta (SSE-CMK)
  • Podwójne szyfrowanie danych nieużywanych
  • Szyfrowanie oparte na hoście

Aby uzyskać więcej informacji, w tym opis usługi Azure Disk Encryption, zobacz porównanie opcji szyfrowania platformy Azure.

Uwaga

Obecnie nie używaj szyfrowania opartego na hoście na maszynie wirtualnej, która znajduje się w rodzinie maszyn wirtualnych z serii M podczas pracy z systemem Linux z powodu potencjalnego ograniczenia wydajności. Korzystanie z szyfrowania SSE-CMK dla dysków zarządzanych nie ma wpływu na to ograniczenie.

W przypadku wdrożeń SAP w systemach Linux nie używaj usługi Azure Disk Encryption. Usługa Azure Disk Encryption obejmuje szyfrowanie uruchomione wewnątrz maszyn wirtualnych SAP przy użyciu zestawów CMKs z usługi Azure Key Vault. W przypadku systemu Linux usługa Azure Disk Encryption nie obsługuje obrazów systemu operacyjnego używanych na potrzeby obciążeń SAP. Usługa Azure Disk Encryption może być używana w systemach Windows z obciążeniami SAP, ale nie łączy usługi Azure Disk Encryption z natywnym szyfrowaniem bazy danych. Zalecamy użycie szyfrowania natywnego bazy danych zamiast usługi Azure Disk Encryption. Aby uzyskać więcej informacji, zapoznaj się z następną sekcją.

Podobnie jak w przypadku szyfrowania dysków zarządzanych szyfrowanie usługi Azure Files magazynowanych (SMB i NFS) jest dostępne w przypadku zestawów PMKs lub CMKs.

W przypadku udziałów sieciowych SMB dokładnie przejrzyj zależności usługi Azure Files i systemu operacyjnego z wersjami protokołu SMB, ponieważ konfiguracja wpływa na obsługę szyfrowania podczas przesyłania.

Ważne

Znaczenie starannego planu przechowywania i ochrony kluczy szyfrowania, jeśli nie można przecenić szyfrowania zarządzanego przez klienta. Bez kluczy szyfrowania zaszyfrowane zasoby, takie jak dyski, są niedostępne i mogą prowadzić do utraty danych. Starannie rozważ ochronę kluczy i dostępu do kluczy tylko uprzywilejowanym użytkownikom lub usługom.

Szyfrowanie składników SAP

Szyfrowanie na poziomie SAP można oddzielić od dwóch warstw:

  • Szyfrowanie systemu DBMS
  • Szyfrowanie transportu

W przypadku szyfrowania systemu DBMS każda baza danych obsługiwana dla oprogramowania SAP NetWeaver lub wdrożenie SAP S/4HANA obsługuje szyfrowanie natywne. Przezroczyste szyfrowanie bazy danych jest całkowicie niezależne od szyfrowania infrastruktury, które jest na platformie Azure. Jednocześnie można używać szyfrowania SSE i bazy danych. W przypadku korzystania z szyfrowania lokalizacja, magazyn i bezpieczne przechowywanie kluczy szyfrowania są niezwykle ważne. Utrata kluczy szyfrowania prowadzi do utraty danych, ponieważ nie będzie można uruchomić ani odzyskać bazy danych.

Niektóre bazy danych mogą nie mieć metody szyfrowania bazy danych lub nie wymagają dedykowanego ustawienia do włączenia. W przypadku innych baz danych kopie zapasowe systemu DBMS mogą być szyfrowane niejawnie po aktywowaniu szyfrowania bazy danych. Zapoznaj się z następującą dokumentacją systemu SAP, aby dowiedzieć się, jak włączyć i używać przezroczystego szyfrowania bazy danych:

Skontaktuj się z dostawcą oprogramowania SAP lub dostawcą usługi DBMS, aby uzyskać pomoc techniczną dotyczącą sposobu włączania, używania lub rozwiązywania problemów z szyfrowaniem oprogramowania.

Ważne

Nie można przecenić, jak ważne jest, aby zachować ostrożny plan przechowywania i ochrony kluczy szyfrowania. Bez kluczy szyfrowania baza danych lub oprogramowanie SAP mogą być niedostępne i mogą utracić dane. Starannie zastanów się, jak chronić klucze. Zezwalaj na dostęp do kluczy tylko przez uprzywilejowanych użytkowników lub usług.

Szyfrowanie transportu lub komunikacji można stosować do połączeń programu SQL Server między aparatami SAP i systemem DBMS. Podobnie można szyfrować połączenia z warstwy prezentacji SAP (SAPGui secure network connection lub SNC) lub https połączenia z frontonem internetowym. Zapoznaj się z dokumentacją dostawcy aplikacji, aby włączyć szyfrowanie podczas przesyłania i zarządzać nim.

Monitorowanie zagrożeń i zgłaszanie alertów

Aby wdrożyć i używać rozwiązań do monitorowania zagrożeń i zgłaszania alertów, zacznij od korzystania z architektury organizacji. Usługi platformy Azure zapewniają ochronę przed zagrożeniami i widok zabezpieczeń, który można uwzględnić w ogólnym planie wdrożenia sap. Microsoft Defender dla Chmury spełnia wymagania dotyczące ochrony przed zagrożeniami. Defender dla Chmury zazwyczaj jest częścią ogólnego modelu ładu dla całego wdrożenia platformy Azure, a nie tylko dla składników SAP.

Aby uzyskać więcej informacji na temat rozwiązań do zarządzania zdarzeniami informacji o zabezpieczeniach (SIEM) i automatycznego reagowania na orkiestrację zabezpieczeń (SOAR), zobacz Rozwiązania usługi Microsoft Sentinel na potrzeby integracji z oprogramowaniem SAP.

Oprogramowanie zabezpieczające wewnątrz maszyn wirtualnych SAP

2808515 SAP Note dla systemów Linux i SAP Note 106267 dla systemu Windows opisują wymagania i najlepsze rozwiązania podczas korzystania ze skanerów wirusów lub oprogramowania zabezpieczającego na serwerach SAP. Zalecamy przestrzeganie zaleceń dotyczących oprogramowania SAP podczas wdrażania składników SAP na platformie Azure.

Wysoka dostępność

Wysoka dostępność oprogramowania SAP na platformie Azure ma dwa składniki:

  • Wysoka dostępność infrastruktury platformy Azure: wysoka dostępność zasobów obliczeniowych platformy Azure, sieci i usług magazynu oraz sposobu zwiększania dostępności aplikacji SAP.

  • Wysoka dostępność aplikacji SAP: jak można ją połączyć z wysoką dostępnością infrastruktury platformy Azure przy użyciu naprawy usługi. Przykład, który używa wysokiej dostępności w składnikach oprogramowania SAP:

    • Wystąpienie sap (A)SCS i SAP ERS
    • Serwer bazy danych

Aby uzyskać więcej informacji na temat wysokiej dostępności oprogramowania SAP na platformie Azure, zobacz następujące artykuły:

Program Pacemaker w systemie Linux i klaster trybu failover systemu Windows Server to jedyne platformy wysokiej dostępności dla obciążeń SAP, które są bezpośrednio obsługiwane przez firmę Microsoft na platformie Azure. Każda inna platforma wysokiej dostępności nie jest obsługiwana przez firmę Microsoft i będzie potrzebować pomocy technicznej dotyczącej projektowania, implementacji i operacji od dostawcy. Aby uzyskać więcej informacji, zobacz Obsługiwane scenariusze dotyczące oprogramowania SAP na platformie Azure.

Odzyskiwanie po awarii

Często aplikacje SAP należą do najbardziej krytycznych procesów biznesowych w przedsiębiorstwie. Na podstawie ich znaczenia i czasu wymaganego do ponownego działania po nieprzewidzianej przerwie należy dokładnie zaplanować scenariusze ciągłości działania i odzyskiwania po awarii (BCDR).

Aby dowiedzieć się, jak rozwiązać to wymaganie, zobacz Omówienie odzyskiwania po awarii i wytyczne dotyczące infrastruktury dla obciążenia SAP.

Wykonywanie kopii zapasowej

W ramach strategii BCDR tworzenie kopii zapasowych dla obciążenia SAP musi być integralną częścią każdego planowanego wdrożenia. Rozwiązanie do tworzenia kopii zapasowych musi obejmować wszystkie warstwy stosu rozwiązania SAP: maszyny wirtualnej, systemu operacyjnego, warstwy aplikacji SAP, warstwy DBMS i dowolnego rozwiązania magazynu udostępnionego. Tworzenie kopii zapasowych usług platformy Azure używanych przez obciążenie SAP oraz innych kluczowych zasobów, takich jak szyfrowanie i klucze dostępu, również musi być częścią projektu kopii zapasowej i bcDR.

Usługa Azure Backup oferuje rozwiązania PaaS do tworzenia kopii zapasowych:

  • Konfiguracja maszyny wirtualnej, system operacyjny i warstwa aplikacji SAP (zmiana rozmiaru danych na dyskach zarządzanych) za pomocą usługi Azure Backup dla maszyny wirtualnej. Zapoznaj się z macierzą obsługi, aby sprawdzić, czy twoja architektura może używać tego rozwiązania.
  • Sql Server i SAP HANA database data and log backup (Dane bazy danych i kopia zapasowa dziennika sap HANA ). Obejmuje ona obsługę technologii replikacji bazy danych, takich jak replikacja systemu HANA lub zawsze włączone sql, oraz obsługa między regionami dla sparowanych regionów.
  • Tworzenie kopii zapasowej udziału plików za pośrednictwem usługi Azure Files. Sprawdź obsługę systemu plików NFS lub SMB i innych szczegółów konfiguracji.

Alternatywnie, jeśli wdrożysz usługę Azure NetApp Files, opcje tworzenia kopii zapasowych są dostępne na poziomie woluminu, w tym integrację oprogramowania SAP HANA i Oracle DBMS z zaplanowaną kopią zapasową.

Rozwiązania usługi Azure Backup oferują opcję usuwania nietrwałego, aby zapobiec złośliwemu lub przypadkowemu usunięciu i zapobiec utracie danych. Usuwanie nietrwałe jest również dostępne dla udziałów plików wdrażanych przy użyciu usługi Azure Files.

Opcje tworzenia kopii zapasowych są dostępne dla rozwiązania, które samodzielnie tworzysz i zarządzasz, lub jeśli używasz oprogramowania innej firmy. Opcja polega na korzystaniu z usług w usłudze Azure Storage, w tym przy użyciu niezmiennego magazynu dla danych obiektów blob. Ta opcja samozarządzana jest obecnie wymagana jako opcja tworzenia kopii zapasowej programu DBMS dla niektórych baz danych, takich jak SAP ASE lub IBM Db2.

Skorzystaj z zaleceń w najlepszych rozwiązaniach platformy Azure, aby chronić i weryfikować ataki wymuszającego okup .

Napiwek

Upewnij się, że strategia tworzenia kopii zapasowych obejmuje ochronę automatyzacji wdrażania, kluczy szyfrowania dla zasobów platformy Azure i przezroczystego szyfrowania bazy danych, jeśli jest używana.

Kopia zapasowa między regionami

W przypadku dowolnego wymagania dotyczącego tworzenia kopii zapasowych między regionami określ cel czasu odzyskiwania (RTO) i cel punktu odzyskiwania (RPO), który jest oferowany przez rozwiązanie i czy jest zgodny z projektem i potrzebami bcDR.

Migracja oprogramowania SAP na platformę Azure

Nie można opisać wszystkich metod migracji i opcji dla wielu różnych produktów SAP, zależności wersji i natywnych systemów operacyjnych i technologii DBMS, które są dostępne. Zespół projektu dla twojej organizacji i przedstawicieli po stronie dostawcy usług powinien rozważyć kilka technik bezproblemowej migracji sap na platformę Azure.

  • Testowanie wydajności podczas migracji. Ważnym elementem planowania migracji sap jest testowanie wydajności techniczne. Zespół ds. migracji musi zapewnić wystarczający czas i dostępność dla personelu kluczowego do uruchamiania aplikacji i testowania technicznego zmigrowanego systemu SAP, w tym połączonych interfejsów i aplikacji. W przypadku pomyślnej migracji sap kluczowe jest porównanie premigration i po migracji środowiska uruchomieniowego oraz dokładności kluczowych procesów biznesowych w środowisku testowym. Użyj tych informacji, aby zoptymalizować procesy przed migracją środowiska produkcyjnego.

  • Korzystanie z usług platformy Azure na potrzeby migracji systemu SAP. Niektóre obciążenia oparte na maszynach wirtualnych są migrowane bez zmiany na platformę Azure przy użyciu usług takich jak Azure Migrate lub Azure Site Recovery lub narzędzie innej firmy. Sumiennie upewnij się, że wersja systemu operacyjnego i uruchomione przez niego obciążenie SAP są obsługiwane przez usługę.

    Często żadne obciążenie bazy danych nie jest celowo obsługiwane, ponieważ usługa nie może zagwarantować spójności bazy danych. Jeśli typ DBMS jest obsługiwany przez usługę migracji, zmiana bazy danych lub współczynnik zmian często jest zbyt wysoka. Większość zajętych systemów SAP nie spełnia współczynnika zmian dozwolonych przez narzędzia migracji. Problemy mogą nie być widoczne lub odnalezione do czasu migracji produkcyjnej. W wielu sytuacjach niektóre usługi platformy Azure nie są odpowiednie do migrowania systemów SAP. Usługa Azure Site Recovery i usługa Azure Migrate nie mają walidacji migracji sap na dużą skalę. Sprawdzona metodologia migracji sap polega na replikacji systemu DBMS lub narzędziach do migracji sap.

    Wdrożenie na platformie Azure zamiast podstawowej migracji maszyny wirtualnej jest preferowane i łatwiejsze niż migracja lokalna. Zautomatyzowane struktury wdrażania, takie jak Azure Center dla rozwiązań SAP i struktura automatyzacji wdrażania platformy Azure, umożliwiają szybkie wykonywanie zautomatyzowanych zadań. Aby przeprowadzić migrację środowiska SAP do nowej wdrożonej infrastruktury przy użyciu natywnych technologii replikacji systemu DBMS, takich jak replikacja systemu HANA, tworzenie kopii zapasowych i przywracanie systemu DBMS, lub narzędzia migracji SAP używają ustalonej wiedzy technicznej na temat systemu SAP.

  • Skalowanie infrastruktury w górę. Podczas migracji systemu SAP posiadanie większej pojemności infrastruktury może pomóc w szybkim wdrożeniu. Zespół projektu powinien rozważyć skalowanie w górę rozmiaru maszyny wirtualnej, aby zapewnić więcej procesora CPU i pamięci. Zespół powinien również rozważyć skalowanie w górę magazynu zagregowanego maszyny wirtualnej i przepływności sieci. Podobnie na poziomie maszyny wirtualnej rozważ elementy magazynu, takie jak poszczególne dyski, aby zwiększyć przepływność dzięki warstwom zwiększania wydajności i zwiększania wydajności dla dysków SSD w warstwie Premium w wersji 1. Zwiększ liczbę operacji we/wy na sekundę i przepływność, jeśli używasz dysków SSD w warstwie Premium w wersji 2 powyżej skonfigurowanych wartości. Zwiększ udziały plików NFS i SMB, aby zwiększyć limity wydajności. Należy pamiętać, że nie można zmniejszyć rozmiaru dysków zarządzanych przez platformę Azure, a zmniejszenie rozmiaru, warstw wydajności i wskaźników KPI przepływności może mieć różne czasy ochładzania.

  • Optymalizowanie kopiowania danych i sieci. Migrowanie systemu SAP na platformę Azure zawsze wiąże się z przenoszeniem dużej ilości danych. Dane mogą być kopiami zapasowymi bazy danych i plików lub replikacją, transferem danych aplikacji do aplikacji lub eksportem migracji sap. W zależności od używanego procesu migracji należy wybrać poprawną ścieżkę sieci, aby przenieść dane. W przypadku wielu operacji przenoszenia danych użycie Internetu zamiast sieci prywatnej jest najszybszą ścieżką do bezpiecznego kopiowania danych do usługi Azure Storage.

    Korzystanie z usługi ExpressRoute lub sieci VPN może prowadzić do wąskich gardeł:

    • Dane migracji używają zbyt dużej przepustowości i zakłócają dostęp użytkowników do obciążeń uruchomionych na platformie Azure.
    • Wąskie gardła sieci lokalnej, takie jak ograniczenie zapory lub przepływności, często są wykrywane tylko podczas migracji.

    Niezależnie od używanego połączenia sieciowego wydajność sieci pojedynczego strumienia dla przenoszenia danych często jest niska. Aby zwiększyć szybkość transferu danych w wielu strumieniach TCP, użyj narzędzi, które mogą obsługiwać wiele strumieni. Zastosuj techniki optymalizacji opisane w dokumentacji systemu SAP i w wielu wpisach w blogu w tym temacie.

Napiwek

Na etapie planowania ważne jest, aby wziąć pod uwagę wszystkie dedykowane sieci migracji, które będą używane do dużych transferów danych na platformę Azure. Przykłady obejmują kopie zapasowe lub replikację bazy danych lub użycie publicznego punktu końcowego na potrzeby transferu danych do usługi Azure Storage. Należy oczekiwać i ograniczyć wpływ migracji na ścieżki sieciowe dla użytkowników i aplikacji. W ramach planowania sieci należy wziąć pod uwagę wszystkie fazy migracji i koszty częściowo produktywnego obciążenia na platformie Azure podczas migracji.

Obsługa i operacje dla oprogramowania SAP

Kilka innych obszarów należy wziąć pod uwagę przed wdrożeniem sap i podczas wdrażania na platformie Azure.

Rozszerzenie maszyny wirtualnej platformy Azure dla oprogramowania SAP

Rozszerzenie monitorowania platformy Azure, rozszerzone monitorowanie i rozszerzenie platformy Azure dla oprogramowania SAP odwołują się do rozszerzenia maszyny wirtualnej, które należy wdrożyć, aby udostępnić podstawowe dane dotyczące infrastruktury platformy Azure agentowi hosta SAP. Uwagi SAP mogą odnosić się do rozszerzenia jako rozszerzenia monitorowania lub rozszerzonego monitorowania. Na platformie Azure jest to rozszerzenie platformy Azure dla oprogramowania SAP. W celach pomocy technicznej rozszerzenie musi być zainstalowane na wszystkich maszynach wirtualnych platformy Azure z obciążeniem SAP. Aby dowiedzieć się więcej, zobacz Rozszerzenie maszyny wirtualnej platformy Azure dla oprogramowania SAP.

Program SAProuter na potrzeby obsługi oprogramowania SAP

Obsługa środowiska SAP na platformie Azure wymaga łączności z oprogramowaniem SAP i z systemu SAP do celów pomocy technicznej. Zazwyczaj łączność jest w formie połączenia SAProuter, jeśli odbywa się za pośrednictwem kanału sieciowego szyfrowania przez Internet lub za pośrednictwem prywatnego połączenia SIECI VPN z oprogramowaniem SAP. Aby uzyskać najlepsze rozwiązania i przykładową implementację programu SAProuter na platformie Azure, zobacz scenariusz architektury w artykule Przychodzące i wychodzące połączenia internetowe dla oprogramowania SAP na platformie Azure.

Następne kroki