SQL Server Nasazení Azure Virtual Machines DBMS pro SAP NetWeaver

Tento dokument popisuje několik různých oblastí, které je třeba zvážit při nasazování SQL Server úlohy SAP v Azure IaaS. Jako předběžnou podmínku tohoto dokumentu byste si měli přečíst dokument Důležité informace o nasazení Azure Virtual Machines DBMS pro úlohy SAP a další příručky v dokumentaci k úlohám SAP v Azure.

Důležité

Oborem tohoto dokumentu je Windows na SQL Server. SAP v žádném ze softwarových aplikací SAP SQL Server verzi Linuxu. Dokument se nezabývá Microsoft Azure SQL Database, což je nabídka platformy jako služby pro Microsoft Azure platformy. V tomto dokumentu se diskutuje o provozu produktu SQL Server, který je známý pro místní nasazení v Azure Virtual Machines s využitím funkce infrastruktury jako služby v Azure. Možnosti a funkce databáze mezi těmito dvěma nabídkami se liší a neměly by se vzájemně míchat. Viz také: https://azure.microsoft.com/services/sql-database/

Obecně byste měli zvážit použití nejnovějších verzí SQL Server ke spouštění úloh SAP v Azure IaaS. Nejnovější SQL Server 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.

Než budete pokračovat, doporučujeme si článek Co je SQL Server azure Virtual Machines (Windows).

V následujících částech se části dokumentace pod výše uvedeným odkazem agregují a zmiňují. Zmiňme také specifika týkající se SAP a některé koncepty jsou podrobněji popsány. Důrazně ale doporučujeme nejprve projít si výše uvedenou dokumentaci, než si SQL Server pro konkrétní dokumentaci.

V konkrétních SQL Server IaaS byste měli vědět několik informací, než budete pokračovat:

  • SQL verze: Pro zákazníky SAP se SQL Server virtual machine podporuje verze 2008 R2 Microsoft Azure novější. Starší edice se nepodporují. Další podrobnosti najdete v tomto obecném prohlášení o podpoře. Obecně platí, že SQL Server 2008 podporuje také Microsoft. Vzhledem k významným funkcím pro SAP, které byly zavedeny v SQL Server 2008 R2, je SQL Server 2008 R2 minimální verzí pro SAP. Obecně byste měli zvážit použití nejnovějších verzí SQL Server ke spouštění úloh SAP v Azure IaaS. Nejnovější SQL Server 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. Dokument je proto omezen na SQL Server 2016 a SQL Server 2017.
  • SQL výkon: Microsoft Azure hostované Virtual Machines dobře ve srovnání s jinými nabídkami virtualizace veřejného cloudu, ale jednotlivé výsledky se můžou lišit. Podívejte se na článek Osvědčené postupy z oblasti výkonu pro SQL Server v Azure Virtual Machines.
  • Použití imagí z Azure Marketplace: Nejrychlejší způsob nasazení nového virtuálního Microsoft Azure virtuálního počítače je použít image z Azure Marketplace. V této verzi jsou Azure Marketplace image, které obsahují nejnovější SQL Server verzí. Image, SQL Server jsou už nainstalované, není možné okamžitě použít pro aplikace SAP NetWeaver. Důvodem je výchozí nastavení, SQL Server se kolace instaluje v rámci těchto imagí, a ne kolace vyžadované systémy SAP NetWeaver. Pokud chcete takové obrázky použít, podívejte se na postup popsaný v kapitole Použití SQL Server obrázku z Microsoft Azure Marketplace.
  • SQL Server více instancí v rámci jednoho virtuálního počítače Azure: Tato metoda nasazení je podporovaná. Je však třeba mít na paměti omezení prostředků, zejména v případě šířky pásma sítě a úložiště pro typ 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 můžou bránit v implementaci stejné architektury s více instancemi, jako můžete implementovat místně. Od konfigurace a interference 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í.
  • Několik databází SAP v SQL Server instanci na jednom virtuálním počítače: Stejně jako výše jsou podporované konfigurace, jako jsou tyto. Aspekty více databází SAP sdílejících sdílené prostředky jedné instance SQL Server jsou stejné jako u místních nasazení. Další mějte na paměti i další omezení, jako je počet disků, které je možné připojit ke konkrétnímu typu virtuálního počítače. Nebo omezení kvót sítě a úložiště pro konkrétní typy virtuálních počítačů, jak je podrobně velikosti pro virtuální počítače v Azure.

V souladu s obecným popisem, operačním systémem, spustitelnými soubory SQL Server a v případě systémů SAP se 2 vrstvami musí být spustitelné soubory SAP umístěné nebo nainstalované samostatné disky Azure. Většina běžných systémových databází SQL Server úlohou SAP NetWeaver na vysoké úrovni nevyužívat. Nicméně systémové databáze SQL Server (hlavní databáze, databáze MSDB a model) by měly být společně s ostatními SQL Server adresáři na samostatném disku Azure. SQL Server databáze tempdb by měla být umístěná ve složce D:\ bez přípony nebo na samostatný disk.

  • Všechny typy virtuálních počítače s certifikací SAP (viz SAP Note 1928533) s výjimkou virtuálních počítače řady A, dat tempdb a souborů protokolů je možné umístit do neuchované složky D:\ Jednotky.
  • U starších SQL Server verzí, kdy SQL Server databáze tempdb s jedním datovým souborem ve výchozím nastavení, se doporučuje použít více datových souborů databáze tempdb. Uvědomte si D:\ Svazky jednotky se liší podle typu virtuálního počítače. Přesné velikosti složky D:\ různých virtuálních počítačů, podívejte se na článek Velikosti virtuálních Windows počítačů v Azure.

Tyto konfigurace umožňují databázi tempdb spotřebovávat více místa a důležitější je větší IOPS a šířka pásma úložiště, než dokáže poskytovat systémová jednotka. The nonpersistent D:\ disk také nabízí lepší latenci a propustnost V/V (s výjimkou virtuálních počítače řady A). 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 datové soubory tempdb a soubor protokolu umístěte do složky ve složce D:\ na vytvořené jednotce, musíte se ujistit, že složka po restartování virtuálního počítače existuje. Vzhledem k tomu, že D:\ Jednotka se po restartování virtuálního počítače znovu inicializuje a vymažou se všechny struktury souborů a adresářů. Možnost znovu vytvořit struktury případných adresářů v adresáři D:\ před zahájením služby SQL Server je zdokumentovaná v tomto článku.

Konfigurace virtuálního počítače, která běží SQL Server s databází SAP a kde jsou data databáze tempdb a soubor protokolu tempdb umístěné v D:\ Jednotka by vypadala takhle:

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

V diagramu výše se zobrazí jednoduchý případ. Jak je uvedené v článku Důležité informace pro nasazení Azure Virtual Machines DBMSpro úlohy SAP, typ úložiště Azure, počet a velikost disků závisí na různých faktorech. Obecně ale doporučujeme:

  • Použití jednoho velkého svazku, který obsahuje SQL Server datové soubory. Důvodem pro tuto konfiguraci je, že v reálném životě existuje mnoho databází SAP s různými databázovými soubory s různými V/V úlohami.
  • Pokud je výkon dostatečně dobrý, použijte pro databázi tempdb složku D:\drive. Pokud je celková úloha omezena výkonem databáze tempdb umístěnou ve složce D:\ disk, který možná budete muset zvážit při přesunu databáze tempdb na samostatné disky Azure Premium Storage nebo Ultra podle doporučení v tomto článku.

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

V případě virtuálního počítače Azure M-series se latence zápisu do transakčního protokolu může snížit faktory v porovnání s výkonem služby Azure Premium Storage při použití azure Akcelerátor zápisu. Proto byste měli nasadit Azure Akcelerátor zápisu virtuálních hd(ů), které tvoří svazek pro SQL Server transakční protokol. Podrobnosti si můžete přečíst v dokumentu Akcelerátor zápisu.

Formátování disků

Například SQL Server systému souborů NTFS pro disky, které obsahují SQL Server dat a souborů protokolu, 64 kB. D:\ není potřeba formátovat. Jednotky. Tato jednotka je předem naformátovaná.

Abyste se ujistili, že obnovení nebo vytvoření databází neicializuje datové soubory vynulováním obsahu souborů, měli byste se ujistit, že kontext uživatele, ve SQL Server je spuštěná služba SQL Server, má určitá oprávnění. Uživatelé ve skupině Windows mají obvykle tato oprávnění. Pokud je SQL Server spuštěná v kontextu uživatele uživatele, který není správcem Windows, musíte mu přiřadit uživatelské oprávnění Provádět úlohy údržby svazků. Podrobnosti najdete v tomto znalostní báze Microsoft Knowledge Base článku: https://support.microsoft.com/kb/2574695

Dopad komprese databáze

V konfiguracích, kde se může omezovat šířka pásma vstupně-výstupních operací, může každá míra, která snižuje počet IOPS, pomoct roztáhnout úlohu ve scénáři IaaS, jako je Azure. Proto, pokud jste to ještě neudělali, doporučuje sap i Microsoft před nahráním existující databáze SAP do Azure použít kompresi SQL Server PAGE.

Doporučení k provedení komprese databáze před nahráním do Azure je uvedené ze dvou důvodů:

  • Množství dat, která se nahrají, je nižší.
  • Doba provádění komprese je kratší za předpokladu, že je možné použít silnější hardware s více procesory nebo větší šířkou pásma pro V/V nebo menší latenci V/V v místním prostředí.
  • Menší velikosti databází můžou vést k nižším nákladům na přidělení disku.

Komprese databáze funguje stejně jako v Virtual Machines Azure stejně jako v místním prostředí. Další podrobnosti o komprimaci existujících databází SAP NetWeaver SQL Server najdete v článku Vylepšený kompresní nástroj SAP MSSCOMPRESS.

SQL Server 2014 a novější – ukládání databázových souborů přímo do azure blob Storage

SQL Server 2014 a novějších verzích otevírají možnost ukládat databázové soubory přímo do Úložiště objektů blob v Azure bez "obálky" virtuálního pevného disku kolem nich. Zvláště při použití standardu Azure Storage nebo menších typů virtuálních počítačů tento typ nasazení umožňuje scénáře, kdy můžete překonat limity IOPS, které by vynucoval omezený počet disků, které je možné připojit k některým menším typům virtuálních počítačů. Tento způsob nasazení funguje pro uživatelské databáze, ale ne pro systémové databáze SQL Server. Funguje také pro data a soubory protokolů SQL Server. Pokud chcete nasadit databázi SAP SQL Server tímto způsobem místo "zabalení" do virtuálních disků, mějte na paměti:

  • Použitý Storage virtuálního počítače musí být ve stejné oblasti Azure jako ten, který se používá k nasazení virtuálního počítače SQL Server ve které běží.
  • Pro tuto metodu nasazení platí také předchozí důležité informace týkající se distribuce virtuálních měr Azure Storage různých virtuálních měr. Znamená, že se V/V operace počítají do limitů Azure Storage účtu.
  • Místo účtování podle kvóty V/V úložiště virtuálního počítače se provoz objektů blob úložiště představujících data SQL Server a soubory protokolů bude započítat do šířky pásma sítě virtuálního počítače konkrétního typu virtuálního počítače. Informace o šířce pásma sítě a úložiště konkrétního typu virtuálního počítače najdete v článku Velikosti Windows virtuálních počítačů v Azure.
  • V důsledku nasazování V/V souborů prostřednictvím kvóty sítě se kvóta úložiště většinou uchýluje a s tím, že celkovou šířku pásma virtuálního počítače využívají jenom částečně.
  • Cíle výkonu vstupně-výstupních operací a vstupně-výstupních operací, které azure Premium Storage pro různé velikosti disků, už neplatí. I v případě, že se objekty blob, které jste vytvořili, nacházejí v Azure Premium Storage. Cíle jsou zdokumentované v článku Vysoce výkonné Premium Storage a spravované disky pro virtuální počítače. V důsledku umístění datových souborů SQL Server protokolů přímo do objektů blob uložených v Azure Premium Storage se výkonové charakteristiky mohou lišit v porovnání s virtuálními počítači v Azure Premium Storage.
  • Ukládání do mezipaměti na základě hostitele, jak je k dispozici pro azure Premium Storage disky není k dispozici při SQL Server datových souborů přímo do objektů blob Azure.
  • Na virtuálních počítači řady M-series Akcelerátor zápisu Azure použít k podpoře zápisů do souboru transakčního protokolu v řádu SQL Server milisekund.

Podrobnosti o této funkci najdete v článku o SQL Server datových souborů v Microsoft Azure

Pro produkční systémy doporučujeme se této konfiguraci vyhnout SQL Server místo přímého umístění datových SQL Server souborů protokolu v azure Premium Storage VHD.

SQL Server fondu vyrovnávací paměti 2014

SQL Server 2014 zavedl novou funkci, která se nazývá rozšíření fondu vyrovnávacích pamětí. Tato funkce rozšiřuje fond vyrovnávacích pamětí SQL Server, který se uchová v paměti s mezipamětí druhé úrovně, která je zálohovaná místními disky SSD serveru nebo virtuálního počítače. Rozšíření fondu vyrovnávacích pamětí umožňuje zachovat větší pracovní sadu dat "v paměti". V porovnání s přístupem k Azure Standard Storage přístup do rozšíření fondu vyrovnávacích pamětí, který je uložený na místních ssdcích virtuálního počítače Azure, je mnoho faktorů rychlejší. Porovnání rozšíření fondu vyrovnávacích pamětí s azure Premium Storage mezipaměti pro čtení, jak se doporučuje pro SQL Server datových souborů, neočekává se u rozšíření fondu vyrovnávacích pamětí žádné významné výhody. Důvodem je to, že obě mezipaměti (SQL Server fondu vyrovnávacích pamětí a Premium Storage mezipaměti pro čtení) používají místní disky výpočetního uzlu Azure.

Zkušenosti získané mezitím s rozšířením fondu vyrovnávacích pamětí SQL Server úlohou SAP jsou smíšené a stále neumožňují jasná doporučení, jestli ho ve všech případech používat. Ideální případ je, že pracovní sada, kterou aplikace SAP vyžaduje, se vejde do hlavní paměti. Vzhledem k tomu, že Azure mezitím nabízí virtuální počítače, které mají až 4 TB paměti, by mělo být dosažitelné zachovat pracovní sadu v paměti. Použití rozšíření fondu vyrovnávacích pamětí je proto omezené na některé vzácné případy a nemělo by jít o běžný případ.

Důležité informace o zálohování a obnovení pro SQL Server

Při nasazování SQL Server do Azure je nutné zkontrolovat metodologii zálohování. I když systém není produkčním systémem, databáze SAP hostovaná systémem SQL Server musí být pravidelně zálohována. Protože Azure Storage tři image, je teď zálohování méně důležité v souvislosti s kompenzačním selháním úložiště. Důvodem priority pro zachování správného plánu zálohování a obnovení je více, než to, že můžete kompenzovat logické a ruční chyby tím, že poskytnete možnosti obnovení k bodu v čase. Cílem tedy 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 nasáhnutí jiného systému zkopírováním stávající databáze.

Pokud se chcete podívat na různé SQL Server zálohování v Azure, přečtěte si článek Zálohování a obnovení pro SQL Server v Azure Virtual Machines. Tento článek se zabývá několika různými možnostmi.

Ruční zálohování

Máte několik možností, jak provádět ruční zálohování:

  1. Provádění konvenčních SQL Server zálohování na přímo připojené disky Azure. Tato metoda má výhodu, že máte rychle dostupné zálohy pro aktualizace systému a sestavování nových systémů jako kopií stávajících systémů SAP.
  2. SQL Server 2012 CU4 a vyšší může zálohovat databáze na adresu URL úložiště Azure.
  3. File-Snapshot zálohy pro databázové soubory ve službě Azure Blob Storage. Tato metoda funguje jenom v případě, SQL Server jsou vaše data a soubory protokolů umístěné ve službě Azure Blob Storage.

První metoda je dobře známá a používá se v mnoha případech i v místním světě. I tak ale máte úlohu, která řeší dlouhodobější umístění zálohy. Vzhledem k tomu, že nechcete uchovat zálohy po dobu 30 nebo více dnů v místně připojeném Azure Storage, je potřeba použít buď službu Azure Backup Services, nebo jiný nástroj pro zálohování a obnovení třetí strany, který zahrnuje správu přístupu a uchovávání pro vaše zálohy. Nebo sestavíte velký souborový server v Azure pomocí Windows prostorů úložiště.

Druhá metoda je popsána blíže v článku o SQL Server zálohování na adresu URL. Různé verze SQL Server mají v této funkci několik variací. Proto byste si měli prohlédněte dokumentaci ke kontrole konkrétních SQL Server verzí. Je důležité si uvědomit, že tento článek obsahuje řadu omezení. Buď máte možnost provést zálohování proti:

  • Jeden objekt blob stránky Azure, který pak omezuje velikost zálohy na 1 000 GB. Toto omezení také omezuje propustnost, které můžete dosáhnout.
  • Více (až 64) objektů blob bloku Azure, které umožňují teoretickou velikost zálohy 12 TB. Při testech u databází zákazníků se však zjistilo, že maximální velikost zálohy může být menší než teoretický limit. V takovém případě zodpovídáte také za správu uchovávání záloh a přístup k zálohám.

Automatizovaná záloha pro SQL Server

Automatizované zálohování poskytuje službu automatického zálohování pro SQL Server Standard a Enterprise edici běžící na virtuálním Windows virtuálním počítači v Azure. Tuto službu poskytuje rozšíření agenta SQL Server IaaS,které se automaticky instaluje SQL Server Windows imagí virtuálních počítačů v Azure Portal. Pokud nasadíte vlastní image operačního systému s SQL Server nainstalovanými imagemi, musíte rozšíření virtuálního počítače nainstalovat samostatně. Nezbytné kroky jsou dokumentované v tomto článku.

Další podrobnosti o možnostech této metody najdete v těchto článcích:

Když se podíváme na dokumentaci, uvidíte, že funkce s nejnovějšími verzemi SQL Server vylepšené. Některé další podrobnosti o SQL Server automatizovaných zálohách najdete v článku SQL Server Managed Backup to Microsoft Azure. Teoretický limit velikosti zálohy je 12 TB. Automatizované zálohy mohou být dobrou metodou pro velikosti záloh až 12 TB. Vzhledem k tomu, že se do více objektů blob zapisuje paralelně, můžete očekávat propustnost větší než 100 MB/s.

Azure Backup pro SQL Server virtuální počítače

Tato nová metoda zálohování SQL Server nabízí od června 2018 ve verzi Public Preview Azure Backup služby. Metoda zálohování SQL Server je stejná jako u jiných nástrojů třetích stran, konkrétně rozhraní služby SQL Server VSS/VDI pro streamování záloh do cílového umístění. V tomto případě je cílovým umístěním trezor služby Azure Recovery Services.

Podrobnější popis této metody zálohování, který přidává řadu výhod konfigurací centrálního zálohování, monitorování a správy, je k dispozici na stránce Zálohování SQL Server databází do Azure.

Řešení zálohování třetích stran

Pro poměrně řadu zákazníků SAP nebylo možné začít znovu a zavést kompletní nová řešení zálohování pro část jejich prostředí SAP, která běžela v Azure. V důsledku toho je potřeba použít stávající řešení zálohování a rozšířit je do Azure. Rozšíření stávajících řešení zálohování do Azure obvykle fungovalo dobře s většinou hlavních dodavatelů v této oblasti.

Použití image SQL Server mimo Microsoft Azure Marketplace

Microsoft nabízí virtuální počítače v Azure Marketplace, které již obsahují verze SQL Server. Zákazníci SAP, kteří potřebují licence pro SQL Server a Windows, můžou mít použití těchto imagí příležitost pokrýt potřebu licencí tím, že virtuální počítače roztáčí s SQL Server nainstalovanými imagemi. Aby bylo možné tyto obrázky použít pro SAP, je potřeba vzít v úvahu následující aspekty:

Změna SQL Server kolace virtuálního počítače Microsoft Windows/SQL Server

Vzhledem k SQL Server, že image Azure Marketplace nejsou nastavené pro použití kolace, kterou aplikace SAP NetWeaver potřebují, je potřeba je okamžitě po nasazení změnit. Pro SQL Server 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é virtuálnímu počítače:

  • Otevřete Windows příkazového řádku 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 při prvním nasazení virtuálního počítače prostřednictvím galerie definován jako účet správce.

Proces by měl trvat jen několik minut. Abyste se ujistili, jestli 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.
  • V hlavní databázi sp_helpsort příkaz SQL Server příkaz .

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

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 nasazení SAP a zjistěte, proč příkaz pro nastavení nefunguje podle očekávání. Nasazení aplikací SAP NetWeaver do SQL Server instance s různými SQL Server kódu, než je uvedeno výše, se NEPODPORUJE.

SQL Server High-Availability pro SAP v Azure

Při SQL Server nasazení Azure IaaS pro SAP můžete přidat několik různých možností nasazení vrstvy DBMS s vysokou dostupnou úrovní. Jak je popsáno v tématu Aspekty nasazení Azure Virtual Machines DBMS pro úlohy SAP, Azure poskytuje různé smlouvy SLA pro jeden virtuální počítač a dvojici virtuálních počítače nasazené ve skupině dostupnosti Azure. Předpokladem je, že u produkčních nasazení, která vyžadují nasazení ve skupině dostupnosti Azure, se řídíte aktuálními smlouvami SLA. V takovém případě musíte do takové skupiny dostupnosti nasadit minimálně dva virtuální počítače. Jeden virtuální počítač spustí aktivní instanci SQL Server virtuálního počítače. Druhý virtuální počítač spustí pasivní instanci.

SQL Server Clustering s využitím Windows souborového serveru se škálování na více systémů nebo sdíleného disku Azure

V Windows Server 2016 microsoft představil Prostory úložiště Direct. Na základě Prostory úložiště nasazení se SQL Server clustering FCI podporuje obecně. Azure také nabízí sdílené disky Azure, které je možné použít Windows clusteringu. U úloh SAP tyto možnosti hašování podporujeme.

SQL Server Přesouvání protokolů

Jednou z metod vysoké dostupnosti (HA) je SQL Server přesouvání protokolu. Pokud virtuální počítače, které se účastní konfigurace vysoké kvality, 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í protokolu, a principy týkající se přesouvání protokolů. Podrobnosti o SQL Server přesouvání protokolu najdete v článku o přesouvání protokolu (SQL Server).

Funkce SQL Server protokolu se v Azure jen málo používala k dosažení vysoké dostupnosti v rámci jedné oblasti Azure. V následujících scénářích však zákazníci SAP používají přesouvání protokolů v 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 migrace z místního prostředí do Azure V těchto případech se k synchronizaci nového nasazení DBMS v Azure s místním produkčním systémem používá přesouvání protokolů. V době převyšování se produkční prostředí vypne a je nutné zajistit, aby se poslední a nejnovější zálohy transakčních protokolů přenesly do nasazení Azure DBMS. Pak se otevře nasazení Azure DBMS pro produkční prostředí.

Zrcadlení databáze

Zrcadlení databáze, jak podporuje SAP (viz SAP Note 965908), spoléhá na definování partnera pro převzetí služeb při selhání v připojovacím řetězci SAP. Pro případy mezi místními prostředími předpokládáme, že oba virtuální počítače jsou ve stejné doméně a že kontext uživatele obsahuje také dvě instance SQL Server spuštěné pod uživatelem domény a že mají dostatečná oprávnění v obou zapojených instancích SQL Server. Nastavení zrcadlení databáze v Azure se proto mezi obvyklou místní instalací a konfigurací neliší.

Od Cloud-Only nasazení je nejjednodušší mít v Azure další nastavení domény, aby tyto virtuální počítače DBMS (a ideálně vyhrazené virtuální počítače SAP) byly v jedné doméně.

Pokud doména není možná, můžete také použít certifikáty pro koncové body zrcadlení databáze, jak je popsáno tady: Použití certifikátů pro koncový bod zrcadlení databáze (Transact-SQL)

Kurz nastavení zrcadlení databáze v Azure najdete tady: Zrcadlení databáze (SQL Server)

AlwaysOn SQL Serveru

Protože místní SAP podporuje Always On (viz SAP Note [1772688),]podporuje se v kombinaci se SAP v Azure. Nasazení naslouchacího procesu skupiny dostupnosti SQL Server (nezaměňovat se se skupinou dostupnosti Azure) je několik zvláštních požadavků, protože Azure v tomto okamžiku neumožňuje vytvoření objektu AD/DNS, protože je možné ho vytvořit místně. Proto je k překonání konkrétního chování Azure potřeba několik různých instalačních kroků.

Při naslouchacím procesu skupiny dostupnosti je třeba vzít v úvahu následující aspekty:

  • Použití naslouchacího procesu skupiny dostupnosti je možné pouze Windows Server 2012 nebo vyšším hostem operačního systému virtuálního počítače. V Windows Server 2012 se ujistěte, že je tato oprava použitá:https://support.microsoft.com/kb/2854082
  • Pro Windows Server 2008 R2 tato oprava neexistuje a funkce Always On by se měla 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 (prostřednictvím parametru dbs/mss/server SAP default.pfl – viz SAP Note 965908).
  • Při použití naslouchacího procesu skupiny dostupnosti je potřeba virtuální počítače databáze připojit k vyhrazenému Load Balancer. Aby se zabránilo tomu, že Azure přiřazovat nové IP adresy v případech, kdy jsou oba virtuální počítače incidentně vypnuté, je třeba přiřadit statické IP adresy síťovým rozhraním těchto virtuálních počítačů v konfiguraci Always On (definice statické IP adresy je popsaná v tomto článku).
  • Při vytváření konfigurace clusteru SLUŽBY WSFC se vyžaduje zvláštní postup, kdy cluster potřebuje přiřazenou speciální IP adresu, protože Azure s 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é k virtuálním počítači, na kterých běží primární a sekundární repliky skupiny dostupnosti.
  • Možná bude potřeba tyto koncové body zabezpečit pomocí seznamu ACL.

Podrobná dokumentace k nasazení Always On s SQL Server ve virtuálních počítačech Azure, jako je:

Poznámka

Pokud konfigurujete nástroj pro vyrovnávání zatížení Azure pro virtuální IP adresu naslouchacího procesu skupiny dostupnosti, ujistěte se, že je nakonfigurovaná možnost DirectServerReturn. Konfigurací této možnosti se sníží latence doby odezvy sítě mezi aplikační vrstvou SAP a vrstvou DBMS.

Poznámka

V článku SQL Server skupin dostupnosti Always Onna virtuálních počítačích Azure si přečtete o naslouchacím procesu DNN (Direct Network Name)služby SQL Server. Tato nová funkce byla zavedena v SQL Server 2019 CU8. Díky této nové funkci je používání nástroje pro vyrovnávání zatížení Azure, který se bude zabývat virtuální IP adresou naslouchacího procesu skupiny dostupnosti, zastaralé.

SQL Server Always On je nejběžnější funkcí vysoké dostupnosti a zotavení po havárii, která se v Azure používá pro nasazení úloh SAP. Většina zákazníků používá Always On pro vysokou dostupnost v jedné oblasti Azure. Pokud je nasazení omezené jenom 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.
  • Pomocí SQL Server 2019 CU8 nebo novějších verzí, kde můžete místo toho použít naslouchací proces DNN (Direct Network Name). Tím se eliminuje požadavek na nástroj pro vyrovnávání zatížení Azure.
  • Použití parametrů připojení pro SQL Server databáze V takovém případě musíte nakonfigurovat připojení aplikací SAP tak, aby názvy obou uzlů byly pojmenovány. Přesné podrobnosti o takové konfiguraci na straně SAP jsou dokumentované v dokumentu SAP Note #965908. Při použití této možnosti není potřeba konfigurovat naslouchací proces skupiny dostupnosti. A s tím žádný nástroj pro vyrovnávání zatížení Azure pro SQL Server dostupnost. Vzpomeňte si, že tato možnost funguje jenom v případě, že omezíte skupinu dostupnosti na dvě instance.

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

SQL Server transparentní šifrování dat

Existuje mnoho zákazníků, kteří při nasazování databází SAP SQL Server Azure používají SQL Server transparentní šifrování dat (TDE). SAP SQL Server plně podporuje funkci TDE (viz SAP Note #1380493).

Použití SQL Server TDE

V případech, kdy provádíte heterogenní migraci z jiného systému DBMS spuštěného místně do systému Windows/SQL Server spuštěného v Azure, byste měli v SQL Server vytvořit prázdnou cílovou databázi předem. V dalším kroku použijete SQL Server TDE. I když produkční systém stále používáte v místním prostředí. V této sekvenci chcete provést operaci proto, že šifrování prázdné databáze může trvat poměrně dlouho. Procesy importu SAP pak importují data do šifrované databáze během fáze výpadku. Režie při importu do šifrované databáze má mnohem menší časový dopad než šifrování databáze po fázi exportu ve fázi prostojů. Při pokusu o použití TDE s úlohou SAP spuštěnou nad databází docílily negativních zkušeností. Proto doporučení považuje nasazení TDE za aktivitu, kterou je potřeba provést bez úloh SAP pro konkrétní databázi.

V případech, kdy přesunete SQL Server databáze SAP z místního prostředí do Azure, doporučujeme testovat, na které infrastruktuře můžete šifrování použít nejrychleji. Mějte proto na paměti tato fakta:

  • Nemůžete definovat, kolik vláken se používá k použití šifrování dat v databázi. Počet vláken je do velké míry závislý na počtu diskových svazků, SQL Server jsou distribuována data a soubory protokolu. Znamená, že čím více různých svazků (písmen jednotek), tím více vláken bude zapojeno paralelně, aby bylo možné provést šifrování. Taková konfigurace je v rozporu s dřívějším návrhem na konfiguraci disků při vytváření jednoho nebo menšího počtu prostorů úložiště pro SQL Server souborů databáze na virtuálních počítači Azure. Konfigurace s malým počtem svazků by vedla k malému počtu vláken, která provádí šifrování. Šifrování jednoho vlákna znamená čtení rozsahů 64 kB, jeho zašifrování a zápis záznamu do souboru transakčního protokolu, který říká, že rozsah byl zašifrován. V důsledku toho je zatížení transakčního protokolu střední.
  • Ve starších SQL Server verzích už komprese zálohování při šifrování vaší databáze SQL Server efektivitu. Toto chování by se mohlo vyvinout v případě, že vaším plánem bylo šifrovat místní databázi SQL Server a pak zkopírovat zálohu do Azure a obnovit databázi v Azure. SQL Server zálohování obvykle dosahuje kompresního poměru 4. faktoru.
  • V SQL Server 2016 SQL Server nové funkce, které umožňují efektivní komprimaci šifrovaných databází. Podrobnosti najdete na tomto blogu.

Při práci s používáním šifrování TDE bez nebo jen s malým zatížením SAP byste měli v konkrétní konfiguraci testovat, jestli je lepší použít TDE na místní databázi SAP nebo to udělat v Azure. V Azure máte určitě větší flexibilitu z hlediska infrastruktury pro zřizování a zmenšování infrastruktury po použití TDE.

Pomocí Azure Key Vault

Azure nabízí službu poskytovatele Key Vault pro ukládání šifrovacích klíčů. SQL Server na druhé straně nabízí konektor, který Azure Key Vault jako úložiště pro certifikáty TDE.

Další podrobnosti o použití Azure Key Vault pro SQL Server TDE, jako jsou:

Důležité

S SQL Server TDE, zejména s Azure Key Vaultem, se doporučuje používat nejnovější opravy SQL Server 2014, SQL Server 2016 a SQL Server 2017. Důvodem je to, že na základě zpětné vazby od zákazníků se v kódu použily optimalizace a opravy. Podívejte se například na článek KBA #4058175.

Obecné SQL Server pro SAP v Azure údajů

V této příručce najdete řadu doporučení. Před plánováním nasazení Azure ji doporučujeme přečíst více než jednou. Obecně se ale ujistěte, že dodržujete hlavní obecná doporučení DBMS v Azure:

  1. Použijte nejnovější verzi DBMS, jako SQL Server 2017, která má v Azure největší výhody.
  2. Pečlivě naplánujte prostředí systému SAP v Azure tak, aby 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 IOPS.
    • Pokud tento účet Spravované disky, mějte na paměti, že počet IOPS je omezený také na účet Azure Storage a že účty Storage jsou omezené v rámci jednotlivých předplatných Azure(další podrobnosti).
    • Prokládáte je jen v případě, že potřebujete dosáhnout vyšší propustnosti.
  3. Nikdy neinstalujte software ani do složky D:\ neumisujte žádné soubory, které vyžadují trvalost. disk, protože není trvalý a cokoli na této jednotce se při restartování Windows ztratí.
  4. Nepoužívejte ukládání do mezipaměti disku pro Azure Standard Storage.
  5. Nepoužívejte geograficky replikované účty Azure Standard Storage Účty. Používejte místně redundantní pro úlohy DBMS.
  6. K replikaci databázových dat použijte řešení HA/DR od dodavatele DBMS.
  7. Vždy používejte překlad IP adres, nespoléhejte na IP adresy.
  8. Pomocí SQL Server TDE použijte nejnovější opravy SQL Server zabezpečení.
  9. Použijte nejvyšší možnou kompresi databáze. Což je komprese stránek pro SQL Server.
  10. Při používání SQL Server obrázků z Azure Marketplace buďte opatrní. Pokud použijete SQL Server, musíte před instalací libovolného systému SAP NetWeaver změnit kolaci instance.
  11. Nainstalujte a nakonfigurujte monitorování hostitele SAP pro Azure, jak je popsáno v průvodci nasazením.

Další kroky

Přečtěte si článek.