Consideraciones para la implementación de DBMS de Azure Virtual Machines para la carga de trabajo de SAP

  • Artículo

Esta guía forma parte de la documentación sobre la implementación del software de SAP en Microsoft Azure. Antes de leer esta guía, lea la Guía de planeamiento e implementación y los artículos a los que hace referencia la guía de planeamiento. En este documento se describen los aspectos de implementación genéricos de los sistemas DBMS relacionados con SAP en Microsoft Azure Virtual Machines (VM) mediante las funcionalidades de infraestructura como servicio (IaaS) de Azure.

El documento complementa la documentación de instalación de SAP y las Notas de SAP, que representan los principales recursos para las instalaciones e implementaciones de software de SAP en las plataformas proporcionadas.

En este documento, se presentan las consideraciones sobre la ejecución de sistemas DBMS relacionados con SAP en máquinas virtuales de Azure. Hay pocas referencias a sistemas DBMS específicos en el documento. Los sistemas DBMS específicos se tratan en otros documentos específicos del sistema de base de datos.

Recursos

Hay otros artículos disponibles sobre la carga de trabajo SAP en Azure. Comience con Carga de trabajo SAP en Azure: Introducción y, a continuación, elija el área 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 (Nota de SAP 1928533: Aplicaciones SAP en Azure: productos admitidos y tipos de máquina virtual de Azure)
2015553 SAP on Microsoft Azure: Support Prerequisites (Nota de soporte técnico 2015553 de SAP en Microsoft Azure: requisitos previos de soporte técnico)
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 (SAP en Linux con Azure: supervisión mejorada)
2191498 SAP on Linux with Azure: Enhanced Monitoring (SAP en Linux con Azure: supervisión mejorada)
2039619 SAP Applications on Microsoft Azure using the Oracle Database: Supported products and versions (Aplicaciones de SAP en Microsoft Azure con Base de datos de Oracle: versiones y productos compatibles)
2233094 DB6: aplicaciones 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)
2578899 SUSE Linux Enterprise Server 15: nota de instalación
1984787 SUSE LINUX Enterprise Server 12: Notas de instalación
2772999 Red Hat Enterprise Linux 8.x: instalación y configuración
2002167 Red Hat Enterprise Linux 7.x: Instalación y actualización
2069760 Instalación y actualización de SAP en Oracle Linux 7.x
1597355 Recomendación de espacio de intercambio para Linux
2799900 Nota técnica central para Oracle Database 19c
2171857 Oracle Database 12c: compatibilidad con sistema de archivos en Linux
1114181 Oracle Database 11g: compatibilidad con sistema de archivos en Linux
2969063 Error de validación de microcódigo en HCMT en Azure
3246210 Azure: error de HCMT durante algunas pruebas de rendimiento de disco

Para información sobre todas las notas de SAP para Linux, consulte la wiki de la comunidad SAP.

Debe tener conocimientos prácticos sobre la arquitectura de Microsoft Azure y cómo se implementan y usan las máquinas virtuales de Microsoft Azure. Para más información, consulte la documentación de Azure.

En general, el proceso de instalación y configuración de DBMS, Windows y Linux es prácticamente el mismo en cualquier máquina virtual o máquina sin sistema operativo que se instala en un entorno local. Hay algunas decisiones de implementación de administración de sistemas y arquitecturas que difieren cuando se usa IaaS de Azure. En este documento se explican las diferencias de administración del sistema y arquitectura específicas que se deben tener en cuenta cuando se usa IaaS de Azure.

Estructura de almacenamiento de una máquina virtual para las implementaciones de RDBMS

Para seguir este capítulo, lea y comprenda la información presentada en:

Para el almacenamiento en bloques de Azure, es obligatorio el uso de discos administrados de Azure. Para obtener más información sobre los discos administrados de Azure, lea el artículo Introducción a los discos administrados para VM de Azure.

En una configuración básica, normalmente se recomienda una estructura de implementación en la que el sistema operativo, el DBMS y los archivos binarios finales de SAP sean independientes de los archivos de base de datos. Se recomienda tener discos de Azure independientes para:

  • El sistema operativo (VHD base o VHD del SO)
  • Ejecutables del sistema de administración de bases de datos
  • Ejecutables de SAP, como /usr/sap
  • Archivos de datos de DBMS
  • Archivos de registro de puesta al día de DBMS

Una configuración que separe estos componentes en cinco volúmenes diferentes puede proporcionar una mayor resistencia, ya que el uso excesivo de un volumen no interfiere necesariamente con el uso de otros volúmenes, siempre y cuando no se superen los límites y la cuota de almacenamiento de la máquina virtual.

Los datos de DBMS y los archivos de registro de transacciones y de fase de puesta al día se almacenan en el almacenamiento en bloque admitido de Azure o Azure NetApp Files. Azure Files o Azure Premium Files no se admiten como almacenamiento para datos o archivos de registro de puesta al día de DBSM con una carga de trabajo de SAP. Se almacenan en discos distintos y se asocian como discos lógicos a la máquina virtual de la imagen del sistema operativo de Azure original. Para las implementaciones de Linux, hay documentadas diferentes recomendaciones. Lea el artículo Tipos de Azure Storage para una carga de trabajo de SAP para conocer las funcionalidades y la compatibilidad de los distintos tipos de almacenamiento para su escenario. En concreto, para SAP HANA, comience con el artículo Configuraciones de almacenamiento de máquinas virtuales de Azure en SAP HANA.

Al planear el diseño del disco, encuentre el mejor equilibrio entre estos elementos:

  • El número de archivos de datos
  • El número de discos que contienen los archivos.
  • Las cuotas de IOPS de un solo disco o recurso compartido NFS.
  • El rendimiento de datos por disco o recurso compartido NFS.
  • El número de discos de datos adicionales posibles por tamaño de máquina virtual.
  • El rendimiento general de almacenamiento o de red que puede proporcionar una VM.
  • La latencia que pueden proporcionar los diferentes tipos de Azure Storage.
  • IOPS de almacenamiento y cuota de procesamiento de las máquinas virtuales.
  • Cuota de red de las máquinas virtuales si utiliza NFS. El tráfico a los recursos compartidos NFS cuenta para la cuota de red de las máquinas virtuales y NO para la cuota de almacenamiento.
  • SLA de máquina virtual.

Azure impone una cuota de IOPS por disco de datos o recurso compartido NFS. Estas cuotas son diferentes para los discos hospedados en las distintas soluciones o recursos compartidos de almacenamiento en bloque de Azure. La latencia de E/S también es diferente entre estos distintos tipos de almacenamiento.

Cada uno de los distintos tipos de máquina virtual tiene un número limitado de discos de datos que se pueden asociar. Otra restricción es que solo determinados tipos de máquinas virtuales pueden usar, por ejemplo, almacenamiento premium. Normalmente, la decisión de usar un determinado tipo de máquina virtual se basa en los requisitos de CPU y memoria. También debe considerar los requisitos de IOPS, latencia y procesamiento de disco, que normalmente se escalan con el número de discos o el tipo de discos de Premium Storage v1. El número de IOPS y el procesamiento que se debe conseguir por cada disco podrían determinar el tamaño del disco, especialmente con Premium Storage v1. Con los discos de Premium Storage v2 o Ultra, puede seleccionar el volumen de IOPS y procesamiento aprovisionado con independencia de la capacidad del disco.

Nota

Para las implementaciones de DBMS, se recomienda encarecidamente usar Azure Premium Storage (v1 y v2), discos Ultra o recursos compartidos NFS basados en Azure NetApp Files para cualquier tipo de datos, registro de transacciones o archivos de puesta al día. No importa si se quieren implementar sistemas de producción o que no sean de producción. La latencia de los discos HDD o SSD estándar de Azure no es aceptable para ningún tipo de sistema de producción.

Nota

Para maximizar el acuerdo de nivel de servicio de máquina virtual única de Azure, todos los discos que se conecten deben ser de Azure Premium Storage (v1 o v2) o de Azure Ultra Disks, que incluyen el disco VHD base (Azure Premium Storage).

Nota

