Editar

Compartir a través de

Implementación de SAP en Azure mediante una base de datos de Oracle Database

Azure ExpressRoute
SAP HANA en Azure (instancias grandes)
Azure Virtual Machines
Azure Virtual Network
Azure NetApp Files

En esta arquitectura de referencia, se muestra un conjunto de prácticas probadas para ejecutar una SAP NetWeaver de alta disponibilidad con Oracle Database en Azure. Los principios de arquitectura son independientes del sistema operativo, pero, a menos que se especifique lo contrario, se supone que se basa en Linux.

El primer diagrama muestra una arquitectura de referencia para SAP en Oracle en Azure. Se recomienda implementar en dos zonas de disponibilidad.

Diagrama de la arquitectura de un sistema de SAP de producción en Oracle en Azure.

Descargar un archivo Visio de esta arquitectura y otras relacionadas.

Nota

Para implementar esta arquitectura de referencia, necesita las licencias adecuadas de los productos de SAP y de otras tecnologías que no son de Microsoft.

Componentes

Esta arquitectura de referencia describe un sistema de producción de SAP típico que se ejecuta en Oracle Database en Azure en una implementación de alta disponibilidad para maximizar la disponibilidad del sistema. La arquitectura y sus componentes se pueden personalizar en función de los requisitos empresariales (objetivo de tiempo de recuperación (RTO), objetivo de punto de recuperación (RPO), expectativas de tiempo de actividad, rol del sistema) y se puede reducir potencialmente a una sola máquina virtual. El diseño de red se ha simplificado para mostrar los principios de arquitectura de un entorno de SAP de este tipo y no pretende describir una red empresarial completa.

Redes

Redes virtuales. El servicio Azure Virtual Network conecta los recursos de Azure entre sí con seguridad mejorada. En esta arquitectura, la red virtual se conecta al entorno local a través de una puerta de enlace de red privada virtual (VPN) implementada en el centro de una topología en estrella tipo hub-spoke. Las aplicaciones y la base de datos de SAP se encuentran en su propia red virtual de radio. Las redes virtuales se dividen en subredes independientes para cada capa: aplicación (SAP NetWeaver), base de datos y servicios compartidos (como Azure Bastion).

Esta arquitectura divide el espacio de direcciones de la red virtual en subredes. Coloque los servidores de aplicaciones en una subred independiente y los servidores de bases de datos en otra. Esto le permite protegerlos más fácilmente mediante la administración de las directivas de seguridad de subred en lugar de los servidores individuales y separa de forma clara las reglas de seguridad aplicables a bases de datos y servidores de aplicaciones.

Emparejamiento de redes virtuales. En esta arquitectura se usa una topología de red en estrella tipo hub-and-spoke con varias redes virtuales que están emparejadas. Esta topología ofrece la segmentación y el aislamiento de red para los servicios implementados en Azure. El emparejamiento permite la conectividad transparente entre redes virtuales emparejadas a través de la red troncal de Microsoft.

Puerta de enlace con redundancia de zona. Una puerta de enlace conecta redes distintas, y extiende la red local a la red virtual de Azure. Se recomienda usar ExpressRoute para crear conexiones privadas que no vayan a través de la red pública de Internet, pero también puede usar una conexión de sitio a sitio. Use instancias de Azure ExpressRoute o VPN Gateway con redundancia de zona para protegerse frente a errores de zona. Consulte Puertas de enlace de red virtual con redundancia de zona para comprender las diferencias entre una implementación zonal y una implementación con redundancia de zona. Merece la pena mencionar aquí que las direcciones IP utilizadas deben ser de la SKU Estándar para una implementación de zona de las puertas de enlace.

Grupos de seguridad de red. Para restringir el tráfico entrante, saliente y de la propia subred de la red virtual, cree grupos de seguridad de red (NSG) que, a su vez, se asignan a subredes específicas. Las subredes de base de datos y de aplicación están protegidas con grupos de seguridad de red específicos de la carga de trabajo.

Grupos de seguridad de aplicaciones. Para definir directivas de seguridad de red pormenorizadas en sus grupos de seguridad de red en función de las cargas de trabajo que se centran en aplicaciones, use grupos de seguridad de aplicación en lugar de direcciones IP explícitas. Permiten agrupar VM por nombre y le ayudan a proteger las aplicaciones mediante el filtrado del tráfico desde segmentos de confianza de la red.

Tarjetas de interfaz de red (NIC). Las tarjetas de interfaz de red permiten todas las comunicaciones entre las máquinas virtuales en una red virtual. En las implementaciones de SAP locales tradicionales, se implementan varias tarjetas de interfaz de red por máquina para aislar el tráfico administrativo del empresarial.

En Azure, la red virtual es una red definida por el software que envía todo el tráfico a través del mismo tejido de red. Por lo tanto, no es necesario usar varias NIC por motivos de rendimiento. Pero si su organización necesita separar el tráfico, puede implementar varias NIC por VM y conectar cada NIC a una subred diferente. A continuación, puede usar grupos de seguridad de red para aplicar las distintas directivas de control de acceso en cada subred.

Las NIC de Azure admiten varias direcciones IP. Esta compatibilidad se ajusta al procedimiento recomendado de SAP de usar nombres de host virtuales para las instalaciones. Para obtener un esquema completo, consulte la nota de SAP 962955. (Para acceder a las notas de SAP, necesita una cuenta de SAP Service Marketplace).

Máquinas virtuales

Esta arquitectura usa máquinas virtuales (VM). En el caso del nivel de aplicación de SAP, las máquinas virtuales se implementan para todos los roles de instancia: Web Dispatcher y servidores de aplicaciones, tanto los servicios centrales SAP (A)SCS como ERS, así como los servidores de aplicaciones (PAS, AAS). Ajuste el número de máquinas virtuales según sus requisitos. En la guía de planeación e implementación de Azure Virtual Machines se incluyen detalles sobre cómo ejecutar SAP NetWeaver en máquinas virtuales.

De forma similar, se usan máquinas virtuales para todos los propósitos de Oracle, tanto para Oracle Database como para las máquinas virtuales de observador de Oracle. Las máquinas virtuales de observador de esta arquitectura son más pequeñas en comparación con los servidores de bases de datos reales.

  • Máquinas virtuales de vCPU restringidas. Para ahorrar costos potencialmente en las licencias de Oracle, considere la posibilidad de usar máquinas virtuales con vCPU restringidas
  • Familias de máquinas virtuales certificadas para SAP. Para obtener más información sobre la compatibilidad de SAP con los tipos de máquina virtual y las métricas de rendimiento (SAPS) de Azure, vea la nota de SAP 1928533. (Para acceder a las notas de SAP, necesita una cuenta de SAP Service Marketplace).

Grupos con ubicación por proximidad (PPG). Cuando las máquinas virtuales se implementan en zonas de disponibilidad, la latencia dentro de la zona suele ser ideal para las aplicaciones de SAP. En raras situaciones en las que es necesario reducir la latencia entre la base de datos y las máquinas virtuales de aplicaciones, puede usar grupos de selección de ubicación de proximidad. En tales situaciones, los PPG garantizan la intercalación, lo que significa que las máquinas virtuales están en el mismo centro de datos para minimizar la latencia de la aplicación. Debido a posibles restricciones con ppG, la adición de AvSet de la base de datos al PPG del sistema SAP debe realizarse dispersamente y solo cuando sea necesario. Para más información sobre los escenarios de uso de los PPG, consulte la documentación vinculada.

Máquinas virtuales de generación 2 (Gen2). Azure ofrece la opción de indicar si deben ser de la generación 1 o 2. Las máquinas virtuales de generación 2 admiten características clave que no están disponibles para las máquinas virtuales de la generación 1. Esto es importante especialmente para bases de datos de Oracle muy grandes, ya que algunas familias de máquinas virtuales, como la Mv2 o la Mdsv2, se admiten solo como máquinas virtuales Gen2. Del mismo modo, la certificación de SAP en Azure para algunas máquinas virtuales más recientes podría requerir que solo sean Gen2 para obtener compatibilidad completa, incluso si Azure permite ambas en ellas. Para más información, consulte Nota de SAP 1928533: Aplicaciones de SAP en Microsoft Azure: tipos de máquina virtual de Azure y productos admitidos.

Dado que todas las demás VM que admiten SAP permiten elegir solo Gen2 o Gen1+2 de forma selectiva, se recomienda implementar todas las VM de SAP solo como Gen2, incluso si los requisitos de memoria son muy bajos. Incluso las máquinas virtuales más pequeñas que se implementan como Gen2 se pueden escalar verticalmente hasta las más grandes disponibles con una operación sencilla de desasignación y cambio de tamaño. Las VM de Gen1 solo se pueden cambiar de tamaño en las familias de VM que pueden ejecutar VM de Gen1.

Storage

Esta arquitectura usa discos administrados de Azure para las máquinas virtuales y Recursos compartidos de archivos de Azure o Azure NetApp Files (NFS) para cualquier requisito de almacenamiento compartido, como sapmnt y los volúmenes de NFS de transporte de SAP. Las directrices para la implementación del almacenamiento con SAP en Azure se detallan en la guía Tipos de Azure Storage para una carga de trabajo de SAP.

Alta disponibilidad

La arquitectura anterior muestra una implementación de alta disponibilidad, con cada capa de aplicación contenida en dos o más máquinas virtuales. Se usan los siguientes componentes.

En Azure, la implementación de cargas de trabajo de SAP puede ser regional o zonal, en función de los requisitos de disponibilidad y resistencia de las aplicaciones sap y de la región seleccionada. Azure proporciona diferentes opciones de implementación, como Virtual Machine Scale Sets con orquestación flexible (FD=1), zonas de disponibilidad y conjuntos de disponibilidad para aumentar la disponibilidad de los recursos. Para obtener una descripción completa de las opciones de implementación y su aplicabilidad en diferentes regiones de Azure (incluidas las distintas zonas, dentro de una sola zona o en una región sin zonas), consulte Escenarios y arquitectura de alta disponibilidad para SAP NetWeaver.

Equilibradores de carga. Azure Load Balancer se usa para distribuir el tráfico a las máquinas virtuales en las subredes de SAP. Al incorporar Azure Load Balancer en una implementación zonal de SAP, asegúrese de seleccionar el equilibrador de carga de la SKU estándar. El equilibrador de la SKU básica no admite redundancia zonal.

Tenga en cuenta los factores de decisión al implementar máquinas virtuales entre zonas de disponibilidad para SAP. El uso de grupos con ubicación por proximidad con una implementación de zona de disponibilidad se debe evaluar y usar solo para las máquinas virtuales de la capa de aplicación.

Nota:

Las zonas de disponibilidad admiten la alta disponibilidad dentro de la región, pero no son eficaces para la recuperación ante desastres (DR). Las distancias entre zonas son demasiado cortas. Las regiones de recuperación ante desastres típicas deben tener al menos 100 kilómetros de distancia de la región principal.

Componentes específicos de Oracle. Las máquinas virtuales de Oracle Database se implementan en un conjunto de disponibilidad o en distintas zonas de disponibilidad. Cada máquina virtual contiene su propia instalación del software de base de datos y el almacenamiento de base de datos local de la máquina virtual. Configure la replicación de base de datos sincrónica mediante Oracle Data Guard entre las bases de datos para garantizar la coherencia y permitir tiempos de servicio de RPO y RTO bajos en caso de errores individuales. Además de las máquinas virtuales de base de datos, se necesitan máquinas virtuales adicionales con el observador de Oracle Data Guard para una configuración de conmutación por error de inicio rápido de Oracle Data Guard. Las máquinas virtuales de observador de Oracle supervisan la base de datos y el estado de replicación y facilitan la conmutación por error de la base de datos de forma automatizada, sin necesidad de ningún administrador del clúster. La administración de la replicación de bases de datos se puede realizar después mediante Oracle Data Guard Broker por facilidad de uso.

Para obtener más información sobre la implementación de Oracle Data Guard, consulte la Documentación de Oracle Data Guard en Azure.

Esta arquitectura utiliza herramientas nativas de Oracle sin ningún software de clúster real o la necesidad de un equilibrador de carga en el nivel de base de datos. Con la conmutación por error de inicio rápido de Oracle Data Guard y la configuración de SAP, se automatiza el proceso de conmutación por error y las aplicaciones de SAP se conectan de nuevo a la nueva base de datos principal en caso de que se produzca una conmutación por error. Existen varias soluciones de clúster de terceros como alternativa, como SIOS Protection Suite o Veritas InfoScale, cuyos detalles de implementación se puede encontrar en la documentación del proveedor de terceros correspondiente, respectivamente.

Oracle RAC. Oracle Real Application Cluster (RAC) actualmente no está certificado ni es compatible con Oracle en Azure. Sin embargo, las tecnologías de Oracle Data Guard y la arquitectura para alta disponibilidad pueden proporcionar entornos de SAP altamente resistentes con protección contra interrupciones del servicio en bastidores, centros de datos o regiones.

Nivel NFS. Para todas las implementaciones de SAP de alta disponibilidad, es necesario usar un nivel de NFS resistente que proporcione volúmenes NFS para el directorio de transporte de SAP, el volumen sapmnt para los archivos binarios de SAP, así como volúmenes adicionales para las instancias de (A)SCS y ERS. Las opciones para proporcionar una capa de NFS son:

  • Azure Files NFS con almacenamiento con redundancia de zona (ZRS): guías para SLES y RHEL
  • Azure NetApp Files implementación de volúmenes NFS: guías para SLES y RHEL
  • Clúster de NFS basado en máquinas virtuales: dos máquinas virtuales adicionales con almacenamiento local, replicadas entre máquinas virtuales con DRBD (dispositivo de bloque replicado distribuido): guías para SLES y RHEL

Clúster de servicios centrales de SAP. Esta arquitectura de referencia ejecuta los servicios centrales en máquinas virtuales discretas. Central Services es un posible único punto de error (SPOF) cuando se implementa en una única VM. Para implementar una solución de alta disponibilidad, se necesita software de administración de clústeres que automatice la conmutación por error de las instancias de (A)SCS y ERS en la máquina virtual correspondiente. Como esto está fuertemente relacionado con la solución de NFS elegida

La solución de clúster elegida requiere un mecanismo para decidir en caso de falta de disponibilidad del software o la infraestructura qué máquina virtual debe atender a los servicios respectivos. Con SAP en Azure, hay dos opciones disponibles para la implementación basada en Linux de STONITH: cómo tratar una máquina virtual o una aplicación que no responde

  • Solo SUSE-Linux SBD (dispositivo de bloque STONITH): utiliza una o tres máquinas virtuales adicionales que sirven como exportaciones iSCSI de un dispositivo de bloque pequeño, al que acceden regularmente las máquinas virtuales miembros del clúster reales, dos máquinas virtuales (A)SCS/ERS en este grupo de clústeres. Las máquinas virtuales usan estos montajes SBD para convertir votos y, por tanto, lograr un cuórum para las decisiones del clúster. La arquitectura contenida en esta página NO contiene 1 o 3 máquinas virtuales de SBD adicionales.
  • Agente de barrera de Azure. Sin usar máquinas virtuales adicionales, se usa la API de administración de Azure para las comprobaciones periódicas de disponibilidad de las máquinas virtuales.

