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

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

Esta arquitectura de referencia describe prácticas probadas para ejecutar SAP NetWeaver con Oracle Database en Azure en una configuración de alta disponibilidad (HA). Los principios de arquitectura de alto nivel se aplican a los sistemas operativos compatibles. A menos que se especifique lo contrario, suponga que esta arquitectura usa Linux.

Note

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.

Architecture

En el diagrama siguiente se 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 SAP de producción en Oracle en Azure.

Descargar un archivo Visio de esta arquitectura y arquitecturas relacionadas.

Workflow

El siguiente flujo de trabajo corresponde al diagrama anterior:

  1. Los usuarios y los sistemas empresariales se conectan desde redes locales o redes de Azure emparejadas, a través de la red central, a la red virtual spoke de SAP.

  2. SAP Web Dispatcher y los servidores de aplicaciones de SAP procesan las solicitudes en el nivel de aplicación y envían llamadas de base de datos al nodo principal de Oracle.

  3. Oracle Data Guard mantiene una base de datos en espera sincronizada en otra zona de disponibilidad, y las máquinas virtuales (VM) del observador de Oracle Data Guard supervisan la replicación y el estado de preparación para la conmutación por error.

  4. Si se produce un fallo en un nodo o una zona de la base de datos, Oracle Data Guard realiza una conmutación por error de inicio rápido, promueve el nodo en espera a nodo principal y los servidores de aplicaciones de SAP se vuelven a conectar al nuevo nodo principal.

  5. Los sistemas de archivos compartidos de SAP, como los volúmenes sapmnt y transport, siguen estando disponibles a través del nivel resiliente del Sistema de archivos de red (NFS) seleccionado. Los servicios de copia de seguridad protegen las máquinas virtuales de base de datos y aplicaciones.

Components

Esta arquitectura de referencia describe un sistema de producción de SAP típico que se ejecuta en Oracle Database en Azure en una configuración de alta disponibilidad para maximizar la disponibilidad del sistema. Puede ajustar la arquitectura y sus componentes en función de los requisitos empresariales, como el objetivo de tiempo de recuperación (RTO), el objetivo de punto de recuperación (RPO), las expectativas de tiempo de actividad y el rol del sistema. Para entornos no productivos o cargas de trabajo que no requieren alta disponibilidad, puede implementar el sistema en una sola máquina virtual. El diseño de red se simplifica para mostrar los principios arquitectónicos básicos de un entorno sap y no representa una red empresarial completa.

Networking

  • Redes virtuales:Azure Virtual Network conecta Azure recursos 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 ExpressRoute que se implementa en el centro de una topología en estrella tipo hub-spoke. Esta arquitectura contiene aplicaciones y bases de datos de SAP en su propia red virtual radial y subdivide las redes virtuales en subredes independientes para cada nivel: aplicación (SAP NetWeaver), la 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. Mediante este enfoque, puede proteger los servidores más fácilmente mediante la administración de las directivas de seguridad de subred en lugar de los servidores individuales. También puede separar limpiamente las reglas de seguridad aplicables a las bases de datos de los servidores de aplicaciones.

  • Emparejamiento de redes virtuales: Esta arquitectura usa una topología de red en estrella tipo hub-and-spoke con varias redes virtuales emparejadas. Esta topología proporciona segmentación de red y aislamiento 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 Azure. Se recomienda usar Azure ExpressRoute para crear conexiones privadas que no pasen por la red pública de Internet, pero también puede usar una conexión de sitio a sitio. Use ExpressRoute con redundancia de zona o puertas de enlace VPN para protegerse contra fallos de zona. Para obtener más información sobre las diferencias entre una implementación zonal y una implementación con redundancia de zona, consulte Confiabilidad de las puertas de enlace de red virtual de Azure. Las puertas de enlace de una implementación de zona requieren direcciones IP de SKU estándar.

  • Grupos de seguridad de red (NSG): Para restringir el tráfico entrante, saliente e intrasubnet en la red virtual, cree grupos de seguridad de red y asígnelos a subredes específicas. Los grupos de seguridad de red específicos para cada carga de trabajo protegen las subredes de base de datos y de aplicaciones.

  • Grupos de seguridad de aplicaciones (ASG): Para definir directivas de seguridad de red específicas dentro de los NSG en función de los roles de aplicación, use ASG en lugar de direcciones IP explícitas. Asigne interfaces de red de VM a los ASG y use esos grupos como orígenes o destinos en reglas NSG.

  • NIC: Los controladores de interfaz de red (NIC) permiten toda la comunicación entre máquinas virtuales de una red virtual. Las implementaciones de SAP locales tradicionales implementan varias NIC por máquina para separar el tráfico administrativo del tráfico empresarial.

    En Azure, la red virtual es una red definida por software (SDN) 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 máquina virtual y conectar cada NIC a una subred diferente. A continuación, puede usar NSG para aplicar distintas directivas de control de acceso en cada subred.

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

Máquinas virtuales

Esta arquitectura usa máquinas virtuales. Para el nivel de aplicación de SAP, la implementación usa máquinas virtuales para todos los roles de instancia. Estos roles incluyen SAP Web Dispatcher y servidores de aplicaciones de SAP, las instancias de servicios centrales ASCS y Servidor de replicación en cola (ERS) de SAP y los servidores de aplicaciones principal servidor de aplicaciones (PAS) y servidor de aplicaciones adicional (AAS). Ajuste el número de máquinas virtuales en función de sus requisitos. Para obtener más información sobre cómo ejecutar SAP NetWeaver en máquinas virtuales, consulte Plan e implementación de una implementación de SAP en Azure.

De forma similar, la arquitectura usa máquinas virtuales para todos los componentes de Oracle, incluidas oracle Database y las máquinas virtuales del observador de Oracle. Las máquinas virtuales de observador de esta arquitectura son más pequeñas que las de los servidores de bases de datos.

  • Máquinas virtuales de CPU virtual restringidas (vCPU): Para ahorrar costos en las licencias de Oracle, considere la posibilidad de usar máquinas virtuales restringidas de vCPU.

  • Familias de máquinas virtuales certificadas para SAP: Para más información sobre la compatibilidad de SAP con Azure tipos de máquina virtual y métricas de rendimiento (SAPS), consulte la nota de SAP 1928533.

  • Grupos de selección de ubicación por proximidad (PPG): En la mayoría de las implementaciones zonales, la latencia dentro de la zona es suficiente para las aplicaciones de SAP. Si la latencia medida entre las capas de aplicación y de base de datos afecta a la carga de trabajo, use PPGs para las máquinas virtuales de SAP ASCS/SCS y de la capa de aplicación. Mantenga las máquinas virtuales de base de datos fuera del PPG para mantener la flexibilidad necesaria para cambiar el tamaño de la máquina virtual de la base de datos y los cambios de SKU.

  • Máquinas virtuales de generación 2 (Gen2): Al implementar máquinas virtuales en Azure, puede elegir la generación 1 (Gen1) o Gen2. Las máquinas virtuales gen2 admiten características que Gen1 no proporciona. Estas características son importantes para las bases de datos de Oracle de gran tamaño, ya que algunas familias de máquinas virtuales, como Mv2 y Mdsv2, solo se ejecutan como máquinas virtuales gen2. La certificación de SAP en Azure para algunas máquinas virtuales más recientes podría requerir también Gen2 para una compatibilidad completa, incluso si Azure admite ambas generaciones en esas máquinas virtuales. Para obtener más información, consulte la nota de SAP 1928533: productos compatibles y tipos de máquina virtual Azure.

    Todas las demás máquinas virtuales que admiten SAP solo admiten Gen2 o Gen1 y Gen2. Se recomienda implementar todas las máquinas virtuales de SAP como Gen2, incluso cuando los requisitos de memoria son bajos. Puede escalar las máquinas virtuales Gen2 más pequeñas que en su momento se implementaron como Gen2 hasta la máquina virtual más grande disponible con una sencilla operación de desasignación y cambio de tamaño. Las máquinas virtuales de Gen1 solo se pueden escalar a familias de máquinas virtuales que Azure admiten para Gen1.

Storage

Esta arquitectura usa discos administrados de Azure para máquinas virtuales y recursos compartidos de archivos de Azure o Azure NetApp Files para cualquier necesidad de almacenamiento compartido NFS, como sapmnt y volúmenes NFS de SAP transport. Para obtener más información sobre la implementación de almacenamiento con SAP en Azure, consulte la guía sobre los tipos de Azure Storage para cargas 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. Usa 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 la región seleccionada. Azure proporciona diferentes opciones de implementación, como Azure 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 más información sobre 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 Arquitectura de alta disponibilidad y escenarios para SAP NetWeaver.

  • Equilibradores de carga: Un equilibrador de carga interno Azure distribuye el tráfico a las máquinas virtuales en las subredes de SAP. Azure Load Balancer admite la distribución con redundancia de zona para implementaciones zonales de SAP.

    Tenga en cuenta los factores de decisión al implementar máquinas virtuales entre zonas de disponibilidad para SAP. Considere los PPG con una implementación de zona de disponibilidad y úselos solo para máquinas virtuales de nivel de aplicación.

    Note

    Las zonas de disponibilidad proporcionan alta disponibilidad dentro de una región, pero la recuperación ante desastres entre zonas podría no cumplir los requisitos de resiliencia para un desastre de gran alcance geográfico. Seleccione una región de recuperación ante desastres en función de los requisitos empresariales y normativos de distancia, la disponibilidad del servicio, la latencia y los objetivos de RPO/RTO.

  • Componentes específicos de Oracle: En regiones zonales, implementará máquinas virtuales de Oracle Database en diferentes zonas de disponibilidad con el modelo de implementación de Virtual Machine Scale Sets recomendado por SAP con el recuento de dominios de error establecido en 1 (FD=1). En regiones sin zonas de disponibilidad, utilice las opciones de implementación regional de alta 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 sincrónica de bases de datos a través de Oracle Data Guard entre las bases de datos para garantizar la coherencia y permitir tiempos de servicio RTO y RPO bajos en caso de errores individuales. Además de las VM de base de datos, una configuración de Fast-Start Failover de Oracle Data Guard requiere VM adicionales con Oracle Data Guard Observer. Las VM de observador de Oracle supervisan la base de datos y el estado de la replicación, y permiten la conmutación por error de la base de datos de forma automática, sin ningún gestor de clúster. Puede realizar la administración de replicación de bases de datos mediante Oracle Data Guard Broker. Para obtener más información, consulte Arquitecturas para la base de datos de Oracle en Azure Virtual Machines.

    Esta arquitectura usa herramientas nativas de Oracle sin software de clúster 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, el proceso de conmutación por error está automatizado y las aplicaciones SAP se vuelven a conectar a la nueva base de datos principal si se produce una conmutación por error.

    Existen varias soluciones de clúster que no son de Microsoft como alternativas, como SIOS Protection Suite o Veritas InfoScale, y puede encontrar detalles de implementación en la documentación de cada proveedor.

  • Oracle RAC: Los clústeres de aplicaciones reales (RAC) de Oracle no se admiten en máquinas virtuales de Azure. Oracle AI Database@Azure admite implementaciones de RAC en Exadata, pero ese servicio no forma parte de esta arquitectura. Para este diseño basado en máquinas virtuales, Oracle Data Guard puede proporcionar alta disponibilidad y protección frente a interrupciones del servicio a nivel de rack, de centro de datos o regionales.

  • Nivel NFS: Para las implementaciones de SAP basadas en Linux de alta disponibilidad, debe usar un nivel NFS resistente que proporcione volúmenes NFS para el directorio de transporte de SAP, el sapmnt volumen de archivos binarios de SAP y volúmenes adicionales para las instancias de (A)SCS y ERS.

    Entre las opciones para proporcionar un nivel NFS se incluyen:

  • Clúster de SAP Central Services: Esta arquitectura de referencia ejecuta Central Services en máquinas virtuales discretas. Central Services se convierte en un único punto de error (SPoF) potencial al implementarlo en una sola máquina virtual. Para implementar una solución de alta disponibilidad, se necesita software de gestión de clústeres que automatice la conmutación por error de las instancias de (A)SCS y ERS a la máquina virtual correspondiente. Esta configuración depende de la solución NFS elegida, por lo que la configuración sigue los requisitos de la solución.

    La solución de clúster debe determinar qué máquina virtual sirve a cada servicio cuando el software o la infraestructura deja de estar disponible. SAP en Azure proporciona dos opciones para las implementaciones de STONITH basadas en Linux para controlar máquinas virtuales o aplicaciones que no responden:

    • Dispositivo de bloque STONITH (SBD): SBD admite dos formas. En el formulario iSCSI, se implementan una o tres máquinas virtuales adicionales que sirven como destinos iSCSI para un dispositivo de bloque compartido pequeño. Las máquinas virtuales miembros del clúster (las dos máquinas virtuales (A)SCS/ERS de este grupo del clúster) acceden periódicamente a este dispositivo y utilizan los montajes SBD para emitir votos y alcanzar el cuórum en las decisiones del clúster. Esta arquitectura no incluye las máquinas virtuales SBD adicionales. En el formulario Azure disco compartido, un disco compartido Azure reemplaza las máquinas virtuales de destino iSCSI, por lo que no se requieren máquinas virtuales adicionales. En el caso de las implementaciones zonales, use un disco compartido ZRS para mantener la disponibilidad del disco entre zonas.

    • Agente de aislamiento de Azure: Esta opción usa la API de Azure Management para aislar los nodos con fallos deteniéndolos y reiniciándolos a través de la API de cómputo de Azure. No requiere máquinas virtuales adicionales.

    Para conocer los pasos de configuración y los detalles de diseño, consulte las guías vinculadas en la sección nivel NFS. Los gestores de clústeres no certificados por Microsoft Azure pueden proporcionar alta disponibilidad para SAP Central Services.

  • Grupo de servidores de aplicaciones de SAP: Implemente dos o más servidores de aplicaciones. El servidor de mensajes de SAP o los despachadores web equilibran la carga de las solicitudes para lograr la alta disponibilidad. Cada servidor de aplicaciones funciona de forma independiente y este grupo de máquinas virtuales no requiere equilibrio de carga de red.

  • Grupo de SAP Web Dispatcher: El componente Web Dispatcher equilibra el tráfico de SAP entre los servidores de aplicaciones de SAP. Para lograr la alta disponibilidad de SAP Web Dispatcher, use un clúster de conmutación por error o una configuración paralela de Web Dispatcher y coloque las instancias del distribuidor detrás de Load Balancer.

    Web Dispatcher embebido en (A)SCS es una opción especial. Considere un dimensionamiento adecuado debido a la carga de trabajo adicional en (A)SCS.

    En el caso de las comunicaciones accesibles desde 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 artículo se centra principalmente en implementaciones basadas en Linux. Los mismos principios arquitectónicos se aplican a Windows. La arquitectura de Oracle no difiere entre Linux y Windows.

    Para obtener más información sobre la aplicación SAP, consulte Ejecución de SAP NetWeaver en Windows en Azure.

Considerations

Estas consideraciones implementan los pilares del Azure Well-Architected Framework, que es un conjunto de principios rectores que puede utilizar para mejorar la calidad de una carga de trabajo. Para obtener más información, consulte Well-Architected Framework.

Reliability

La confiabilidad ayuda a garantizar que la aplicación pueda cumplir los compromisos que realice para sus clientes. Para obtener más información, vea Lista de verificación para la revisión del diseño en términos de confiabilidad.

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 recuperación de desastres y usa zonas de disponibilidad.

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

Descargar un archivo Visio de esta arquitectura y arquitecturas 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 cargas de trabajo de SAP e instrucciones de recuperación ante desastres para la aplicación SAP.

Backup

La copia de seguridad de Oracle en Azure tiene varias opciones:

Para las máquinas virtuales que no son de base de datos, recomendamos Azure Backup para máquinas virtuales para proteger las máquinas virtuales de aplicaciones SAP y la infraestructura de apoyo, como SAP Web Dispatcher.

Optimización de costos

La optimización de costos se centra en formas de reducir los gastos innecesarios y mejorar las eficiencias operativas. Para obtener más información, consulte Lista de comprobación de revisión de diseño para la optimización de costes.

Los principales factores de costo de esta arquitectura son:

  • Las SKU de VM certificadas por Oracle y SAP y el número de VM en la capa de aplicación, la capa de base de datos y los nodos observadores.

  • Decisiones del modelo de licencias de Oracle para el sistema operativo y el software de base de datos. Considere usar las SKU de VM con restricción de vCPU para reducir los núcleos sujetos a licencia, cuando proceda.

  • Niveles de rendimiento de almacenamiento y capacidad aprovisionada para datos, registros, copias de seguridad y volúmenes NFS compartidos de Oracle.

  • Servicios de red y de alta disponibilidad, especialmente ExpressRoute o puertas de enlace VPN, equilibradores de carga y tráfico de replicación entre zonas o regiones.

Consulte la estimación preconfigurada en la calculadora de precios de Azure para obtener una arquitectura de alta disponibilidad de Oracle de tamaño mediano para calcular los costos de la topología y las SKU seleccionadas. Para controlar el gasto:

  • Ajuste correctamente la memoria y la CPU de la máquina virtual a los requisitos medidos de SAPS y de rendimiento de Oracle.

  • Use niveles de almacenamiento de mayor costo solo cuando los requisitos de latencia y entrada/salida por segundo (IOPS) los exijan.

  • Evalúe las reservas o los planes de ahorro para una capacidad de cómputo constante después de validar la flexibilidad operativa y en las licencias.

Contributors

Microsoft mantiene este artículo. Los siguientes colaboradores escribieron este artículo.

Autor principal:

Para ver los perfiles no públicos de LinkedIn, inicie sesión en LinkedIn.

Pasos siguientes

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