Zagadnienia dotyczące wdrażania usługi Azure Virtual Machines DBMS dla obciążenia SAP

  • Artykuł

Ten przewodnik jest częścią dokumentacji dotyczącej wdrażania i wdrażania oprogramowania SAP na platformie Microsoft Azure. Zanim zapoznasz się z tym przewodnikiem, przeczytaj przewodnik planowania i implementacji oraz artykuły z przewodnikiem planowania. W tym dokumencie omówiono ogólne aspekty wdrażania systemów DBMS związanych z oprogramowaniem SAP na maszynach wirtualnych platformy Microsoft Azure przy użyciu funkcji infrastruktury jako usługi (IaaS) platformy Azure.

Dokument uzupełnia dokumentację instalacji sap i uwagi SAP, które reprezentują podstawowe zasoby dotyczące instalacji i wdrożeń oprogramowania SAP na określonych platformach.

W tym dokumencie przedstawiono zagadnienia dotyczące uruchamiania systemów DBMS związanych z oprogramowaniem SAP na maszynach wirtualnych platformy Azure. W tym dokumencie znajduje się kilka odwołań do określonych systemów DBMS. Zamiast tego określone systemy DBMS są obsługiwane w innych dokumentach specyficznych dla systemu bazy danych.

Zasoby

Na platformie Azure są dostępne inne artykuły dotyczące obciążenia SAP. Zacznij od obciążenia SAP na platformie Azure: rozpocznij pracę, a następnie wybierz swój obszar zainteresowania.

Poniższe uwagi SAP są związane z oprogramowaniem SAP na platformie Azure w odniesieniu do obszaru omówionego w tym dokumencie.

Numer notatki Stanowisko
1928533 Aplikacje SAP na platformie Azure: obsługiwane produkty i typy maszyn wirtualnych platformy Azure
2015553 Oprogramowanie SAP na platformie Microsoft Azure: wymagania wstępne dotyczące pomocy technicznej
1999351 Rozwiązywanie problemów z rozszerzonym monitorowaniem platformy Azure dla oprogramowania SAP
2178632 Kluczowe metryki monitorowania oprogramowania SAP na platformie Microsoft Azure
1409604 Wirtualizacja w systemie Windows: rozszerzone monitorowanie
2191498 Oprogramowanie SAP w systemie Linux z platformą Azure: ulepszone monitorowanie
2039619 Aplikacje SAP na platformie Microsoft Azure przy użyciu bazy danych Oracle: obsługiwane produkty i wersje
2233094 DB6: Aplikacje SAP na platformie Azure korzystające z programu IBM DB2 dla systemu Linux, system UNIX i Windows: dodatkowe informacje
2243692 Maszyna wirtualna Z systemem Linux na platformie Microsoft Azure (IaaS): problemy z licencjami sap
2578899 SUSE Linux Enterprise Server 15: Uwaga dotycząca instalacji
1984787 SUSE LINUX Enterprise Server 12: Informacje o instalacji
2772999 Red Hat Enterprise Linux 8.x: instalacja i konfiguracja
2002167 Red Hat Enterprise Linux 7.x: instalacja i uaktualnienie
2069760 Instalacja i uaktualnianie oprogramowania Oracle Linux 7.x SAP
1597355 Zalecenie dotyczące zamiany miejsca dla systemu Linux
2799900 Central Technical Note for Oracle Database 19c (Central Technical Note for Oracle Database 19c)
2171857 Oracle Database 12c: obsługa systemu plików w systemie Linux
1114181 Oracle Database 11g: obsługa systemu plików w systemie Linux
2969063 Weryfikacja mikrokodu nie powiodła się w narzędziu HCMT na platformie Azure
3246210 Azure — NARZĘDZIE HCMT kończy się niepowodzeniem podczas niektórych testów wydajnościowych dysku

Aby uzyskać informacje na temat wszystkich notatek SAP dla systemu Linux, zobacz witrynę typu wiki społeczności SAP.

Potrzebujesz działającej wiedzy na temat architektury platformy Microsoft Azure oraz sposobu wdrażania i obsługi maszyn wirtualnych platformy Microsoft Azure. Aby uzyskać więcej informacji, zobacz dokumentację platformy Azure.

