Sdílet prostřednictvím


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 Azure IaaS. Jako předpoklad tohoto dokumentu si přečtěte důležité informace o dokumentu pro nasazení DBMS služby Azure Virtual Machines pro úlohy SAP a 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írá službou Microsoft Azure SQL Database, což je nabídka platformy jako služby platformy Microsoft Azure. Diskuze v tomto dokumentu se týká provozování produktu SQL Serveru, protože je známé pro místní nasazení ve službě Azure Virtual Machines s využitím funkce Infrastruktura jako služba 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 spuštěném na virtuálních počítačích Azure najdete v těchto článcích:

Ne všechny obsahy a příkazy 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 rušení sdílení prostředků dostupných v rámci jednoho virtuálního počítače je potřeba vzít v úvahu stejné aspekty jako v místním 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. Důležité informace o několika databázích SAP, které sdílejí 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 Serveru. Důvodem je počet uzlů NUMA prezentovaných v hostovaném operačním systému Windows Server, který má větší než 64 virtuálních procesorů příliš velký, aby sql Server vyhovoval. Zakázáním SMT v hostovaném operačním systému Windows Server dochází ke snížení počtu virtuálních procesorů. Počet virtuálních procesorů je tedy v každém uzlu NUMA menší než 64. Způsob, jak zakázat SMT, je zde popsán. 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, operačním systémem, spustitelnými soubory SQL Serveru by měly být spustitelné soubory SAP umístěné nebo nainstalované samostatné disky Azure. Většina systémových databází SQL Serveru se obvykle nevyužívá na vysoké úrovni 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. Databáze tempdb SQL Serveru by měla být umístěna na neperisistované jednotce D:\ nebo na samostatném disku.

  • U všech typů certifikovaných virtuálních počítačů SAP (viz SAP Note #1928533) je možné data databáze tempdb a soubory protokolů umístit na nepersistovanou jednotku D:\ .
  • U verzí SQL Serveru, kdy SQL Server instaluje databázi tempdb pouze s jedním datovým souborem, se doporučuje použít více datových souborů tempdb. 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í databázi tempdb využí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. Jednotka D:\ bez výkonu také nabízí lepší latenci a propustnost vstupně-výstupních operací. Pokud chcete určit správnou velikost databáze tempdb, můžete zkontrolovat velikosti databáze tempdb v existujících systémech.

Poznámka:

V případě, že umístíte datové soubory tempdb a soubor protokolu do složky na jednotce D:\, kterou jste vytvořili, je nutné zajistit, aby složka po restartování virtuálního počítače existovala. Vzhledem k tomu, že jednotka D:\ může být čerstvě inicializována po restartování virtuálního počítače všechny struktury souborů a adresářů může být vymazána. 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 zdokumentovaná v tomto článku.

Konfigurace virtuálního počítače, na které běží SQL Server s databází SAP a kde jsou data tempdb a soubor protokolu tempdb umístěné na jednotce D:\ a Azure Premium Storage v1 nebo v2 by vypadaly 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. Vzhledem k tomu, že ve velkých nasazeních, zejména v nasazeních, ve kterých se zákazník přesunul s heterogenní migrací databáze do SQL Serveru v Azure, jsme použili samostatné disky a potom distribuoval datové soubory mezi tyto disky. Taková architektura je úspěšná pouze 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.
  • Pro databázi tempdb použijte jednotku D:\, pokud je výkon dostatečně dobrý. Pokud je celková úloha omezená na výkon databáze tempdb umístěné na jednotce D:\, musíte databázi tempdb přesunout do úložiště Azure Premium Storage verze 1 nebo v2, jak je doporučeno v tomto článku.

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 databáze obsahuje příliš málo datových souborů nebo existující datové soubory jsou vysoce nevyvážené, nejlepší metodou, která je správná, je export a import R3load. Export a import R3load zahrnuje výpadek a měl by se provést pouze v případě, že dojde k zjevnému problému s výkonem, který je potřeba 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 roste datové soubory rovnoměrně, pokud je nastaven příznak trasování 1117 nebo pokud se SQL Server 2016 nebo vyšší používá bez příznaku trasování.

Speciální pro virtuální počítače řady M

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 do Azure. Pokud zadanou latenci služby Premium Storage v1 omezuje škálovatelnost úlohy SAP, je možné pro akcelerátor zápisu povolit disk, který ukládá soubor transakčního protokolu SQL Serveru. Podrobnosti lze přečíst v akcelerátoru zápisu dokumentu. Azure Write Accelerator nefunguje s diskem Azure Premium Storage v2 a Ultra. V obou případech je latence lepší než služba Azure Premium Storage v1. Akcelerátor zápisu nepodporuje ssd úrovně Premium 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.

SQL Server 2014 a novější verze SQL Serveru – 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 těchto dnech se nedoporučuje používat tuto metodu nasazení a místo toho zvolte Azure Premium Storage verze 1, Premium Storage v2 nebo Disk Úrovně Ultra. Závisí na požadavcích.

Aspekty zálohování nebo 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 údržby správného plánu zálohování a obnovení je důležitá pro funkci obnovení k určitému bodu v čase, aby se kompenzuje logické nebo ruční chyby. 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í image SQL Serveru mimo 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 imagí příležitostí pokrýt potřebu licencí tím, že se virtuální počítače s SQL Serverem už nainstalovaly. 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é jsou podporovány sapem pro jejich software, můžete použít jenom vy.
  • Kolace instance SQL Serveru, která je nainstalovaná na virtuálních počítačích nabízených na Azure Marketplace, není kolace SAP NetWeaver vyžaduje spuštění instance SQL Serveru. Kolaci ale můžete změnit podle pokynů v následující části.

Změna kolace SQL Serveru virtuálního počítače s Windows nebo 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 sadu 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ž je uvedeno, 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 obnovení pro jeden virtuální počítač s využitím různých blokových úložišť Azure, dvojice virtuálních počítačů nasazených ve skupině dostupnosti Azure nebo dvojice virtuálních počítačů nasazených v azure Zóny dostupnosti. 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 s využitím souborového serveru se škálováním na více systémů 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. V závislosti na Prostory úložiště se obecně podporuje clustering FCI SQL Serveru. 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 přesouvání protokolů 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 nastavení, které se provádí místně v souvislosti s nastavením přesouvání protokolů a principy přesouvání protokolů. 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
  • Přímé scénáře z místního prostředí do Azure. V těchto případech se přesouvání protokolů používá k synchronizaci nového nasazení databáze v Azure s probíhajícím produkčním systémem místně. V době, kdy dojde k výpadku, je produkční prostředí vypnuté a je zajištěno, že se do nasazení databáze Azure přenesly poslední a nejnovější zálohy transakčních protokolů. Pak se otevře nasazení databáze Azure pro produkční prostředí.

Sql Server AlwaysOn

Vzhledem k tomu, že místní sap podporuje alwaysOn (viz SAP Note #1772688), podporuje se v kombinaci se SAP v Azure. Nasazení naslouchacího procesu skupiny dostupnosti SQL Serveru (nezaměňovat se se skupinou dostupnosti Azure) je potřeba vzít v úvahu některé zvláštní aspekty. Proto jsou nezbytné některé různé kroky instalace.

Mezi důležité informace při použití naslouchacího procesu skupiny dostupnosti patří:

  • Použití naslouchacího procesu skupiny dostupnosti je možné pouze s Windows Serverem 2012 nebo novějším jako hostujícím operačním systémem virtuálního počítače. Pro Windows Server 2012 se ujistěte, že byla použita aktualizace umožňující 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 se funkce AlwaysOn potřebovala použít stejným způsobem jako zrcadlení databáze. Zadáním partnera pro převzetí služeb při selhání v připojovacím řetězci (provedeným prostřednictvím parametru SAP default.pfl dbs/mss/server – viz SAP Note #965908).
  • Pomocí naslouchacího procesu skupiny dostupnosti je potřeba připojit databázové virtuální počítače k vyhrazenému nástroji pro vyrovnávání 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 tomto článku). 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 sestavování konfigurace clusteru WSFC, kde cluster potřebuje přiřazenou speciální IP adresu, protože Azure s jeho aktuální funkcí přiřadí název clusteru stejnou IP adresu jako uzel, 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í proces 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 tyto koncové body bude potřeba zabezpečit pomocí seznamů ACL.

Podrobná dokumentace k nasazení AlwaysOnu s SQL Serverem v seznamech virtuálních počítačů Azure, jako jsou:

Poznámka:

Čtení úvodu ke skupinám dostupnosti AlwaysOn SQL Serveru na virtuálních počítačích Azure si přečtete o naslouchacím procesu DNN (Direct Network Name) SQL Serveru. Tato nová funkce byla představena s SQL Serverem 2019 CU8. Díky této nové funkci se používá nástroj pro vyrovnávání zatížení Azure, který zpracovává virtuální IP adresu naslouchacího procesu skupiny dostupnosti, zastaralá.

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 procesu skupiny dostupnosti S naslouchacím procesem skupiny dostupnosti musíte nasadit nástroj pro vyrovnávání zatížení Azure.
  • S SQL Serverem 2016 SP3, SQL Serverem 2017 CU 25 nebo SQL Serverem 2019 CU8 nebo novějšími verzemi SQL Serveru ve Windows Serveru 2016 nebo novějším můžete místo nástroje pro vyrovnávání zatížení Azure použít naslouchací proces DNN (Direct Network Name). DNN eliminuje požadavek na nástroj pro vyrovnávání zatížení Azure.

Použití parametrů připojení zrcadlení databáze SQL Serveru by mělo být považováno pouze za kolo vyšetřování problémů s dalšími dvěma metodami. 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í proces skupiny dostupnosti. A s tím, že žádný nástroj pro vyrovnávání zatížení Azure a s tím, který by mohl 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 funkce transparentního šifrování dat SQL Serveru (viz SAP Note #1380493).

Použití transparentního šifrování dat SQL Serveru

V případech, kdy provádíte heterogenní migraci z jiné databáze běžící místně na Windows/SQL Server běžící v Azure, byste měli předem vytvořit prázdnou cílovou databázi v SQL Serveru. Jako další krok použijete funkci transparentního šifrování dat SQL Serveru pro tuto prázdnou databázi. Důvodem, proč chcete v této sekvenci provést, je, ž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. Režie při importu do šifrované databáze má kratší dopad než šifrování databáze po fázi exportu ve fázi výpadku. Při pokusu o použití transparentního šifrování dat s úlohou SAP spuštěnou nad databází došlo k negativním zkušenostem. Proto doporučujeme považovat nasazení transparentního šifrování dat za aktivitu, kterou je potřeba provést bez úlohy SAP nebo s nízkou zátěží SAP v konkrétní databázi. Z SQL Serveru 2016 můžete zastavit a obnovit kontrolu transparentního šifrování dat, která provádí počáteční šifrování. Dokument transparentní šifrování dat (TDE) popisuje příkaz a podrobnosti.

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 je výrazně závislý na počtu diskových svazků, ve které jsou data a soubory protokolů SYSTÉMU SQL Server distribuovány. Znamená, že čím více jedinečných svazků (písmen jednotek), tím více vláken je zapojeno paralelně k provedení šifrování. Tato konfigurace je trochu v rozporu s návrhem dřívější konfigurace disku při vytváření jednoho nebo menšího počtu prostorů úložiště pro soubory databáze SQL Serveru na virtuálních počítačích Azure. Konfigurace s několika svazky by vedla k několika vláknům provádějícím šifrování. Šifrování jediného vlákna čte rozsahy 64 kB, šifruje ho a pak zapíše záznam do souboru transakčního protokolu, který říká, že rozsah je zašifrovaný. 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. Toto chování se může vyvinout jako problém, kdy váš plán zašifroval místní databázi SQL Serveru a pak zkopírovat zálohu do Azure, aby se databáze obnovila 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 seznamy transparentního šifrování dat SQL Serveru, jako jsou:

Důležité

Použití transparentního šifrování dat SQL Serveru, zejména u služby Azure Key Vault, se doporučuje používat nejnovější opravy SQL Serveru 2014, SQL Serveru 2016 a SQL Serveru 2017. Důvodem je to, že na základě zpětné vazby zákazníků, optimalizace a oprav se pro kód použily. Například zkontrolujte znalostní bázi KBA #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 v porovnání s velikostí databáze velkoryse v paměti. 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 dát na začátek 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ší
# of data files 4
# of log files 0
# of temp data files 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 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 = jen pro čtení pro premium storage v1
# a typ disků protokolu 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ěť = NONE
Parametr maximální paměti SQL Serveru 90 % fyzické paměti RAM Za předpokladu, že jedna instance

Příklad konfigurace nebo malé instance SQL Serveru s velikostí databáze mezi 250 GB – 750 GB, například menší systém SAP Business Suite, by mohl vypadat takto:

Konfigurace Databázový virtuální počítač Komentáře
Typ virtuálního počítače E16s_v3/v4/v5 (16 vCPU/128 GiB RAM)
Akcelerované síťové služby Povolit
Verze SQL Serveru SQL Server 2019 nebo novější
# of data files 8
# of log files 0
# of temp data files 8 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 bloku 64 kB
# a typ datových disků Premium Storage v1: 4 x P20 (RAID0)
Premium Storage v2: 4 x 100 GiB – 200 GiB (RAID0) – výchozí IOPS a 25 MB/s extra propustnost na disk nebo ekvivalentní SSD úrovně Premium v2
Cache = jen pro čtení pro premium storage v1
# a typ disků protokolu Premium storage v1: 1 x P20
Premium Storage v2: 1 x 200 GiB – výchozí IOPS a propustnost nebo ekvivalentní SSD úrovně Premium v2
Mezipaměť = NONE
Parametr maximální paměti SQL Serveru 90 % fyzické paměti RAM Za předpokladu, že jedna instance

Příklad konfigurace pro střední instanci SQL Serveru s velikostí databáze mezi 750 GB – 2 000 GB, jako je například střední systém SAP Business Suite, by mohl vypadat takto:

Konfigurace Databázový virtuální počítač Komentáře
Typ virtuálního počítače E64s_v3/v4/v5 (64 vCPU/432 GiB RAM)
Akcelerované síťové služby Povolit
Verze SQL Serveru SQL Server 2019 nebo novější
# of data devices 16
# of log devices 0
# of temp data files 8 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 bloku 64 kB
# a typ datových disků Premium Storage v1: 4 x P30 (RAID0)
Premium Storage v2: 4 x 250 GiB - 500 GiB - plus 2 000 IOPS a 75 MB/s propustnost na disk nebo ekvivalentní SSD úrovně Premium v2
Cache = jen pro čtení pro premium storage v1
# a typ disků protokolu Premium storage v1: 1 x P20
Premium Storage v2: 1 x 400 GiB – výchozí IOPS a 75 MB/s extra propustnost nebo ekvivalentní ssd úrovně Premium v2
Mezipaměť = NONE
Parametr maximální paměti SQL Serveru 90 % fyzické paměti RAM Za předpokladu, že jedna instance

Příklad konfigurace pro větší instanci SQL Serveru s velikostí databáze mezi 2 000 GB a 4 000 GB, jako je například větší systém SAP Business Suite, by mohl vypadat takto:

Konfigurace Databázový virtuální počítač Komentáře
Typ virtuálního počítače E96(d)s_v5 (96 vCPU/672 GiB RAM)
Akcelerované síťové služby Povolit
Verze SQL Serveru SQL Server 2019 nebo novější
# of data devices 24
# of log devices 0
# of temp data files 8 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 bloku 64 kB
# a typ datových disků Premium Storage v1: 4 x P30 (RAID0)
Premium Storage v2: 4 x 500 GiB – 800 GiB – plus 2500 IOPS a 100 MB/s propustnost na disk nebo ekvivalentní SSD úrovně Premium v2
Cache = jen pro čtení pro premium storage v1
# a typ disků protokolu Premium storage v1: 1 x P20
Premium Storage v2: 1 x 400 GiB – plus 1 000 IOPS a 75 MB/s extra propustnost nebo ekvivalentní SSD úrovně Premium v2
Mezipaměť = NONE
Parametr maximální paměti SQL Serveru 90 % fyzické paměti RAM Za předpokladu, že jedna instance

Příklad konfigurace pro velkou instanci SQL Serveru s velikostí databáze 4 TB+, jako je například velký globálně používaný systém SAP Business Suite, by mohl vypadat takto:

Konfigurace Databázový virtuální počítač Komentáře
Typ virtuálního počítače Řada M (1,0 až 4,0 TB RAM)
Akcelerované síťové služby Povolit
Verze SQL Serveru SQL Server 2019 nebo novější
# of data devices 32
# of log devices 0
# of temp data files 8 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 bloku 64 kB
# a typ datových disků Premium Storage v1: 4+ x P40 (RAID0)
Premium Storage v2: 4+ x 1 000 GiB - 4 000 GiB - plus 4 500 IOPS a 125 MB/s propustnost na disk nebo ekvivalentní SSD úrovně Premium v2
Cache = jen pro čtení pro premium storage v1
# a typ disků protokolu Premium storage v1: 1 x P30
Premium Storage v2: 1 x 500 GiB – plus 2 000 IOPS a propustnost 125 MB/s nebo ekvivalentní ssd úrovně Premium v2
Mezipaměť = NONE
Parametr maximální paměti SQL Serveru 95 % fyzické paměti RAM Za předpokladu, že jedna 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 spouští veškeré zpracování finančních prostředků, prodej a distribuci a mnoho dalších obchodních procesů z různých oblastí, včetně Severní Amerika n 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čů. Vzhledem k tomu, že systém používá AlwaysOn 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
# of data files 32
# of log files 0
# of temp data files 8
Operační systém Windows Server 2019
Agregace disků Prostory úložiště
Systém souborů NTFS
Formát velikosti 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 typ disků protokolu Premium Storage v1: 1 x P60 nebo ekvivalentní SSD úrovně Premium v2 Použití akcelerátoru zápisu
# a typ disků tempdb 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ě ale nezapomeňte postupovat podle hlavních doporučení SQL Serveru v Azure:

  1. Použijte nejnovější verzi SQLServeru, jako je SQL Server 2022, která má v Azure největší výhody.
  2. Pečlivě naplánujte prostředí systému SAP v Azure, abyste vyvážit rozložení datových souborů a omezení Azure:
    • Nemáte příliš mnoho disků, ale dostatek k zajištění toho, abyste dosáhli požadovaného počtu IOPS.
      • Prokládání mezi disky pouze v případě, že potřebujete dosáhnout vyšší propustnosti.
  3. Nikdy neinstalujte software ani neukládejte žádné soubory, které vyžadují trvalost na jednotku D:\ jako nepermanent. 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.
  4. Replikujte data databáze pomocí řešení AlwaysOn sql Serveru.
  5. Vždy používejte překlad ip adres, nespoléhejte na IP adresy.
  6. Pomocí transparentního šifrování dat SQL Serveru použijte nejnovější opravy SQL Serveru.
  7. Buďte opatrní při používání imagí SQL Serveru z Azure Marketplace. Pokud používáte SQL Server, musíte před instalací jakéhokoli systému SAP NetWeaver změnit kolaci instance.
  8. Nainstalujte a nakonfigurujte monitorování hostitele SAP pro Azure, jak je popsáno v průvodci nasazením.

Další kroky

Přečíst článek