No se permite hospedar archivos de bases de datos principales (archivos de datos y de registro) de bases de datos SAP en hardware de almacenamiento ubicado en centros de datos de terceros colocados y subyacentes a centros de datos de Azure. El almacenamiento proporcionado a través de los dispositivos de software hospedados en VM de Azure tampoco se admite en este caso de uso. Para cargas de trabajo DBMS de SAP, solo se admite el almacenamiento representado como un servicio nativo de Azure para los archivos de datos y de registro de transacciones de bases de datos SAP en general. Los distintos DBMS podrían admitir distintos tipos de almacenamiento de Azure. Para obtener más detalles, consulte el artículo Tipos de Azure Storage para una carga de trabajo de SAP.

La colocación de los archivos de base de datos y los archivos de registro y fase de puesta al día, y el tipo de almacenamiento de Azure que se use, se debe definir en función de los requisitos de IOPS, latencia y rendimiento. En concreto, para que Azure Premium Storage v1 consiga IOPS suficientes, es posible que tenga que usar varios discos o un disco de Premium Storage de mayor tamaño. Si usa varios discos, cree una sección de software en todos los discos que contenga los archivos de datos o los archivos de registro y fase de puesta al día. En esos casos, los contratos de nivel de servicio de IOPS y rendimiento de los discos de almacenamiento premium subyacentes o la cantidad máxima de IOPS que se puede alcanzar de los discos de almacenamiento estándar son acumulativos para el espacio seccionado resultante.

Si el requisito de IOPS es superior a lo que puede proporcionar un solo disco VHD, equilibre el número de operaciones IOPS necesarias para los archivos de la base de datos entre varios discos VHD. La forma más sencilla de distribuir la carga de IOPS entre los discos consiste en crear una sección de software por los diferentes discos. Después, coloque una serie de archivos de datos del DBMS de SAP en los LUN extraídos de la sección de software. El número de discos de la sección está controlado por las demandas de IOPS, rendimiento y volumen.

Windows storage striping Windows

Se recomienda usar espacios de almacenamiento de Windows para crear conjuntos seccionados entre varios discos duros virtuales de Azure. Use al menos Windows Server 2012 R2 o Windows Server 2016.

Linux storage striping Linux

Para crear un software RAID en Linux, solo se admiten MDADM y LVM (Logical Volume Manager). Para más información, consulte:

En el caso de Azure Premium Storage v2 y Azure Ultra Disks, no es necesaria esta división, ya que puede definir el volumen de IOPS y el procesamiento de disco con independencia del tamaño del disco.

Nota

Dado que Azure Storage mantiene tres imágenes de los discos duros virtuales, no tiene sentido configurar una redundancia al seccionar. Solo tiene que configurar el seccionamiento para que las operaciones de E/S se distribuyan entre los diferentes discos duros virtuales.

Discos administrados o no administrados

Las cuentas de Azure Storage son una construcción administrativa y también están sujetas a limitaciones. Para información sobre las funcionalidades y limitaciones, consulte Objetivos de escalabilidad y rendimiento de Azure Storage. Con el almacenamiento estándar, recuerde que hay un límite en el número de IOPS por cuenta de almacenamiento. Consulte la fila que contiene Tasa de solicitud total del artículo Objetivos de escalabilidad y rendimiento de Azure Storage. Además, hay un límite inicial en el número de cuentas de almacenamiento por suscripción de Azure. En 2017 Azure introdujo el concepto de Azure Managed Disks, que liberan a los usuarios de cualquier tarea de administración de las cuentas de almacenamiento. El uso de discos administrados de Azure es el valor predeterminado para la implementación de cargas de trabajo de SAP en Azure.

Importante

Dadas las ventajas que ofrece Azure Managed Disks, se recomienda usar Azure Managed Disks para las implementaciones de DBMS y de SAP en general.

Si tiene una carga de trabajo de SAP que aún no usa discos administrados, para pasar de discos no administrados a discos administrados, consulte:

Almacenamiento en caché de máquinas virtuales y discos de datos

Al montar discos en máquinas virtuales, se puede elegir almacenar en caché el tráfico de E/S entre la máquina virtual y esos discos ubicados en Azure Storage.

En las recomendaciones siguientes se da por hecho estas características de E/S para DBMS estándar:

  • Es principalmente una carga de trabajo de lectura en los archivos de datos de una base de datos. Estas operaciones de lectura son críticas para el rendimiento del sistema DBMS.
  • La escritura en los archivos de datos se produce en ráfagas en función de puntos de comprobación o un flujo constante. Se promedia durante un día, hay menos escrituras que lecturas. Al contrario que las operaciones de lectura de archivos de datos, estas operaciones de escritura son asincrónicas y no bloquean transacciones de usuario.
  • Apenas hay lecturas del registro de transacciones o de los archivos de fase de puesta al día. Las excepciones son las operaciones de E/S de gran tamaño al realizar copias de seguridad del registro de transacciones.
  • La carga principal en los archivos de registro de transacciones o de fase de puesta al día es una operación de escritura. Según la naturaleza de la carga de trabajo, puede tener operaciones de E/S de solo 4 KB o llegar a superar 1 MB.
  • Todas las operaciones de escritura se deben conservar en el disco de forma confiable.

Para Azure Premium Storage v1, existen las siguientes opciones de almacenamiento en caché:

  • None
  • Lectura
  • Lectura/escritura
  • Ninguno + Acelerador de escritura, que es solo para máquinas virtuales de la serie M de Azure
  • Lectura + Acelerador de escritura, que es solo para máquinas virtuales de la serie M de Azure

Para Premium Storage v1, se recomienda usar el almacenamiento en caché de lectura para archivos de datos de la base de datos de SAP y elegir la opción Sin almacenamiento en caché para los discos de archivos de registro.

Para las implementaciones de la serie M, se recomienda usar el Acelerador de escritura de Azure solo para los discos de archivos de registro. Para más información, incluidas las restricciones y la implementación del Acelerador de escritura de Azure, consulte Habilitar el acelerador de escritura.

Para Premium Storage v2, Ultra Disks y Azure NetApp Files, no se ofrecen opciones de almacenamiento en caché.

Discos de Azure no persistentes

Las máquinas virtuales de Azure ofrecen discos no persistentes después de implementar una máquina virtual. Si se reinicia una máquina virtual, se borra todo el contenido de esas unidades. Es evidente que los archivos de datos y los archivos de registro y puesta al día de las bases de datos no deben colocarse bajo ninguna circunstancia en esas unidades de disco no persistentes. Es posible que haya excepciones para algunas de las bases de datos, donde estas unidades de disco no persistentes podrían ser adecuadas para espacios de tablas tempdb y temp.

Para más información, consulte Understand the temporary drive on Windows VMs in Azure (Comprender la unidad temporal en máquinas virtuales Windows en Azure).

Windows nonpersisted disk Windows

La unidad D:\ de una máquina virtual de Azure es una unidad no persistente respaldada por algunos discos locales del nodo de ejecución de Azure. Como es persistente, todos los cambios realizados en el contenido de la unidad D se pierden cuando se reinicia la máquina virtual. Los cambios incluyen archivos que se almacenaron, directorios que se crearon y aplicaciones que se instalaron.

Linuxnonpersisted disk Linux

Las máquinas virtuales Linux de Azure montan automáticamente una unidad en /mnt/resource, que es una unidad no persistente respaldada por discos locales del nodo de ejecución de Azure. Como no es persistente, los cambios realizados en el contenido en /mnt/resource se pierden cuando se reinicia la máquina virtual. Los cambios incluyen archivos que se almacenaron, directorios que se crearon y aplicaciones que se instalaron.

Resistencia de Microsoft Azure Storage

Microsoft Azure Storage almacena el disco duro virtual base (con SO) y blobs o los discos asociados en, al menos, tres nodos de almacenamiento independientes. Este tipo de almacenamiento se denomina almacenamiento con redundancia local (LRS). LRS es el valor predeterminado para todos los tipos de almacenamiento en Azure.

Hay otros métodos de redundancia. Para más información, consulte Replicación de Azure Storage.

Nota

Azure Premium Storage v1 y v2, Ultra Disks y Azure NetApp Files son los tipos de almacenamiento recomendados para máquinas virtuales de DBMS y discos en los que se almacenan archivos de base de datos, de registro o de puesta al día. A excepción de Premium Storage v1, el único método de redundancia disponible para estos tipos de almacenamiento es LRS. Como resultado, debe configurar métodos de base de datos para habilitar la replicación de datos de base de datos en otra zona de disponibilidad o región de Azure. Los métodos de base de datos incluyen SQL Server Always On, Oracle Data Guard y replicación del sistema HANA.

Resistencia de nodos de máquina virtual

Azure ofrece varios contratos de nivel de servicio distintos para las máquinas virtuales. Para más información, consulte la versión más reciente de Contrato de nivel de servicio para Máquinas virtuales. Dado que la capa de DBMS es fundamental para la disponibilidad en un sistema SAP, debe comprender los distintos tipos de implementación y eventos de mantenimiento. Para más información sobre estos conceptos, consulte Administración de la disponibilidad de máquinas virtuales en Azure.

La recomendación mínima para escenarios DBMS de producción con una carga de trabajo SAP es:

  • Implemente dos máquinas virtuales con el tipo de implementación elegido en la misma región de Azure.
  • Ejecute estas dos máquinas virtuales en la misma red virtual de Azure y cuente con NIC asociadas fuera de las mismas subredes.
  • Use los métodos de la base de datos para mantener una espera activa con la segunda máquina virtual. Los métodos pueden ser SQL Server Always On, Oracle Data Guard o Replicación del sistema de HANA.

También puede implementar una tercera máquina virtual en otra región de Azure y usar los mismos métodos de base de datos para proporcionar una réplica asincrónica en otra región de Azure.

Consideraciones sobre la red de Azure

En las implementaciones de SAP a gran escala, use el proyecto de Azure Virtual Datacenter. Utilícelo para la configuración de la red virtual y las asignaciones de roles y permisos a diferentes partes de su organización.

Estos procedimientos recomendados son el resultado de miles de implementaciones de clientes:

  • Las redes virtuales en las que se implementa la aplicación de SAP no tienen acceso a Internet.
  • Las VM de base de datos se ejecutan en la misma red virtual que el nivel de aplicación, separadas en una subred diferente de la capa de aplicación de SAP.
  • Las máquinas virtuales dentro de la red virtual tienen una asignación estática de la dirección IP privada. Para más información, consulte Tipos de direcciones IP y métodos de asignación en Azure.
  • Con los firewalls instalados en las máquinas virtuales de DBMS locales, no se establecen restricciones de enrutamiento hacia y desde las máquinas virtuales de DBMS. En su lugar, el enrutamiento del tráfico se define mediante grupos de seguridad de red (NSG).
  • Para separar y aislar el tráfico a la máquina virtual de DBMS, asigne diferentes NIC a la máquina virtual. Cada NIC recibe una dirección IP diferente y cada NIC se asigna a una subred de red virtual diferente. Cada subred tiene diferentes reglas de NSG. El aislamiento o la separación del tráfico de red es una medida para el enrutamiento. No se usa para establecer cuotas para el rendimiento de la red.

Nota

Asignar direcciones IP estáticas mediante Azure significa asignarlas NIC virtuales individuales. No asigne direcciones IP estáticas dentro del sistema operativo invitado a una NIC virtual. Algunos servicios de Azure como Azure Backup se basan en el hecho de que al menos la NIC virtual principal del sistema operativo invitado está establecida en DHCP y no en direcciones IP estáticas. Para más información, consulte Solución de problemas de copia de seguridad de máquinas virtuales de Azure. Para asignar varias direcciones IP estáticas a una máquina virtual, asigne varias NIC virtuales a una máquina virtual.

Advertencia

No se admite la configuración de aplicaciones virtuales de red en la ruta de comunicación entre la aplicación de SAP y la capa de DBMS de un sistema SAP basado en SAP NetWeaver, Hybris o S/4HANA. Esta restricción es por motivos de rendimiento y funcionalidad. La comunicación entre la capa de la aplicación de SAP y la capa de DBMS debe ser directa. La restricción no incluye las reglas del grupo de seguridad de aplicaciones (ASG) y las reglas NSG si estas permiten una ruta de acceso de comunicación directa. Esto también incluye el tráfico hacia recursos compartidos NFS que hospedan datos de DBMS y archivos de registro de puesta al día.