Ogólnie rzecz biorąc, instalacja i konfiguracja systemu Windows, Linux i DBMS są zasadniczo takie same jak każda maszyna wirtualna lub maszyna bez systemu operacyjnego instalowana lokalnie. Istnieją pewne decyzje dotyczące architektury i wdrażania zarządzania systemem, które różnią się w przypadku korzystania z usługi Azure IaaS. W tym dokumencie opisano konkretne różnice w zarządzaniu architekturą i systemem, które należy przygotować podczas korzystania z usługi Azure IaaS.

Struktura magazynu maszyny wirtualnej dla wdrożeń programu RDBMS

Aby postępować zgodnie z tym rozdziałem, przeczytaj i zapoznaj się z informacjami przedstawionymi w:

W przypadku magazynu blokowego platformy Azure użycie dysków zarządzanych platformy Azure jest obowiązkowe. Aby uzyskać szczegółowe informacje na temat dysków zarządzanych platformy Azure, przeczytaj artykuł Wprowadzenie do dysków zarządzanych dla maszyn wirtualnych platformy Azure.

W podstawowej konfiguracji zwykle zalecamy strukturę wdrażania, w której system operacyjny, system DBMS i ostateczne pliki binarne SAP są oddzielone od plików bazy danych. Zalecamy posiadanie oddzielnych dysków platformy Azure dla:

  • System operacyjny (podstawowy dysk VHD lub dysk VHD systemu operacyjnego)
  • Pliki wykonywalne systemu zarządzania bazami danych
  • Pliki wykonywalne SAP, takie jak /usr/sap
  • Pliki danych programu DBMS
  • Pliki dziennika ponownego wdrażania systemu DBMS

Konfiguracja, która oddziela te składniki na pięć różnych woluminów, może spowodować większą odporność, ponieważ nadmierne użycie na jednym woluminie nie musi zakłócać użycia innych woluminów, o ile limity przydziału i limity magazynu maszyny wirtualnej nie są przekraczane.

Dane systemu DBMS i pliki dziennika transakcji/ponownego przechowywania są przechowywane w magazynie blokowym pomoc techniczna platformy Azure lub w usłudze Azure NetApp Files. Usługa Azure Files lub Azure Premium Files nie jest obsługiwana jako magazyn dla danych DBSM i/lub ponownie plików dziennika z obciążeniem SAP. Są one przechowywane na oddzielnych dyskach i dołączone jako dyski logiczne do oryginalnej maszyny wirtualnej obrazu systemu operacyjnego Platformy Azure. W przypadku wdrożeń systemu Linux udokumentowane są różne zalecenia. Przeczytaj artykuł Azure Storage types for SAP workload for the capabilities and the support of the different storage types for your scenario (Typy usługi Azure Storage dla obciążenia SAP), aby zapoznać się z możliwościami i obsługą różnych typów magazynów dla danego scenariusza. W szczególności w przypadku platformy SAP HANA zacznij od artykułu Konfiguracje magazynu maszyn wirtualnych platformy Azure sap HANA.

Podczas planowania układu dysku znajdź najlepszą równowagę między tymi elementami:

  • Liczba plików danych.
  • Liczba dysków zawierających pliki.
  • Limity przydziału operacji we/wy na sekundę dla pojedynczego dysku lub udziału NFS.
  • Przepływność danych na dysk lub udział NFS.
  • Liczba dodatkowych dysków danych możliwych na rozmiar maszyny wirtualnej.
  • Ogólna przepływność magazynu lub sieci, która może zapewnić maszyna wirtualna.
  • Opóźnienia różnych typów usługi Azure Storage mogą być dostępne.
  • Liczba operacji we/wy na sekundę magazynu maszyn wirtualnych i limit przydziału przepływności.
  • Limit przydziału sieci maszyny wirtualnej w przypadku korzystania z systemu plików NFS — ruch do udziałów NFS jest liczony z limitem przydziału sieci maszyny wirtualnej, a nie limitem przydziału magazynu.
  • Umowy SLA maszyn wirtualnych.

Platforma Azure wymusza limit przydziału operacji we/wy na sekundę na dysk danych lub udział NFS. Te limity przydziału różnią się w przypadku dysków hostowanych w różnych rozwiązaniach magazynu blokowego platformy Azure lub udziałach. Opóźnienie we/wy różni się również między tymi różnymi typami magazynu.

Każdy z różnych typów maszyn wirtualnych ma ograniczoną liczbę dysków danych, które można dołączyć. Innym ograniczeniem jest to, że tylko niektóre typy maszyn wirtualnych mogą używać, na przykład magazynu w warstwie Premium. Zazwyczaj decydujesz się na użycie określonego typu maszyny wirtualnej na podstawie wymagań dotyczących procesora CPU i pamięci. Należy również wziąć pod uwagę wymagania dotyczące liczby operacji we/wy na sekundę, opóźnienia i przepływności dysku, które zwykle są skalowane przy użyciu liczby dysków lub typu dysków magazynu w warstwie Premium w wersji 1. Liczba operacji we/wy na sekundę i przepływność, która ma zostać osiągnięta przez każdy dysk, może dyktować rozmiar dysku, szczególnie w przypadku magazynu w warstwie Premium w wersji 1. W przypadku magazynu w warstwie Premium w wersji 2 lub Ultra można wybrać aprowizowaną liczbę operacji we/wy na sekundę i przepływność niezależnie od pojemności dysku.

Uwaga

W przypadku wdrożeń systemu plików DBMS zdecydowanie zalecamy usługę Azure Premium Storage (w wersji 1 i 2), ultra disk lub udziały NFS oparte na usłudze Azure NetApp Files dla dowolnych danych, dziennika transakcji lub plików ponownego użycia. Nie ma znaczenia, czy chcesz wdrażać systemy produkcyjne, czy nieprodukcyjne. Opóźnienie dysków HDD lub SSD w warstwie Standardowa platformy Azure nie jest akceptowalne dla dowolnego typu systemu produkcyjnego.

Uwaga

Aby zmaksymalizować umowę SLA pojedynczej maszyny wirtualnej platformy Azure, wszystkie dołączone dyski muszą być magazynem Azure Premium Storage (wersja 1 lub wersja 2) lub typem dysku Azure Ultra, który obejmuje podstawowy dysk VHD (Azure Premium Storage).

Uwaga

Hostowanie głównych plików baz danych, takich jak pliki danych i dzienników, baz danych SAP na sprzęcie magazynu znajdującym się we współlokalizacyjnych centrach danych innych firm sąsiadujących z centrami danych platformy Azure, nie jest obsługiwane. Magazyn udostępniany za pośrednictwem urządzeń programowych hostowanych na maszynach wirtualnych platformy Azure również nie jest obsługiwany w tym przypadku użycia. W przypadku obciążeń SYSTEMU SAP DBMS tylko magazyn reprezentowany jako natywna usługa platformy Azure jest obsługiwany dla plików dziennika danych i transakcji baz danych SAP. Różne maszyny DBMS mogą obsługiwać różne typy magazynu platformy Azure. Aby uzyskać więcej informacji, zobacz Artykuł Azure Storage types for SAP workload (Typy usługi Azure Storage dla obciążenia SAP)

Umieszczanie plików bazy danych oraz plików dziennika i ponownego tworzenia oraz typu używanej usługi Azure Storage jest definiowane przez wymagania dotyczące liczby operacji we/wy na sekundę, opóźnienia i przepływności. W szczególności w przypadku usługi Azure Premium Storage w wersji 1, aby uzyskać wystarczającą liczbę operacji we/wy na sekundę, możesz być zmuszony do korzystania z wielu dysków lub użyć większego dysku magazynu w warstwie Premium. Jeśli używasz wielu dysków, utwórz pasek oprogramowania na dyskach zawierających pliki danych lub pliki dziennika i ponownego wykonania. W takich przypadkach liczba operacji we/wy na sekundę i umowy SLA przepływności dysku bazowego magazynu w warstwie Premium lub maksymalne osiągalne operacje we/wy na sekundę dysków magazynu w warstwie Standardowa są kumulacyjne dla wynikowego zestawu pasków.

Jeśli wymaganie dotyczące liczby operacji we/wy na sekundę przekracza liczbę dostępnych dysków VHD, zrównoważ liczbę operacji we/wy na sekundę wymaganą dla plików bazy danych w wielu wirtualnych dyskach twardych. Najprostszym sposobem dystrybucji obciążenia operacji we/wy na sekundę na dyskach jest utworzenie oprogramowania rozłożonego na różne dyski. Następnie umieść wiele plików danych systemu SAP DBMS na jednostkach LUN wyrzeźbionych z paska oprogramowania. Liczba dysków w pasie jest generowana przez wymagania dotyczące liczby operacji we/wy na sekundę, zapotrzebowanie na przepływność dysku i zapotrzebowanie na woluminy.

Windows storage striping Windows

Zalecamy używanie Miejsca do magazynowania systemu Windows do tworzenia zestawów stripe na wielu wirtualnych dyskach twardych platformy Azure. Użyj co najmniej systemu Windows Server 2012 R2 lub Windows Server 2016.

Linux storage striping Linux

Do tworzenia programowej macierzy RAID w systemie Linux są obsługiwane tylko oprogramowanie MDADM i Menedżer woluminów logicznych (LVM). Aby uzyskać więcej informacji, zobacz:

W przypadku usługi Azure Premium Storage w wersji 2 i Ultra dysk rozbieranie może nie być konieczne, ponieważ można zdefiniować liczbę operacji we/wy na sekundę i przepływność dysku niezależnie od rozmiaru dysku.

Uwaga

Ponieważ usługa Azure Storage przechowuje trzy obrazy dysków VHD, nie ma sensu konfigurować nadmiarowości podczas usuwania. Wystarczy skonfigurować rozdzielanie tak, aby we/wy zostały rozmieszczone na różnych dyskach VHD.

Dyski zarządzane lub niezarządzane

Konto usługi Azure Storage to konstrukcja administracyjna, a także podlega ograniczeniom. Aby uzyskać informacje na temat możliwości i ograniczeń, zobacz Cele dotyczące skalowalności i wydajności usługi Azure Storage. W przypadku magazynu w warstwie Standardowa należy pamiętać, że istnieje limit liczby operacji we/wy na sekundę na konto magazynu. Zobacz wiersz zawierający łączną liczbę żądań w artykule Cele dotyczące skalowalności i wydajności usługi Azure Storage. Istnieje również początkowy limit liczby kont magazynu na subskrypcję platformy Azure. Od 2017 r. platforma Azure wprowadziła pojęcia dotyczące usługi Azure Dyski zarządzane, które ułatwiają dbanie o administrację konta magazynu. Używanie dysków zarządzanych platformy Azure jest domyślnym rozwiązaniem do wdrożenia dla obciążenia SAP na platformie Azure.

Ważne

Biorąc pod uwagę zalety usługi Azure Dyski zarządzane, należy używać usługi Azure Dyski zarządzane dla wdrożeń systemu DBMS i wdrożeń sap w ogóle.

Jeśli masz obciążenie SAP, które nie korzysta jeszcze z dysków zarządzanych, aby przekonwertować z niezarządzanych na dyski zarządzane, zobacz:

Buforowanie dla maszyn wirtualnych i dysków danych

Podczas instalowania dysków na maszynach wirtualnych można wybrać, czy ruch we/wy między maszyną wirtualną a tymi dyskami znajdującymi się w usłudze Azure Storage jest buforowany.

W poniższych zaleceniach przyjęto założenie, że te cechy we/wy dla standardowych systemów DBMS:

  • Jest to głównie obciążenie odczytu względem plików danych bazy danych. Te operacje odczytu mają krytyczne znaczenie dla wydajności systemu DBMS.
  • Zapisywanie względem plików danych odbywa się w przypadku wzrostów na podstawie punktów kontrolnych lub strumienia ciągłego. Średnio w ciągu dnia liczba operacji zapisu jest mniejsza niż liczba operacji odczytu. W przeciwieństwie do operacji odczytu z plików danych te zapisy są asynchroniczne i nie przechowują żadnych transakcji użytkownika.
  • Nie ma żadnych odczytów z dziennika transakcji lub ponownego tworzenia plików. Wyjątki są dużymi operacjami we/wy podczas wykonywania kopii zapasowych dziennika transakcji.
  • Głównym obciążeniem plików dziennika transakcji lub ponownych operacji jest zapis. W zależności od charakteru obciążenia można mieć operacje we/wy tak małe, jak 4 KB lub, w innych przypadkach, rozmiary we/wy o rozmiarze 1 MB lub więcej.
  • Wszystkie zapisy muszą być utrwalane na dysku w niezawodny sposób.

W przypadku usługi Azure Premium Storage w wersji 1 istnieją następujące opcje buforowania:

  • Brak
  • Przeczytaj
  • Czytaj/zapisz
  • Brak + akcelerator zapisu, który jest przeznaczony tylko dla maszyn wirtualnych serii M platformy Azure
  • Akcelerator odczytu i zapisu, który jest przeznaczony tylko dla maszyn wirtualnych serii M platformy Azure

W przypadku magazynu w warstwie Premium w wersji 1 zalecamy użycie buforowania odczytu dla plików danych bazy danych SAP i wybrania opcji Brak buforowania dla dysków plików dziennika.

W przypadku wdrożeń serii M zalecamy używanie akceleratora zapisu platformy Azure tylko dla dysków plików dziennika. Aby uzyskać szczegółowe informacje, ograniczenia i wdrażanie akceleratora zapisu platformy Azure, zobacz Włączanie akceleratora zapisu.

W przypadku magazynu w warstwie Premium w wersji 2, ultra disk i usługi Azure NetApp Files nie są oferowane żadne opcje buforowania.

Dyski niepersistentne platformy Azure

Maszyny wirtualne platformy Azure oferują dyski niepersistentne po wdrożeniu maszyny wirtualnej. Jeśli maszyna wirtualna zostanie ponownie uruchomiona, cała zawartość tych dysków może zostać wyczyszczona. Jest to dane, że pliki danych i pliki dziennika i ponownego tworzenia baz danych nie powinny znajdować się w żadnych okolicznościach na tych niepersistowanych dyskach. W niektórych bazach danych mogą występować wyjątki, w przypadku których te niepersistowane dyski mogą być odpowiednie dla przestrzeni tabel tempdb i tymczasowych.

Aby uzyskać więcej informacji, zobacz Omówienie dysku tymczasowego na maszynach wirtualnych z systemem Windows na platformie Azure.

Windows nonpersisted disk Windows

Dysk D na maszynie wirtualnej platformy Azure to niepersistowany dysk, który jest wspierany przez niektóre dyski lokalne w węźle obliczeniowym platformy Azure. Ponieważ nie jest to możliwe, wszelkie zmiany wprowadzone w zawartości na dysku D zostaną utracone po ponownym uruchomieniu maszyny wirtualnej. Zmiany obejmują pliki, które zostały zapisane, katalogi, które zostały utworzone, i aplikacje, które zostały zainstalowane.

Linuxnonpersisted disk Linux

Maszyny wirtualne platformy Azure z systemem Linux automatycznie zainstalują dysk w lokalizacji /mnt/resource, który jest dyskiem niepersistowym wspieranym przez dyski lokalne w węźle obliczeniowym platformy Azure. Ponieważ nie jest ono niezakłócone, wszelkie zmiany wprowadzone w zawartości w /mnt/resource zostaną utracone po ponownym uruchomieniu maszyny wirtualnej. Zmiany obejmują pliki, które zostały zapisane, katalogi, które zostały utworzone, i aplikacje, które zostały zainstalowane.

Odporność usługi Microsoft Azure Storage

Usługa Microsoft Azure Storage przechowuje podstawowy wirtualny dysk twardy z systemem operacyjnym i dołączonymi dyskami lub obiektami blob na co najmniej trzech oddzielnych węzłach magazynu. Ten typ magazynu jest nazywany magazynem lokalnie nadmiarowym (LRS). Magazyn LRS jest domyślny dla wszystkich typów magazynu na platformie Azure.

Istnieją inne metody nadmiarowości. Aby uzyskać więcej informacji, zobacz Replikacja usługi Azure Storage.

Uwaga

Usługi Azure Premium Storage w wersji 1 i 2, Ultra Disk i Azure NetApp Files są zalecanym typem magazynu dla maszyn wirtualnych DBMS i dysków, które przechowują bazy danych i pliki dziennika i ponownego tworzenia. Z wyjątkiem magazynu w warstwie Premium w wersji 1 jedyną dostępną metodą nadmiarowości dla tych typów magazynów jest LRS. W związku z tym należy skonfigurować metody bazy danych, aby umożliwić replikację danych bazy danych do innego regionu platformy Azure lub strefy dostępności. Metody bazy danych obejmują funkcję SQL Server Always On, Oracle Data Guard i replikację systemu HANA.

Odporność węzła maszyny wirtualnej

Platforma Azure oferuje kilka różnych umów SLA dla maszyn wirtualnych. Aby uzyskać więcej informacji, zobacz najnowszą wersję umowy SLA dla maszyn wirtualnych. Ponieważ warstwa DBMS ma kluczowe znaczenie dla dostępności w systemie SAP, musisz zrozumieć różne typy wdrożeń i zdarzenia konserwacji. Aby uzyskać więcej informacji na temat tych pojęć, zobacz Zarządzanie dostępnością maszyn wirtualnych na platformie Azure.

Minimalną rekomendacją dla produkcyjnych scenariuszy systemu DBMS z obciążeniem SAP jest:

  • Wdróż dwie maszyny wirtualne przy użyciu wybranego typu wdrożenia w tym samym regionie świadczenia usługi Azure.
  • Uruchom te dwie maszyny wirtualne w tej samej sieci wirtualnej platformy Azure i mają dołączone karty sieciowe z tych samych podsieci.
  • Użyj metod bazy danych, aby zachować gorącą rezerwę z drugą maszyną wirtualną. Metody mogą być zawsze włączone programu SQL Server, oracle Data Guard lub replikacja systemu HANA.

Możesz również wdrożyć trzecią maszynę wirtualną w innym regionie świadczenia usługi Azure i użyć tych samych metod bazy danych, aby dostarczyć replikę asynchroniczną w innym regionie świadczenia usługi Azure.

Zagadnienia dotyczące sieci platformy Azure

W przypadku wdrożeń SAP na dużą skalę użyj strategii wirtualnego centrum danych platformy Azure. Służy do konfigurowania sieci wirtualnej oraz uprawnień i przypisań ról do różnych części organizacji.

Te najlepsze rozwiązania są wynikiem tysięcy wdrożeń klientów:

  • Sieci wirtualne wdrażane w aplikacji SAP nie mają dostępu do Internetu.
  • Maszyny wirtualne bazy danych działają w tej samej sieci wirtualnej co warstwa aplikacji, oddzielone w innej podsieci od warstwy aplikacji SAP.
  • Maszyny wirtualne w sieci wirtualnej mają statyczną alokację prywatnego adresu IP. Aby uzyskać więcej informacji, zobacz Typy adresów IP i metody alokacji na platformie Azure.
  • Ograniczenia routingu do i z maszyn wirtualnych DBMS nie są ustawiane z zaporami zainstalowanymi na lokalnych maszynach wirtualnych DBMS. Zamiast tego routing ruchu jest definiowany z sieciowymi grupami zabezpieczeń.
  • Aby oddzielić i odizolować ruch do maszyny wirtualnej DBMS, przypisz różne karty sieciowe do maszyny wirtualnej. Każda karta sieciowa otrzymuje inny adres IP, a każda karta sieciowa jest przypisywana do innej podsieci sieci wirtualnej. Każda podsieć ma różne reguły sieciowej grupy zabezpieczeń. Izolacja lub separacja ruchu sieciowego jest miarą routingu. Nie służy do ustawiania limitów przydziału przepływności sieci.

Uwaga

Przypisywanie statycznych adresów IP za pośrednictwem platformy Azure oznacza przypisywanie ich do poszczególnych wirtualnych kart sieciowych. Nie przypisuj statycznych adresów IP w systemie operacyjnym gościa do wirtualnej karty sieciowej. Niektóre usługi platformy Azure, takie jak Azure Backup, polegają na tym, że co najmniej podstawowa wirtualna karta sieciowa w systemie operacyjnym gościa ma wartość DHCP, a nie statyczne adresy IP. Aby uzyskać więcej informacji, zobacz Rozwiązywanie problemów z tworzeniem kopii zapasowych maszyn wirtualnych platformy Azure. Aby przypisać wiele statycznych adresów IP do maszyny wirtualnej, przypisz wiele wirtualnych kart sieciowych do maszyny wirtualnej.

Ostrzeżenie

Konfigurowanie wirtualnych urządzeń sieciowych w ścieżce komunikacyjnej między aplikacją SAP a warstwą DBMS systemu SAP NetWeaver-, Hybris-lub S/4HANA nie jest obsługiwane. To ograniczenie jest ze względów funkcjonalności i wydajności. Ścieżka komunikacji między warstwą aplikacji SAP a warstwą DBMS musi być bezpośrednia. Ograniczenie nie obejmuje reguł grupy zabezpieczeń aplikacji (ASG) i sieciowej grupy zabezpieczeń, jeśli te reguły grupy zabezpieczeń i sieciowej grupy zabezpieczeń zezwalają na bezpośrednią ścieżkę komunikacji. Obejmuje to również ruch do udziałów NFS hostujących dane DBMS i pliki dziennika ponownego tworzenia.

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

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 klientów wirtualne urządzenia sieciowe mogą spowodować niepowodzenie klastrów pacemaker systemu Linux. Są to przypadki, w których komunikacja między węzłami klastra Pacemaker systemu Linux komunikuje się z urządzeniem SBD za pośrednictwem wirtualnego urządzenia sieciowego.

Ważne

Innym projektem, który nie jest obsługiwany, jest podział warstwy aplikacji SAP i warstwy DBMS na różne sieci wirtualne platformy Azure, które nie są ze sobą równorzędne. Zalecamy segregowanie warstwy aplikacji SAP i warstwy DBMS przy użyciu podsieci w sieci wirtualnej platformy Azure zamiast używania różnych sieci wirtualnych platformy Azure.

Jeśli zdecydujesz się nie przestrzegać zalecenia i zamiast tego rozdzielisz obie warstwy na różne sieci wirtualne, te dwie sieci wirtualne muszą być równorzędne.

Należy pamiętać, że ruch sieciowy między dwiema równorzędną sieciami wirtualnymi platformy Azure podlega kosztom transferu. Ogromny wolumin danych składający się z wielu terabajtów jest wymieniany między warstwą aplikacji SAP a warstwą DBMS. Możesz zebrać znaczne koszty, jeśli warstwa aplikacji SAP i warstwa DBMS są rozdzielone między dwie równorzędne sieci wirtualne platformy Azure.

Przekierowywanie ruchu za pomocą usługi Azure Load Balancer

Użycie prywatnych wirtualnych adresów IP używanych w funkcjach, takich jak zawsze włączone programu SQL Server lub replikacja systemu HANA, wymaga konfiguracji modułu równoważenia obciążenia platformy Azure. Moduł równoważenia obciążenia używa portów sondy do określenia aktywnego węzła DBMS i kierowania ruchu wyłącznie do tego aktywnego węzła bazy danych.

Jeśli istnieje tryb failover węzła bazy danych, nie ma potrzeby ponownego konfigurowania aplikacji SAP. Zamiast tego najbardziej typowe architektury aplikacji SAP łączą się ponownie z prywatnym wirtualnym adresem IP. Tymczasem moduł równoważenia obciążenia reaguje na tryb failover węzła, przekierowując ruch do prywatnego wirtualnego adresu IP do drugiego węzła.

Platforma Azure oferuje dwie różne jednostki SKU modułu równoważenia obciążenia: podstawową jednostkę SKU i jednostkę SKU w warstwie Standardowa. Na podstawie zalet konfiguracji i funkcjonalności należy użyć standardowej jednostki SKU modułu równoważenia obciążenia platformy Azure. Jedną z zalet modułu równoważenia obciążenia w warstwie Standardowa jest to, że ruch danych nie jest kierowany przez sam moduł równoważenia obciążenia.

Przykład konfigurowania wewnętrznego modułu równoważenia obciążenia można znaleźć w artykule Samouczek: konfigurowanie grupy dostępności programu SQL Server na maszynach wirtualnych platformy Azure

Uwaga

Istnieją różnice w zachowaniu podstawowej i standardowej jednostki SKU związanej z dostępem do publicznych adresów IP. Sposób obejścia ograniczeń jednostki SKU w warstwie Standardowa w celu uzyskania dostępu do publicznych adresów IP opisano w dokumencie Łączność publicznego punktu końcowego dla maszyn wirtualnych przy użyciu usługi Azure usługa Load Balancer w warstwie Standardowa w scenariuszach wysokiej dostępności oprogramowania SAP

Wdrażanie monitorowania hosta

W przypadku korzystania z aplikacji SAP w środowisku produkcyjnym na maszynach wirtualnych platformy Azure system SAP wymaga możliwości pobierania danych monitorowania hosta z hostów fizycznych, na których są uruchamiane maszyny wirtualne platformy Azure. Wymagany jest określony poziom poprawek agenta hosta SAP, który umożliwia korzystanie z tej funkcji w systemach SAPOSCOL i SAP Host Agent. Dokładny poziom poprawek jest udokumentowany w 1409604 SAP Note.

Aby uzyskać więcej informacji na temat wdrażania składników dostarczających dane hosta do programu SAPOSCOL i programu SAP Host Agent oraz zarządzania cyklem życia tych składników, zacznij od artykułu Implementowanie rozszerzenia maszyny wirtualnej platformy Azure dla rozwiązań SAP.

Następne kroki

Aby uzyskać więcej informacji na temat określonego systemu DBMS, zobacz: