SQL Server Azure Virtual Machines DBMS üzembe helyezése az SAP NetWeaverhez

  • Cikk

Ez a dokumentum több különböző területet is érint, amelyeket figyelembe kell venni az SQL Server sap számítási feladatok azure IaaS-ben való üzembe helyezésekor. A dokumentum előfeltételeként el kellett olvasnia az Azure Virtual Machines DBMS üzembe helyezésének szempontjait az SAP-számítási feladatokhoz , valamint az Azure-dokumentáció SAP-számítási feladatának egyéb útmutatóit.

Fontos

A dokumentum hatóköre az SQL Server Windows-verziója. Az SAP nem támogatja az SQL Server Linux-verzióját egyetlen SAP-szoftverrel sem. A dokumentum nem tárgyalja a Microsoft Azure SQL Database-t, amely a Microsoft Azure Platform szolgáltatásajánlata. Az ebben a cikkben ismertetett vita az SQL Server-termék futtatásáról szól, amely az Azure-beli virtuális gépek helyszíni üzembe helyezéséről ismert, és az Azure szolgáltatásként használható infrastruktúráját kihasználva. A két ajánlat közötti adatbázis-képességek és funkciók eltérőek, és nem szabad összekeverni egymással. További információ: Azure SQL Database.

Általában érdemes megfontolni az SQL Server legújabb kiadásainak használatát az SAP-számítási feladatok Azure IaaS-ben való futtatásához. A legújabb SQL Server-kiadások jobb integrációt biztosítanak az Azure egyes szolgáltatásaiba és funkcióiba. Vagy olyan módosításokat hajthat végre, amelyek optimalizálják az Azure IaaS-infrastruktúra műveleteit.

Az Azure-beli virtuális gépeken futó SQL Server általános dokumentációja az alábbi cikkekben található:

Az Azure-beli virtuális gépek általános SQL Server dokumentációjában szereplő összes tartalom és utasítás nem vonatkozik az SAP számítási feladataira. A dokumentáció azonban jó benyomást tesz az alapelvekre. Az SAP számítási feladataihoz nem támogatott funkciókra példa az FCI-fürtözés használata.

Az IaaS-ben van néhány SQL Server-specifikus információ, amelyeket a folytatás előtt tudnia kell:

  • SQL-verzió támogatása: Még az SAP Megjegyzés #1928533 is azt állítja, hogy a minimálisan támogatott SQL Server-kiadás az SQL Server 2008 R2, az Azure-ban támogatott SQL Server-verziók ablakát az SQL Server életciklusa is meghatározza. Az SQL Server 2012 kiterjesztett karbantartása 2022 közepén véget ért. Ennek eredményeképpen az újonnan üzembe helyezett rendszerek jelenlegi minimális kiadásának az SQL Server 2014-nek kell lennie. Minél újabb, annál jobb. A legújabb SQL Server-kiadások jobb integrációt biztosítanak az Azure egyes szolgáltatásaiba és funkcióiba. Vagy olyan módosításokat hajthat végre, amelyek optimalizálják az Azure IaaS-infrastruktúra műveleteit.
  • Az Azure Marketplace rendszerképeinek használata: Az új Microsoft Azure-beli virtuális gépek üzembe helyezésének leggyorsabb módja az Azure Marketplace-ről származó rendszerkép használata. Az Azure Marketplace-en vannak olyan rendszerképek, amelyek a legújabb SQL Server-kiadásokat tartalmazzák. Azok a képek, amelyeken az SQL Server már telepítve van, nem használhatók azonnal SAP NetWeaver-alkalmazásokhoz. Ennek az az oka, hogy az ALAPÉRTELMEZETT SQL Server-rendezés ezekben a képekben van telepítve, és nem az SAP NetWeaver rendszerek által megkövetelt rendezés. Az ilyen rendszerképek használatához tekintse meg az SQL Server rendszerkép használata a Microsoft Azure Marketplace-ről című fejezetben leírt lépéseket.
  • SQL Server többpéldányos támogatás egyetlen Azure-beli virtuális gépen belül: Ez az üzembe helyezési módszer támogatott. Vegye figyelembe azonban az erőforrás-korlátozásokat, különösen a használt virtuálisgép-típus hálózati és tárolási sávszélességét. Részletes információk az Azure-beli virtuális gépek méreteiről szóló cikkben találhatók. Ezek a kvótakorlátozások megakadályozhatják, hogy ugyanazt a többpéldányos architektúrát implementálja, mint a helyszínen. Az egyetlen virtuális gépen elérhető erőforrások megosztásának konfigurációja és zavarása miatt ugyanazokat a szempontokat kell figyelembe venni, mint a helyszínen.
  • Több SAP-adatbázis egyetlen SQL Server-példányban egyetlen virtuális gépen: Az ilyen konfigurációk támogatottak. Az egyetlen SQL Server-példány megosztott erőforrásait megosztó TÖBB SAP-adatbázis szempontjai megegyeznek a helyszíni üzemelő példányokéval. Tartsa szem előtt az egyéb korlátokat, például az adott virtuálisgép-típushoz csatlakoztatható lemezek számát. Vagy adott virtuálisgép-típusok hálózati és tárolási kvótakorlátjai részletes méretként az Azure-beli virtuális gépekhez.

Az általános leírásnak, az operációs rendszernek és az SQL Server végrehajtható példányainak megfelelően az SAP-végrehajtható fájlokat külön Azure-lemezeken kell elhelyezni vagy telepíteni. Az SQL Server rendszeradatbázisainak többségét általában az SAP NetWeaver számítási feladatai nem használják magas szinten. Az SQL Server rendszeradatbázisainak azonban külön Azure-lemezen kell lenniük a többi SQL Server-címtárral együtt. Az SQL Server tempdb-nek vagy a nempericionált D:\ meghajtón vagy egy külön lemezen kell lennie.

  • Az ÖSSZES SAP-tanúsítvánnyal rendelkező virtuálisgép-típussal (lásd: SAP Note #1928533), a tempdb-adatok és a naplófájlok a nem tárolt D:\ meghajtón helyezhetők el.
  • Az SQL Server kiadásaival, ahol az SQL Server alapértelmezés szerint egy adatfájllal telepíti a tempdb-t, javasoljuk, hogy több tempdb-adatfájlt használjon. Vegye figyelembe, hogy a D:\ meghajtókötetek mérete és képességei a virtuális gép típusától függően eltérőek. A különböző virtuális gépek D:\ meghajtójának pontos méretéért tekintse meg az Azure-beli Windows rendszerű virtuális gépek méretei című cikket.

Ezek a konfigurációk lehetővé teszik a tempdb számára, hogy több helyet és fontosabb I/O-műveleteket használjon másodpercenként ( IOPS) és tárolási sávszélességet, mint amennyit a rendszermeghajtó képes biztosítani. A nem állandó D:\ meghajtó jobb I/O-késést és átviteli sebességet is kínál. A tempdb megfelelő méretének meghatározásához ellenőrizheti a tempdb-méreteket a meglévő rendszereken.

Megjegyzés:

ha tempdb-adatfájlokat és naplófájlokat helyez el egy létrehozott D:\ meghajtón lévő mappába, győződjön meg arról, hogy a mappa a virtuális gép újraindítása után is létezik. Mivel a D:\ meghajtó frissen inicializálható a virtuális gép újraindítása után, az összes fájl- és könyvtárszerkezet törölhető. Lehetőség a D:\ meghajtón lévő végleges címtárstruktúrák újbóli létrehozására az SQL Server szolgáltatás elindítása előtt ebben a cikkben.

A virtuálisgép-konfiguráció, amely SAP-adatbázissal futtatja az SQL Servert, és ahol a tempdb-adatok és a tempdb logfile a D:\ meghajtón vannak elhelyezve, az Azure Premium Storage 1-es vagy v2-es verziójának pedig a következőképpen nézne ki:

Diagram of simple VM disk configuration for SQL Server

A diagram egy egyszerű esetet jelenít meg. Ahogyan a cikkben említettem, az Azure Virtual Machines DBMS sap-számítási feladatokhoz való üzembe helyezésének szempontjai, az Azure Storage típusa, száma és mérete különböző tényezőktől függ. Általában azonban a következőket javasoljuk:

  • Kisebb és középtartományú üzemelő példányok esetén egy nagy kötetet használva, amely tartalmazza az SQL Server-adatfájlokat. Ennek a konfigurációnak az az oka, hogy egyszerűbb kezelni a különböző I/O-számítási feladatokat, ha az SQL Server-adatfájlok nem rendelkeznek ugyanazzal a szabad területtel. Míg a nagy méretű üzemelő példányokban, különösen azokban az üzemelő példányokban, ahol az ügyfél heterogén adatbázis-migrálással költözött az Azure-beli SQL Serverre, külön lemezeket használtunk, majd elosztottuk az adatfájlokat ezeken a lemezeken. Egy ilyen architektúra csak akkor sikeres, ha minden lemezen azonos számú adatfájl található, az összes adatfájl mérete azonos, és nagyjából azonos szabad területtel rendelkezik.
  • Használja a D:\meghajtót a tempdb-hez, amíg a teljesítmény elég jó. Ha a D:\ meghajtón található tempdb teljesítményében korlátozott a teljes számítási feladat, akkor a jelen cikkben javasolt módon át kell helyeznie a tempdb-t az Azure Premium Storage 1-es vagy v2-es verziójára, vagy ultralemezre.

Az SQL Server arányos kitöltési mechanizmusa egyenletesen osztja el az olvasásokat és az írásokat az összes adatfájl között, feltéve, hogy minden SQL Server-adatfájl mérete megegyezik, és ugyanolyan szabad ütemű. Az SQL Serveren futó SAP akkor nyújtja a legjobb teljesítményt, ha az olvasások és írások egyenletesen oszlanak el az összes elérhető adatfájl között. Ha egy adatbázis túl kevés adatfájllal rendelkezik, vagy a meglévő adatfájlok kiegyensúlyozatlanok, a legjobb megoldás az R3load exportálása és importálása. Az R3load exportálása és importálása állásidőt igényel, és csak akkor szabad elvégezni, ha nyilvánvaló teljesítményproblémát kell megoldani. Ha az adatfájlok csak mérsékelten eltérő méretűek, növelje az összes adatfájlt azonos méretre, és az SQL Server idővel újraegyensúlyozza az adatokat. Az SQL Server automatikusan egyenletesen fogja növelni az adatfájlokat, ha be van állítva az 1117 nyomkövetési jelző, vagy ha az SQL Server 2016 vagy újabb verziót használja.

Speciális M sorozatú virtuális gépekhez

Az Azure M sorozatú virtuális gépek esetében a tranzakciónaplóba való írás késése csökkenthető az Azure Premium Storage 1-es teljesítményéhez képest az Azure Write Accelerator használatakor. Ha a premium storage v1 által biztosított késés korlátozza az SAP számítási feladat méretezhetőségét, az SQL Server tranzakciónapló-fájlját tároló lemez engedélyezhető az Írásgyorsítóhoz. A részletek a dokumentum Írásgyorsítójában olvashatók. Az Azure Write Accelerator nem működik az Azure Premium Storage 2-es és ultralemezes verziójával. Mindkét esetben a késés jobb, mint amit az Azure Premium Storage v1 nyújt.

A lemezek formázása

SQL Server esetén az SQL Server-adatokat és naplófájlokat tartalmazó lemezek NTFS-blokkméretének 64 KB-nak kell lennie. A D:\ meghajtót nem kell formázni. Ez a meghajtó előre formázott.

Annak érdekében, hogy az adatbázisok visszaállítása vagy létrehozása ne inicializálja az adatfájlokat a fájlok tartalmának nullázásával, győződjön meg arról, hogy az SQL Server szolgáltatás felhasználói környezetében a felhasználó jogosultsága elvégzi a kötetkarbantartási feladatokat. További információ: Adatbázis azonnali fájl inicializálása.

SQL Server 2014 és újabb – Adatbázisfájlok tárolása közvetlenül az Azure Blob Storage-on

Az SQL Server 2014-es és újabb kiadásai lehetővé teszik az adatbázisfájlok közvetlen tárolását az Azure Blob Store-ban anélkül, hogy a VHD "burkolója" körüljárta őket. Ez a funkció az Azure blokktároló évekkel ezelőtti hiányosságainak kezelésére szolgál. Manapság nem ajánlott ezt az üzembe helyezési módszert használni, ehelyett válassza az Azure Premium Storage v1, a premium storage v2 vagy az Ultra disk lehetőséget. A követelményektől függ.

SQL Server 2014 pufferkészlet bővítmény

Az SQL Server 2014 bevezetett egy új funkciót, amelyet pufferkészlet-bővítménynek hívnak. Ez a funkció bár az Azure-beli SAP-számítási feladatban tesztelve nem nyújtott javulást a számítási feladatok üzemeltetésében. Ezért nem szabad figyelembe venni

Az SQL Server biztonsági mentési/helyreállítási szempontjai

Az SQL Server Azure-ban való üzembe helyezéséhez át kell tekintenie a biztonsági mentési architektúrát. Még akkor is, ha a rendszer nem éles rendszer, az SQL Server által üzemeltetett SAP-adatbázist rendszeres időközönként biztonsági másolatot kell készíteni. Mivel az Azure Storage három lemezképet tárol, a biztonsági mentés már kevésbé fontos a tárolási összeomlás kompenzálása szempontjából. A megfelelő biztonsági mentési és helyreállítási terv fenntartásának elsődleges oka, hogy a logikai/manuális hibák kompenzálhatók az időalapú helyreállítási képességek biztosításával. A cél az, hogy biztonsági másolatokkal visszaállítsa az adatbázist egy adott időpontra. Vagy az Azure-beli biztonsági másolatok használatával egy másik rendszer üzembe helyezéséhez a meglévő adatbázis másolásával.

Az SQL Server-adatbázisok biztonsági mentésének és visszaállításának több módja is van az Azure-ban. A legjobb áttekintés és részletek érdekében olvassa el az Azure-beli virtuális gépeken futó SQL Server biztonsági mentését és visszaállítását ismertető dokumentumot. A cikk több különböző lehetőséget is bemutat.

SQL Server-rendszerkép használata a Microsoft Azure Marketplace-en

A Microsoft az Azure Marketplace-en kínál virtuális gépeket, amelyek már tartalmazzák az SQL Server verzióit. Az SQL Serverhez és a Windowshoz licencet igénylő SAP-ügyfelek számára ezek a rendszerképek lehetővé teszik a licencek szükségességét a már telepített SQL Serverrel rendelkező virtuális gépek pörgetésével. Ahhoz, hogy ilyen képeket használhasson az SAP-hoz, a következő szempontokat kell figyelembe venni:

  • A nem kiértékelt SQL Server-verziók magasabb költségeket kapnak, mint az Azure Marketplace-ről üzembe helyezett "csak Windows"-alapú virtuális gépek. Az árak összehasonlításához tekintse meg a Windows Virtual Machines díjszabását és az SQL Server Enterprise Virtual Machines díjszabását.
  • Csak az SAP által támogatott SQL Server-kiadásokat használhatja.
  • Az Azure Marketplace-en kínált virtuális gépeken telepített SQL Server-példány rendezése nem az SAP NetWeaver rendszerezése, amely az SQL Server-példány futtatását igényli. A rendezést a következő szakaszban szereplő irányokkal módosíthatja.

Microsoft Windows/SQL Server rendszerű virtuális gép SQL Server-rendezésének módosítása

Mivel az Azure Marketplace-en lévő SQL Server-rendszerképek nincsenek beállítva az SAP NetWeaver-alkalmazások által megkövetelt rendezés használatára, az üzembe helyezés után azonnal módosítani kell. SQL Server esetén a rendezés ezen módosítása a következő lépésekkel végezhető el, amint a virtuális gép üzembe lett helyezve, és a rendszergazda bejelentkezhet az üzembe helyezett virtuális gépre:

  • Nyisson meg egy Windows-parancsablakot rendszergazdaként.
  • Módosítsa a könyvtárat a C:\Program Files\Microsoft SQL Server\110\Setup Bootstrap\SQLServer2012 könyvtárra.
  • Hajtsa végre a következő parancsot: Setup.exe /QUIET /ACTION=REBUILDDATABA Standard kiadás /INSTANCENAME=MSSQL Standard kiadás RVER /SQLSYSADMINACCOUNTS=<local_admin_account_name> /SQLCOLLATION=SQL_Latin1_General_Cp850_BIN2
    • <local_admin_account_name> az a fiók, amelyet rendszergazdai fiókként definiáltak a virtuális gép első, katalóguson keresztüli üzembe helyezésekor.

A folyamatnak csak néhány percig kell tartania. Annak ellenőrzéséhez, hogy a lépés a megfelelő eredménnyel végződött-e, hajtsa végre a következő lépéseket:

  • Nyissa meg az SQL Server Management Studiót.
  • Nyisson meg egy lekérdezésablakot.
  • Hajtsa végre a sp_helpsort parancsot az SQL Server főadatbázisában.

A kívánt eredménynek a következőképpen kell kinéznie:

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

Ha az eredmény eltér, állítsa le az üzembe helyezést, és vizsgálja meg, hogy a beállítási parancs miért nem a várt módon működött. Az SAP NetWeaver-alkalmazások SQL Server-példányra történő üzembe helyezése a fent említettnél eltérő SQL Server-kódlapokkal NEM támogatott a NetWeaver-telepítések esetében.

Az SQL Server magas rendelkezésre állása az AZURE-beli SAP-hez

Az SQL Server SAP-hez készült Azure IaaS-környezetekben való használatával számos különböző lehetőség áll rendelkezésre a DBMS-réteg magas rendelkezésre állású üzembe helyezéséhez. Az Azure különböző üzemidős SLA-kat biztosít egyetlen virtuális géphez különböző Azure-blokktárolók, egy Azure rendelkezésre állási csoportban üzembe helyezett virtuális gépek párja vagy az Azure rendelkezésre állási zónákban üzembe helyezett virtuális gépek párja használatával. Éles rendszerek esetében elvárjuk, hogy egy virtuálisgép-méretezési csoporton belül két virtuális gépet helyez üzembe rugalmas vezényléssel két rendelkezésre állási zónában. További információkért tekintse meg az SAP-számítási feladatok különböző üzembehelyezési típusainak összehasonlítását. Egy virtuális gép futtatja az aktív SQL Server-példányt. A másik virtuális gép futtatja a passzív példányt

SQL Server-fürtözés a Windows kibővített fájlkiszolgálóval vagy az Azure-beli megosztott lemezzel

A Windows Server 2016-ban a Microsoft bevezette Tárolóhelyek Directet. A közvetlen üzembe helyezés Tárolóhelyek alapján az SQL Server FCI-fürtözés általában támogatott. Az Azure olyan Megosztott Azure-lemezeket is kínál, amelyek a Windows-fürtözéshez használhatók. Az SAP számítási feladatai esetében nem támogatjuk ezeket a HA-beállításokat.

SQL Server Log Shipping

Az egyik magas rendelkezésre állású funkció az SQL Server naplóküldése. Ha a HA-konfigurációban részt vevő virtuális gépeken működik a névfeloldás, nincs probléma. Az Azure-ban a beállítás nem különbözik a helyszíni beállítástól, amely a naplószállítás beállításához és a naplószállítás alapelveihez kapcsolódik. Az SQL Server naplók szállításának részletei a Naplószállítás (SQL Server) című cikkben találhatók.

Az SQL Server naplószállítási funkcióját alig használták az Azure-ban, hogy magas rendelkezésre állást érjenek el egy Azure-régióban. A következő esetekben azonban az SAP-ügyfelek sikeres naplószállítást használtak az Azure-ban:

  • Vészhelyreállítási forgatókönyvek egy Azure-régióból egy másik Azure-régióba
  • Vészhelyreállítási konfiguráció a helyszíni környezetből egy Azure-régióba
  • A helyszínitől az Azure-ba történő átállásos forgatókönyvek. Ezekben az esetekben a rendszer naplóalapú szállítással szinkronizálja az Új DBMS-üzembe helyezést az Azure-ban a folyamatban lévő helyszíni éles rendszerrel. Az átvágáskor az éles üzem leáll, és meggyőződött arról, hogy az utolsó és legújabb tranzakciónapló biztonsági másolatai átkerültek az Azure DBMS üzembe helyezésébe. Ezután megnyílik az Azure DBMS üzembe helyezése éles környezetben.

SQL Server Always On

Mivel az Always On támogatott a helyszíni SAP-ban (lásd: SAP Note #1772688), az Azure-ban az SAP-val együtt támogatott. Az SQL Server rendelkezésre állási csoport figyelőjének üzembe helyezésével kapcsolatban van néhány speciális szempont (nem tévesztendő össze az Azure rendelkezésre állási csoporttal). Ezért különböző telepítési lépésekre van szükség.

Néhány szempont a rendelkezésre állási csoport figyelőjének használatával:

  • A rendelkezésre állási csoport figyelőjének használata csak a Windows Server 2012 vagy újabb operációs rendszer esetén lehetséges a virtuális gép vendég operációs rendszereként. Windows Server 2012 esetén győződjön meg arról, hogy a Frissítés az SQL Server rendelkezésre állási csoport figyelőinek engedélyezéséhez Windows Server 2008 R2 és Windows Server 2012 rendszerű Microsoft Azure virtuális gépeken lett alkalmazva.
  • Windows Server 2008 R2 esetén ez a javítás nem létezik. Ebben az esetben az Always On-t ugyanúgy kell használni, mint az adatbázis-tükrözést. Feladatátvételi partner megadásával a kapcsolati sztringben (a dbs/mss/server SAP default.pfl paraméteren keresztül történik – lásd: SAP Megjegyzés #965908).
  • Rendelkezésre állási csoport figyelőjével csatlakoztatnia kell az adatbázis virtuális gépeit egy dedikált Load Balancerhez. Statikus IP-címeket kell hozzárendelnie ezeknek a virtuális gépeknek a hálózati adaptereihez az Always On konfigurációban (a statikus IP-cím meghatározásáról ebben a cikkben olvashat). A DHCP-hez képest statikus IP-címek megakadályozzák az új IP-címek hozzárendelését olyan esetekben, amikor mindkét virtuális gépet le lehet állítani.
  • A WSFC-fürtkonfiguráció létrehozásakor speciális lépésekre van szükség, ahol a fürtnek speciális IP-címre van szüksége, mivel az Azure a jelenlegi funkciójával ugyanazt az IP-címet rendeli hozzá a fürt nevéhez, mint a fürt által létrehozott csomópont. Ez a viselkedés azt jelenti, hogy manuális lépést kell végrehajtani egy másik IP-cím fürthöz való hozzárendeléséhez.
  • A rendelkezésre állási csoport figyelője az Azure-ban fog létrejönni TCP/IP-végpontokkal, amelyek a rendelkezésre állási csoport elsődleges és másodlagos replikáit futtató virtuális gépekhez vannak rendelve.
  • Előfordulhat, hogy ezeket a végpontokat ACL-ekkel kell biztonságossá tenni.

Részletes dokumentáció az Always On és az SQL Server Azure-beli virtuális gépeken való üzembe helyezéséről, például:

Megjegyzés:

Az SQL Server Always On rendelkezésre állási csoportjainak bemutatása az Azure-beli virtuális gépeken című témakörben az SQL Server közvetlen hálózati nevének (DNN) figyelőjét fogja olvasni. Ez az új funkció az SQL Server 2019 CU8-ban lett bevezetve. Ez az új funkció elavulttá teszi a rendelkezésre állási csoport figyelőjének virtuális IP-címét kezelő Azure-terheléselosztó használatát.

Az SQL Server Always On a leggyakrabban használt magas rendelkezésre állási és vészhelyreállítási funkció az Azure-ban sap számítási feladatok üzembe helyezéséhez. A legtöbb ügyfél az Always On szolgáltatást használja a magas rendelkezésre álláshoz egyetlen Azure-régión belül. Ha az üzembe helyezés csak két csomópontra korlátozódik, két kapcsolati lehetőség közül választhat:

  • A rendelkezésre állási csoport figyelőjének használata. A rendelkezésre állási csoport figyelőjével üzembe kell helyeznie egy Azure-terheléselosztót.
  • Az SQL Server 2016 SP3, az SQL Server 2017 CU 25 vagy az SQL Server 2019 CU8 vagy újabb WINDOWS Server 2016-os vagy újabb SQL Server-kiadásaival azure-terheléselosztó helyett használhatja a Közvetlen hálózatnév (DNN) figyelőt . A DNN megszünteti az Azure-terheléselosztóra vonatkozó követelményt.

Az SQL Server Database Mirroring kapcsolati paramétereinek használata csak a másik két metódussal kapcsolatos problémák vizsgálatára használható. Ebben az esetben úgy kell konfigurálnia az SAP-alkalmazások kapcsolatát, hogy mindkét csomópont neve el legyen nevezve. Az ilyen SAP-oldali konfiguráció pontos részleteit az SAP Megjegyzés #965908 tartalmazza. Ezzel a beállítással nem kell konfigurálnia egy rendelkezésre állási csoport figyelőt. És ezzel nincs Azure-terheléselosztó, és ezzel megvizsgálhatja az összetevőkkel kapcsolatos problémákat. Ne feledje azonban, hogy ez a beállítás csak akkor működik, ha a rendelkezésre állási csoportot két példányra korlátozza.

A legtöbb ügyfél az SQL Server Always On funkciót használja vészhelyreállítási funkciókhoz az Azure-régiók között. Több ügyfél is képes biztonsági mentéseket végezni egy másodlagos replikáról.

SQL Server transzparens adattitkosítás

Sok ügyfél SQL Server-transzparens adattitkosítás (TDE) használ az SAP SQL Server-adatbázisok Azure-beli üzembe helyezésekor. Az SQL Server TDE funkcióit az SAP teljes mértékben támogatja (lásd: SAP Megjegyzés #1380493).

AZ SQL Server TDE alkalmazása

Azokban az esetekben, amikor heterogén migrálást hajt végre egy másik, a helyszínen futó DBMS-ből az Azure-ban futó Windows/SQL Server rendszerre, előbb létre kell hoznia az üres céladatbázist az SQL Serveren. Következő lépésként sql server TDE-funkciókat alkalmazna erre az üres adatbázisra. Ennek az oka, hogy az üres adatbázis titkosításának folyamata eltarthat egy ideig. Az SAP-importálási folyamatok ezután az állásidő során importálják az adatokat a titkosított adatbázisba. A titkosított adatbázisba való importálás többletterhelése sokkal kisebb időhatással jár, mint az adatbázis titkosítása az exportálási fázis után a leállási fázisban. Negatív élmények történtek, amikor a TDE-t az adatbázis tetején futó SAP-számítási feladattal próbálták alkalmazni. Ezért a javaslat a TDE üzembe helyezését olyan tevékenységként kezeli, amelyet az adott adatbázisban nem vagy alacsony SAP-számítási feladattal kell elvégezni. Az SQL Server 2016-tól kezdve leállíthatja és folytathatja a kezdeti titkosítást végző TDE-vizsgálatot. A dokumentum transzparens adattitkosítás (TDE) leírja a parancsot és a részleteket.

Azokban az esetekben, amikor az SAP SQL Server-adatbázisokat a helyszínről az Azure-ba helyezi át, javasoljuk, hogy tesztelje, melyik infrastruktúrán alkalmazhatja leggyorsabban a titkosítást. Ebben az esetben tartsa szem előtt ezeket a tényeket:

  • Nem határozhatja meg, hogy hány szál használatával alkalmazza az adattitkosítást az adatbázisra. A szálak száma nagyban függ az SQL Server-adatok és naplófájlok elosztott lemezköteteinek számától. Azt jelenti, hogy minél több különböző kötet (meghajtóbetűjel), annál több szál fog párhuzamosan kapcsolódni a titkosítás végrehajtásához. Az ilyen konfiguráció kissé ellentmond a korábbi lemezkonfigurációs javaslatnak, amely egy vagy kevesebb tárolóhelyet hoz létre az Azure-beli virtuális gépek SQL Server-adatbázisfájljaihoz. A néhány kötetet tartalmazó konfiguráció néhány szálat eredményezne a titkosítás végrehajtásához. Egyetlen száltitkosítás 64 KB-os terjedelem olvasása, titkosítása, majd rekord írása a tranzakciónapló-fájlba, amely azt jelzi, hogy a mérték titkosítva lett. Ennek eredményeképpen a tranzakciónapló terhelése mérsékelt.
  • A régebbi SQL Server-kiadásokban a biztonsági mentés tömörítése már nem volt hatékony az SQL Server-adatbázis titkosítása során. Ez a viselkedés akkor válhat problémává, ha a terv az SQL Server-adatbázis helyszíni titkosítása, majd biztonsági másolat másolása az Azure-ba az adatbázis visszaállításához az Azure-ban. Az SQL Server biztonsági mentési tömörítése a 4. tényező tömörítési arányát érheti el.
  • Az SQL Server 2016-ban az SQL Server új funkciókat vezetett be, amelyek lehetővé teszik a titkosított adatbázisok biztonsági mentésének hatékony tömörítését is. További részletekért tekintse meg ezt a blogot .

Az Azure Key Vault használata

Az Azure egy Key Vault szolgáltatását kínálja a titkosítási kulcsok tárolásához. A másik oldalon az SQL Server egy összekötőt kínál, amely az Azure Key Vaultot használja tárolóként a TDE-tanúsítványokhoz.

További részletek az Azure Key Vault SQL Server TDE-listákhoz való használatához:

Fontos

Az SQL Server TDE- és különösen az Azure Key Vault használata esetén ajánlott az SQL Server 2014, az SQL Server 2016 és az SQL Server 2017 legújabb javításainak használata. Ennek oka az, hogy az ügyfelek visszajelzései alapján az optimalizálások és javítások a kódra lettek alkalmazva. Például ellenőrizze a KBA #4058175.

Minimális üzembehelyezési konfigurációk

Ebben a szakaszban minimális konfigurációkat javasolunk az SAP számítási feladatainak különböző méretű adatbázisaihoz. Túl nehéz felmérni, hogy ezek a méretek megfelelnek-e az adott számítási feladatnak. Előfordulhat, hogy az adatbázis méretéhez képest nagyvonalúan használjuk a memóriát. A másik oldalon előfordulhat, hogy a lemezméretezés túl alacsony néhány számítási feladathoz. Ezért ezeket a konfigurációkat úgy kell kezelni, mint amilyenek. Ezek olyan konfigurációk, amelyekkel érdemes kezdeni. Konfigurációk az adott számítási feladathoz és költséghatékonysági követelményekhez való finomhangoláshoz.

Egy 50 GB és 250 GB közötti adatbázisméretű SQL Server-példány konfigurációjának példája

Konfiguráció DBMS virtuális gép Hozzászólások
Virtuális gép típusa E4s_v3/v4/v5 (4 vCPU/32 GiB RAM)
Accelerated Networking Engedélyezés
SQL Server-verzió SQL Server 2019 vagy újabb
Adatfájlok száma 4
Naplófájlok száma 1
Ideiglenes adatfájlok száma 4 vagy alapértelmezett az SQL Server 2016 óta
Operációs rendszer Windows Server 2019 vagy újabb verzió
Lemezösszesítés Tárolóhelyek igény szerint
Fájlrendszer NTFS
Blokk méretének formázása 64 KB
Adatlemezek száma és típusa Premium Storage v1: 2 x P10 (RAID0)
Premium Storage v2: 2 x 150 GiB (RAID0) – alapértelmezett IOPS és átviteli sebesség		 Gyorsítótár = Írásvédett a prémium szintű 1-
A naplólemezek száma és típusa Premium storage v1: 1 x P20
Premium Storage v2: 1 x 128 GiB – alapértelmezett IOPS és átviteli sebesség		 Gyorsítótár = NINCS
SQL Server maximális memóriaparaméter A fizikai RAM 90%-a Egyetlen példány felvállalása

Egy 250 GB–750 GB közötti adatbázisméretű konfigurációra vagy egy kis SQL Server-példányra, például egy kisebb SAP Business Suite-rendszerre, a következőképpen nézhet ki:

Konfiguráció DBMS virtuális gép Hozzászólások
Virtuális gép típusa E16s_v3/v4/v5 (16 vCPU/128 GiB RAM)
Accelerated Networking Engedélyezés
SQL Server-verzió SQL Server 2019 vagy újabb
Adatfájlok száma 8
Naplófájlok száma 1
Ideiglenes adatfájlok száma 8 vagy alapértelmezett az SQL Server 2016 óta
Operációs rendszer Windows Server 2019 vagy újabb verzió
Lemezösszesítés Tárolóhelyek igény szerint
Fájlrendszer NTFS
Blokk méretének formázása 64 KB
Adatlemezek száma és típusa Prémium szintű tároló 1: 4 x P20 (RAID0)
Prémium szintű tároló v2: 4 x 100 GiB – 200 GiB (RAID0) – alapértelmezett IOPS és 25 MB/s extra átviteli sebesség lemezenként		 Gyorsítótár = Írásvédett a prémium szintű 1-
A naplólemezek száma és típusa Premium storage v1: 1 x P20
Premium Storage v2: 1 x 200 GiB – alapértelmezett IOPS és átviteli sebesség		 Gyorsítótár = NINCS
SQL Server maximális memóriaparaméter A fizikai RAM 90%-a Egyetlen példány felvállalása

Egy 750 GB és 2000 GB közötti adatbázisméretű közepes SQL Server-példány konfigurációja, például egy közepes SAP Business Suite-rendszer, a következőképpen nézhet ki:

Konfiguráció DBMS virtuális gép Hozzászólások
Virtuális gép típusa E64s_v3/v4/v5 (64 vCPU/432 GiB RAM)
Accelerated Networking Engedélyezés
SQL Server-verzió SQL Server 2019 vagy újabb
Adateszközök száma 16
Naplóeszközök száma 1
Ideiglenes adatfájlok száma 8 vagy alapértelmezett az SQL Server 2016 óta
Operációs rendszer Windows Server 2019 vagy újabb verzió
Lemezösszesítés Tárolóhelyek igény szerint
Fájlrendszer NTFS
Blokk méretének formázása 64 KB
Adatlemezek száma és típusa Prémium szintű tároló 1: 4 x P30 (RAID0)
Prémium szintű tároló v2: 4 x 250 GiB - 500 GiB - plusz 2000 IOPS és 75 MB/s átviteli sebesség lemezenként		 Gyorsítótár = Írásvédett a prémium szintű 1-
A naplólemezek száma és típusa Premium storage v1: 1 x P20
Prémium szintű 2-es verzió: 1 x 400 GiB – alapértelmezett IOPS és 75 MB/s extra átviteli sebesség		 Gyorsítótár = NINCS
SQL Server maximális memóriaparaméter A fizikai RAM 90%-a Egyetlen példány felvállalása

Egy nagyobb, 2000 GB és 4000 GB közötti adatbázisméretű SQL Server-példány ( például egy nagyobb SAP Business Suite-rendszer) konfigurációja a következőképpen nézhet ki:

Konfiguráció DBMS virtuális gép Hozzászólások
Virtuális gép típusa E96(d)s_v5 (96 vCPU/672 GiB RAM)
Accelerated Networking Engedélyezés
SQL Server-verzió SQL Server 2019 vagy újabb
Adateszközök száma 24
Naplóeszközök száma 1
Ideiglenes adatfájlok száma 8 vagy alapértelmezett az SQL Server 2016 óta
Operációs rendszer Windows Server 2019 vagy újabb verzió
Lemezösszesítés Tárolóhelyek igény szerint
Fájlrendszer NTFS
Blokk méretének formázása 64 KB
Adatlemezek száma és típusa Prémium szintű tároló 1: 4 x P30 (RAID0)
Premium Storage v2: 4 x 500 GiB - 800 GiB - plusz 2500 IOPS és 100 MB/s átviteli sebesség lemezenként		 Gyorsítótár = Írásvédett a prémium szintű 1-
A naplólemezek száma és típusa Premium storage v1: 1 x P20
Prémium szintű 2-es verzió: 1 x 400 GiB – plusz 1000 IOPS és 75 MB/s extra átviteli sebesség		 Gyorsítótár = NINCS
SQL Server maximális memóriaparaméter A fizikai RAM 90%-a Egyetlen példány felvállalása

Egy 4 TB+-os adatbázisméretű nagy SQL Server-példány konfigurációja, például egy nagy, globálisan használt SAP Business Suite-rendszer, a következőképpen nézhet ki:

Konfiguráció DBMS virtuális gép Hozzászólások
Virtuális gép típusa M-sorozat (1,0-4,0 TB RAM)
Accelerated Networking Engedélyezés
SQL Server-verzió SQL Server 2019 vagy újabb
Adateszközök száma 32
Naplóeszközök száma 1
Ideiglenes adatfájlok száma 8 vagy alapértelmezett az SQL Server 2016 óta
Operációs rendszer Windows Server 2019 vagy újabb verzió
Lemezösszesítés Tárolóhelyek igény szerint
Fájlrendszer NTFS
Blokk méretének formázása 64 KB
Adatlemezek száma és típusa Premium Storage 1: 4+ x P40 (RAID0)
Prémium 2-es verzió: 4+ x 1000 GiB - 4000 GiB - plusz 4500 IOPS és 125 MB/s átviteli sebesség lemezenként		 Gyorsítótár = Írásvédett a prémium szintű 1-
A naplólemezek száma és típusa Prémium szintű tároló 1: 1 x P30
Prémium szintű 2-es verzió: 1 x 500 GiB – plusz 2000 IOPS és 125 MB/s átviteli sebesség		 Gyorsítótár = NINCS
SQL Server maximális memóriaparaméter A fizikai RAM 95%-a Egyetlen példány felvállalása

Ez a konfiguráció például egy SQL Serveren futó SAP Business Suite DBMS virtuálisgép-konfigurációja. Ez a virtuális gép üzemelteti egy globális vállalat egyetlen globális SAP Business Suite-példányának 30 TB-os adatbázisát, amely több mint 200B dolláros éves bevétellel és több mint 200 ezer teljes munkaidős alkalmazottal rendelkezik. A rendszer minden pénzügyi feldolgozást, értékesítést és elosztási feldolgozást, valamint számos további üzleti folyamatot futtat különböző területekről, beleértve a Észak-Amerika n bérszámfejtést is. A rendszer 2018 eleje óta fut az Azure-ban, az Azure M sorozatú virtuális gépeket PEDIG DBMS virtuális gépekként használja. Magas rendelkezésre állás esetén a rendszer az Always on szolgáltatást használja egy szinkron replikával ugyanazon Azure-régió egy másik rendelkezésre állási zónájában, és egy másik aszinkron replikával egy másik Azure-régióban. A NetWeaver alkalmazásrétege Ev4 virtuális gépeken van üzembe helyezve.

Konfiguráció DBMS virtuális gép Hozzászólások
Virtuális gép típusa M192dms_v2 (192 vCPU/4,196 GiB RAM)
Accelerated Networking Engedélyezve
SQL Server-verzió SQL Server 2019
Adatfájlok száma 32
Naplófájlok száma 1
Ideiglenes adatfájlok száma 8
Operációs rendszer Windows Server 2019
Lemezösszesítés Tárolóhelyek
Fájlrendszer NTFS
Blokk méretének formázása 64 KB
Adatlemezek száma és típusa Prémium szintű tároló 1: 16 x P40 Gyorsítótár = Írásvédett
A naplólemezek száma és típusa Premium storage v1: 1 x P60 Írásgyorsító használata
Tempdb-lemezek száma és típusa Prémium szintű tároló 1: 1 x P30 Nincs gyorsítótárazás
SQL Server maximális memóriaparaméter A fizikai RAM 95%-a

Általános SQL Server az SAP-hoz az Azure-ban – összefoglalás

Ebben az útmutatóban számos javaslat található, és javasoljuk, hogy az Azure-telepítés megtervezése előtt többször is olvassa el. Általánosságban azonban mindenképpen kövesse az Azure-specifikus javaslatok leggyakoribb általános DBMS-ét:

  1. Használja a legújabb DBMS-kiadást, például az SQL Server 2019-et, amely a legtöbb előnnyel rendelkezik az Azure-ban.
  2. Gondosan tervezze meg az SAP rendszerállapotát az Azure-ban az adatfájl-elrendezés és az Azure-korlátozások egyensúlyba hozása érdekében:
    • Nincs túl sok lemeze, de elég van ahhoz, hogy elérje a szükséges IOPS-t.
      • Csak akkor csíkozza a lemezeket, ha nagyobb átviteli sebességet kell elérnie.
  3. Soha ne telepítsen szoftvereket, és ne helyezzen el olyan fájlokat, amelyek megőrzése szükséges a D:\ meghajtón, mivel az nem állandó, és a meghajtón lévő bármi elveszhet a Windows újraindítása vagy a virtuális gép újraindítása során.
  4. Adatbázisadatok replikálásához használja a DBMS-szállító HA/DR megoldását.
  5. Mindig használjon névfeloldás, ne támaszkodjon IP-címekre.
  6. Az SQL Server TDE használatával alkalmazza a legújabb SQL Server-javításokat.
  7. Legyen óvatos az Azure Marketplace-ről származó SQL Server-rendszerképek használatával. Ha az SQL Servert használja, módosítania kell a példányok rendezést, mielőtt bármilyen SAP NetWeaver-rendszert telepítene rá.
  8. Telepítse és konfigurálja az Azure-beli SAP-gazdagépek monitorozását az üzembe helyezési útmutatóban leírtak szerint.

Következő lépések

A cikk elolvasása