DBMS-distribution för SAP-arbetsbelastning för IBM Db2 på virtuella Azure-datorer
Med Microsoft Azure kan du migrera ditt befintliga SAP-program som körs på IBM Db2 för Linux, UNIX och Windows (LUW) till virtuella Azure-datorer. Med SAP på IBM Db2 för LUW kan administratörer och utvecklare fortfarande använda samma utveckling- och administrationsverktyg, som är tillgängliga lokalt. Allmän information om att köra SAP Business Suite på IBM Db2 för LUW är tillgänglig via SAP Community Network (SCN) i SAP på IBM Db2 för Linux, UNIX och Windows.
Mer information och uppdateringar om SAP på Db2 för LUW på Azure finns i SAP Note 2233094.
Det finns olika artiklar för SAP-arbetsbelastningar i Azure. Vi rekommenderar att du börjar med Kom igång med SAP på virtuella Azure-datorer och läser sedan om andra intressanta områden.
Följande SAP-anteckningar är relaterade till SAP på Azure angående det område som beskrivs i det här dokumentet:
| Anteckningsnummer | Title |
|---|---|
| 1928533 | SAP-program i Azure: Produkter som stöds och typer av virtuella Azure-datorer |
| 2015553 | SAP på Microsoft Azure: Supportkrav |
| 1999351 | Felsöka förbättrad Azure-övervakning för SAP |
| 2178632 | Viktiga övervakningsmått för SAP på Microsoft Azure |
| 1409604 | Virtualisering i Windows: Förbättrad övervakning |
| 2191498 | SAP på Linux med Azure: Förbättrad övervakning |
| 2233094 | DB6: SAP-program i Azure med IBM DB2 för Linux, UNIX och Windows – ytterligare information |
| 2243692 | Linux på en virtuell IaaS-dator (Microsoft Azure): SAP-licensproblem |
| 1984787 | SUSE LINUX Enterprise Server 12: Installationsanteckningar |
| 2002167 | Red Hat Enterprise Linux 7.x: Installation och uppgradering |
| 1597355 | Växlingsutrymmesrekommendering för Linux |
Som en förläsning till det här dokumentet läser du Överväganden för AZURE Virtual Machines DBMS-distribution för SAP-arbetsbelastning. Granska andra guider i SAP-arbetsbelastningen i Azure.
Stöd för IBM Db2 för Linux, UNIX och Windows
SAP på IBM Db2 för LUW på Microsoft Azure Virtual Machine Services stöds från och med Db2 version 10.5.
Information om SAP-produkter som stöds och typer av virtuella Azure-datorer finns i SAP Note 1928533.
IBM Db2 för Linux, UNIX och Windows-konfigurationsriktlinjer för SAP-installationer på virtuella Azure-datorer
Storage-konfiguration
En översikt över Azure-lagringstyper för SAP-arbetsbelastningar finns i artikeln Azure Storage-typer för SAP-arbetsbelastning Alla databasfiler måste lagras på monterade diskar i Azure Block Storage (Windows: NTFS, Linux: xfs, stöds från och med Db2 11.1 eller ext3).
Fjärrdelade volymer som Azure-tjänsterna i de angivna scenarierna stöds INTE för Db2-databasfiler:
Microsoft Azure File Service för alla gästoperativsystem.
Azure NetApp Files for Db2 körs i Windows gästoperativsystem.
Fjärrdelade volymer som Azure-tjänsterna i de angivna scenarierna stöds för Db2-databasfiler:
- Värd för Linux-gästoperativsystembaserade Db2-data och loggfiler på NFS-resurser som finns på Azure NetApp Files stöds!
Om du använder diskar baserat på Azure Page BLOB Storage eller Managed Disks gäller även de instruktioner som gjorts i Överväganden för Azure Virtual Machines DBMS-distribution för SAP-arbetsbelastningar för distributioner med Db2 DBMS (Database Management System).
Som vi förklarade tidigare i den allmänna delen av dokumentet finns det kvoter för IOPS-dataflöde (I/O-åtgärder per sekund) för Azure-diskar. De exakta kvoterna beror på vilken typ av virtuell dator som används. En lista över typer av virtuella datorer med deras kvoter finns här (Linux) och här (Windows).
Så länge den aktuella IOPS-kvoten per disk räcker är det möjligt att lagra alla databasfiler på en enda monterad disk. Du bör alltid separera datafilerna och transaktionsloggfilerna på olika diskar/virtuella hårddiskar.
För prestandaöverväganden, se även kapitlet "Datasäkerhet och prestandaöverväganden för databaskataloger" i SAP-installationsguider.
Du kan också använda Windows Storage-pooler, som endast är tillgängliga i Windows Server 2012 och senare enligt beskrivningen Överväganden för AZURE Virtual Machines DBMS-distribution för SAP-arbetsbelastning. I Linux kan du använda LVM eller mdadm för att skapa en stor logisk enhet över flera diskar.
För virtuella Datorer i Azure M-serien kan du minska med hjälp av faktorer som svarstiden som skrivs in i transaktionsloggarna, jämfört med Azure Premium-lagringsprestanda, när du använder Azure Write Accelerator. Därför bör du distribuera Azure Write Accelerator för en eller flera virtuella hårddiskar som utgör volymen för Db2-transaktionsloggarna. Information kan läsas i dokumentet Skrivaccelerator.
IBM Db2 LUW 11.5 släppte stöd för 4 KB sektorstorlek. Du måste dock aktivera användningen av 4 KB sektorstorlek med 11,5 enligt konfigurationsinställningen för db2set DB2_4K_DEVICE_SUPPORT=ON enligt beskrivningen i:
För äldre Db2-versioner måste en sektorstorlek på 512 byte användas. Premium SSD-diskar är inbyggda i 4 KB och har 512 byte emulering. Ultra disk använder 4 KB sektorstorlek som standard. Du kan aktivera sektorstorleken 512 byte när ultradisken skapas. Information finns i Använda Azure Ultra Disks. Den här sektorstorleken på 512 byte är en förutsättning för IBM Db2 LUW-versioner som är lägre än 11,5.
I Windows med lagringspooler för Db2-lagringssökvägar för log_diroch sapdata saptmp kataloger måste du ange en fysisk disksektorstorlek på 512 byte. När du använder Windows Storage-pooler måste du skapa lagringspoolerna manuellt via kommandoradsgränssnittet med hjälp av parametern -LogicalSectorSizeDefault. Mer information finns i New-StoragePool.
Rekommendation om virtuell dator och diskstruktur för IBM Db2-distribution
IBM Db2 för SAP NetWeaver-program stöds på alla typer av virtuella datorer som anges i SAP-supportanteckningen 1928533. Rekommenderade VM-familjer för att köra IBM Db2-databasen är Esd_v4/Eas_v4/Es_v3 och M/M_v2-serien för stora databaser med flera terabyte. Skrivprestanda för IBM Db2-transaktionsloggdiskar kan förbättras genom att aktivera skrivningsacceleratorn i M-serien.
Följande är en baslinjekonfiguration för olika storlekar och användningar av SAP på Db2-distributioner från små till x-stora.
Viktigt!
De typer av virtuella datorer som anges nedan är exempel som uppfyller vCPU och minnes critiera för var och en av kategorierna. Lagringskonfigurationen baseras på Azure Premium Storage v1. Premium SSD v2 och Azure Ultra Disk stöds även fullt ut med IBM Db2 och kan användas för distributioner. Använd värdena för kapacitet, burst-dataflöde och burst-IOPS för att definiera Ultra-disken eller Premium SSD v2-konfigurationen. Du kan begränsa IOPS för /db2/<SID>/log_dir till cirka 5 000 IOPS. Justera dataflödet och IOPS till den specifika arbetsbelastningen om dessa baslinjerekommendationer inte uppfyller kraven
Extra litet SAP-system: databasstorlek 50–200 GB: exempel på Solution Manager
| VM-storlek/exempel | Db2-monteringspunkt | Azure Premium-disk | Antal diskar | IOPS | Genom- put [MB/s] |
Storlek [GB] | Burst-IOPS | Burst Through- put [GB] |
Randstorlek | Cachelagring |
|---|---|---|---|---|---|---|---|---|---|---|
| vCPU: 4 | /db2 | P6 | 1 | 240 | 50 | 64 | 3 500 | 170 | ||
| RAM: ~32 GiB | /db2/<SID>/sapdata |
P10 | 2 | 1,000 | 200 | 256 | 7 000 | 340 | 256 kB |
Skrivskyddat |
| E4(d)s_v5 | /db2/<SID>/saptmp |
P6 | 1 | 240 | 50 | 128 | 3 500 | 170 | ||
| E4(d)as_v5 | /db2/<SID>/log_dir |
P6 | 2 | 480 | 100 | 128 | 7 000 | 340 | 64 kB |
|
| ... | /db2/<SID>/offline_log_dir |
P10 | 1 | 500 | 100 | 128 | 3 500 | 170 |
Litet SAP-system: databasstorlek 200–750 GB: small Business Suite
| VM-storlek/exempel | Db2-monteringspunkt | Azure Premium-disk | Antal diskar | IOPS | Genom- put [MB/s] |
Storlek [GB] | Burst-IOPS | Burst Through- put [GB] |
Randstorlek | Cachelagring |
|---|---|---|---|---|---|---|---|---|---|---|
| vCPU: 16 | /db2 | P6 | 1 | 240 | 50 | 64 | 3 500 | 170 | ||
| RAM: ~128 GiB | /db2/<SID>/sapdata |
P15 | 4 | 4,400 | 500 | 1.024 | 14 000 | 680 | 256 kB | Skrivskyddat |
| E16(d)s_v5 | /db2/<SID>/saptmp |
P6 | 2 | 480 | 100 | 128 | 7 000 | 340 | 128 kB | |
| E16(d)as_v5 | /db2/<SID>/log_dir |
P15 | 2 | 2 200 | 250 | 512 | 7 000 | 340 | 64 kB |
|
| ... | /db2/<SID>/offline_log_dir |
P10 | 1 | 500 | 100 | 128 | 3 500 | 170 |
Medelstort SAP-system: databasstorlek 500–1 000 GB: small Business Suite
| VM-storlek/exempel | Db2-monteringspunkt | Azure Premium-disk | Antal diskar | IOPS | Genom- put [MB/s] |
Storlek [GB] | Burst-IOPS | Burst Through- put [GB] |
Randstorlek | Cachelagring |
|---|---|---|---|---|---|---|---|---|---|---|
| vCPU: 32 | /db2 | P6 | 1 | 240 | 50 | 64 | 3 500 | 170 | ||
| RAM: ~256 GiB | /db2/<SID>/sapdata |
P30 | 2 | 10,000 | 400 | 2.048 | 10,000 | 400 | 256 kB | Skrivskyddat |
| E32(d)s_v5 | /db2/<SID>/saptmp |
P10 | 2 | 1,000 | 200 | 256 | 7 000 | 340 | 128 kB | |
| E32(d)as_v5 | /db2/<SID>/log_dir |
P20 | 2 | 4,600 | 300 | 1.024 | 7 000 | 340 | 64 kB |
|
| M32ls | /db2/<SID>/offline_log_dir |
P15 | 1 | 1 100 | 125 | 256 | 3 500 | 170 |
Stort SAP-system: databasstorlek 750–2 000 GB: Business Suite
| VM-storlek/exempel | Db2-monteringspunkt | Azure Premium-disk | Antal diskar | IOPS | Genom- put [MB/s] |
Storlek [GB] | Burst-IOPS | Burst Through- put [GB] |
Randstorlek | Cachelagring |
|---|---|---|---|---|---|---|---|---|---|---|
| vCPU: 64 | /db2 | P6 | 1 | 240 | 50 | 64 | 3 500 | 170 | ||
| RAM: ~512 GiB | /db2/<SID>/sapdata |
P30 | 4 | 20 000 | 800 | 4.096 | 20 000 | 800 | 256 kB | Skrivskyddat |
| E64(d)s_v5 | /db2/<SID>/saptmp |
P15 | 2 | 2 200 | 250 | 512 | 7 000 | 340 | 128 kB | |
| E64(d)as_v5 | /db2/<SID>/log_dir |
P20 | 4 | 9,200 | 600 | 2.048 | 14 000 | 680 | 64 kB |
|
| M64ls | /db2/<SID>/offline_log_dir |
P20 | 1 | 2 300 | 150 | 512 | 3 500 | 170 |
Stort SAP-system med flera terabyte: databasstorlek 2 TB+: Globalt Business Suite-system
Särskilt för sådana större system är det viktigt att utvärdera infrastrukturen som systemet körs på och resursförbrukningsdata för dessa system för att hitta den bästa matchningen av Azure-beräknings- och lagringsinfrastrukturen och konfigurationen.
| Namn/storlek på virtuell dator | Db2-monteringspunkt | Azure Premium-disk | Antal diskar | IOPS | Genom- put [MB/s] |
Storlek [GB] | Burst-IOPS | Burst Through- put [GB] |
Randstorlek | Cachelagring |
|---|---|---|---|---|---|---|---|---|---|---|
| vCPU: =>128 | /db2 | P10 | 1 | 500 | 100 | 128 | 3 500 | 170 | ||
| RAM: =>2 048 GiB | /db2/<SID>/sapdata |
P40 | 4 | 30,000 | 1 000 | 8.192 | 30,000 | 1 000 | 256 kB | Skrivskyddat |
| M128s_v2 | /db2/<SID>/saptmp |
P20 | 2 | 4,600 | 300 | 1.024 | 7 000 | 340 | 128 kB | |
| M176s_2_v3 | /db2/<SID>/log_dir |
P30 | 4 | 20 000 | 800 | 4.096 | 20 000 | 800 | 64 kB |
Skriva- Gaspedal |
| M176s_3_v3, M176s_4_v3 |
/db2/<SID>/offline_log_dir |
P30 | 1 | 5 000 | 200 | 1.024 | 5 000 | 200 |
Använda Azure NetApp Files
Användningen av NFS v4.1-volymer baserat på Azure NetApp Files (ANF) stöds med IBM Db2, som finns i Suse eller Red Hat Linux gästoperativsystem. Du bör skapa minst fyra olika volymer som listar som:
- Delad volym för saptmp1, sapmnt, usr_sap,
<sid>_home, db2<sid>_home, db2_software - En datavolym för sapdata1 till sapdatan
- En loggvolym för loggkatalogen för att göra om
- En volym för loggarkiv och säkerhetskopior
En femte potentiell volym kan vara en ANF-volym som du använder för fler långsiktiga säkerhetskopieringar som du använder för att ögonblicksbilder och lagra ögonblicksbilder i Azure Blob Store.
Konfigurationen kan se ut så här:
Prestandanivån och storleken på ANF-värdbaserade volymer måste väljas baserat på prestandakraven. Vi rekommenderar dock att du tar ultraprestandanivån för data och loggvolymen. Det går inte att blanda blocklagring och delade lagringstyper för data- och loggvolymen.
När det gäller monteringsalternativ kan monteringen av dessa volymer se ut (du måste ersätta <SID> och <sid> med SID för DITT SAP-system):
vi /etc/idmapd.conf
# Example
[General]
Domain = defaultv4iddomain.com
[Mapping]
Nobody-User = nobody
Nobody-Group = nobody
mount -t nfs -o rw,hard,sync,rsize=262144,wsize=262144,sec=sys,vers=4.1,tcp 172.17.10.4:/db2shared /mnt
mkdir -p /db2/Software /db2/AN1/saptmp /usr/sap/<SID> /sapmnt/<SID> /home/<sid>adm /db2/db2<sid> /db2/<SID>/db2_software
mkdir -p /mnt/Software /mnt/saptmp /mnt/usr_sap /mnt/sapmnt /mnt/<sid>_home /mnt/db2_software /mnt/db2<sid>
umount /mnt
mount -t nfs -o rw,hard,sync,rsize=262144,wsize=262144,sec=sys,vers=4.1,tcp 172.17.10.4:/db2data /mnt
mkdir -p /db2/AN1/sapdata/sapdata1 /db2/AN1/sapdata/sapdata2 /db2/AN1/sapdata/sapdata3 /db2/AN1/sapdata/sapdata4
mkdir -p /mnt/sapdata1 /mnt/sapdata2 /mnt/sapdata3 /mnt/sapdata4
umount /mnt
mount -t nfs -o rw,hard,sync,rsize=262144,wsize=262144,sec=sys,vers=4.1,tcp 172.17.10.4:/db2log /mnt
mkdir /db2/AN1/log_dir
mkdir /mnt/log_dir
umount /mnt
mount -t nfs -o rw,hard,sync,rsize=262144,wsize=262144,sec=sys,vers=4.1,tcp 172.17.10.4:/db2backup /mnt
mkdir /db2/AN1/backup
mkdir /mnt/backup
mkdir /db2/AN1/offline_log_dir /db2/AN1/db2dump
mkdir /mnt/offline_log_dir /mnt/db2dump
umount /mnt
Kommentar
Monteringsalternativet är hårt och synkroniserat krävs
Säkerhetskopiering/återställning
Säkerhetskopierings-/återställningsfunktionerna för IBM Db2 för LUW stöds på samma sätt som i Windows Server-standardoperativsystem och Hyper-V.
Kontrollera att du har en giltig strategi för säkerhetskopiering av databaser på plats.
Precis som i bare metal-distributioner beror prestanda för säkerhetskopiering/återställning på hur många volymer som kan läsas parallellt och vilket dataflöde dessa volymer kan vara. Dessutom kan cpu-förbrukningen som används vid säkerhetskopieringskomprimering spela en viktig roll på virtuella datorer med upp till åtta CPU-trådar. Därför kan man anta:
- Ju färre diskar som används för att lagra databasenheterna, desto mindre är det totala dataflödet vid läsning
- Ju mindre antal CPU-trådar i den virtuella datorn, desto allvarligare påverkan av säkerhetskopieringskomprimering
- Ju färre mål (Stripe-kataloger, diskar) som säkerhetskopieringen ska skrivas till, desto lägre dataflöde
Om du vill öka antalet mål att skriva till kan två alternativ användas/kombineras beroende på dina behov:
- Ta bort målvolymen för säkerhetskopiering över flera diskar för att förbättra IOPS-dataflödet på den randiga volymen
- Använda mer än en målkatalog för att skriva säkerhetskopian till
Kommentar
Db2 i Windows stöder inte Windows VSS-tekniken. Därför kan inte programsekvent VM-säkerhetskopiering av Azure Backup Service användas för virtuella datorer som Db2 DBMS distribueras i.
Hög tillgänglighet och Haveriberedskap
Linux Pacemaker
Viktigt!
För Db2-versionerna 11.5.6 och senare rekommenderar vi starkt integrerad lösning med pacemaker från IBM.
- Integrerad lösning med pacemaker
- Alternativa eller ytterligare konfigurationer som är tillgängliga på Haveriberedskap med hög tillgänglighet i Microsoft Azure Db2 (HADR) med pacemaker stöds. Både SLES- och RHEL-operativsystem stöds. Den här konfigurationen möjliggör hög tillgänglighet för IBM Db2 för SAP. Distributionsguider:
- SLES: Hög tillgänglighet för IBM Db2 LUW på virtuella Azure-datorer på SUSE Linux Enterprise Server med Pacemaker
- RHEL: Hög tillgänglighet för IBM Db2 LUW på virtuella Azure-datorer på Red Hat Enterprise Linux Server
Windows-klusterserver
Windows Server-redundanskluster (WSFC) som även kallas Microsoft Cluster Server (MSCS) stöds inte.
Haveriberedskap med hög tillgänglighet (HADR) i Db2 stöds. Om de virtuella datorerna i HA-konfigurationen har arbetsnamnsmatchning skiljer sig konfigurationen i Azure inte från någon installation som görs lokalt. Vi rekommenderar inte att du bara förlitar dig på IP-matchning.
Använd inte Geo-Replication för de lagringskonton som lagrar databasdiskarna. Mer information finns i dokumentet Överväganden för AZURE Virtual Machines DBMS-distribution för SAP-arbetsbelastning.
Accelererat nätverk
För Db2-distributioner i Windows rekommenderar vi starkt att du använder Azure-funktionerna i Accelererat nätverk enligt beskrivningen i dokumentet Azure Accelerated Networking. Överväg även rekommendationer som gjorts i Överväganden för AZURE Virtual Machines DBMS-distribution för SAP-arbetsbelastning.
Detaljer för Linux-distributioner
Så länge den aktuella IOPS-kvoten per disk räcker är det möjligt att lagra alla databasfiler på en enda disk. Du bör alltid separera datafilerna och transaktionsloggfilerna på olika diskar.
Om IOPS- eller I/O-dataflödet för en enda virtuell Azure-hårddisk inte räcker kan du använda LVM (Logical Volume Manager) eller MDADM enligt beskrivningen i dokumentet Överväganden för Azure Virtual Machines DBMS-distribution för SAP-arbetsbelastning för att skapa en stor logisk enhet över flera diskar.
För de diskar som innehåller Db2-lagringssökvägarna för dina sapdata kataloger och saptmp kataloger måste du ange en fysisk disksektorstorlek på 512 KB.
Övrigt
Alla andra allmänna områden som Azure-tillgänglighetsuppsättningar eller SAP-övervakning gäller även för distributioner av virtuella datorer med IBM Database. Dessa allmänna områden beskriver vi i Överväganden för AZURE Virtual Machines DBMS-distribution för SAP-arbetsbelastning.
Nästa steg
Läs artikeln: