Implementación de DBMS de Azure Virtual Machines de IBM Db2 para carga de trabajo de SAP
Con Microsoft Azure, puede migrar la aplicación SAP existente que se ejecuta en IBM Db2 para Linux, UNIX y Windows (LUW) a Azure Virtual Machines. Con SAP en IBM Db2 para LUW, los administradores y los desarrolladores pueden seguir usando las mismas herramientas de desarrollo y administración, disponibles de forma local. Información general sobre la ejecución de SAP Business Suite en IBM Db2 para LUW se encuentra disponible a través de SAP Community Network (SCN) en SAP en IBM Db2 para Linux, UNIX y Windows.
Para obtener más información y actualizaciones de SAP en Db2 para LUW en Azure, vea la nota de SAP 2233094.
Hay varios artículos sobre la carga de trabajo de SAP en Azure. Se recomienda comenzar con Introducción a SAP en máquinas virtuales de Azure y, a continuación, leer sobre otras áreas de interés.
Las notas de SAP siguientes están relacionadas con SAP en Azure con respecto al área que se describe en este documento:
| Número de nota | Título |
|---|---|
| 1928533 | SAP Applications on Azure: Supported Products and Azure VM Types (Aplicaciones de SAP en Azure: productos y tipos de máquina virtual de Azure compatibles) |
| 2015553 | SAP on Microsoft Azure: Support Prerequisites (Requisitos previos de soporte técnico de SAP en Microsoft Azure) |
| 1999351 | Troubleshooting Enhanced Azure Monitoring for SAP (Solución de problemas de la supervisión mejorada de Azure para SAP) |
| 2178632 | Key Monitoring Metrics for SAP on Microsoft Azure (Métricas de supervisión clave para SAP en Microsoft Azure) |
| 1409604 | Virtualization on Windows: Enhanced Monitoring (Virtualización en Windows: supervisión mejorada) |
| 2191498 | SAP on Linux with Azure: Enhanced Monitoring (Virtualización en Windows: supervisión mejorada) |
| 2233094 | DB6: SAP Applications on Azure Using IBM DB2 for Linux, UNIX, and Windows - Additional Information (DB6: aplicaciones de SAP en Azure con IBM DB2 para Linux, UNIX y Windows: información adicional) |
| 2243692 | Linux on Microsoft Azure (IaaS) VM: SAP license issues (Linux y máquinas virtuales de Microsoft Azure (IaaS): problemas de licencia de SAP) |
| 1984787 | SUSE LINUX Enterprise Server 12: Notas de instalación |
| 2002167 | Red Hat Enterprise Linux 7.x: Instalación y actualización |
| 1597355 | Recomendación de espacio de intercambio para Linux |
Como lectura previa para este documento, revise Consideraciones para la implementación de DBMS de Azure Virtual Machines para la carga de trabajo de SAP. Revise otras guías en Cargas de trabajo de SAP en Azure.
IBM Db2 para Linux, UNIX y compatibilidad de versiones de Windows
SAP en IBM Db2 para LUW en los servicios de Microsoft Azure Virtual Machines es compatible a partir de la versión 10.5 de Db2.
Para obtener más información sobre los tipos de VM (Virtual Machines) de Azure, consulte la nota de SAP 1928533.
Instrucciones de configuración de IBM Db2 para Linux, UNIX y Windows para instalaciones de SAP en máquinas virtuales de Azure
Configuración de almacenamiento
Para obtener información general sobre los tipos de Azure Storage para las carga de trabajo de SAP, consulte el artículo Tipos de Azure Storage para una carga de trabajo de SAP. Todos los archivos de base de datos deben almacenarse en discos montados de Azure Block Storage (Windows: NTFS, Linux: xfs, admitidos desde Db2 11.1 o ext3).
Los volúmenes compartidos remotos como los servicios de Azure en los escenarios enumerados NO son compatibles con los archivos de base de datos db2:
Microsoft Azure File Service para todos los sistemas operativos invitados.
Azure NetApp Files para db2 que se ejecuta en el sistema operativo invitado Windows.
Los volúmenes compartidos remotos como los servicios de Azure en los escenarios enumerados son compatibles con los archivos de base de datos db2:
- Se admite el hospedaje de archivos de datos y de registro db2 basados en el sistema operativo invitado Linux en recursos compartidos de NFS hospedados Azure NetApp Files.
Si usa discos basados en almacenamiento de blobs en páginas de Azure o Managed Disks, las afirmaciones realizadas en Consideraciones para la implementación de DBMS de Azure Virtual Machines para la carga de trabajo de SAP también se aplican a las implementaciones con el DBMS de Db2.
Como se explicó anteriormente en la parte general del documento, existen cuotas en el rendimiento IOPS para discos de Azure. Las cuotas exactas varían según el tipo de máquina virtual que se utilice. Puede encontrar una lista de tipos de máquinas virtuales con sus cuotas aquí (Linux) y aquí (Windows).
Mientras la cuota actual de IOPS por disco sea suficiente, se pueden almacenar todos los archivos de base de datos en un solo disco montado. Mientras que siempre debe separar los archivos de datos y los de registro de transacciones en otros discos o discos duros virtuales.
Para obtener las consideraciones de rendimiento, consulte también el capítulo "Data Safety and Performance Considerations for Database Directories" (Consideraciones de seguridad y rendimiento de directorios de bases de datos) en las guías de instalación de SAP.
También puede usar bloques de almacenamiento de Windows (solo disponibles en Windows Server 2012 y versiones posteriores), como se describe en Consideraciones para la implementación de DBMS de Azure Virtual Machines para la carga de trabajo de SAP. En Linux, puede usar LVM o mdadm para crear un dispositivo lógico grande con varios discos.
En el caso de la máquina virtual de Azure de la serie M, se puede reducir considerablemente la latencia de escritura en los registros de transacciones, en comparación con el rendimiento de Azure Premium Storage, cuando se usa el Acelerador de escritura de Azure. Por tanto, se debe implementar el Acelerador de escritura de Azure en uno o más discos duros virtuales que forman el volumen para los registros de transacciones de Db2. En el documento Acelerador de escritura se pueden leer los detalles.
IBM Db2 LUW 11.5 publicó compatibilidad con el tamaño del sector de 4 KB. No obstante, debe habilitar el uso del tamaño de sector de 4 KB con la versión 11.5 mediante la configuración de db2set DB2_4K_DEVICE_SUPPORT=ON, como se documenta en:
Para las versiones anteriores de Db2, se debe usar un tamaño de sector de 512 bytes. Los discos SSD prémium son nativos de 4 KB y tienen una emulación de 512 bytes. El disco Ultra usa un tamaño de sector de 4 KB de forma predeterminada. Puede habilitar el tamaño del sector de 512 bytes durante la creación del disco Ultra. Los detalles están disponibles en Uso de los discos Ultra de Azure. Este tamaño de sector de 512 bytes es un requisito previo para las versiones de Db2 para LUW de IBM inferiores a 11.5.
En Windows, si se usan bloques de almacenamiento para las rutas de acceso de almacenamiento de Db2 para los directorios log_dir, sapdata y saptmp, se debe especificar un tamaño de sector de disco físico de 512 bytes. Si usa bloques de almacenamiento de Windows, debe crearlos manualmente en la interfaz de la línea de comandos con el parámetro -LogicalSectorSizeDefault. Para obtener más información, consulte New-StoragePool.
Recomendación sobre la estructura de disco y las máquinas virtuales para la implementación de IBM Db2
Las aplicaciones de IBM Db2 para SAP NetWeaver se admiten en cualquier tipo de máquina virtual que aparezca en la nota de soporte de SAP 1928533. Las familias de máquinas virtuales recomendadas para ejecutar la base de datos IBM Db2 son las series Esd_v4/Eas_v4/Es_v3 y M/M_v2 para grandes bases de datos de varios terabytes. El rendimiento de escritura en disco del registro de transacciones de IBM Db2 se puede mejorar si se habilita el Acelerador de escritura de la serie M.
A continuación, se facilita una configuración de línea de base para varios tamaños y usos de las implementaciones de SAP en DB2, que van de pequeña a grande. La lista se basa en Azure Premium Storage. Sin embargo, el disco Ultra de Azure también es totalmente compatible con DB2 y también se puede usar. Use los valores de capacidad, rendimiento de ráfaga e IOPS de ráfaga para definir la configuración del disco Ultra. Puede limitar la IOPS para /db2/<SID>/log_dir en torno a 5000 IOPS.
Sistema SAP extra pequeño: tamaño de la base de datos de 50 a 200 GB: ejemplo de administrador de soluciones
| Nombre/tamaño de la máquina virtual | Punto de montaje de Db2 | Disco Premium de Azure | N.º de discos | E/S | Rendimiento [MB/s] |
Tamaño [GB] | IOPS de ráfaga | Rendimiento en ráfaga [GB] |
Stripe size (Tamaño de las franjas) | Almacenamiento en memoria caché |
|---|---|---|---|---|---|---|---|---|---|---|
| E4ds_v4 | /db2 | P6 | 1 | 240 | 50 | 64 | 3500 | 170 | ||
| vCPU: 4 | /db2/<SID>/sapdata |
P10 | 2 | 1,000 | 200 | 256 | 7000 | 340 | 256 KB |
ReadOnly |
| RAM: 32 GiB | /db2/<SID>/saptmp |
P6 | 1 | 240 | 50 | 128 | 3500 | 170 | ||
/db2/<SID>/log_dir |
P6 | 2 | 480 | 100 | 128 | 7000 | 340 | 64 KB |
||
/db2/<SID>/offline_log_dir |
P10 | 1 | 500 | 100 | 128 | 3500 | 170 |
Sistema SAP pequeño: tamaño de la base de datos de 200 a 750 GB: Small Business Suite
| Nombre/tamaño de la máquina virtual | Punto de montaje de Db2 | Disco Premium de Azure | N.º de discos | E/S | Rendimiento [MB/s] |
Tamaño [GB] | IOPS de ráfaga | Rendimiento en ráfaga [GB] |
Stripe size (Tamaño de las franjas) | Almacenamiento en memoria caché |
|---|---|---|---|---|---|---|---|---|---|---|
| E16ds_v4 | /db2 | P6 | 1 | 240 | 50 | 64 | 3500 | 170 | ||
| vCPU: 16 | /db2/<SID>/sapdata |
P15 | 4 | 4400 | 500 | 1024 | 14 000 | 680 | 256 KB | ReadOnly |
| RAM: 128 GB | /db2/<SID>/saptmp |
P6 | 2 | 480 | 100 | 128 | 7000 | 340 | 128 KB | |
/db2/<SID>/log_dir |
P15 | 2 | 2200 | 250 | 512 | 7000 | 340 | 64 KB |
||
/db2/<SID>/offline_log_dir |
P10 | 1 | 500 | 100 | 128 | 3500 | 170 |
Sistema SAP medio: tamaño de base de datos de 500 a 1000 GB: Small Business Suite
| Nombre/tamaño de la máquina virtual | Punto de montaje de Db2 | Disco Premium de Azure | N.º de discos | E/S | Rendimiento [MB/s] |
Tamaño [GB] | IOPS de ráfaga | Rendimiento en ráfaga [GB] |
Stripe size (Tamaño de las franjas) | Almacenamiento en memoria caché |
|---|---|---|---|---|---|---|---|---|---|---|
| E32ds_v4 | /db2 | P6 | 1 | 240 | 50 | 64 | 3500 | 170 | ||
| vCPU: 32 | /db2/<SID>/sapdata |
P30 | 2 | 10 000 | 400 | 2048 | 10 000 | 400 | 256 KB | ReadOnly |
| RAM: 256 GiB | /db2/<SID>/saptmp |
P10 | 2 | 1,000 | 200 | 256 | 7000 | 340 | 128 KB | |
/db2/<SID>/log_dir |
P20 | 2 | 4600 | 300 | 1024 | 7000 | 340 | 64 KB |
||
/db2/<SID>/offline_log_dir |
P15 | 1 | 1 100 | 125 | 256 | 3500 | 170 |
Sistema SAP grande: tamaño de la base de datos de 750 a 2000 GB: Business Suite
| Nombre/tamaño de la máquina virtual | Punto de montaje de Db2 | Disco Premium de Azure | N.º de discos | E/S | Rendimiento [MB/s] |
Tamaño [GB] | IOPS de ráfaga | Rendimiento en ráfaga [GB] |
Stripe size (Tamaño de las franjas) | Almacenamiento en memoria caché |
|---|---|---|---|---|---|---|---|---|---|---|
| E64ds_v4 | /db2 | P6 | 1 | 240 | 50 | 64 | 3500 | 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 | 2200 | 250 | 512 | 7000 | 340 | 128 KB | |
/db2/<SID>/log_dir |
P20 | 4 | 9200 | 600 | 2048 | 14 000 | 680 | 64 KB |
||
/db2/<SID>/offline_log_dir |
P20 | 1 | 2,300 | 150 | 512 | 3500 | 170 |
Sistema SAP grande de varios terabytes: tamaño de base de datos de 2 TB o más: Sistema Global Business Suite
| Nombre/tamaño de la máquina virtual | Punto de montaje de Db2 | Disco Premium de Azure | N.º de discos | E/S | Rendimiento [MB/s] |
Tamaño [GB] | IOPS de ráfaga | Rendimiento en ráfaga [GB] |
Stripe size (Tamaño de las franjas) | Almacenamiento en memoria caché |
|---|---|---|---|---|---|---|---|---|---|---|
| M128s | /db2 | P10 | 1 | 500 | 100 | 128 | 3500 | 170 | ||
| vCPU: 128 | /db2/<SID>/sapdata |
P40 | 4 | 30,000 | 1000 | 8192 | 30,000 | 1000 | 256 KB | ReadOnly |
| RAM: 2048 GiB | /db2/<SID>/saptmp |
P20 | 2 | 4600 | 300 | 1024 | 7000 | 340 | 128 KB | |
/db2/<SID>/log_dir |
P30 | 4 | 20 000 | 800 | 4.096 | 20 000 | 800 | 64 KB |
Escritura Acelerador |
|
/db2/<SID>/offline_log_dir |
P30 | 1 | 5\.000 | 200 | 1024 | 5\.000 | 200 |
Uso de Azure NetApp Files
El uso de volúmenes NFS v4.1 basados en Azure NetApp Files (ANF) se admite con IBM Db2, hospedado en el sistema operativo invitado SUSE o Red Hat Linux. Debe crear al menos cuatro volúmenes diferentes como los siguientes:
- Un volumen compartido para saptmp1, sapmnt, usr_sap,
<sid>_home, db2<sid>_home, db2_software - Un volumen de datos para los directorios sapdata del 1 al 4
- Un volumen de registro para el directorio de registro de la fase de puesta al día
- Un volumen para los archivos de registro y las copias de seguridad
Un quinto volumen posible podría ser un volumen de ANF que se usa para copias de seguridad a más largo plazo usadas para crear instantáneas y almacenarlas en el almacén de blobs de Azure.
La configuración podría ser similar a la siguiente:
El nivel de rendimiento y el tamaño de los volúmenes hospedados en ANF deben elegirse en función de los requisitos de rendimiento. Pero se recomienda usar el nivel de rendimiento Ultra para los datos y el volumen de registro. No se admite la combinación de tipos de almacenamiento compartido y en bloque para los datos y el volumen de registro.
En cuanto a las opciones de montaje, el montaje de esos volúmenes podría parecerse al siguiente (debe reemplazar <SID> y <sid> por el SID de su 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
Las opciones de montaje "hard" y "sync" son necesarias.
Copia de seguridad y restauración
La funcionalidad de copia de seguridad y restauración para IBM Db2 para LUW es compatible del mismo modo que en los sistemas operativos Windows Server y Hyper-V estándares.
Asegúrese de seguir una estrategia establecida de copias de seguridad de bases de datos válida.
Como en las implementaciones sin sistema operativo, el rendimiento de las copias de seguridad y las restauraciones depende de cuántos volúmenes puedan leerse en paralelo y el rendimiento que estos volúmenes puedan tener. Además, el consumo de CPU que se emplea en la compresión de copias de seguridad podría desempeñar un papel importante en las máquinas virtuales con ocho subprocesos de CPU como máximo. Por lo tanto, se pueden asumir los siguientes puntos:
- Cuantos menos discos se utilicen para almacenar los dispositivos de las bases de datos, menor será el rendimiento general de lectura
- Cuantos menos subprocesos de CPU haya en la máquina virtual, mayor será el impacto en la compresión de copias de seguridad.
- Cuantos menos destinos (directorios de seccionamiento, discos) en los que escribir la copia de seguridad haya, menor será el rendimiento
Para aumentar la cantidad de destinos en los que escribir, existen dos opciones que se pueden usar o combinar según sus necesidades:
- Seccionamiento del volumen de destino de la copia de seguridad en varios discos para mejorar el rendimiento de IOPS en ese volumen seccionado
- Uso de más de un directorio de destino en el que escribir copias de seguridad
Nota:
Db2 en Windows no es compatible con la tecnología de Windows VSS. Como resultado, no se puede aprovechar la copia de seguridad de máquina virtual coherente con la aplicación del servicio Azure Backup para las máquinas virtuales en las que se implementa el DBMS de Db2.
Alta disponibilidad y recuperación ante desastres
Linux Pacemaker
Importante
Para la versión 11.5.6 u otras posteriores de Db2, se recomienda encarecidamente la solución integrada mediante Pacemaker de IBM.
- Solución integrada mediante Pacemaker
- Configuraciones alternativas o adicionales disponibles en Microsoft Azure Se admite la recuperación ante desastres de alta disponibilidad (HADR) de Db2 con Pacemaker. Se admiten los sistemas operativos SLES y RHEL. Esta configuración habilita la alta disponibilidad de IBM Db2 para SAP. Guías de implementación:
- SLES: Alta disponibilidad de IBM Db2 LUW en máquinas virtuales de Azure en SUSE Linux Enterprise Server con Pacemaker
- RHEL: Alta disponibilidad de IBM Db2 LUW en máquinas virtuales de Azure en Red Hat Enterprise Linux Server
Windows Cluster Server
Microsoft Cluster Server (MSCS) no es compatible.
La alta disponibilidad y la recuperación ante desastres (HADR) de Db2 sí son compatibles. Si las máquinas virtuales de la configuración de alta disponibilidad tienen una resolución de nombres correcta, la configuración de Azure no será diferente a cualquier otra realizada de forma local. No se recomienda depender exclusivamente de la resolución de direcciones IP.
No utilice la replicación geográfica para las cuentas de almacenamiento en las que se almacenan los discos de base de datos. Para obtener más información, consulte el documento Consideraciones para la implementación de DBMS de Azure Virtual Machines para la carga de trabajo de SAP.
Redes aceleradas
Para las implementaciones de Db2 en Windows, se recomienda usar la funcionalidad Redes aceleradas de Azure, como se describe en el documento sobre redes aceleradas de Azure. Tenga en cuenta también las recomendaciones realizadas en Consideraciones para la implementación de DBMS de Azure Virtual Machines para la carga de trabajo de SAP.
Características específicas para las implementaciones de Linux
Mientras la cuota actual de IOPS por disco sea suficiente, se pueden almacenar todos los archivos de base de datos en un solo disco. Mientras que siempre debe separar los archivos de datos y los de registro de transacciones en otros discos.
Si el IOPS o el rendimiento de E/S de un solo disco duro virtual de Azure no es suficiente, puede usar LVM (Administrador de discos lógicos) o mdadm, como se describe en el documento Consideraciones para la implementación de DBMS de Azure Virtual Machines para la carga de trabajo de SAP, para crear un dispositivo lógico de gran tamaño en varios discos.
Para los discos que contienen rutas de acceso de almacenamiento de Db2 para directorios sapdata y saptmp, debe especificar un tamaño de sector de disco físico de 512 kB.
Otros
Todas las demás áreas generales, como los conjuntos de disponibilidad de Azure o la supervisión de SAP, también se aplican a las implementaciones de máquinas virtuales con IBM Database. Se describen estas áreas generales en Consideraciones para la implementación de DBMS de Azure Virtual Machines para la carga de trabajo de SAP.
Pasos siguientes
Lea el artículo: