Azure spotyka SAP: SAP na Azure wyjaśnione dla Microsoft Teams

By Mirko Peters · 2026-11-05

Co naprawdę oznacza uruchamianie SAP w Microsoft Azure: certyfikowane maszyny wirtualne i pamięć masową, strefę docelową (landing zone), którą buduje się najpierw, łączność hybrydową, trzy ścieżki wdrożenia oraz błędy, które sprawiają, że wspierany system SAP staje się niewspierany.

Automatically translated with AI from the original post. Read the English original

Jako Microsoft MVP najwięcej czasu spędzam z ludźmi, którzy doskonale znają Azure, Entra ID i Microsoft 365, a nagle słyszą prośbę, by "wesprzeć przeniesienie SAP". Wielu z nich SAP wydaje się odrębnym światem z własnym słownictwem. Dobra wiadomość jest taka, że SAP na Azure jest znacznie zwyczajniejszy, niż brzmi. Sprowadza się do dwóch zasad: pozostań w certyfikowanych konfiguracjach i zbuduj fundament, zanim pojawi się pierwszy system SAP. Ten wpis omawia obie, w kolejności, w jakiej faktycznie wykonuje się te prace.

Co naprawdę oznacza SAP na Azure

SAP na Azure oznacza, że systemy SAP działają w Microsoft Azure. Baza danych SAP HANA, serwery aplikacyjne i usługi centralne znajdują się na maszynach wirtualnych Azure i korzystają z pamięci masowej oraz sieci Azure. Samo oprogramowanie SAP się nie zmienia: SAP S/4HANA nadal jest S/4HANA, a SAP NetWeaver nadal jest NetWeaverem. Zmienia się wyłącznie podłoże.

Ten podział pokazuje, kto za co odpowiada. Microsoft zapewnia platformę: maszyny wirtualne, dyski, sieci, tożsamość i monitorowanie. SAP dostarcza aplikację i bazę danych, a wy eksploatujecie je zgodnie z oczekiwaniami SAP. Punktem styku obu stron jest certyfikowana infrastruktura pośrodku.

Warto odróżnić to od pokrewnego tematu. Kopiowanie danych SAP do Azure na potrzeby raportów w Power BI lub Microsoft Fabric to integracja danych – przydatne, ale inne zadanie. Uruchamianie SAP na Azure oznacza, że sam system produkcyjny znajduje się tam, przetwarza tam swoje transakcje i obsługuje z tego miejsca swoich użytkowników.

Jeśli najpierw chcesz poznać szerszy obraz rodziny produktów SAP, strona tematyczna SAP na M365.FM zbiera nasze powiązane treści.

Dlaczego "certyfikowane" rozstrzyga wszystko

W świecie SAP stwierdzenie "działa na Azure" naprawdę oznacza "działa na certyfikowanym Azure". SAP i Microsoft testują konkretne typy maszyn wirtualnych i opcje pamięci masowej pod kątem określonych produktów i scenariuszy SAP, a wspierane są wyłącznie te kombinacje. Microsoft dokumentuje certyfikaty i konfiguracje SAP dla Azure oraz oprogramowanie SAP wspierane na Azure. Dla SAP HANA miarodajną listą jest własny SAP HANA Hardware Directory; dla systemów opartych na NetWeaver notatka SAP 1928533 zawiera listę wspieranych typów maszyn wirtualnych Azure.

Certyfikacja nie jest cechą całego Azure. Jest cechą konkretnej maszyny wirtualnej, konkretnej opcji pamięci masowej i konkretnego scenariusza SAP, dobranych razem. Hojnie wyposażona maszyna wirtualna, idealna dla aplikacji webowej, może po prostu nie znajdować się na liście dla HANA. Jeśli mimo to ją wybierzesz, nie zaoszczędzisz pieniędzy – zbudujesz system, za który żaden z dostawców nie będzie chciał odpowiadać.

Storage działa według tej samej logiki. Azure managed disks to codzienny element podstawowy, Azure NetApp Files zapewnia magazyn NFS wykorzystywany w kilku architekturach SAP, a Azure Files na pamięci premium (SSD) może hostować udziały katalogów. Tańszy standardowy poziom Azure Files nie jest obsługiwany dla udziałów wysokiej dostępności usług centralnych SAP, więc tania opcja jest tutaj złym wyborem. Microsoft wymienia te ograniczenia w obsługiwanych scenariuszach dla obciążeń SAP na maszynach wirtualnych Azure.

Nawyk, który zapobiega większości problemów: zanim dobierzesz rozmiar choćby jednej maszyny, otwórz listę certyfikowanych konfiguracji dla swojego produktu SAP i scenariusza i projektuj zgodnie z nią.

Landing zone, który budujesz najpierw

Azure landing zone to fundament, który zapewnia każdemu obciążeniu tożsamość, sieć, bezpieczeństwo i zarządzanie, zanim cokolwiek zostanie w nim wdrożone. Cloud Adoption Framework firmy Microsoft dzieli go na dwie części:

• Platform landing zone: wspólna baza z grupami zarządzania, centralną łącznością, usługami tożsamości, bezpieczeństwa i zarządzania.
• Application (workload) landing zones: poszczególne środowiska, zazwyczaj deweloperskie, testowe i produkcyjne, każde złożone z subskrypcji, które dziedziczą zabezpieczenia platformy.

Dla SAP ma to większe znaczenie niż dla większości obciążeń, ponieważ SAP obsługuje finanse, łańcuch dostaw i operacje. Zasady, reguły sieciowe i tożsamość powinny istnieć, zanim wdrożysz pierwszy system SAP. Dodawanie ich później oznacza przenoszenie zasobów w działającym systemie biznesowym.

Microsoft oferuje akcelerator landing zone SAP on Azure z referencyjnymi projektami opartymi na topologii sieci typu hub-and-spoke lub Azure Virtual WAN. Azure Policy i hierarchia grup zarządzania wyznaczają zabezpieczenia, a każdy system SAP trafia następnie właśnie w ich ramy. Dzięki temu drugi i trzeci system SAP mogą pojawić się bez ponownej dyskusji o nazewnictwie, dostępie i regułach sieciowych.

Utrzymywanie łączności SAP z centrum danych

Przeniesienie SAP do Azure rzadko oznacza pozostawienie wszystkiego za sobą. Większość krajobrazów pozostaje hybrydowa przez długi czas, dlatego łączność spina je w całość.

Główną prywatną opcją jest Azure ExpressRoute, dedykowane prywatne połączenie między centrum danych a Azure, zamiast ruchu przez publiczny internet. Tam, gdzie ExpressRoute jest niedostępny, alternatywą jest połączenie site-to-site VPN. W obu przypadkach połączenie zwykle kończy się w centralnym hubie lub Virtual WAN, a sieć wirtualna SAP łączy się z nim stamtąd. Wewnątrz Azure typowa architektura SAP oddziela warstwy aplikacji i bazy danych w osobnych podsieciach, chronionych przez grupy zabezpieczeń sieci, tabele tras i zaporę.

Tożsamości warto przyjrzeć się uważnie, ponieważ tu zespoły Microsoft często przyjmują błędne założenia. Microsoft Entra ID doskonale sprawdza się w logowaniu jednokrotnym (SSO) do aplikacji SAP. Systemy SAP NetWeaver i S/4HANA działające na Windows nie korzystają jednak z kont Entra ID w samej aplikacji SAP. Nadal wymagają Active Directory Domain Services, rozszerzonego z infrastruktury lokalnej lub dostarczonego przez Microsoft Entra Domain Services. Logowanie i katalog systemu operacyjnego to dwie różne sprawy.

Trzy opcje wdrożenia

Nie ma jednego właściwego sposobu wdrożenia SAP w Azure. Wybierz ścieżkę zgodną z tym, jak działa Twój zespół.

1. Zwykłe maszyny wirtualne Azure. Sam zarządzasz systemem operacyjnym, instalacją SAP, poprawkami i monitoringiem. Maksymalna kontrola, maksymalna praca. Dobrze sprawdza się, gdy wiedza o SAP i Azure jest dostępna w zespole.
2. Azure Center for SAP solutions. Usługa platformy Azure, która traktuje SAP jako obciążenie najwyższego poziomu. Może utworzyć infrastrukturę i zainstalować oprogramowanie SAP dla systemów na jednym serwerze, systemów rozproszonych oraz rozproszonych z wysoką dostępnością, a także zarejestrować systemy SAP, które już działają na platformie Azure. Każdy system staje się Virtual Instance for SAP solutions, logicznym widokiem SID, usług centralnych, serwera bazy danych i serwerów aplikacji. Stamtąd można sprawdzić kondycję i stan systemu, uruchamiać i zatrzymywać go, wykonywać kontrole jakości zgodne z najlepszymi praktykami oraz monitorować dane. Szczegóły znajdziesz w omówieniu Azure Center for SAP solutions.
3. SAP on Azure deployment automation framework. Otwartoźródłowe podejście infrastruktury jako kodu dla zespołów, które chcą powtarzalnych, wersjonowanych wdrożeń i procesu DevOps.

Prosta zasada decyzyjna: pełna kontrola i silne kompetencje wskazują na zwykłe maszyny wirtualne; prowadzona konfiguracja z jednym miejscem do zarządzania systemem wskazuje na Azure Center for SAP solutions; wiele systemów wdrażanych w ten sam sposób wskazuje na framework automatyzacji.

Najczęstsze błędy

Najbardziej bolesne pierwsze migracje mają wspólny schemat: krok, który wydawał się opcjonalny.

• Traktowanie certyfikacji jako formalności. Niecertyfikowana maszyna wirtualna lub typ pamięci masowej zamienia wspierany system w niewspierany, a zwykle dowiadujesz się o tym w najgorszym możliwym momencie.
• Pominięcie landing zone. Zdanie „dodamy zarządzanie później” rzadko się sprawdza, a dopasowywanie reguł tożsamości i sieci wokół działającego systemu SAP jest powolne i ryzykowne.
• Założenie, że Entra ID zastępuje Active Directory w systemach SAP opartych na Windows. Tak nie jest.
• Projektowanie łączności na końcu. Rozdzielenie warstwy aplikacji SAP i warstwy bazy danych między środowiskiem lokalnym a platformą Azure lub między regionami Azure nie jest obsługiwane.
• Założenie, że wszystko działa na platformie Azure. Azure VMware Solution generalnie nie jest obsługiwaną platformą do hostowania obciążeń SAP, a SAP HANA Large Instances nie są już oferowane nowym klientom.
• Używanie Azure Site Recovery dla bazy danych. Azure Site Recovery nie jest obsługiwane dla warstwy bazy danych SAP; do odzyskiwania po awarii użyj natywnej replikacji bazy danych, na przykład SAP HANA System Replication.

Każdy z tych punktów to miejsce, w którym granice wsparcia Microsoft i SAP przestają się pokrywać. Te ograniczenia nie istnieją po to, by Cię spowalniać; wyznaczają obszar, za który oba podmioty wezmą odpowiedzialność za Twój system.

Podsumowanie: kolejność działań

Jeśli masz zapamiętać jedną rzecz, zapamiętaj kolejność. Określ, czego system SAP potrzebuje pod względem wydajności, dostępności i odzyskiwania. Zbuduj landing zone. Połącz sieć i katalog z centrum danych. Wybierz stopień zarządzania: zwykłe maszyny wirtualne, Azure Center for SAP solutions lub framework automatyzacji. Wybierz certyfikowane zasoby obliczeniowe i pamięć masową. Następnie zaprojektuj wysoką dostępność i odzyskiwanie po awarii, opierając się na możliwościach samej bazy danych.

Nie musisz przenosić wszystkiego naraz. Zaczęcie od jednego systemu pokazuje, gdzie landing zone jest słaby i gdzie zespół potrzebuje wsparcia, dopóki stawka jest wciąż niewielka. Dla specjalistów Microsoft SAP na platformie Azure nie jest obcym światem. To zestaw zwyczajnych decyzji inżynierskich, z certyfikacją jako jedyną zasadą, której nigdy nie łamiesz.