Otros escenarios donde no se admiten aplicaciones virtuales de red se encuentran en:

Las aplicaciones virtuales de red de las rutas de comunicación pueden duplicar fácilmente la latencia de red entre dos asociados de comunicación. También pueden restringir el rendimiento en las rutas críticas entre la capa de aplicación de SAP y la capa de DBMS. En algunos escenarios de clientes, las aplicaciones virtuales de red pueden provocar un error en los clústeres de Linux Pacemaker. Hay casos donde las comunicaciones entre los nodos del clúster de Linux Pacemaker se comunican con su dispositivo SBD mediante una aplicación virtual de red.

Importante

Otro diseño que no se admite es la segregación de la capa de la aplicación de SAP ni la capa de DBMS en diferentes redes virtuales de Azure que no están emparejadas entre sí. Se recomienda separar la capa de aplicación de SAP y la capa de DBMS mediante subredes dentro de una red virtual de Azure, en lugar de usar diferentes redes virtuales de Azure.

Si decide no seguir la recomendación y separa las dos capas en redes virtuales diferentes, las dos redes virtuales deben estar emparejadas.

Tenga en cuenta que el tráfico entre dos redes virtuales de Azure emparejadas está sujeto a costos de transferencia. Un enorme volumen de datos que consta de muchos terabytes se intercambia entre la capa de aplicación de SAP y la capa de DBMS. Puede acumular costos sustanciales si la capa de aplicación de SAP y la capa de DBMS se separan entre dos redes virtuales de Azure emparejadas.

Uso de Azure Load Balancer para redirigir el tráfico

El uso de direcciones IP virtuales privadas en funcionalidades como SQL Server Always On o Replicación de sistema de HANA requiere la configuración de una instancia de Azure Load Balancer. El equilibrador de carga usa puertos de sondeo para determinar el nodo de DBMS activo y enrutar el tráfico exclusivamente a ese nodo de base de datos activo.

Si hay una conmutación por error del nodo de base de datos, no hay necesidad de volver a configurar la aplicación de SAP. En su lugar, las arquitecturas de aplicaciones de SAP más comunes se vuelven a conectar con la dirección IP virtual privada. Mientras tanto, el equilibrador de carga reacciona a la conmutación por error del nodo mediante la redirección del tráfico con la dirección IP virtual privada al segundo nodo.

Azure ofrece dos SKU de equilibrador de carga diferentes: una SKU básica y una SKU estándar. En función de las ventajas de la instalación y la funcionalidad, debe usar la SKU estándar del Azure Load Balancer. Una de las grandes ventajas de la versión Standard de Load Balancer es que el tráfico de datos no se redirige a través del propio equilibrador de carga.

Puede encontrar un ejemplo de cómo configurar un equilibrador de carga interno en el artículo Tutorial: Configuración de un grupo de disponibilidad de SQL Server Always On en Azure Virtual Machines de forma manual.

Nota

Hay diferencias en el comportamiento de la SKU básica y estándar relacionadas con el acceso de las direcciones IP públicas. Una solución alternativa a las restricciones de la SKU estándar para acceder a las direcciones IP públicas se describe en el artículo Conectividad del punto de conexión público para las máquinas virtuales que usan Azure Standard Load Balancer en escenarios de alta disponibilidad de SAP.

Implementación de la supervisión del host

Para el uso en producción de aplicaciones de SAP en máquinas virtuales de Azure, SAP necesita que se puedan obtener datos de supervisión de los hosts físicos que se ejecutan en dichas máquinas. Se requiere un nivel de revisión específico del agente de host de SAP que permita esta funcionalidad en SAPOSCOL y el agente de host de SAP. El nivel de revisión exacto se menciona en la nota de SAP 1409604.

Para obtener más información sobre la implementación de componentes que proporcionen datos de host a SAPOSCOL y a SAP Host Agent, y sobre la administración del ciclo de vida de esos componentes, consulte el artículo Implementación de la extensión de máquina virtual de Azure para soluciones de SAP.

Pasos siguientes

Para más información sobre un DBMS concreto, consulte: