Nasazení DBMS pro SQL Server Azure Virtual Machines pro SAP NetWeaver

Tento dokument popisuje několik různých oblastí, které je potřeba zvážit při nasazování SQL Serveru pro úlohy SAP v infrastruktuře Azure jako službě (IaaS). Jako předpoklad pro tento dokument si přečtěte důležité informace o nasazení DBMS služby Azure Virtual Machines pro úlohy SAP. Projděte si také další příručky v dokumentaci k úloze SAP v Azure.

Důležité

Oborem tohoto dokumentu je verze Systému Windows na SQL Serveru. SAP nepodporuje linuxovou verzi SQL Serveru s žádným softwarem SAP. Dokument se nezabývá Microsoft Azure SQL Database, což je Platforma jako služba (PaaS) poskytovaná platformou Microsoft Azure. Diskuze v tomto článku se týká spuštění produktu SQL Serveru, známého pro místní nasazení ve virtuálních počítačích Azure s využitím funkce IaaS v Azure. Možnosti a funkce databáze mezi těmito dvěma nabídkami se liší a neměly by se vzájemně kombinovat. Další informace najdete v tématu Azure SQL Database.

Obecně byste měli zvážit použití nejnovějších verzí SQL Serveru ke spouštění úloh SAP v Azure IaaS. Nejnovější verze SQL Serveru nabízejí lepší integraci do některých služeb a funkcí Azure. Nebo můžete mít změny, které optimalizují operace v infrastruktuře Azure IaaS.

Obecná dokumentace k SQL Serveru běžícímu na virtuálním počítači Azure najdete v těchto článcích:

Ne všechny příkazy a obsah provedené v obecné dokumentaci k SQL Serveru na virtuálním počítači Azure platí pro úlohy SAP. Dokumentace ale dává dobrý dojem na principy. Příkladem funkcí, které nejsou podporovány pro úlohy SAP, je použití clusteringu FCI.

V IaaS najdete některé informace specifické pro SQL Server, které byste měli vědět, než budete pokračovat:

  • Podpora verzí SQL: I v případě SAP Note #1928533 uvádějící, že minimální podporovaná verze SQL Serveru je SQL Server 2008 R2, okno podporovaných verzí SQL Serveru v Azure je také diktováno životním cyklem SQL Serveru. Rozšířená údržba SQL Serveru 2012 skončila v polovině roku 2022. V důsledku toho by aktuální minimální verze pro nově nasazené systémy měla být SQL Server 2014. Čím novější, tím lépe. Nejnovější verze SQL Serveru nabízejí lepší integraci do některých služeb a funkcí Azure. Nebo můžete mít změny, které optimalizují operace v infrastruktuře Azure IaaS.

  • Použití imagí z Azure Marketplace: Nejrychlejší způsob, jak nasadit nový virtuální počítač Microsoft Azure, je použít image z Azure Marketplace. Na Azure Marketplace jsou image, které obsahují nejnovější verze SQL Serveru. Image, ve kterých už je SQL Server nainstalovaný, se nedají okamžitě použít pro aplikace SAP NetWeaver. Důvodem je, že v těchto imagích se instaluje výchozí kolace SQL Serveru, nikoli kolace vyžadovaná pro systémy SAP NetWeaver. Pokud chcete takové image použít, projděte si kroky popsané v kapitole Použití image SQL Serveru z Webu Microsoft Azure Marketplace.

  • Podpora více instancí SQL Serveru v rámci jednoho virtuálního počítače Azure: Tato metoda nasazení je podporovaná. Mějte ale na paměti omezení prostředků, zejména v případě šířky pásma sítě a úložiště typu virtuálního počítače, který používáte. Podrobné informace najdete v článku Velikosti virtuálních počítačů v Azure. Tato omezení kvót vám můžou bránit implementovat stejnou architekturu s více instancemi, jakou můžete implementovat místně. Vzhledem k konfiguraci a interferencím při sdílení zdrojů dostupných v rámci jednoho VM je potřeba vzít v úvahu stejné aspekty jako v on-premise prostředí.

  • V jednom virtuálním počítači je podporováno několik databází SAP v jedné instanci SQL Serveru: Podporují se tyto konfigurace. Úvahy o více databázích SAP, které využívají sdílené prostředky jedné instance SQL Serveru, jsou stejné jako u místních nasazení. Mějte na paměti další limity, jako je počet disků, které je možné připojit k určitému typu virtuálního počítače. Nebo limity kvót sítě a úložiště pro konkrétní typy virtuálních počítačů jako podrobné velikosti virtuálních počítačů v Azure.