Las guías vinculadas dentro de la sección de la capa de NFS contienen los pasos y el diseño necesarios para la elección del clúster correspondiente. También se pueden usar administradores de clústeres certificados de Azure de terceros para proporcionar alta disponibilidad de los servicios centrales de SAP.

El grupo de servidores de aplicaciones SAP. Dos o más servidores de aplicaciones en los que la alta disponibilidad se logra mediante el equilibrio de carga de las solicitudes con el servidor de mensajes de SAP o los distribuidores web. Cada servidor de aplicaciones es independiente y no se requiere equilibrio de carga de red para este grupo de máquinas virtuales.

Grupo de distribuidores web de SAP. El componente Web Dispatcher se usa como equilibrador de carga para el tráfico SAP que circula entre los servidores de aplicaciones de SAP. Para lograr una alta disponibilidad de SAP Web Dispatcher, Azure Load Balancer implementa el clúster de conmutación por error o la configuración de Web Dispatcher en paralelo.

Web Dispatcher insertado en (A)SCS es una opción especial. Debe tener en cuenta el dimensionamiento adecuado debido a la carga de trabajo adicional en (A)SCS.

Para las comunicaciones orientadas a Internet, se recomienda una solución independiente en la red perimetral (también conocida como DMZ) para abordar los problemas de seguridad.

Implementaciones de Windows. Este documento, como se ha mencionado al principio, se centra principalmente en las implementaciones basadas en Linux. Para el uso con Windows, se aplican los mismos principios arquitectónicos y no hay diferencias de arquitectura con Oracle entre Linux y Windows.

Para la parte de la aplicación de SAP, consulte los detalles en la guía de arquitectura Ejecución de SAP NetWeaver en Windows en Azure.

Consideraciones

Recuperación ante desastres

En el diagrama siguiente se muestra la arquitectura de un sistema SAP de producción en Oracle en Azure. La arquitectura proporciona la recuperación ante desastres y usa zonas de disponibilidad.

Diagrama que muestra la arquitectura de un sistema SAP de producción en Oracle en Azure.

Descargar un archivo Visio de esta arquitectura y otras relacionadas.

Cada capa arquitectónica de la pila de aplicaciones de SAP usa un enfoque diferente para proporcionar protección de recuperación ante desastres. Para conocer las estrategias de recuperación ante desastres y los detalles de implementación, consulte Introducción a la recuperación ante desastres e instrucciones de infraestructura para la carga de trabajo de SAP y Directrices de recuperación ante desastres para la aplicación SAP.

Backup

La copia de seguridad de Oracle en Azure se puede lograr mediante varios medios:

  • Azure Backup. Los scripts proporcionados y mantenidos por Azure for Oracle Database y Azure Backup para Oracle abordan los requisitos de copia de seguridad.
  • Azure Storage. Aproveche las ventajas de las copias de seguridad de bases de datos basadas en archivos, por ejemplo las programadas con las herramientas de BR de SAP, para su almacenamiento y creación de versiones como archivos o directorios en servicios de almacenamiento de Azure Blob NFS, Azure Blob o Azure Files. Consulte los detalles documentados sobre cómo lograr las copias de seguridad de datos y registros de Oracle.
  • Soluciones de copia de seguridad de terceros. Consulte la arquitectura del proveedor de almacenamiento de copia de seguridad compatible con Oracle en Azure.

En el caso de las máquinas virtuales que no son de base de datos, se recomienda Azure Backup para máquina virtual para proteger las máquinas virtuales de aplicaciones de SAP y la infraestructura auxiliar, como SAP Web Dispatcher.

Colaboradores

Microsoft mantiene este artículo. Originalmente lo escribieron los siguientes colaboradores.

Autor principal:

Pasos siguientes

Comunidades

Las comunidades pueden responder preguntas y ayudarle a configurar una implementación correcta. Tenga en cuenta estos recursos:

Consulte el artículo siguiente para obtener más información y ejemplos de cargas de trabajo de SAP que usan algunas de las mismas tecnologías: