Share via

Wdrażanie programu SQL Server Azure Virtual Machines DBMS dla oprogramowania SAP NetWeaver

  • Artykuł

Ten dokument obejmuje kilka różnych obszarów, które należy wziąć pod uwagę podczas wdrażania programu SQL Server dla obciążenia SAP w usłudze Azure IaaS. Jako warunek wstępny tego dokumentu należy zapoznać się z dokumentem Considerations for Azure Virtual Machines DBMS deployment for SAP workload and other guides in the SAP workload on Azure documentation (Zagadnienia dotyczące wdrażania systemu DBMS usługi Azure Virtual Machines dla obciążenia SAP w dokumentacji platformy Azure).

Ważne

Zakresem tego dokumentu jest wersja systemu Windows w programie SQL Server. Oprogramowanie SAP nie obsługuje wersji programu SQL Server z systemem Linux z żadnym oprogramowaniem SAP. Dokument nie omawia usługi Microsoft Azure SQL Database, która jest ofertą platformy jako usługi platformy Microsoft Azure. W tym dokumencie omówiono uruchamianie produktu SQL Server, ponieważ jest on znany z wdrożeń lokalnych w usłudze Azure Virtual Machines, wykorzystując możliwości infrastruktury jako usługi platformy Azure. Możliwości i funkcje bazy danych między tymi dwiema ofertami są różne i nie powinny być ze sobą mieszane. Aby uzyskać więcej informacji, zobacz Azure SQL Database.

Ogólnie rzecz biorąc, należy rozważyć użycie najnowszych wersji programu SQL Server do uruchamiania obciążenia SAP w usłudze Azure IaaS. Najnowsze wersje programu SQL Server oferują lepszą integrację z niektórymi usługami i funkcjami platformy Azure. Lub zmiany, które optymalizują operacje w infrastrukturze IaaS platformy Azure.

Ogólna dokumentacja dotycząca programu SQL Server uruchomionego na maszynach wirtualnych platformy Azure można znaleźć w następujących artykułach:

Nie wszystkie instrukcje i zawartości wprowadzone w ogólnej dokumentacji programu SQL Server na maszynie wirtualnej platformy Azure dotyczą obciążenia SAP. Jednak dokumentacja daje dobre wrażenie na zasadach. Przykładem funkcji, które nie są obsługiwane w przypadku obciążenia SAP, jest użycie klastrowania wystąpienia klastra trybu failover.

Przed kontynuowaniem należy znać niektóre informacje specyficzne dla programu SQL Server w usłudze IaaS:

  • Obsługa wersji programu SQL: nawet w przypadku programu SAP Note #1928533 stwierdzającego, że minimalna obsługiwana wersja programu SQL Server to SQL Server 2008 R2, okno obsługiwanych wersji programu SQL Server na platformie Azure jest również zależne od cyklu życia programu SQL Server. Rozszerzona konserwacja programu SQL Server 2012 zakończyła się w połowie 2022 r. W związku z tym bieżąca minimalna wersja dla nowo wdrożonych systemów powinna być programem SQL Server 2014. Tym częściej, tym lepiej. Najnowsze wersje programu SQL Server oferują lepszą integrację z niektórymi usługami i funkcjami platformy Azure. Lub zmiany, które optymalizują operacje w infrastrukturze IaaS platformy Azure.
  • Używanie obrazów z witryny Azure Marketplace: najszybszym sposobem wdrożenia nowej maszyny wirtualnej platformy Microsoft Azure jest użycie obrazu z witryny Azure Marketplace. W witrynie Azure Marketplace znajdują się obrazy zawierające najnowsze wersje programu SQL Server. Obrazy, na których program SQL Server jest już zainstalowany, nie mogą być natychmiast używane dla aplikacji SAP NetWeaver. Przyczyną jest zainstalowanie domyślnego sortowania programu SQL Server na tych obrazach, a nie sortowania wymaganego przez systemy SAP NetWeaver. Aby użyć takich obrazów, zapoznaj się z krokami opisanymi w rozdziale Using a SQL Server image out of the Microsoft Azure Marketplace (Korzystanie z obrazu programu SQL Server z witryny Microsoft Azure Marketplace).
  • Obsługa wielu wystąpień programu SQL Server na jednej maszynie wirtualnej platformy Azure: ta metoda wdrażania jest obsługiwana. Należy jednak pamiętać o ograniczeniach zasobów, szczególnie w przypadku sieci i przepustowości magazynu używanego typu maszyny wirtualnej. Szczegółowe informacje są dostępne w artykule Rozmiary maszyn wirtualnych na platformie Azure. Te ograniczenia limitów przydziału mogą uniemożliwić zaimplementowanie tej samej architektury wielu wystąpień, co można zaimplementować lokalnie. W zależności od konfiguracji i interferencji udostępniania zasobów dostępnych na jednej maszynie wirtualnej należy wziąć pod uwagę te same kwestie, które należy wziąć pod uwagę w środowisku lokalnym.
  • Wiele baz danych SAP w jednym wystąpieniu programu SQL Server na jednej maszynie wirtualnej: obsługiwane są takie konfiguracje. Zagadnienia dotyczące wielu baz danych SAP współużytkowanych zasobów pojedynczego wystąpienia programu SQL Server są takie same jak w przypadku wdrożeń lokalnych. Zachowaj inne limity, takie jak liczba dysków, które można dołączyć do określonego typu maszyny wirtualnej. Lub limity przydziału sieci i magazynu określonych typów maszyn wirtualnych jako szczegółowe rozmiary maszyn wirtualnych na platformie Azure.

Zgodnie z ogólnym opisem system operacyjny, pliki wykonywalne programu SQL Server powinny znajdować się lub instalować oddzielne dyski platformy Azure. Zazwyczaj większość systemowych baz danych programu SQL Server nie jest używana na wysokim poziomie przez obciążenie SAP NetWeaver. Niemniej jednak systemowe bazy danych programu SQL Server powinny być, wraz z innymi katalogami programu SQL Server na oddzielnym dysku platformy Azure. Baza danych tempdb programu SQL Server powinna znajdować się na nieperystryzowanej stacji D:\ lub na oddzielnym dysku.

  • Ze wszystkimi certyfikowanymi typami maszyn wirtualnych SAP (zobacz SAP Note #1928533), dane bazy danych tempdb i pliki dziennika można umieścić na dysku D:\ nietrwałym.
  • W przypadku wydań programu SQL Server, w których program SQL Server domyślnie instaluje bazę danych tempdb z jednym plikiem danych, zaleca się używanie wielu plików danych bazy danych tempdb. Należy pamiętać, że woluminy dysku D:\ różnią się rozmiarem i możliwościami na podstawie typu maszyny wirtualnej. Aby uzyskać dokładne rozmiary dysku D:\ różnych maszyn wirtualnych, zapoznaj się z artykułem Rozmiary maszyn wirtualnych z systemem Windows na platformie Azure.

Te konfiguracje umożliwiają bazie danych tempdb wykorzystanie większej ilości miejsca i ważniejsze więcej operacji we/wy na sekundę (IOPS) i przepustowość magazynu niż dysk systemowy jest w stanie zapewnić. Dysk D:\ niepersistentny oferuje również lepsze opóźnienie we/wy i przepływność. Aby określić odpowiedni rozmiar bazy danych tempdb, można sprawdzić rozmiary bazy danych tempdb w istniejących systemach.

Uwaga

W przypadku umieszczenia plików danych bazy danych tempdb i pliku dziennika w folderze na utworzonym dysku D:\ należy upewnić się, że folder istnieje po ponownym uruchomieniu maszyny wirtualnej. Ponieważ dysk D:\ może być świeżo zainicjowany po ponownym uruchomieniu maszyny wirtualnej wszystkie struktury plików i katalogów mogą zostać wyczyszczone. Możliwość ponownego utworzenia ewentualnych struktur katalogów na dysku D:\ przed rozpoczęciem usługi SQL Server jest udokumentowana w tym artykule.

Konfiguracja maszyny wirtualnej, która uruchamia program SQL Server z bazą danych SAP i gdzie dane bazy danych tempdb i plik dziennika bazy danych tempdb są umieszczane na dysku D:\ i w usłudze Azure Premium Storage w wersji 1 lub 2 wygląda następująco:

Diagram of simple VM disk configuration for SQL Server

Diagram przedstawia prosty przypadek. Jak wyjaśniono w artykule Considerations for Azure Virtual Machines DBMS deployment for SAP workload, Azure Storage type, number, and size of disks is zależny od różnych czynników. Ogólnie jednak zalecamy:

  • W przypadku wdrożeń mniejszych i średnich zakresów należy użyć jednego dużego woluminu zawierającego pliki danych programu SQL Server. Przyczyną tej konfiguracji jest to, że łatwiej jest radzić sobie z różnymi obciążeniami we/wy, jeśli pliki danych programu SQL Server nie mają tego samego wolnego miejsca. Podczas dużych wdrożeń, zwłaszcza wdrożeń, w których klient przeprowadził się z heterogeniczną migracją bazy danych do programu SQL Server na platformie Azure, użyliśmy oddzielnych dysków, a następnie rozpowszechniliśmy pliki danych na tych dyskach. Taka architektura kończy się powodzeniem tylko wtedy, gdy każdy dysk ma taką samą liczbę plików danych, wszystkie pliki danych mają ten sam rozmiar i mają mniej więcej takie samo wolne miejsce.
  • Użyj dysku D:\drive dla bazy danych tempdb, o ile wydajność jest wystarczająco dobra. Jeśli ogólne obciążenie jest ograniczone w wydajności przez bazę danych tempdb znajdującą się na dysku D:\, musisz przenieść bazę danych tempdb do usługi Azure Premium Storage w wersji 1 lub 2 lub ultra, zgodnie z zaleceniami w tym artykule.

Mechanizm wypełniania proporcjonalnego programu SQL Server dystrybuuje odczyty i zapisy do wszystkich plików danych, pod warunkiem że wszystkie pliki danych programu SQL Server mają taki sam rozmiar i mają takie same tempo zwolnienia. Oprogramowanie SAP w programie SQL Server zapewni najlepszą wydajność, gdy odczyty i zapisy są dystrybuowane równomiernie we wszystkich dostępnych plikach danych. Jeśli baza danych ma zbyt mało plików danych lub istniejące pliki danych są wysoce niezrównoważone, najlepszą metodą poprawienia jest eksportowanie i importowanie R3load. Eksportowanie i importowanie ładunku R3 obejmuje przestój i należy to zrobić tylko wtedy, gdy wystąpi oczywisty problem z wydajnością, który należy rozwiązać. Jeśli pliki danych mają tylko umiarkowanie różne rozmiary, zwiększ wszystkie pliki danych do tego samego rozmiaru, a program SQL Server z czasem ponownie zrównoważy dane. Program SQL Server automatycznie zwiększa pliki danych, nawet jeśli flaga śledzenia 1117 jest ustawiona lub czy jest używany program SQL Server 2016 lub nowszy.

Specjalne dla maszyn wirtualnych serii M

W przypadku maszyny wirtualnej z serii Azure M opóźnienie zapisu w dzienniku transakcji można zmniejszyć w porównaniu z wydajnością usługi Azure Premium Storage w wersji 1 podczas korzystania z akceleratora zapisu platformy Azure. Jeśli opóźnienie zapewniane przez usługę Premium Storage w wersji 1 ogranicza skalowalność obciążenia SAP, dysk, który przechowuje plik dziennika transakcji programu SQL Server, można włączyć dla akceleratora zapisu. Szczegóły można odczytać w dokumencie Akcelerator zapisu. Akcelerator zapisu platformy Azure nie działa z usługą Azure Premium Storage w wersji 2 i Ultra Disk. W obu przypadkach opóźnienie jest lepsze niż to, co zapewnia usługa Azure Premium Storage w wersji 1.

Formatowanie dysków

W przypadku programu SQL Server rozmiar bloku NTFS dla dysków zawierających dane i pliki dziennika programu SQL Server powinien wynosić 64 KB. Nie ma potrzeby formatowania dysku D:\. Ten dysk jest wstępnie sformatowany.

Aby uniknąć przywracania lub tworzenia baz danych inicjuje pliki danych przez zerowanie zawartości plików, upewnij się, że kontekst użytkownika, w którym działa usługa SQL Server, ma zadanie konserwacji woluminu Prawo użytkownika. Aby uzyskać więcej informacji, zobacz Inicjowanie plików błyskawicznych bazy danych.

SQL Server 2014 i nowsze — przechowywanie plików bazy danych bezpośrednio w usłudze Azure Blob Storage

Program SQL Server 2014 i nowsze wersje otwierają możliwość przechowywania plików baz danych bezpośrednio w usłudze Azure Blob Store bez otoki wirtualnego dysku twardego wokół nich. Ta funkcja miała na celu rozwiązanie problemów z brakami magazynu blokowego platformy Azure z powrotem. W dzisiejszych czasach nie zaleca się używania tej metody wdrażania, a zamiast tego wybierz usługę Azure Premium Storage w wersji 1, magazyn Premium Storage w wersji 2 lub Ultra Disk. Zależne od wymagań.

Rozszerzenie puli buforów programu SQL Server 2014

Program SQL Server 2014 wprowadził nową funkcję o nazwie Rozszerzenie puli buforów. Ta funkcja jest testowana w ramach obciążenia SAP na platformie Azure, ale nie zapewnia poprawy obciążenia hostingu. W związku z tym nie należy go uznać za

Zagadnienia dotyczące tworzenia kopii zapasowych/odzyskiwania dla programu SQL Server

Wdrożenie programu SQL Server na platformie Azure wymaga przejrzenia architektury kopii zapasowej. Nawet jeśli system nie jest systemem produkcyjnym, baza danych SAP hostowana przez program SQL Server musi być okresowo wykonywana kopia zapasowa. Ponieważ usługa Azure Storage przechowuje trzy obrazy, kopia zapasowa jest teraz mniej ważna w odniesieniu do kompensowania awarii magazynu. Priorytetową przyczyną utrzymania odpowiedniego planu tworzenia kopii zapasowych i odzyskiwania jest więcej, co pozwala zrekompensować błędy logiczne/ręczne, zapewniając możliwości odzyskiwania do punktu w czasie. Celem jest użycie kopii zapasowych w celu przywrócenia bazy danych z powrotem do określonego punktu w czasie. Możesz też użyć kopii zapasowych na platformie Azure, aby zainicjować inny system, kopiując istniejącą bazę danych.

Istnieje kilka sposobów tworzenia kopii zapasowych i przywracania baz danych programu SQL Server na platformie Azure. Aby uzyskać najlepsze omówienie i szczegóły, przeczytaj dokument Tworzenie kopii zapasowej i przywracanie dla programu SQL Server na maszynach wirtualnych platformy Azure. Artykuł obejmuje kilka różnych możliwości.

Korzystanie z obrazu programu SQL Server z witryny Microsoft Azure Marketplace

Firma Microsoft oferuje maszyny wirtualne w witrynie Azure Marketplace, które zawierają już wersje programu SQL Server. W przypadku klientów SAP, którzy wymagają licencji dla programu SQL Server i systemu Windows, użycie tych obrazów może być okazją do pokrycia potrzeby licencji przez skonfigurowanie już zainstalowanych maszyn wirtualnych z programem SQL Server. Aby można było używać takich obrazów dla systemu SAP, należy wziąć pod uwagę następujące kwestie:

  • Wersje nienadycyjne programu SQL Server uzyskują wyższe koszty niż maszyna wirtualna "tylko dla systemu Windows" wdrożona z witryny Azure Marketplace. Aby porównać ceny, zobacz Cennik maszyn wirtualnych z systemem Windows i Cennik maszyn wirtualnych programu SQL Server Enterprise.
  • Można używać tylko wersji programu SQL Server, które są obsługiwane przez oprogramowanie SAP.
  • Sortowanie wystąpienia programu SQL Server zainstalowanego na maszynach wirtualnych oferowanych w witrynie Azure Marketplace nie jest sortowaniem oprogramowania SAP NetWeaver, które wymaga uruchomienia wystąpienia programu SQL Server. Sortowanie można jednak zmienić za pomocą wskazówek w poniższej sekcji.

Zmienianie sortowania programu SQL Server na maszynie wirtualnej z systemem Microsoft Windows/SQL Server

Ponieważ obrazy programu SQL Server w witrynie Azure Marketplace nie są skonfigurowane do używania sortowania, które jest wymagane przez aplikacje SAP NetWeaver, należy je zmienić natychmiast po wdrożeniu. W przypadku programu SQL Server tę zmianę sortowania można wykonać, wykonując następujące czynności natychmiast po wdrożeniu maszyny wirtualnej, a administrator może zalogować się do wdrożonej maszyny wirtualnej:

  • Otwórz okno poleceń systemu Windows jako administrator.
  • Zmień katalog na C:\Program Files\Microsoft SQL Server\110\Setup Bootstrap\SQLServer2012.
  • Wykonaj polecenie: Setup.exe /QUIET /ACTION=REBUILDDATABASE /INSTANCENAME=MSSQLSERVER /SQLSYSADMINACCOUNTS=<local_admin_account_name> /SQLCOLLATION=SQL_Latin1_General_Cp850_BIN2
    • <local_admin_account_name> to konto, które zostało zdefiniowane jako konto administratora podczas wdrażania maszyny wirtualnej po raz pierwszy za pośrednictwem galerii.

Proces powinien potrwać tylko kilka minut. Aby upewnić się, czy krok zakończył się prawidłowym wynikiem, wykonaj następujące kroki:

  • Otwórz program SQL Server Management Studio.
  • Otwórz okno zapytania.
  • Wykonaj polecenie sp_helpsort w bazie danych master programu SQL Server.

Żądany wynik powinien wyglądać następująco:

Latin1-General, binary code point comparison sort for Unicode Data, SQL Server Sort Order 40 on Code Page 850 for non-Unicode Data

Jeśli wynik jest inny, zatrzymaj dowolne wdrożenie i zbadaj, dlaczego polecenie konfiguracji nie działa zgodnie z oczekiwaniami. Wdrażanie aplikacji SAP NetWeaver w wystąpieniu programu SQL Server z różnymi stronami kodowymi programu SQL Server niż wymienione nie jest obsługiwane w przypadku wdrożeń NetWeaver.

Wysoka dostępność programu SQL Server dla oprogramowania SAP na platformie Azure

Korzystając z programu SQL Server we wdrożeniach IaaS platformy Azure dla systemu SAP, istnieje kilka różnych możliwości dodania do wdrożenia warstwy DBMS o wysokiej dostępności. Platforma Azure udostępnia różne umowy SLA dotyczące czasu pracy dla jednej maszyny wirtualnej przy użyciu różnych magazynów blokowych platformy Azure, pary maszyn wirtualnych wdrożonych w zestawie dostępności platformy Azure lub pary maszyn wirtualnych wdrożonych w usłudze Azure Strefy dostępności. W przypadku systemów produkcyjnych oczekujemy wdrożenia pary maszyn wirtualnych w zestawie skalowania maszyn wirtualnych z elastyczną aranżacją w dwóch strefach dostępności. Aby uzyskać więcej informacji, zobacz porównanie różnych typów wdrożeń dla obciążenia SAP. Jedna maszyna wirtualna uruchomi aktywne wystąpienie programu SQL Server. Druga maszyna wirtualna uruchomi wystąpienie pasywne

Klaster programu SQL Server przy użyciu serwera plików skalowalnego w poziomie systemu Windows lub dysku udostępnionego platformy Azure

W systemie Windows Server 2016 firma Microsoft wprowadziła Miejsca do magazynowania Direct. W oparciu o Miejsca do magazynowania, bezpośrednie wdrażanie klastrowanie klastrów trybu failover programu SQL Server jest ogólnie obsługiwane. Platforma Azure oferuje również dyski udostępnione platformy Azure, których można użyć do klastrowania systemu Windows. W przypadku obciążenia SAP nie obsługujemy tych opcji wysokiej dostępności.

Wysyłanie dzienników programu SQL Server

Jedną z funkcji wysokiej dostępności jest wysyłanie dzienników programu SQL Server. Jeśli maszyny wirtualne uczestniczące w konfiguracji wysokiej dostępności mają działające rozpoznawanie nazw, nie ma problemu. Konfiguracja na platformie Azure nie różni się od konfiguracji wykonywanej lokalnie w celu skonfigurowania wysyłania dzienników i zasad dotyczących wysyłania dzienników. Szczegółowe informacje na temat wysyłania dzienników programu SQL Server można znaleźć w artykule About Log Shipping (SQL Server) (Informacje o wysyłaniu dzienników (SQL Server).

Funkcja wysyłania dzienników programu SQL Server nie była używana na platformie Azure w celu osiągnięcia wysokiej dostępności w jednym regionie świadczenia usługi Azure. Jednak w następujących scenariuszach klienci SAP pomyślnie korzystali z wysyłania dzienników z platformą Azure:

  • Scenariusze odzyskiwania po awarii z jednego regionu świadczenia usługi Azure do innego regionu świadczenia usługi Azure
  • Konfiguracja odzyskiwania po awarii ze środowiska lokalnego do regionu świadczenia usługi Azure
  • Scenariusze jednorazowe z środowiska lokalnego na platformę Azure. W takich przypadkach wysyłanie dzienników jest używane do synchronizowania nowego wdrożenia systemu DBMS na platformie Azure z trwającym systemem produkcyjnym lokalnie. W czasie cięcia produkcji jest zamykana i upewniono się, że ostatnie i najnowsze kopie zapasowe dziennika transakcji zostały przeniesione do wdrożenia usługi Azure DBMS. Następnie wdrożenie usługi Azure DBMS jest otwarte dla środowiska produkcyjnego.

Zawsze włączony program SQL Server

Ponieważ funkcja Always On jest obsługiwana w środowisku lokalnym SAP (zobacz sap Note #1772688), jest obsługiwana w połączeniu z oprogramowaniem SAP na platformie Azure. Istnieją pewne specjalne zagadnienia dotyczące wdrażania odbiornika grupy dostępności programu SQL Server (nie należy mylić z zestawem dostępności platformy Azure). W związku z tym konieczne są pewne różne kroki instalacji.

Oto niektóre zagadnienia dotyczące korzystania z odbiornika grupy dostępności:

  • Korzystanie z odbiornika grupy dostępności jest możliwe tylko w systemie Windows Server 2012 lub nowszym jako system operacyjny gościa maszyny wirtualnej. W systemie Windows Server 2012 upewnij się, że zastosowano aktualizację w celu włączenia odbiorników grupy dostępności programu SQL Server w systemach Windows Server 2008 R2 i Windows Server 2012.
  • W systemie Windows Server 2008 R2 ta poprawka nie istnieje. W takim przypadku zawsze włączone musi być używane w taki sam sposób jak dublowanie bazy danych. Określając partnera trybu failover w parametrach połączeń (wykonywane za pośrednictwem parametru SAP default.pfl dbs/mss/server — zobacz uwaga SAP #965908).
  • Korzystając z odbiornika grupy dostępności, należy połączyć maszyny wirtualne bazy danych z dedykowanym modułem równoważenia obciążenia. Statyczne adresy IP należy przypisać do interfejsów sieciowych tych maszyn wirtualnych w konfiguracji Always On (definiowanie statycznego adresu IP zostało opisane w tym artykule). Statyczne adresy IP w porównaniu z protokołem DHCP uniemożliwiają przypisanie nowych adresów IP w przypadkach, gdy obie maszyny wirtualne mogą zostać zatrzymane.
  • Podczas kompilowania konfiguracji klastra WSFC wymagane są specjalne kroki, w których klaster potrzebuje przypisanego specjalnego adresu IP, ponieważ platforma Azure z bieżącą funkcjonalnością przypisze nazwę klastra taki sam adres IP jak węzeł, w którym jest tworzony klaster. To zachowanie oznacza, że należy wykonać krok ręczny w celu przypisania innego adresu IP do klastra.
  • Odbiornik grupy dostępności zostanie utworzony na platformie Azure z punktami końcowymi TCP/IP przypisanymi do maszyn wirtualnych z replikami podstawowymi i pomocniczymi grupy dostępności.
  • Może być konieczne zabezpieczenie tych punktów końcowych przy użyciu list ACL.

Szczegółowa dokumentacja dotycząca wdrażania funkcji Always On z programem SQL Server na listach maszyn wirtualnych platformy Azure, takich jak:

Uwaga

Przeczytaj artykuł Wprowadzenie do zawsze włączonych grup dostępności programu SQL Server na maszynach wirtualnych platformy Azure. Zapoznasz się z odbiornikiem direct network name (DNN) programu SQL Server. Ta nowa funkcja została wprowadzona w programie SQL Server 2019 CU8. Ta nowa funkcja sprawia, że użycie modułu równoważenia obciążenia platformy Azure obsługującego wirtualny adres IP odbiornika grupy dostępności jest przestarzałe.

Zawsze włączone program SQL Server to najczęściej używane funkcje wysokiej dostępności i odzyskiwania po awarii używane na platformie Azure na potrzeby wdrożeń obciążeń SAP. Większość klientów używa funkcji Always On w celu zapewnienia wysokiej dostępności w jednym regionie świadczenia usługi Azure. Jeśli wdrożenie jest ograniczone tylko do dwóch węzłów, masz dwie opcje łączności:

  • Za pomocą odbiornika grupy dostępności. Odbiornik grupy dostępności wymaga wdrożenia modułu równoważenia obciążenia platformy Azure.
  • W programie SQL Server 2016 SP3, SQL Server 2017 CU 25 lub SQL Server 2019 CU8 lub nowszych wersjach programu SQL Server w systemie Windows Server 2016 lub nowszym można użyć odbiornika nazwy sieci bezpośredniej (DNN) zamiast modułu równoważenia obciążenia platformy Azure. Nazwa sieci rozproszonej eliminuje wymaganie modułu równoważenia obciążenia platformy Azure.

Użycie parametrów łączności dublowania bazy danych programu SQL Server powinno być brane pod uwagę tylko w przypadku rundy badania problemów z innymi dwiema metodami. W takim przypadku należy skonfigurować łączność aplikacji SAP w taki sposób, w którym nazwy obu węzłów są nazwane. Szczegółowe informacje o takiej konfiguracji po stronie sap są udokumentowane w artykule SAP Note #965908. Korzystając z tej opcji, nie trzeba konfigurować odbiornika grupy dostępności. Ponadto bez modułu równoważenia obciążenia platformy Azure i z tym rozwiązaniem może zbadać problemy z tymi składnikami. Pamiętaj jednak, że ta opcja działa tylko wtedy, gdy ograniczysz grupę dostępności do użycia dwóch wystąpień.

Większość klientów korzysta z funkcji Always On programu SQL Server na potrzeby funkcji odzyskiwania po awarii między regionami świadczenia usługi Azure. Kilku klientów korzysta również z możliwości wykonywania kopii zapasowych z repliki pomocniczej.

SQL Server Transparent Data Encryption

Wielu klientów korzysta z funkcji Transparent Data Encryption (TDE) programu SQL Server podczas wdrażania baz danych programu SAP SQL Server na platformie Azure. Funkcja TDE programu SQL Server jest w pełni obsługiwana przez oprogramowanie SAP (zobacz sap Note #1380493).

Stosowanie funkcji TDE programu SQL Server

W przypadkach, gdy przeprowadzasz heterogeniczną migrację z innej bazy danych DBMS uruchomionej lokalnie do systemu Windows/programu SQL Server uruchomionego na platformie Azure, należy z wyprzedzeniem utworzyć pustą docelową bazę danych w programie SQL Server. W następnym kroku zastosujesz funkcję TDE programu SQL Server do tej pustej bazy danych. Powodem, dla którego chcesz wykonać tę sekwencję, jest to, że proces szyfrowania pustej bazy danych może zająć sporo czasu. Procesy importowania oprogramowania SAP następnie importować dane do zaszyfrowanej bazy danych w fazie przestoju. Obciążenie związane z importowaniem do zaszyfrowanej bazy danych ma znacznie mniejszy wpływ na czas niż szyfrowanie bazy danych po fazie eksportowania w fazie czasu awarii. Negatywne środowiska zostały wykonane podczas próby zastosowania funkcji TDE z obciążeniem SAP uruchomionym na bazie danych. W związku z tym zaleca się traktowanie wdrożenia funkcji TDE jako działania, które należy wykonać bez obciążenia sap lub niskiego obciążenia w określonej bazie danych. W programie SQL Server 2016 można zatrzymać i wznowić skanowanie TDE, które wykonuje początkowe szyfrowanie. W dokumencie Transparent Data Encryption (TDE) opisano polecenie i szczegóły.

W przypadku przenoszenia baz danych programu SAP SQL Server ze środowiska lokalnego na platformę Azure zalecamy przetestowanie, w której infrastrukturze można najszybciej zastosować szyfrowanie. W tym przypadku należy pamiętać o następujących faktach:

  • Nie można zdefiniować, ile wątków jest używanych do stosowania szyfrowania danych do bazy danych. Liczba wątków jest zasadniczo zależna od liczby woluminów dysku, w których są dystrybuowane dane programu SQL Server i pliki dziennika. Oznacza, że bardziej odrębne woluminy (litery dysku), tym więcej wątków będzie zaangażowanych równolegle w celu przeprowadzenia szyfrowania. Taka konfiguracja jest nieco sprzeczna z sugestią wcześniejszej konfiguracji dysku na temat tworzenia jednej lub mniejszej liczby miejsc do magazynowania dla plików bazy danych programu SQL Server na maszynach wirtualnych platformy Azure. Konfiguracja z kilkoma woluminami doprowadziłaby do kilku wątków wykonujących szyfrowanie. Szyfrowanie jednego wątku polega na odczytywaniu zakresów 64 KB, szyfruje go, a następnie zapisuje rekord w pliku dziennika transakcji, informując, że zakres został zaszyfrowany. W rezultacie obciążenie dziennika transakcji jest umiarkowane.
  • W starszych wersjach programu SQL Server kompresja kopii zapasowych nie zapewniała już wydajności podczas szyfrowania bazy danych programu SQL Server. Takie zachowanie może przekształcić się w problem polegający na tym, że plan polegał na zaszyfrowaniu lokalnej bazy danych programu SQL Server, a następnie skopiowaniu kopii zapasowej na platformę Azure w celu przywrócenia bazy danych na platformie Azure. Kompresja kopii zapasowych programu SQL Server może osiągnąć współczynnik kompresji 4.
  • W programie SQL Server 2016 program SQL Server wprowadził nowe funkcje, które umożliwiają kompresowanie kopii zapasowych zaszyfrowanych baz danych oraz w wydajny sposób. Aby uzyskać szczegółowe informacje, zobacz ten blog .

Korzystanie z usługi Azure Key Vault

Platforma Azure oferuje usługę usługi Key Vault do przechowywania kluczy szyfrowania. Program SQL Server po drugiej stronie oferuje łącznik do używania usługi Azure Key Vault jako magazynu dla certyfikatów TDE.

Więcej szczegółów dotyczących używania usługi Azure Key Vault dla list TDE programu SQL Server, takich jak:

Ważne

Korzystanie z funkcji TDE programu SQL Server, zwłaszcza w przypadku usługi Azure Key Vault, zaleca się używanie najnowszych poprawek programu SQL Server 2014, programu SQL Server 2016 i programu SQL Server 2017. Przyczyną jest to, że w oparciu o opinie klientów, optymalizacje i poprawki zostały zastosowane do kodu. Na przykład sprawdź plik KBA #4058175.

Minimalne konfiguracje wdrożenia

W tej sekcji sugerujemy zestaw minimalnych konfiguracji dla różnych rozmiarów baz danych w ramach obciążenia SAP. Zbyt trudno jest ocenić, czy te rozmiary pasują do określonego obciążenia. W niektórych przypadkach możemy być hojni w pamięci w porównaniu z rozmiarem bazy danych. Z drugiej strony rozmiar dysku może być zbyt niski dla niektórych obciążeń. W związku z tym te konfiguracje powinny być traktowane jako to, co są. Są to konfiguracje, które powinny dać punkt na początek. Konfiguracje w celu dostosowania do konkretnych wymagań dotyczących obciążenia i wydajności kosztów.

Przykład konfiguracji dla małego wystąpienia programu SQL Server o rozmiarze bazy danych z zakresu od 50 GB do 250 GB może wyglądać następująco:

Konfigurowanie Maszyna wirtualna SYSTEMU DBMS Komentarze
Typ maszyny wirtualnej E4s_v3/v4/v5 (4 procesory wirtualne/32 GiB RAM)
Accelerated Networking Włączanie
Wersja programu SQL Server SQL Server 2019 lub nowsze
Liczba plików danych 4
Liczba plików dziennika 1
Liczba plików danych tymczasowych 4 lub domyślne od programu SQL Server 2016
System operacyjny Windows Server 2019 lub nowsze
Agregacja dysku Miejsca do magazynowania w razie potrzeby
System plików NTFS
Formatowanie rozmiaru bloku 64 KB
Liczba i typ dysków danych Premium Storage v1: 2 x P10 (RAID0)
Premium Storage w wersji 2: 2 x 150 GiB (RAID0) — domyślna liczba operacji we/wy na sekundę i przepływność		 Pamięć podręczna = tylko do odczytu dla magazynu w warstwie Premium v1
# i typ dysków dziennika Premium storage v1: 1 x P20
Premium Storage w wersji 2: 1 x 128 GiB — domyślna liczba operacji we/wy na sekundę i przepływność		 Pamięć podręczna = BRAK
Parametr maksymalnej pamięci programu SQL Server 90% fizycznej pamięci RAM Przy założeniu pojedynczego wystąpienia

Przykład konfiguracji lub małego wystąpienia programu SQL Server o rozmiarze bazy danych z zakresu od 250 GB do 750 GB, takich jak mniejszy system SAP Business Suite, może wyglądać następująco:

Konfigurowanie Maszyna wirtualna SYSTEMU DBMS Komentarze
Typ maszyny wirtualnej E16s_v3/v4/v5 (16 procesorów wirtualnych/128 GiB RAM)
Accelerated Networking Włączanie
Wersja programu SQL Server SQL Server 2019 lub nowsze
Liczba plików danych 8
Liczba plików dziennika 1
Liczba plików danych tymczasowych 8 lub wartość domyślna od programu SQL Server 2016
System operacyjny Windows Server 2019 lub nowsze
Agregacja dysku Miejsca do magazynowania w razie potrzeby
System plików NTFS
Formatowanie rozmiaru bloku 64 KB
Liczba i typ dysków danych Premium Storage v1: 4 x P20 (RAID0)
Magazyn Premium w wersji 2: 4 x 100 GiB — 200 GiB (RAID0) — domyślna liczba operacji we/wy na sekundę i dodatkowa przepływność 25 MB/s na dysk		 Pamięć podręczna = tylko do odczytu dla magazynu w warstwie Premium v1
# i typ dysków dziennika Premium storage v1: 1 x P20
Premium Storage w wersji 2: 1 x 200 GiB — domyślna liczba operacji we/wy na sekundę i przepływność		 Pamięć podręczna = BRAK
Parametr maksymalnej pamięci programu SQL Server 90% fizycznej pamięci RAM Przy założeniu pojedynczego wystąpienia

Przykład konfiguracji dla średniego wystąpienia programu SQL Server o rozmiarze bazy danych z zakresu od 750 GB do 2000 GB, takich jak średni system SAP Business Suite, może wyglądać następująco:

Konfigurowanie Maszyna wirtualna SYSTEMU DBMS Komentarze
Typ maszyny wirtualnej E64s_v3/v4/v5 (64 procesory wirtualne/432 GiB RAM)
Accelerated Networking Włączanie
Wersja programu SQL Server SQL Server 2019 lub nowsze
Liczba urządzeń danych 16
Liczba urządzeń dziennika 1
Liczba plików danych tymczasowych 8 lub wartość domyślna od programu SQL Server 2016
System operacyjny Windows Server 2019 lub nowsze
Agregacja dysku Miejsca do magazynowania w razie potrzeby
System plików NTFS
Formatowanie rozmiaru bloku 64 KB
Liczba i typ dysków danych Magazyn Premium w wersji 1: 4 x P30 (RAID0)
Magazyn w warstwie Premium w wersji 2: 4 x 250 GiB — 500 GiB — plus 2000 operacji we/wy na sekundę i 75 MB/s przepływności na dysk		 Pamięć podręczna = tylko do odczytu dla magazynu w warstwie Premium v1
# i typ dysków dziennika Premium storage v1: 1 x P20
Premium Storage w wersji 2: 1 x 400 GiB — domyślna liczba operacji we/wy na sekundę i dodatkowa przepływność 75 MB/s		 Pamięć podręczna = BRAK
Parametr maksymalnej pamięci programu SQL Server 90% fizycznej pamięci RAM Przy założeniu pojedynczego wystąpienia

Przykład konfiguracji dla większego wystąpienia programu SQL Server o rozmiarze bazy danych z zakresu od 2000 GB do 4000 GB, na przykład większym systemem SAP Business Suite, może wyglądać następująco:

Konfigurowanie Maszyna wirtualna SYSTEMU DBMS Komentarze
Typ maszyny wirtualnej E96(d)s_v5 (96 procesorów wirtualnych/672 GiB RAM)
Accelerated Networking Włączanie
Wersja programu SQL Server SQL Server 2019 lub nowsze
Liczba urządzeń danych 24
Liczba urządzeń dziennika 1
Liczba plików danych tymczasowych 8 lub wartość domyślna od programu SQL Server 2016
System operacyjny Windows Server 2019 lub nowsze
Agregacja dysku Miejsca do magazynowania w razie potrzeby
System plików NTFS
Formatowanie rozmiaru bloku 64 KB
Liczba i typ dysków danych Magazyn Premium w wersji 1: 4 x P30 (RAID0)
Magazyn w warstwie Premium w wersji 2: 4 x 500 GiB — 800 GiB — plus 2500 operacji we/wy na sekundę i 100 MB/s przepływności na dysk		 Pamięć podręczna = tylko do odczytu dla magazynu w warstwie Premium v1
# i typ dysków dziennika Premium storage v1: 1 x P20
Magazyn Premium w wersji 2: 1 x 400 GiB — plus 1000 operacji we/wy na sekundę i dodatkowa przepływność 75 MB/s		 Pamięć podręczna = BRAK
Parametr maksymalnej pamięci programu SQL Server 90% fizycznej pamięci RAM Przy założeniu pojedynczego wystąpienia

Przykład konfiguracji dużego wystąpienia programu SQL Server o rozmiarze 4 TB lub większej niż duża globalnie używana wersja systemu SAP Business Suite może wyglądać następująco:

Konfigurowanie Maszyna wirtualna SYSTEMU DBMS Komentarze
Typ maszyny wirtualnej Seria M (od 1,0 do 4,0 TB pamięci RAM)
Accelerated Networking Włączanie
Wersja programu SQL Server SQL Server 2019 lub nowsze
Liczba urządzeń danych 32
Liczba urządzeń dziennika 1
Liczba plików danych tymczasowych 8 lub wartość domyślna od programu SQL Server 2016
System operacyjny Windows Server 2019 lub nowsze
Agregacja dysku Miejsca do magazynowania w razie potrzeby
System plików NTFS
Formatowanie rozmiaru bloku 64 KB
Liczba i typ dysków danych Premium Storage v1: 4+ x P40 (RAID0)
Premium Storage v2: 4+ x 1000 GiB - 4000 GiB - plus 4500 operacji we/wy na sekundę i 125 MB/s przepływności na dysk		 Pamięć podręczna = tylko do odczytu dla magazynu w warstwie Premium v1
# i typ dysków dziennika Premium storage v1: 1 x P30
Magazyn Premium w wersji 2: 1 x 500 GiB — plus 2000 operacji we/wy na sekundę i przepływność 125 MB/s		 Pamięć podręczna = BRAK
Parametr maksymalnej pamięci programu SQL Server 95% fizycznej pamięci RAM Przy założeniu pojedynczego wystąpienia

Na przykład ta konfiguracja to konfiguracja maszyny wirtualnej DBMS pakietu SAP Business Suite w programie SQL Server. Ta maszyna wirtualna hostuje bazę danych 30 TB pojedynczego globalnego wystąpienia pakietu SAP Business Suite globalnej firmy z ponad 200B rocznym przychodem i ponad 200 000 pracowników zatrudnionych w pełnym wymiarze godzin. System uruchamia wszystkie procesy przetwarzania finansowego, sprzedaży i dystrybucji oraz wiele innych procesów biznesowych z różnych obszarów, w tym Ameryka Północna n płac. System działa na platformie Azure od początku 2018 r. przy użyciu maszyn wirtualnych z serii M platformy Azure jako maszyn wirtualnych DBMS. W przypadku wysokiej dostępności system używa zawsze włączonej repliki synchronicznej w innej strefie dostępności tego samego regionu platformy Azure i innej repliki asynchronicznej w innym regionie świadczenia usługi Azure. Warstwa aplikacji NetWeaver jest wdrażana na maszynach wirtualnych Ev4.

Konfigurowanie Maszyna wirtualna SYSTEMU DBMS Komentarze
Typ maszyny wirtualnej M192dms_v2 (192 vCPU/4,196 GiB RAM)
Accelerated Networking Włączony
Wersja programu SQL Server SQL Server 2019
Liczba plików danych 32
Liczba plików dziennika 1
Liczba plików danych tymczasowych 8
System operacyjny Windows Server 2019
Agregacja dysku Miejsca do magazynowania
System plików NTFS
Formatowanie rozmiaru bloku 64 KB
Liczba i typ dysków danych Premium storage v1: 16 x P40 Pamięć podręczna = tylko do odczytu
# i typ dysków dziennika Premium storage v1: 1 x P60 Korzystanie z akceleratora zapisu
Liczba i typ dysków bazy danych tempdb Premium storage v1: 1 x P30 Brak buforowania
Parametr maksymalnej pamięci programu SQL Server 95% fizycznej pamięci RAM

Ogólne podsumowanie programu SQL Server dla oprogramowania SAP na platformie Azure

W tym przewodniku znajduje się wiele zaleceń i zalecamy przeczytanie go więcej niż raz przed zaplanowanym wdrożeniem platformy Azure. Ogólnie jednak pamiętaj, aby postępować zgodnie z głównymi ogólnymi zaleceniami systemu DBMS dotyczącymi platformy Azure:

  1. Użyj najnowszej wersji systemu DBMS, takiej jak SQL Server 2019, która ma największe zalety na platformie Azure.
  2. Starannie zaplanuj poziom systemu SAP na platformie Azure, aby zrównoważyć układ plików danych i ograniczenia platformy Azure:
    • Nie masz zbyt wielu dysków, ale masz wystarczająco dużo, aby upewnić się, że możesz uzyskać dostęp do wymaganej liczby operacji we/wy na sekundę.
      • Rozbieraj tylko dyski, jeśli chcesz uzyskać większą przepływność.
  3. Nigdy nie instaluj oprogramowania ani nie umieszczaj żadnych plików, które wymagają trwałości na dysku D:\, ponieważ jest on nietrwały i cokolwiek na tym dysku można utracić podczas ponownego uruchamiania systemu Windows lub ponownego uruchamiania maszyny wirtualnej.
  4. Użyj rozwiązania wysokiej dostępności/odzyskiwania po awarii dostawcy DBMS, aby replikować dane bazy danych.
  5. Zawsze używaj rozpoznawania nazw, nie polegaj na adresach IP.
  6. Za pomocą funkcji TDE programu SQL Server zastosuj najnowsze poprawki programu SQL Server.
  7. Należy zachować ostrożność przy użyciu obrazów programu SQL Server z witryny Azure Marketplace. W przypadku korzystania z programu SQL Server należy zmienić sortowanie wystąpienia przed zainstalowaniem dowolnego systemu SAP NetWeaver.
  8. Instalowanie i konfigurowanie monitorowania hosta SAP dla platformy Azure zgodnie z opisem w przewodniku wdrażania.

Następne kroki

Przeczytaj artykuł