Nové virtuální počítače řady M a SQL Server

Azure vydal několik nových rodin skladových položek řady M-series v rámci rodiny Mv3. Některé typy virtuálních počítačů v této rodině by se neměly používat pro SQL Server, včetně SQL Serveru 2022 bez zakázání SMT (Hyperthreading) v hostovaném operačním systému Windows Server. Důvodem je, že počet uzlů NUMA prezentovaných v hostovaném OS Windows Server s více než 64 virtuálními procesory je příliš velký, aby jej SQL Server zvládl. Zakázáním SMT v hostovaném operačním systému Windows Server se sníží počet virtuálních procesorů. Počet virtuálních procesorů je tedy v každém uzlu NUMA menší než 64. Jak zakázat SMT je popsáno v sekci Zakázání SMT na virtuálním počítači Azure. Konkrétní typy virtuálních počítačů:

  • M176(d)s_3_v3 – zakažte SMT nebo jako alternativu použijte M176bds_4_v3 nebo M176bds_4_v3
  • M176(d)s_4_v3 – zakažte SMT nebo použijte M176bds_4_v3 jako alternativu
  • M624(d)s_12_v3 – zakažte SMT nebo jako alternativu použijte M416ms_v2
  • M832(d)s_12_v3 – zakažte SMT nebo jako alternativu použijte M416ms_v2
  • M832i(d)s_16_v3 – zakažte SMT nebo jako alternativu použijte M416ms_v2

Poznámka:

U některých nových typů virtuálních počítačů M(b)v3 může využití úložiště SSD úrovně Premium v1 uložené v mezipaměti čtení vést k nižším rychlostem IOPS čtení a zápisu, než byste získali v případě, že nepoužíváte mezipaměť pro čtení.

V souladu s obecným popisem by měly být operační systém, spustitelné soubory SQL Serveru a spustitelné soubory SAP umístěny nebo nainstalovány na samostatných discích Azure. Většina systémových databází SQL Serveru se obvykle nevyužívá ve vysokém rozsahu při práci s úlohou SAP NetWeaver. Systémové databáze SQL Serveru by však měly být společně s ostatními adresáři SQL Serveru na samostatném disku Azure. SQL Server tempdb by měl být umístěný na neperisistované jednotce D:\ nebo na samostatném disku.

  • Se všemi typy certifikovaných virtuálních počítačů SAP (viz SAP Note #1928533), tempdb data a soubory protokolů se dají umístit na nepersistovanou jednotku D:\ .
  • U verzí SQL Serveru, kdy se SQL Server instaluje tempdb pouze s jedním datovým souborem, se doporučuje použít více tempdb datových souborů. Mějte na paměti, že svazky jednotek D:\ se liší velikostí a schopnostmi na základě typu virtuálního počítače. Přesné velikosti jednotky D:\ různých virtuálních počítačů najdete v článku Velikosti virtuálních počítačů s Windows v Azure.

Tyto konfigurace umožňují tempdb spotřebovávat více místa a důležitějších vstupně-výstupních operací za sekundu (IOPS) a šířku pásma úložiště, než dokáže systémová jednotka poskytnout. Nepersistentní jednotka D:\ také nabízí lepší latenci a propustnost I/O operací. Pokud chcete určit správnou tempdb velikost, můžete zkontrolovat tempdb velikosti stávajících systémů.

Poznámka:

Pokud umístíte tempdb datové soubory a soubory protokolu do složky na jednotce D:\ , kterou jste vytvořili, musíte se ujistit, že složka existuje po restartování virtuálního počítače. Vzhledem k tomu, že jednotka D:\ může být po restartování virtuálního počítače čerstvě inicializována, je možné vymazat všechny soubory a adresářové struktury. Možnost opětovného vytvoření konečných adresářových struktur na jednotce D:\ před spuštěním služby SQL Serveru je popsána v tématu Použití disků SSD ve virtuálních počítačích Azure k ukládání rozšíření databáze tempDB a fondu vyrovnávacích pamětí SQL Serveru.

Konfigurace virtuálního počítače s SQL Serverem a databází SAP, kde tempdb data a tempdb protokolový soubor jsou umístěny na jednotce D:\ a Azure Premium Storage v1 nebo v2, bude vypadat takto:

Diagram jednoduché konfigurace disku virtuálního počítače pro SQL Server

Diagram zobrazuje jednoduchý případ. Jak je uvedeno v článku Důležité informace o nasazení DBMS pro virtuální počítače Azure pro úlohy SAP, typ úložiště Azure, počet a velikost disků závisí na různých faktorech. Obecně ale doporučujeme:

  • V případě menších a středně velkých nasazení použijte jeden velký svazek, který obsahuje datové soubory SQL Serveru. Důvodem této konfigurace je, že je jednodušší pracovat s různými vstupně-výstupními úlohami v případě, že datové soubory SQL Serveru nemají stejný volný prostor. Zatímco ve velkých nasazeních, zejména v nasazeních, ve kterých se zákazník přesunul s heterogenní migrací databáze na SQL Server v Azure, jsme použili samostatné disky a potom distribuoval datové soubory mezi tyto disky. Tato architektura je úspěšná jenom v případě, že každý disk má stejný počet datových souborů, všechny datové soubory mají stejnou velikost a přibližně mají stejné volné místo.
  • Použijte jednotku D:\drive tempdb, pokud je výkon dostatečně dobrý. Pokud je celková úloha omezena výkonem tempdb na jednotce D:\, musíte přesunout tempdb na Azure Premium Storage verzi 1 nebo v2 nebo na Disk Ultra, jak je doporučeno v pokynech pro osvědčené postupy výkonu.

Mechanismus proporcionální výplně SQL Serveru distribuuje čtení a zápisy do všech datových souborů rovnoměrně za předpokladu, že všechny datové soubory SQL Serveru mají stejnou velikost a mají stejné volné tempo. SAP na SQL Serveru zajišťuje nejlepší výkon při rovnoměrné distribuci čtení a zápisu napříč všemi dostupnými datovými soubory. Pokud má databáze příliš málo datových souborů nebo jsou stávající datové soubory vysoce nevyvážené, nejlepší metodou je export a import R3load. Export a importu R3load způsobuje výpadek a měl by se provést pouze, když je zde zjevný problém s výkonem, který je nutné vyřešit. Pokud jsou datové soubory pouze středně odlišné velikosti, zvyšte všechny datové soubory na stejnou velikost a SQL Server v průběhu času vyrovnává data. SQL Server automaticky zvětšuje velikost datových souborů rovnoměrně, pokud je nastaven příznak trasování 1117 nebo pokud se používá SQL Server 2016 nebo vyšší bez příznaku trasování.

Důležité informace o virtuálních počítačích řady M-Series

U virtuálního počítače Azure M-Series je možné snížit latenci zápisu do transakčního protokolu v porovnání s výkonem Azure Premium Storage v1 při použití akcelerátoru zápisu Azure. Pokud zadaná latence služby Premium Storage v1 omezuje škálovatelnost úlohy SAP, je možné pro disk, který ukládá soubor transakčního protokolu SQL Serveru, povolit funkci Write Accelerator. Podrobnosti lze přečíst v dokumentu Write Accelerator. Azure Write Accelerator nefunguje s Azure Premium Storage v2 a Ultra Disk. V obou případech je latence lepší než to, co poskytuje Azure Premium Storage v1. Akcelerátor zápisu nepodporuje Azure Premium SSD v2.

Poznámka:

U některých nových typů virtuálních počítačů M(b)v3 může využití úložiště SSD úrovně Premium v1 uložené v mezipaměti čtení vést k nižším rychlostem IOPS čtení a zápisu, než byste získali v případě, že nepoužíváte mezipaměť pro čtení.

Formátování disků

U SQL Serveru by velikost bloku NTFS pro disky obsahující data a soubory protokolu SQL Serveru měla být 64 kB. Jednotku D:\ nemusíte formátovat. Tato jednotka je předem naformátovaná.

Aby se zabránilo tomu, že obnovení nebo vytváření databází inicializuje datové soubory tak, že se obsah souborů nenuluje, ujistěte se, že kontext uživatele, ve kterém je služba SQL Serveru spuštěná, má oprávnění uživatele Provádět úlohy údržby svazku. Další informace naleznete v tématu Okamžité inicializace souboru databáze.

Ukládání databázových souborů přímo ve službě Azure Blob Storage

SQL Server 2014 a novější verze otevírají možnost ukládat databázové soubory přímo do Azure Blob Store bez obálky virtuálního pevného disku kolem nich. Tato funkce měla za cíl řešit nedostatky v úložišti bloků Azure po letech. V dnešní době se nedoporučuje používat tuto metodu nasazení. Místo toho volte Azure Premium Storage v1 nebo v2, nebo Ultra Disk, v závislosti na požadavcích.

Aspekty zálohování a obnovení pro SQL Server

Nasazení SQL Serveru do Azure je potřeba zkontrolovat architekturu zálohování. I když systém není produkčním systémem, musí se databáze SAP SQL Serveru pravidelně zálohovat. Vzhledem k tomu, že Azure Storage uchovává tři image, je teď zálohování méně důležité, pokud jde o kompenzační selhání úložiště. Priorita správné údržby plánu zálohování a obnovení je zajistit funkci obnovení k určitému bodu v čase pro kompenzaci logických nebo manuálních chyb. Cílem je buď použít zálohy k obnovení databáze zpět k určitému bodu v čase. Nebo použít zálohy v Azure k vytvoření jiného systému s kopírováním existující zálohy databáze.

Existuje několik způsobů zálohování a obnovení databází SQL Serveru v Azure. Pokud chcete získat nejlepší přehled a podrobnosti, přečtěte si dokument Zálohování a obnovení SQL Serveru na virtuálních počítačích Azure. Článek popisuje několik různých možností.

Použití obrazu SQL Serveru z Microsoft Azure Marketplace

Microsoft nabízí virtuální počítače na Azure Marketplace, které už obsahují verze SQL Serveru. Pro zákazníky SAP, kteří vyžadují licence pro SQL Server a Windows, může být použití těchto obrazů příležitostí k pokrytí potřeby licencí spuštěním virtuálních počítačů, které již mají nainstalovaný SQL Server. Aby bylo možné tyto image použít pro SAP, je potřeba vzít v úvahu následující aspekty:

  • Nehodnocené verze SQL Serveru získávají vyšší náklady než virtuální počítač s Windows nasazený z Azure Marketplace. Pokud chcete porovnat ceny, přečtěte si informace o cenách služby Windows Virtual Machines a cenách služby SQL Server Enterprise Virtual Machines.
  • Verze SQL Serveru, které SAP podporuje pro svůj software, můžete použít jenom vy.
  • Kolace instance SQL Serveru, nainstalovaná ve virtuálních počítačích v Azure Marketplace, není tou, kterou SAP NetWeaver vyžaduje pro spuštění instance SQL Serveru. Pokud chcete, můžete změnit řazení podle pokynů v následující části.

Změna kolace SQL Serveru virtuálního počítače s Windows SQL Serverem

Vzhledem k tomu, že image SQL Serveru na Azure Marketplace nejsou nastavené tak, aby používaly kolaci, která se vyžaduje pro aplikace SAP NetWeaver, je potřeba ji okamžitě po nasazení změnit. U SQL Serveru je možné tuto změnu kolace provést pomocí následujících kroků, jakmile je virtuální počítač nasazený a správce se může přihlásit k nasazeným virtuálnímu počítači:

  • Otevřete příkazové okno systému Windows jako správce.
  • Změňte adresář na C:\Program Files\Microsoft SQL Server\110\Setup Bootstrap\SQLServer2012.
  • Spusťte příkaz: Setup.exe /QUIET /ACTION=REBUILDDATABASE /INSTANCENAME=MSSQLSERVER /SQLSYSADMINACCOUNTS=<local_admin_account_name> /SQLCOLLATION=SQL_Latin1_General_Cp850_BIN2
    • <local_admin_account_name> je účet, který byl definován jako účet správce při prvním nasazení virtuálního počítače prostřednictvím galerie.

Proces by měl trvat jen několik minut. Pokud chcete zajistit, aby krok skončil se správným výsledkem, proveďte následující kroky:

  • Otevřete SQL Server Management Studio.
  • Otevřete okno dotazu.
  • Spusťte příkaz sp_helpsort v hlavní databázi SQL Serveru.

Požadovaný výsledek by měl vypadat takto:

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

Pokud se výsledek liší, zastavte jakékoli nasazení a prozkoumejte, proč příkaz nastavení nefungoval podle očekávání. Nasazení aplikací SAP NetWeaver do instance SQL Serveru s různými kódovými stránkami SQL Serveru než ta uvedená, není podporováno pro nasazení NetWeaver.

Vysoká dostupnost SQL Serveru pro SAP v Azure

Při použití SQL Serveru v nasazeních Azure IaaS pro SAP máte několik různých možností, jak přidat nasazení databázové vrstvy s vysokou dostupností. Azure poskytuje různé smlouvy SLA pro dobu up-time pro jeden virtuální počítač pomocí:

  • Různá bloková úložiště Azure
  • Pár virtuálních počítačů nasazených ve skupině dostupnosti Azure
  • Pár virtuálních počítačů nasazených napříč zónami dostupnosti Azure

U produkčních systémů očekáváme, že nasadíte dvojici virtuálních počítačů ve škálovací sadě virtuálních počítačů s flexibilní orchestrací napříč dvěma zónami dostupnosti. Další informace najdete v porovnání různých typů nasazení pro úlohy SAP. Na jednom virtuálním počítači běží aktivní instance SQL Serveru. Druhý virtuální počítač spouští pasivní instanci.

Clustering SQL Serveru pomocí škálovatelného souborového serveru Windows nebo sdíleného disku Azure

S Windows Serverem 2016 společnost Microsoft zavedla Prostory úložiště s přímým přístupem. Na základě Storage Spaces je clustering FCI SQL Serveru obecně podporován. Azure také nabízí sdílené disky Azure, které je možné použít pro clustering s Windows. Pro úlohy SAP nepodporujeme tyto možnosti vysoké dostupnosti.

Přesouvání protokolů SQL Serveru

Jednou z funkcí vysoké dostupnosti je log shipping SQL Serveru. Pokud virtuální počítače, které se účastní konfigurace vysoké dostupnosti, mají funkční překlad ip adres, není problém. Nastavení v Azure se neliší od jakéhokoli nastavení, které se provádí místně, pokud jde o nastavení přesouvání protokolů a principy s tím spojené. Podrobnosti o přesouvání protokolů SQL Serveru najdete v článku o přesouvání protokolů (SQL Server).

Funkce přesouvání protokolů SQL Serveru se v Azure těžko používala k dosažení vysoké dostupnosti v jedné oblasti Azure. V následujících scénářích však zákazníci SAP používali přesouvání protokolů s Azure úspěšně:

  • Scénáře zotavení po havárii z jedné oblasti Azure do jiné oblasti Azure
  • Konfigurace zotavení po havárii z místního prostředí do oblasti Azure
  • Scénáře přesunu z lokálního prostředí do Azure. V těchto případech se přeprava protokolů používá k synchronizaci nového nasazení databáze v Azure s probíhajícím produkčním systémem na místě. V době, kdy dojde k přerušení, se produkční prostředí vypne a zajistí, že se do nasazení databáze Azure přenesly poslední a nejnovější zálohy transakčních protokolů. Pak bude nasazení Azure databáze zpřístupněno pro produkční prostředí.

Sql Server AlwaysOn

AlwaysOn se podporuje pro místní SAP (viz SAP Note #1772688) a podporuje se v kombinaci se SAP v Azure. V souvislosti s nasazením naslouchací služby skupiny dostupnosti SQL Serveru (nezaměňovat se se skupinou dostupnosti Azure) je třeba vzít v úvahu zvláštní aspekty. Proto jsou nezbytné různé kroky instalace.

Některá hlediska použití listeneru skupiny dostupnosti jsou:

  • Použití naslouchacího procesu skupiny dostupnosti je možné pouze s Windows Serverem 2012 a novějším jako hostujícím operačním systémem virtuálního počítače. V případě Windows Serveru 2012 se ujistěte, že jsou použity naslouchací procesy skupiny dostupnosti SQL Serveru na virtuálních počítačích Microsoft Azure se systémem Windows Server 2008 R2 a Windows Server 2012 .
  • V systému Windows Server 2008 R2 tato oprava neexistuje. V takovém případě by funkce Always On musela být použita stejným způsobem jako zrcadlení databáze. Zadáním partnera pro převzetí služeb při selhání prostřednictvím parametru SAP default.pfl dbs/mss/server v připojovacím řetězci. Viz SAP Note #965908.
  • Pomocí posluchače skupiny dostupnosti je potřeba připojit databázové virtuální počítače k vyhrazenému vyrovnávači zatížení. Statické IP adresy byste měli přiřadit síťovým rozhraním těchto virtuálních počítačů v konfiguraci AlwaysOn. Definování statické IP adresy je popsáno v tématu Vytvoření virtuálního počítače se statickou privátní IP adresou. Statické IP adresy ve srovnání s protokolem DHCP brání přiřazení nových IP adres v případech, kdy se oba virtuální počítače můžou zastavit.
  • Při vytváření konfigurace clusteru WSFC, kde cluster potřebuje přiřazenou speciální IP adresu, je potřeba provést zvláštní kroky. Azure se svou aktuální funkcionalitou přiřadí názvu clusteru stejnou IP adresu jako uzlu, na kterém je cluster vytvořen. Toto chování znamená, že je nutné provést ruční krok pro přiřazení jiné IP adresy ke clusteru.
  • Naslouchací modul skupiny dostupnosti se vytvoří v Azure s koncovými body TCP/IP, které jsou přiřazené virtuálním počítačům s primárními a sekundárními replikami skupiny dostupnosti.
  • Je možné, že bude třeba tyto koncové body zabezpečit pomocí seznamů řízení přístupu (ACL).

Podrobná dokumentace k nasazení Always On s SQL Serverem na virtuálních počítačích Azure zahrnuje seznamy jako:

Poznámka:

Čtením úvodu ke skupinám dostupnosti Always On na virtuálních počítačích Azure se dozvíte o naslouchacím procesu DNN (Direct Network Name) SQL Serveru. Funkce DNN byla představena s SQL Serverem 2019 CU8. Tato nová funkce činí použití nástroje pro vyrovnávání zatížení Azure, který zpracovává virtuální IP adresu naslouchacího serveru skupiny dostupnosti, zbytečným.

SQL Server AlwaysOn je nejběžnější funkce vysoké dostupnosti a zotavení po havárii, které se používají v Azure pro nasazení úloh SAP. Většina zákazníků používá AlwaysOn pro zajištění vysoké dostupnosti v rámci jedné oblasti Azure. Pokud je nasazení omezeno pouze na dva uzly, máte dvě možnosti připojení:

  • Použití naslouchacího serveru skupiny dostupnosti S listenerem skupiny dostupnosti je nutné nasadit vyrovnávač zatížení Azure.

  • Naslouchací služba Direct Network Name (DNN) může být použita místo nástroje pro vyrovnávání zatížení Azure. Služba DNN eliminuje požadavek na použití nástroje pro vyrovnávání zatížení Azure, který platí také pro:

    • SQL Server 2016 SP3

      • Nové vydání SQL Serveru na Windows Serveru 2016

    • SQL Server 2017 CU 25

    • SQL Server 2019 CU8

Použití parametrů připojení pro zrcadlení databáze SQL Server by mělo být považováno pouze jako doplněk k zkoumání problémů pomocí dalších dvou metod. V tomto případě je potřeba nakonfigurovat připojení aplikací SAP způsobem, ve kterém jsou pojmenovány oba názvy uzlů. Přesné podrobnosti o takové konfiguraci na straně SAP jsou popsané v SAP Note #965908. Pomocí této možnosti byste nemuseli konfigurovat naslouchací službu skupiny pro dostupnost. A kvůli absenci nástroje pro vyrovnávání zatížení Azure bylo možné prozkoumat problémy s těmito komponentami. Připomeňme si ale, že tato možnost funguje jenom v případě, že skupinu dostupnosti omezíte na dvě instance.

Většina zákazníků používá funkci AlwaysOn SQL Serveru pro funkce zotavení po havárii mezi oblastmi Azure. Několik zákazníků také používá možnost provádět zálohy ze sekundární repliky.

SQL Server transparentní šifrování dat

Mnoho zákazníků používá SQL Server transparentní šifrování dat (TDE) při nasazování databází SAP SQL Serveru v Azure. SAP plně podporuje funkcionalitu TDE v SQL Serveru. Viz SAP Note #1380493.

Použití TDE na SQL Serveru

V případech, kdy provádíte heterogenní migraci z jiné databáze běžící místně na Windows SQL Server spuštěný v Azure, byste měli předem vytvořit prázdnou cílovou databázi v SQL Serveru. Jako další krok použijete funkci TDE serveru SQL na tuto prázdnou databázi. Důvod, proč to chcete provést v této sekvenci, je ten, že proces šifrování prázdné databáze může nějakou dobu trvat. Procesy importu SAP pak během fáze výpadku naimportují data do šifrované databáze. Náročnost importu do šifrované databáze má podstatně nižší dopad na čas než šifrování databáze po fázi exportu během doby nečinnosti. Při pokusu o použití transparentního šifrování dat (TDE) s úkolem SAP spuštěným nad databází vznikly negativní zkušenosti. Proto doporučujeme považovat nasazení Transparentního šifrování dat (TDE) za aktivitu, kterou je vhodné provést v době, kdy není, nebo je minimální zátěž SAP na konkrétní databázi. Od SQL Serveru 2016 můžete zastavit a znovu spustit TDE sken, který provádí počáteční šifrování.

V případech, kdy přesunete databáze SAP SQL Serveru z místního prostředí do Azure, doporučujeme otestovat, jakou infrastrukturu můžete použít nejrychleji. V tomto případě mějte na paměti tyto skutečnosti:

  • Nemůžete definovat, kolik vláken se používá k použití šifrování dat v databázi. Počet vláken závisí hlavně na počtu diskových svazků, na kterých jsou datové soubory a soubory protokolu SQL Serveru rozloženy. Čím více jedinečných svazků (písmen jednotek), tím více vláken běží paralelně, aby bylo možné šifrování provést. Taková konfigurace je v rozporu s návrhem konfigurace disku, který umožňuje vytvořit jeden nebo malý počet prostorů úložiště pro soubory databáze SQL Server v Azure virtuálních počítačích. Konfigurace s několika svazky vede k několika vláknům provádějícím šifrování. Jedno šifrované vlákno čte rozsahy 64 kB, zašifruje je a potom zapíše záznam do souboru transakčního protokolu, aby si poznamenal, že rozsah byl zašifrován. V důsledku toho je zatížení transakčního protokolu střední.
  • Ve starších verzích SQL Serveru už komprese zálohování nezísela efektivitu, když jste zašifrovali databázi SQL Serveru. Takové chování se může stát problémem, když byl vaším plánem zašifrovat místní databázi SQL Serveru a obnovit databázi v Azure. Komprese zálohování SQL Serveru může dosáhnout poměru komprese faktoru 4.
  • S SQL Serverem 2016 zavedl SQL Server nové funkce, které umožňují efektivně komprimovat zálohování šifrovaných databází. Podrobnosti najdete v tomto blogu .

Použití služby Azure Key Vault

Azure nabízí službu Key Vault pro ukládání šifrovacích klíčů. SQL Server na druhé straně nabízí konektor pro použití služby Azure Key Vault jako úložiště certifikátů transparentního šifrování dat.

Další podrobnosti o používání služby Azure Key Vault pro SQL Server TDE, například:

Důležité

Pokud používáte SQL Server TDE, zejména se službou Azure Key Vault, doporučujeme používat nejnovější opravy SQL Serveru 2014, SQL Serveru 2016 a SQL Serveru 2017. Důvodem je, že na základě zpětné vazby zákazníků se pro kód použily optimalizace a opravy. Například zkontrolujte článek znalostní báze č. 4058175.

Minimální konfigurace nasazení

V této části navrhujeme sadu minimálních konfigurací pro různé velikosti databází v rámci úlohy SAP. Je příliš obtížné posoudit, jestli tyto velikosti odpovídají vašim konkrétním úlohám. V některých případech můžeme být s pamětí velkorysí ve srovnání s databází. Na druhé straně může být velikost disku pro některé úlohy příliš nízká. Proto by se tyto konfigurace měly považovat za to, co jsou. Jedná se o konfigurace, které by vám měly poskytnout výchozí bod. Konfigurace pro vyladění konkrétních požadavků na úlohu a nákladovou efektivitu

Příklad konfigurace pro malou instanci SQL Serveru s velikostí databáze mezi 50 GB – 250 GB může vypadat takto:

Konfigurace Databázový virtuální počítač Komentáře
Typ virtuálního počítače E4s_v3/v4/v5 (4 vCPU/32 GiB RAM)
Akcelerované síťové služby Povolit
Verze SQL Serveru SQL Server 2019 nebo novější
Počet datových souborů 4
Počet souborů logu 0
Počet dočasných datových souborů 4 nebo výchozí od SQL Serveru 2016
Operační systém Windows Server 2019 nebo novější
Agregace disků Prostory úložiště v případě potřeby
Systém souborů NTFS
Formát velikosti datového bloku 64 kB
# a typ datových disků Premium Storage v1: 2 x P10 (RAID0)
Premium Storage v2: 2 x 150 GiB (RAID0) – výchozí IOPS a propustnost nebo ekvivalentní SSD úrovně Premium v2		 Cache = pouze pro čtení pro prémiové úložiště v1
# a počet a typ logovacích disků Premium storage v1: 1 x P20
Premium Storage v2: 1 x 128 GiB – výchozí IOPS a propustnost nebo ekvivalentní SSD úrovně Premium v2		 Mezipaměť = ŽÁDNÁ
Parametr maximální paměti SQL Serveru 90 % fyzické paměti RAM Při předpokladu jedné instance

Tato konfigurace je například konfigurace databázového virtuálního počítače sap Business Suite na SQL Serveru. Tento virtuální počítač hostuje databázi 30 TB jedné globální instance SAP Business Suite globální společnosti s více než 200B ročními výnosy a více než 200 tisíc zaměstnanců na plný úvazek. Systém provádí veškeré finanční zpracování, zpracování prodeje a distribuce a mnoho dalších obchodních procesů z různých oblastí, včetně Severoamerické mzdy. Systém běží v Azure od začátku roku 2018 pomocí virtuálních počítačů řady Azure M jako databázových virtuálních počítačů. Systém pro vysokou dostupnost používá Always On s jednou synchronní replikou v jiné zóně dostupnosti stejné oblasti Azure. A další asynchronní replika v jiné oblasti Azure. Aplikační vrstva NetWeaver je nasazená na nejnovějších rodinách virtuálních počítačů D(a)/E(a).

Konfigurace Databázový virtuální počítač Komentáře
Typ virtuálního počítače M192dms_v2 (192 vCPU/4 196 GiB RAM)
Akcelerované síťové služby Povoleno
Verze SQL Serveru SQL Server 2019
Počet datových souborů 32
Počet souborů logu 0
Počet dočasných datových souborů 8
Operační systém Windows Server 2019
Agregace disků Prostory úložiště
Systém souborů NTFS
Formát velikosti datového bloku 64 kB
# a typ datových disků Premium Storage v1: 16 x P40 nebo ekvivalentní SSD úrovně Premium v2 Mezipaměť = jen pro čtení
# a počet a typ logovacích disků Premium Storage v1: 1 x P60 nebo ekvivalentní SSD úrovně Premium v2 Použití akcelerátoru zápisu
# a typ tempdb disků Premium Storage v1: 1 x P30 nebo ekvivalentní SSD úrovně Premium v2 Žádné ukládání do mezipaměti
Parametr maximální paměti SQL Serveru 95 % fyzické paměti RAM

Obecný souhrn SQL Serveru pro SAP v Azure

Tato příručka obsahuje mnoho doporučení a před plánováním nasazení Azure ji doporučujeme přečíst více než jednou. Obecně platí, že se ujistěte, že postupujete podle hlavních doporučení sql Serveru v Azure:

  • Použijte nejnovější verzi SQLServeru, jako je SQL Server 2022, která má v Azure největší výhody.
  • Pokud chcete vyvážit rozložení datových souborů a omezení Azure, pečlivě naplánujte systém SAP v Azure:
    • Nemáte příliš mnoho disků, ale dostatek k zajištění toho, abyste dosáhli požadovaného počtu IOPS.
      • Páskování přes disky použijte pouze v případě, že potřebujete dosáhnout vyšší propustnosti.
  • Nikdy neinstalujte software ani neukládejte žádné soubory, které vyžadují trvalost, na jednotku D:\, protože není trvalý. Při restartování nebo restartování virtuálního počítače s Windows může dojít ke ztrátě čehokoli na této jednotce.
  • K replikaci databázových dat použijte řešení ALWAYSOn SQL Serveru.
  • Vždy používejte překlad jmen, nespoléhejte na IP adresy.
  • Pomocí SQL Server TDE použijte nejnovější opravy SQL Serveru.
  • Při používání imagí SQL Serveru z Azure Marketplace buďte opatrní. Pokud používáte SQL Server, musíte před instalací jakéhokoli systému SAP NetWeaver změnit kolaci instance.
  • Nainstalujte a nakonfigurujte monitorování hostitele SAP pro Azure, jak je popsáno v průvodci nasazením.
  • Last updated on