Distribuzione DBMS per IBM DB2 di macchine virtuali di Azure per un carico di lavoro SAP

Con Microsoft Azure è possibile eseguire facilmente la migrazione dell'applicazione SAP esistente in esecuzione in IBM Db2 per Linux, UNIX e Windows (LUW) alle macchine virtuali di Azure. Con SAP in IBM Db2 per LUW, gli amministratori e gli sviluppatori possono continuare a usare gli stessi strumenti di sviluppo e amministrazione disponibili in locale. Informazioni generali sull'esecuzione di SAP Business Suite in IBM Db2 per LUW sono disponibili tramite SAP Community Network (SCN) in SAP in IBM Db2 per Linux, UNIX e Windows.

Per altre informazioni e aggiornamenti su SAP in Db2 per LUW in Azure vedere la nota SAP 2233094.

Sono stati pubblicati vari articoli sul carico di lavoro SAP in Azure. È consigliabile iniziare a usare SAP nelle macchine virtuali di Azure e quindi leggere altre aree di interesse.

Le note SAP seguenti sono correlate a SAP in Azure relativamente all'area coperta in questo documento:

Numero della nota Titolo
1928533 Applicazioni SAP in Azure: prodotti e tipi di macchine virtuali di Azure supportati.
2015553 SAP in Microsoft Azure: prerequisiti per il supporto
1999351 Risoluzione dei problemi del monitoraggio avanzato di Azure per SAP
2178632 Metriche chiave del monitoraggio per SAP in Microsoft Azure
1409604 Virtualizzazione in Windows: monitoraggio avanzato
2191498 SAP in Linux con Azure: monitoraggio avanzato
2233094 DB6: informazioni aggiuntive sulle applicazioni SAP in Azure che usano IBM DB2 per Linux, UNIX e Windows
2243692 Linux in una macchina virtuale di Microsoft Azure (IaaS): problemi delle licenze SAP
1984787 SUSE LINUX Enterprise Server 12: Note sull'installazione
2002167 Red Hat Enterprise Linux 7.x: installazione e aggiornamento
1597355 Raccomandazione sullo spazio di scambio per Linux

Come pre-lettura a questo documento, è necessario leggere il documento Considerazioni per la distribuzione di DBMS per azure Macchine virtuali DBMS per il carico di lavoro SAP e altre guide nel carico di lavoro SAP nella documentazione di Azure.

Supporto della versione di IBM Db2 per Linux, UNIX e Windows

SAP in IBM Db2 per LUW nei servizi Macchine virtuali di Microsoft Azure è supportato a partire da Db2 versione 10.5.

Per informazioni sui prodotti SAP e sui tipi di VM di Azure supportati, vedere la nota SAP 1928533.

Linee guida per la configurazione di IBM Db2 per Linux, UNIX e Windows per le installazioni di SAP nelle VM di Azure

Configurazione dell'archiviazione

Per una panoramica dei tipi di archiviazione di Azure per il carico di lavoro SAP, vedere l'articolo Tipi di archiviazione di Azure per i carichi di lavoro SAP Tutti i file di database devono essere archiviati nei dischi montati dell'archiviazione a blocchi di Azure (Windows: NTFS, Linux: xfs o ext3). I volumi condivisi remoti come i servizi di Azure negli scenari elencati non sono supportati per i file di database Db2:

I volumi condivisi remoti come i servizi di Azure negli scenari elencati sono supportati per i file di database Db2:

  • L'hosting di file di dati e log del sistema operativo guest Linux basato su Db2 nelle condivisioni NFS ospitate in Azure NetApp Files è supportato.

Se si usano dischi basati su Archiviazione BLOB di pagine di Azure o su Managed Disks, le istruzioni riportate in Considerazioni sulla distribuzione DBMS di Macchine virtuali di Azure per un carico di lavoro SAP si applicano anche a DBMS Db2.

Come spiegato in precedenza nella parte generale del documento, esistono quote relative alla velocità effettiva delle operazioni di I/O al secondo per i dischi di Azure. Le quote esatte dipendono dal tipo di VM usato. Un elenco dei tipi di VM con le rispettive quote è disponibile qui (per Linux) e qui (per Windows).

Se la quota corrente di operazioni di I/O al secondo per ogni disco è sufficiente, è possibile archiviare tutti i file di database in un singolo disco montato. Mentre è sempre consigliabile separare i file di dati e i file di log delle transazioni nei diversi dischi/dischi rigidi virtuali.

Per le considerazioni sulle prestazioni, vedere anche il capitolo relativo alle considerazioni sulle prestazioni e la sicurezza dei dati per le directory di database nelle guide di installazione di SAP.

In alternativa, è possibile usare pool di archiviazione Windows (disponibili solo in Windows Server 2012 e versioni successive) come descritto Considerazioni per la distribuzione di DATABASEMS di Azure Macchine virtuali per il carico di lavoro SAP o LVM o mdadm in Linux per creare un dispositivo logico di grandi dimensioni su più dischi.

Per la macchina virtuale serie M di Azure, la latenza di scrittura nei log delle transazioni può essere ridotta da fattori, rispetto alle prestazioni di archiviazione Premium di Azure, quando si usa l'acceleratore di scrittura di Azure. Pertanto, è necessario distribuire l'acceleratore di scrittura di Azure per i dischi rigidi virtuali che formano il volume per i log delle transazioni Db2. I dettagli sono disponibili nel documento relativo all'acceleratore di scrittura.

Ibm Db2 LUW 11.5 ha rilasciato il supporto per le dimensioni del settore a 4 KB. Anche se è necessario abilitare l'utilizzo delle dimensioni del settore a 4 KB con 11,5 dall'impostazione delle configurazioni di db2set DB2_4K_DEVICE_SUPPORT=ON come documentato in:

Per le versioni precedenti di Db2, è necessario usare una dimensione del settore a 512 byte. I dischi SSD Premium sono nativi di 4 KB e hanno 512 byte emulazione. Il disco Ultra usa le dimensioni del settore a 4 KB per impostazione predefinita. È possibile abilitare le dimensioni del settore a 512 byte durante la creazione di un disco Ultra. I dettagli sono disponibili usando i dischi ultra di Azure. Questa dimensione del settore di 512 byte è un prerequisito per le versioni IBM Db2 LUW inferiori a 11,5.

In Windows che usa pool di archiviazione per i percorsi di archiviazione Db2 per log_dirsapdata e saptmp directory, è necessario specificare una dimensione del settore del disco fisico pari a 512 byte. Quando si usano pool di archiviazione di Windows, è necessario creare manualmente i pool di archiviazione tramite l'interfaccia della riga di comando usando il parametro -LogicalSectorSizeDefault. Per altre informazioni, vedere New-StoragePool.

Raccomandazione sulla macchina virtuale e sulla struttura del disco per la distribuzione di IBM Db2

IBM Db2 per le applicazioni SAP NetWeaver è supportato in qualsiasi tipo di macchina virtuale elencato nella nota di supporto SAP 1928533. Le famiglie di macchine virtuali consigliate per l'esecuzione del database IBM Db2 sono Esd_v4/Eas_v4/Es_v3 e serie M/M_v2 per database multi-terabyte di grandi dimensioni. Le prestazioni di scrittura del disco del log delle transazioni IBM Db2 possono essere migliorate abilitando l'acceleratore di scrittura serie M.

Di seguito è riportata una configurazione di base per varie dimensioni e l'uso di SAP nelle distribuzioni db2 da piccole a grandi dimensioni. L'elenco si basa sull'archiviazione Premium di Azure. Tuttavia, il disco Azure Ultra è completamente supportato con Db2 e può essere usato anche. Usare i valori per capacità, velocità effettiva burst e operazioni di I/O al secondo per definire la configurazione del disco Ultra. È possibile limitare le operazioni di I/O al secondo per /db2//<SID>log_dir a circa 5000 operazioni di I/O al secondo.

Sistema SAP di dimensioni aggiuntive: dimensioni del database 50 - 200 GB: esempio di Solution Manager

Nome macchina virtuale/dimensioni Punto di montaggio Db2 Disco Premium di Azure # di Dischi Operazioni di I/O al secondo Attraverso-
inserire [MB/s]
Dimensioni [GB] Operazioni di I/O al secondo in modalità burst Burst Through-
put [GB]
Dimensioni di striping Memorizzazione nella cache
E4ds_v4 /db2 P6 1 240 50 64 3\.500 170
vCPU: 4 /db2//<SID>sapdata P10 2 1\.000 200 256 7.000 340 256
KB
ReadOnly
RAM: 32 GiB /db2//<SID>saptmp P6 1 240 50 128 3\.500 170
/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

Sistema SAP di piccole dimensioni: dimensioni del database 200 - 750 GB: small Business Suite

Nome macchina virtuale/dimensioni Punto di montaggio Db2 Disco Premium di Azure # di Dischi Operazioni di I/O al secondo Attraverso-
inserire [MB/s]
Dimensioni [GB] Operazioni di I/O al secondo in modalità burst Burst Through-
put [GB]
Dimensioni di striping Memorizzazione nella cache
E16ds_v4 /db2 P6 1 240 50 64 3\.500 170
vCPU: 16 /db2//<SID>sapdata P15 4 4.400 500 1.024 14.000 680 256 KB ReadOnly
RAM: 128 GiB /db2//<SID>saptmp P6 2 480 100 128 7.000 340 128 KB
/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

Sistema SAP medio: dimensioni del database da 500 a 1000 GB: small Business Suite

Nome/dimensione della macchina virtuale Punto di montaggio Db2 Disco Premium di Azure Numero di dischi Operazioni di I/O al secondo Through-
put [MB/s]
Dimensioni [GB] Operazioni di I/O al secondo in modalità burst Burst Through-
put [GB]
Dimensioni di striping Memorizzazione nella cache
E32ds_v4 /db2 P6 1 240 50 64 3\.500 170
vCPU: 32 /db2/<SID>/sapdata P30 2 10,000 400 2.048 10,000 400 256 KB ReadOnly
RAM: 256 GiB /db2/<SID>/saptmp P10 2 1\.000 200 256 7.000 340 128 KB
/db2/<SID>/log_dir P20 2 4,600 300 1.024 7.000 340 64
KB
/db2/<SID>/offline_log_dir P15 1 1.100 125 256 3\.500 170

Sistema SAP di grandi dimensioni: dimensioni del database da 750 a 2000 GB: Business Suite

Nome/dimensione della macchina virtuale Punto di montaggio Db2 Disco Premium di Azure Numero di dischi Operazioni di I/O al secondo Through-
put [MB/s]
Dimensioni [GB] Operazioni di I/O al secondo in modalità burst Burst Through-
put [GB]
Dimensioni di striping Memorizzazione nella cache
E64ds_v4 /db2 P6 1 240 50 64 3\.500 170
vCPU: 64 /db2/<SID>/sapdata P30 4 20.000 800 4.096 20.000 800 256 KB ReadOnly
RAM: 504 GiB /db2/<SID>/saptmp P15 2 2.200 250 512 7.000 340 128 KB
/db2/<SID>/log_dir P20 4 9.200 600 2.048 14.000 680 64
KB
/db2/<SID>/offline_log_dir P20 1 2\.300 150 512 3\.500 170

Sistema SAP multi-terabyte di grandi dimensioni: dimensioni del database 2 TB+: sistema Global Business Suite

Nome/dimensione della macchina virtuale Punto di montaggio Db2 Disco Premium di Azure Numero di dischi Operazioni di I/O al secondo Through-
put [MB/s]
Dimensioni [GB] Operazioni di I/O al secondo in modalità burst Burst Through-
put [GB]
Dimensioni di striping Memorizzazione nella cache
M128s /db2 P10 1 500 100 128 3\.500 170
vCPU: 128 /db2/<SID>/sapdata P40 4 30.000 1.000 8.192 30.000 1.000 256 KB ReadOnly
RAM: 2048 GiB /db2/<SID>/saptmp P20 2 4,600 300 1.024 7.000 340 128 KB
/db2/<SID>/log_dir P30 4 20.000 800 4.096 20.000 800 64
KB
Scrittura-
Acceleratore
/db2/<SID>/offline_log_dir P30 1 5\.000 200 1.024 5\.000 200

Uso di Azure NetApp Files

L'utilizzo dei volumi NFS v4.1 basato su Azure NetApp Files (ANF) è supportato con IBM Db2, ospitato nel sistema operativo guest Suse o Red Hat Linux. È consigliabile creare almeno quattro volumi diversi, ad esempio:

  • Volume condiviso per saptmp1, sapmnt, usr_sap, <sid>_home, db2<sid>_home, db2_software
  • Un volume di dati da sapdata1 a sapdatan
  • Un volume di log per la directory di log di rollforward
  • Un volume per gli archivi di log e i backup

Un quinto volume potenziale può essere un volume ANF usato per backup a lungo termine usati per creare snapshot e archiviare gli snapshot nell'archivio BLOB di Azure.

La configurazione potrebbe essere simile a quella illustrata qui

Esempio di configurazione di Db2 con ANF

Il livello di prestazioni e le dimensioni dei volumi ospitati ANF devono essere scelti in base ai requisiti di prestazioni. È tuttavia consigliabile usare il livello di prestazioni Ultra per i dati e il volume di log. Non è supportata la combinazione di archiviazione a blocchi e tipi di archiviazione condivisa per il volume di dati e log.

A partire dalle opzioni di montaggio, il montaggio di tali volumi potrebbe essere simile a (è necessario sostituire <SID> e <sid> con il SID del sistema SAP):

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

Nota

L'opzione di montaggio è obbligatoria e la sincronizzazione

Backup/Ripristino

La funzionalità di backup/ripristino per IBM Db2 per LUW è supportata esattamente come nei sistemi operativi Windows Server standard e in Hyper-V.

Assicurarsi di disporre di una strategia di backup del database valida.

Come nelle distribuzioni bare metal, le prestazioni di backup/ripristino dipendono dalla quantità di volumi leggibili in parallelo e dalla velocità effettiva di tali volumi. Inoltre, l'uso di CPU associato alla compressione del backup può avere un ruolo significativo per VM con un massimo di otto thread CPU. Si può quindi presumere quanto segue:

  • Minore è il numero dei dischi usati per l'archiviazione dei dispositivi del database, più bassa è la velocità effettiva generale nella lettura
  • Minore è il numero di thread CPU nella VM, più forte è l'impatto della compressione del backup
  • Minore è il numero di destinazioni (directory di striping o dischi) in cui scrivere il backup, più bassa è la velocità effettiva

Per aumentare il numero di destinazioni in cui scrivere, è possibile usare/combinare due opzioni a seconda delle proprie esigenze:

  • Striping del volume di destinazione di backup su più dischi per migliorare la velocità effettiva delle operazioni di I/O al secondo in quel volume con striping
  • Uso di più di una directory di destinazione in cui scrivere il backup

Nota

Db2 su Windows non supporta la tecnologia Windows VSS. Di conseguenza, il backup della macchina virtuale coerente con l'applicazione del servizio Backup di Azure non può essere usato per le macchine virtuali in cui è distribuito Db2 DBMS.

Disponibilità elevata e ripristino di emergenza

Linux Pacemaker

Importante

Per Db2 versioni 11.5.6 e successive, è consigliabile usare la soluzione integrata con Pacemaker di IBM.

Windows Cluster Server

Il server di cluster Microsoft non è supportato.

La disponibilità elevata e il ripristino di emergenza Db2 sono supportati. Se le macchine virtuali della configurazione a disponibilità elevata hanno una risoluzione dei nomi funzionante, la configurazione in Azure non sarà diversa da quelle eseguite in locale. Non è consigliabile affidarsi solo alla risoluzione IP.

Non usare la replica geografica per gli account di archiviazione in cui vengono archiviati i dischi di database. Per altre informazioni, vedere il documento Considerazioni per la distribuzione di DBMS di Azure Macchine virtuali per il carico di lavoro SAP.

Rete accelerata

Per le distribuzioni Db2 in Windows, è consigliabile usare la funzionalità Rete accelerata di Azure come descritto nell'articolo relativo alla Rete accelerata di Azure. Valutare anche i consigli offerti in Considerations for Azure Virtual Machines DBMS deployment for SAP workload (Considerazioni sulla distribuzione DBMS di macchine virtuali di Azure per un carico di lavoro SAP).

Informazioni specifiche per le distribuzioni di Linux

Se la quota corrente di operazioni di I/O al secondo per ogni disco è sufficiente, è possibile archiviare tutti i file di database in un singolo disco. Mentre è sempre necessario separare i file di dati e i file di log delle transazioni in dischi diversi.

Se la velocità effettiva di I/O al secondo o I/O di un singolo disco rigido virtuale di Azure non è sufficiente, è possibile usare LVM (Logical Volume Manager) o MDADM come descritto nel documento Considerazioni sulla distribuzione di DBMS di Azure Macchine virtuali per il carico di lavoro SAP per creare un dispositivo logico di grandi dimensioni su più dischi. Per i dischi contenenti i percorsi di archiviazione Db2 per le directory sapdata e saptmp, è necessario specificare una dimensione del settore del disco pari a 512 kB.

Altri

Tutti gli altri argomenti generali, ad esempio i set di disponibilità di Azure o il monitoraggio SAP, si applicano come descritto nel documento Considerations for Azure Virtual Machines DBMS deployment for SAP workload (Considerazioni sulla distribuzione DBMS di Macchine virtuali di Azure per un carico di lavoro SAP) anche per le distribuzioni di VM con IBM Database.

Passaggi successivi

Leggi l'articolo