Ejecución de SAP NetWeaver en Windows en Azure

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

Está guía presenta un conjunto de prácticas probadas para ejecutar SAP NetWeaver en un entorno de Windows en Azure con alta disponibilidad. La base de datos es AnyDB, el término de SAP para todos los sistemas de administración de bases de datos (DBMS) compatibles que no sean SAP HANA.

Architecture

En el siguiente diagrama se muestra SAP NetWeaver en un entorno de Windows en un escenario de conjunto de disponibilidad. La arquitectura usa Azure NetApp Files para la capa de archivos compartidos y un grupo con ubicación por proximidad para un mejor rendimiento.

Un diagrama de arquitectura que muestra una solución para SAP NetWeaver en Windows. La base de datos es AnyDB en los VM de Azure con conjuntos de disponibilidad.

Descargue un archivo Visio de esta arquitectura.

En el siguiente diagrama se muestra SAP NetWeaver en un entorno de Windows. Las zonas de disponibilidad se usan para mejorar la resistencia.

Un diagrama de arquitectura que muestra una solución para SAP NetWeaver en Windows. La base de datos es AnyDB en los VM de Azure con conjuntos de disponibilidad de zonas.

Descargue un archivo Visio de esta arquitectura.

Nota

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

Esta guía describe un sistema de producción. Esta arquitectura se implementa con tamaños de máquina virtual (VM) específicos que puede cambiar para acomodarlos a las necesidades de la organización. Este sistema se puede reducir a una única VM. En esta guía, el diseño de red se simplifica considerablemente para demostrar los principios arquitectónicos. No está pensado para describir una red empresarial completa.

Flujo de trabajo

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 a un entorno local a través de una puerta de enlace de red privada virtual (VPN) implementada en el concentrador de una topología en estrella tipo hub-and-spoke. La red radial es la red virtual que se usa tanto para las aplicaciones de SAP como para las capas de bases de datos.

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. No se produce ninguna disminución del rendimiento si se implementa dentro de una sola región. La red virtual se divide en subredes independientes para cada capa: aplicación (SAP NetWeaver), base de datos y servicios compartidos (como Jumpbox y Windows Server Active Directory).

Máquinas virtuales. Esta arquitectura usa máquinas virtuales para la capa de aplicación y la capa de base de datos, agrupadas como se indica a continuación:

  • SAP NetWeaver. La capa de aplicación usa máquinas virtuales de Windows y ejecuta SAP Central Services y servidores de aplicaciones de SAP. Las VM que ejecutan Central Services están configuradas como un clúster de conmutación por error de Windows Server para alta disponibilidad. Son compatibles con recursos compartidos de archivos de Azure o discos compartidos de Azure.

  • AnyDB. La capa de base de datos ejecuta AnyDB como base de datos, que puede ser Microsoft SQL Server, Oracle o IBM Db2.

  • Jumpbox/host de tipo bastión. Los administradores usan una máquina virtual de seguridad mejorada que se denomina jump box o un host bastión para conectarse a otras máquinas virtuales. Normalmente forma parte de los servicios compartidos, como los controladores de dominio y los servicios de copia de seguridad. Si el protocolo Secure Shell (SSH) y el Protocolo de escritorio remoto (RDP) son los únicos servicios que se usan para la administración del servidor, un host de Azure Bastion es una alternativa. Pero si usa otras herramientas de administración, como SQL Server Management Studio o el Front-End de SAP, use un jump box tradicional autoimplementado.

  • Controladores de dominio de Windows Server Active Directory. Los controladores de dominio se usan para la administración de identidades de todas las máquinas virtuales y usuarios del dominio.

Servicio de DNS privado.Azure Private DNS ofrece un servicio DNS fiable y seguro para su red virtual. Azure Private DNS administra y resuelve los nombres de dominio en la red virtual sin necesidad de configurar una solución DNS personalizada.

Equilibradores de carga. Los equilibradores de carga se usan para distribuir el tráfico a las máquinas virtuales en la subred de la capa de aplicaciones. Para una alta disponibilidad de SAP, use el SAP Web Dispatcher integrado, Azure Load Balancer o dispositivos de red. Su elección depende del tipo de tráfico (como HTTP o SAP GUI) o de los servicios de red necesarios, como la terminación de Capa de sockets seguros (SSL). Al incorporar Azure Load Balancer en una implementación zonal de SAP, asegúrese de seleccionar el Standard Load Balancer, porque el equilibrador de la SKU Básica no incluye redundancia de zona.

Para ver algunos ejemplos de diseño de entrada y salida accesibles por Internet, consulte Conexiones a Internet entrantes y salientes para SAP en Azure.

Standard Load Balancer admite varias direcciones IP virtuales de front-end. Esta compatibilidad es ideal para las implementaciones de clúster que implican estos componentes:

  • Advanced Business Application Programming (ABAP) SAP Central Service (ASCS)
  • Liquidación de recibos evaluados (ERS)

Los servicios pueden compartir un equilibrador de carga para simplificar la solución.

La SKU estándar también admite clústeres SAP de varios identificadores de seguridad (varios SID). En otras palabras, varios sistemas SAP en Windows pueden compartir una infraestructura de alta disponibilidad común para ahorrar costes. Evalúe el ahorro de costes y evite colocar demasiados sistemas en un único clúster. Azure no admite más de cinco SID por clúster.

Puerta de enlace de aplicación. Azure Application Gateway es un equilibrador de carga de tráfico web que puede usar para administrar el tráfico a las aplicaciones web. Los equilibradores de carga tradicionales funcionan en la capa de transporte (capa OSI 4 - TCP y UDP). En función del puerto y la dirección IP de origen, los equilibradores de carga tradicionales enrutan el tráfico a un puerto y una dirección IP de destino. Application Gateway puede tomar decisiones de enrutamiento basadas en los atributos adicionales de una solicitud HTTP, como una ruta de acceso de identificador URI o un encabezado host. Este tipo de enrutamiento se conoce como equilibrio de carga de capa de aplicación (OSI capa 7).

Conjuntos de disponibilidad. Las VM para todos los grupos y clústeres (Web Dispatcher, servidores de aplicaciones de SAP, Central Services y bases de datos) se agrupan en conjuntos de disponibilidad independientes. Se dispone de al menos dos máquinas virtuales por rol. Los conjuntos de disponibilidad aumentan la disponibilidad de las aplicaciones y las VM. Lo hacen mediante la administración de errores del sistema host o eventos de mantenimiento al distribuir las instancias de rol en varios hosts. Una alternativa consiste en usar zonas de disponibilidad para mejorar la disponibilidad de las cargas de trabajo, como se describe más adelante en este artículo.

Puerta de enlace con redundancia de zona. Se pueden implementar puertas de enlace de Azure ExpressRoute o VPN entre zonas 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. Las direcciones IP utilizadas deben ser de la SKU Estándar para una implementación de zona de las puertas de enlace.

Grupo con ubicación por proximidad. Este grupo lógico impone una restricción en las máquinas virtuales implementadas en un conjunto de disponibilidad o en un conjunto de escalado de máquinas virtuales. Un grupo con ubicación por proximidad favorece la coubicación, por lo que las máquinas virtuales residen en el mismo centro de datos para minimizar la latencia de la aplicación.

Grupos de seguridad de red. Para restringir el tráfico de entrada, de salida e interno de las subredes en la red virtual, cree grupos de seguridad de red.

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

Puerta de enlace. 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. Para reducir la latencia o aumentar el rendimiento, le recomendamos que use Global Reach de ExpressRoute y FastPath de ExpressRoute, como se describe más adelante en este artículo.

Azure Storage. Azure Storage proporciona persistencia de datos para una máquina virtual en forma de disco duro virtual (VHD). Se recomienda usar los discos administrados de Azure.

Recomendaciones

En esta arquitectura se describe una pequeña implementación en el nivel de producción. La implementación variará en función de los requisitos empresariales, por lo que debe tener en cuenta estas recomendaciones como punto de partida.

Máquinas virtuales

En las granjas y clústeres de servidores de aplicaciones, ajuste el número de máquinas virtuales según sus requisitos. Para más información acerca de la ejecución de SAP NetWeaver en las máquinas virtuales, consulte Planificación e implementación de Azure Virtual Machines para SAP NetWeaver.

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, consulte la nota de SAP 1928533. (Para acceder a las notas de SAP, debe tener una cuenta de SAP Service Marketplace).

SAP Web Dispatcher

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 la alta disponibilidad para el componente Web Dispatcher, se usa Azure Load Balancer para implementar el clúster de conmutación por error de componentes SWD o la configuración paralela SWD. Consulte:Alta disponibilidad de SAP Web Dispatcher para obtener una descripción detallada de la solución.

Grupo de servidores de aplicaciones

La transacción SMLG de SAP se usa normalmente para administrar los grupos de inicio de sesión de los servidores de aplicaciones de ABAP y para equilibrar la carga de los usuarios de inicio de sesión. Otras transacciones, como SM61 para grupos de servidores de procesos por lotes, y RZ12 para grupos RFC, también equilibran la carga de usuarios de inicio de sesión. Estas transacciones usan la funcionalidad de equilibrio de carga en el servidor de mensajes de SAP Central Services para distribuir las sesiones o cargas de trabajo entrantes entre el grupo de servidores de aplicaciones de SAP para SAP GUI y el tráfico de RFC.

Clúster de SAP Central Services

Esta arquitectura ejecuta Central Services en máquinas virtuales en la capa de aplicación. 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, use un clúster de disco compartido o de recursos compartidos de archivos.

En el caso de los recursos compartidos de archivos de alta disponibilidad, hay varias opciones. Se recomienda usar recursos compartidos de Azure Files como recursos compartidos y totalmente administrados de bloque de mensajes de servidor (SMB) nativos en la nube (SMB) o recursos compartidos del sistema de archivos de red (NFS). Una alternativa a Azure Files es Azure NetApp files, que ofrece recursos compartidos NFS y SMB de alto rendimiento.

También puede implementar los recursos compartidos de archivos de alta disponibilidad en las instancias de Central Services mediante un clúster de conmutación por error de Windows Server con Azure Files. Esta solución también admite un clúster de Windows con discos compartidos mediante un disco compartido de Azure como volumen compartido del clúster (CSV). Si prefiere usar discos compartidos, se recomiendan discos compartidos de Azure para configurar un clúster de conmutación por error de Windows Server como clúster de SAP Central Services.

También existen productos de terceros, como SIOS DataKeeper Cluster Edition, de SIOS Technology Corp., que replica el contenido de discos independientes conectados a los nodos de clúster de ASCS y, después, presenta los discos como CSV al software del clúster.

En el caso de la creación de particiones de red en clúster, el software del clúster usa votos de cuórum para decidir qué segmento de la red y sus servicios asociados van a actuar como cerebro del clúster fragmentado. Windows ofrece muchos modelos de cuórum. Esta solución usa testigo en la nube de Azure porque es más fácil y ofrece más disponibilidad que un testigo de nodo de ejecución. El testigo de recurso compartido de archivos de Azure es otra alternativa para proporcionar un voto de cuórum de clúster.

En una implementación de Azure, los servidores de aplicaciones se conectan a Central Services de alta disponibilidad mediante los nombres de host virtual de los servicios ASCS o ERS. Estos nombres de host se asignan a la configuración IP de front-end del clúster del equilibrador de carga. Azure Load Balancer admite varias direcciones IP de front-end, por lo que las direcciones IP virtuales (VIP) de ASCS y ERS se pueden enlazar a un equilibrador de carga.

Conjuntos de disponibilidad

Los conjuntos de disponibilidad distribuyen los servidores en varios grupos de actualización e infraestructuras físicas para mejorar la disponibilidad del servicio. Para cumplir con los contratos de nivel de servicio (SLA), coloque las máquinas virtuales que cumplen el mismo rol en el mismo conjunto de disponibilidad. Esto ayuda a protegerse frente a tiempos de inactividad planeados y no planeados impuestos por el mantenimiento de la infraestructura de Azure o debido a errores de hardware. Para obtener un SLA superior, tiene que tener dos máquinas virtuales o más por conjunto de disponibilidad.

Todas las máquinas virtuales de un conjunto deben realizar el mismo rol. No mezcle servidores de distintos roles en el mismo conjunto de disponibilidad. Por ejemplo, no coloque un nodo de ASCS en el mismo conjunto de disponibilidad que los servidores de aplicaciones.

Puede implementar conjuntos de disponibilidad de Azure en zonas de disponibilidad de Azure cuando use un grupo con ubicación por proximidad.

Redes

Esta arquitectura usa una topología en estrella tipo hub-and-spoke. La red virtual del centro (hub) sirve como punto central de conectividad con una red local. Los radios (spokes) son redes virtuales que se emparejan con el centro y que aíslan las cargas de trabajo de SAP. El tráfico fluye entre el centro de datos local y el concentrador a través de una conexión de puerta de enlace.

Tarjetas de interfaz de red (NIC)

Las NIC (interfaces de red virtual) habilitan toda la comunicación entre 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. Luego puede usar los grupos de seguridad de red para aplicar las distintas directivas de control de acceso.

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, debe tener una cuenta de SAP Service Marketplace).

Subredes y grupos de seguridad de red

Esta arquitectura divide el espacio de direcciones de la red virtual en subredes. Puede asociar cada subred con un grupo de seguridad de red en el que se definen las directivas de acceso para la subred. Coloque los servidores de aplicaciones en una subred independiente. Esto le permite protegerlos más fácilmente mediante la administración de las directivas de seguridad de la subred, en lugar de los servidores individuales.

Cuando un grupo de seguridad de red se asocia a una subred, este se aplica a todos los servidores de la subred y ofrece un control más exhaustivo de los servidores. Configure grupos de seguridad de red medianteAzure portal, PowerShell o la CLI de Azure.

Global Reach de ExpressRoute

Si el entorno de red incluye dos conexiones ExpressRoute o más, Global Reach de ExpressRoute puede ayudar a reducir los saltos de red y la latencia. Esta tecnología es una configuración de emparejamiento de rutas de BGP entre dos conexiones ExpressRoute o más para unir dos dominios de enrutamiento de ExpressRoute. Global Reach reduce la latencia cuando el tráfico de red atraviesa más de una conexión ExpressRoute. Actualmente solo está disponible para el emparejamiento privado en circuitos ExpressRoute.

En este momento, no hay ninguna lista de control de acceso (ACL) de red ni otros atributos que se puedan cambiar en Global Reach. De este modo, todas las rutas aprendidas por un circuito ExpressRoute determinado (del entorno local y Azure) se anuncian a través del emparejamiento del circuito al otro circuito ExpressRoute. Se recomienda establecer el filtrado de tráfico de red en el entorno local para restringir el acceso a los recursos.

FastPath de ExpressRoute

También conocido como Microsoft Edge Exchange (MSEE) v2, FastPath implementa MSEE en el punto de entrada de la red de Azure. FastPath reduce los saltos de red para la mayoría de los paquetes de datos.

Para todas las conexiones ExpressRoute nuevas a Azure, FastPath es la configuración predeterminada. Para los circuitos ExpressRoute existentes, póngase en contacto con el Soporte técnico de Azure para activar FastPath.

FastPath no admite el emparejamiento de red virtual. Si otras redes virtuales están emparejadas con la que está conectada a ExpressRoute, el tráfico de la red local a las otras redes virtuales radiales se seguirá enviando a la puerta de enlace de red virtual. La solución es conectar todas las redes virtuales directamente al circuito de ExpressRoute.

Equilibradores de carga

SAP Web Dispatcher controla el equilibrio de carga del tráfico HTTP(S) en un grupo de servidores de aplicaciones SAP. Este equilibrador de carga de software brinda servicios de capa de aplicación (denominados de capa 7 en el modelo de red ISO) que puede realizar la terminación SSL y otras funciones de descarga.

Azure Load Balancer es un servicio de capa de transmisión de red (capa 4), que equilibra el tráfico de los flujos de datos mediante un hash de cinco tuplas. El hash se basa en la dirección IP de origen, el puerto de origen, la dirección IP de destino, el puerto de destino y el tipo de protocolo. En las implementaciones de SAP en Azure, Load Balancer se usa en las configuraciones de clúster para dirigir el tráfico a la instancia del servicio principal o al nodo correcto en caso de error.

Se recomienda que use Standard Load Balancer de Azure para todos los escenarios de SAP. Si las máquinas virtuales del grupo de back-end necesitan conectividad pública de salida, o si se usan en una implementación de zona de Azure, Standard Load Balancer necesita configuraciones adicionales debido a que están protegidos de manera predeterminada. No permitirán la conectividad saliente a menos que la configure de manera explícita.

Para el tráfico de clientes de la GUI de SAP que se conectan a un servidor SAP a través del protocolo DIAG o RFC, el servidor de mensajes de Central Services equilibra la carga a través de los grupos de inicio de sesión del servidor de aplicaciones de SAP. Para hacer esto, no necesita otro equilibrador de carga.

Storage

Algunas organizaciones usan el almacenamiento estándar para sus servidores de aplicaciones. No se admiten los discos no administrados estándar. Consulte la nota de SAP 1928533. (Para acceder a las notas de SAP, debe tener una cuenta de SAP Service Marketplace). Se recomienda utilizar Azure Managed Disks de tipo prémium en todos los casos. Tenga en cuenta que una actualización reciente de la nota de SAP 2015553 excluye el uso de almacenamiento HDD estándar y SSD estándar para algunos casos de uso específicos.

Los servidores de aplicaciones no hospedan datos empresariales. Por lo tanto, también puede usar los discos prémium P4 y P6 más pequeños para ayudar a minimizar costes. Esto también le permite beneficiarse del contrato de nivel de servicio de VM de instancia única si tiene una instalación central de la pila de SAP.

En escenarios de alta disponibilidad puede usar recursos compartidos de archivos de Azure y discos compartidos de Azure. Los discos administrados SSD prémium de Azure y el almacenamiento en disco Ultra de Azure están disponibles para discos compartidos de Azure, y SSD prémium está disponible para los recursos compartidos de archivos de Azure.

Cloud Witness también usa almacenamiento para mantener el cuórum con un dispositivo de una región remota de Azure, alejada de la región primaria en la que reside el clúster.

En el almacén de datos de copia de seguridad, se recomienda usar los niveles de acceso esporádico y de archivo de Azure. Estos niveles de almacenamiento son una manera rentable de almacenar datos de larga duración a los que se accede con poca frecuencia.

El almacenamiento en disco Ultra reduce considerablemente la latencia del disco. Como resultado, beneficia a las aplicaciones fundamentales para el rendimiento, como los servidores de bases de datos de SAP. Para comparar las opciones de almacenamiento en bloque en Azure, consulte: Tipos de disco administrados por Azure.

Si lo que quiere es un almacén de datos compartido de alto rendimiento y alta disponibilidad, use Azure NetApp Files. Esta tecnología es especialmente útil para la capa de base de datos cuando se usa Oracle, y también cuando se hospedan datos de aplicaciones.

Consideraciones de rendimiento

Los servidores de aplicaciones de SAP se comunican constantemente con los servidores de bases de datos. En el caso de las aplicaciones donde el rendimiento es crítico que se ejecutan en plataformas de bases de datos, habilite el Acelerador de escritura para el volumen de registro. Esto puede mejorar la latencia de escritura de registros. Acelerador de escritura está disponible para las VM de la serie M. Para optimizar las comunicaciones entre servidores, use Redes aceleradas. Redes aceleradas solo está disponible para las series de VM admitidas, como D/DSv2, D/DSv3, E/ESv3, F/FS, FSv2 y Ms/Mms. Para obtener más información, vea Maximización del rendimiento de las máquinas virtuales con redes aceleradas.

Para lograr un rendimiento de disco y un IOPS altos, siga las prácticas habituales de optimización del rendimiento del volumen de almacenamiento, las cuales se aplican al diseño de almacenamiento de Azure. Por ejemplo, puede combinar varios discos para crear un volumen de disco con secciones para mejorar el rendimiento de E/S. La habilitación de la caché de lectura en el contenido de almacenamiento que cambia con poca frecuencia mejora la velocidad de recuperación de datos.

Almacenamiento en disco Ultra ya está disponible para aplicaciones con uso intensivo de E/S. Cuando estos discos estén disponibles, recomendamos usarlos en lugar del almacenamiento prémium del Acelerador de escritura. Puede aumentar o disminuir individualmente las métricas de rendimiento, como IOPS y MBps, sin necesidad de reiniciar.

Para obtener consejos excelentes acerca de la optimización del almacenamiento de Azure para cargas de trabajo de SAP en SQL Server, consulte: Planificación e implementación de Virtual Machines de Azure para SAP NetWeaver.

No se recomienda colocar ninguna aplicación virtual de red (NVA) entre las capas de aplicación y de base de datos para cualquier pila de aplicaciones de SAP. Este procedimiento introduce un tiempo significativo de procesamiento de los paquetes de datos, lo que genera un rendimiento inaceptable de la aplicación.

Grupos de selección de ubicación de proximidad

Algunas aplicaciones de SAP requieren una comunicación frecuente con la base de datos. La proximidad física entre las capas de aplicación y de base de datos influye en la latencia de red, lo que puede afectar negativamente al rendimiento de las aplicaciones.

Para optimizar la latencia de red puede usar grupos con ubicación por proximidad, que establecen una restricción lógica en las máquinas virtuales implementadas en conjuntos de disponibilidad. Los grupos con ubicación por proximidad favorecen la coubicación y el rendimiento en lugar de la escalabilidad, la disponibilidad o el coste. Pueden mejorar considerablemente la experiencia del usuario en la mayoría de las aplicaciones de SAP. Para ver los scripts que están disponibles en GitHub desde el equipo de implementación de SAP de AzureCAT, consulte: Scripts.

Zonas de disponibilidad

Las zonas de disponibilidad proporcionan una manera de implementar máquinas virtuales entre zonas, las cuales están separadas físicamente dentro de una región de Azure específica. Su propósito es mejorar la disponibilidad del servicio. Sin embargo, la implementación de recursos entre zonas puede aumentar la latencia, por lo que debe tener en cuenta las consideraciones de rendimiento.

Los administradores necesitan un perfil de latencia de red claro entre todas las zonas de una región de destino antes de poder decidir la ubicación de los recursos con una latencia mínima entre zonas. Para crear este perfil, implemente máquinas virtuales pequeñas en cada zona para realizar pruebas. Entre las herramientas recomendadas para estas pruebas se incluyen PsPing e Iperf. Una vez completadas las pruebas, elimine las máquinas virtuales que usó para ellas. Como alternativa, considere utilizar una herramienta de comprobación de latencia entre zonas de Azure.

Consideraciones sobre escalabilidad

Para la capa de aplicación de SAP, Azure ofrece una amplia variedad de tamaños de máquina virtual tanto para el escalado vertical como para el horizontal. Para obtener una lista completa, vea la nota de SAP 1928533: SAP Applications on Azure: Supported Products and Azure VM Types (Aplicaciones de SAP en Azure: productos y tipos de VM de Azure compatibles). (Para acceder a las notas de SAP, debe tener una cuenta de SAP Service Marketplace).

Puede escalar verticalmente los servidores de aplicaciones SAP y los clústeres de Central Services. También puede escalarlos verticalmente si cambia el número de instancias que usa. La base de datos AnyDB se puede escalar y reducir verticalmente, pero no horizontalmente. El contenedor de bases de datos SAP para AnyDB no admite el particionamiento.

Consideraciones sobre disponibilidad

La redundancia de recursos es el tema general en las soluciones de infraestructura de alta disponibilidad. Para las empresas que tienen un SLA menos estricto, las máquinas virtuales de Azure de instancia única con discos prémium ofrecen un SLA de tiempo de actividad. Cuando implementa recursos redundantes en un conjunto de disponibilidad o entre instancias de zonas de disponibilidad, se eleva la disponibilidad del servicio.

En esta instalación distribuida de la aplicación SAP, la instalación base se replica para lograr una alta disponibilidad. Para cada capa de la arquitectura, el diseño de la alta disponibilidad varía.

Web Dispatcher en el nivel de servidores de aplicaciones

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.

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.

Web Dispatcher insertado en ASCS es una opción especial. Si usa esta opción, considere el ajuste de tamaño adecuado debido a la carga de trabajo adicional en ASCS.

Central Services en el nivel de servidores de aplicaciones

La alta disponibilidad de Central Services se implementa con el clúster de conmutación por error de Windows Server. Cuando el almacenamiento de clúster para el clúster de conmutación por error se implementa en Azure, puede configurarlo de dos maneras: como un disco compartido en clústeres o como un recurso compartido de archivos en clústeres.

Con la introducción de Standard Load Balancer de Azure, ahora puede habilitar el puerto de alta disponibilidad. Esto le permite evitar configurar reglas de equilibrio de carga para muchos puertos de SAP. Además, al configurar equilibradores de carga, ya sea en el entorno local o en Azure, habilite la característica Direct Server Return (también conocida como IP flotante o DSR). Al hacerlo, se proporciona una manera que permite a las respuestas del servidor omitir el equilibrador de carga. Esta conexión directa evita que el equilibrador de carga se convierta en un cuello de botella en la ruta de transmisión de datos. En el caso de los clústeres de ASCS y de bases de datos, se recomienda habilitar DSR.

Servicios de aplicación en el nivel de servidores de aplicaciones

La alta disponibilidad para los servidores de aplicaciones SAP se logra mediante el equilibrio de carga del tráfico dentro de un grupo de servidores de aplicaciones.

Nivel de base de datos

En esta arquitectura, la base de datos de origen se ejecuta en AnyDB, que es un DBMS como SQL Server, SAP ASE, IBM Db2 o Oracle. La característica de replicación nativa de la capa de base de datos proporciona conmutación por error manual o automática entre los nodos replicados.

Para obtener detalles de la implementación de los sistemas de base de datos específicos, consulte Implementación de DBMS de Azure Virtual Machines para SAP NetWeaver.

Máquinas virtuales implementadas entre zonas de disponibilidad

Una zona de disponibilidad es una construcción lógica diseñada para mejorar la disponibilidad de la carga de trabajo y proteger los servicios de aplicación y las máquinas virtuales frente a interrupciones del centro de datos. Las máquinas virtuales de una única zona se tratan como si estuvieran en un único dominio de error o de actualización. Cuando selecciona la implementación en zonas, las máquinas virtuales de la misma zona se distribuyen en los dominios de error y de actualización en función de la mejor opción.

En las regiones de Azure que admiten esta característica hay al menos tres zonas disponibles. Pero no se garantiza la distancia máxima entre los centros de datos de estas zonas. Para implementar un sistema SAP multinivel entre zonas, tiene que conocer la latencia de red dentro de una zona y en las zonas de destino. También tiene que conocer la sensibilidad de las aplicaciones implementadas frente a la latencia de red.

Tome en cuenta estas consideraciones cuando decida implementar recursos en zonas de disponibilidad:

  • Latencia entre máquinas virtuales de una zona
  • Latencia entre las máquinas virtuales de las zonas seleccionadas
  • Disponibilidad de los mismos servicios de Azure (tipos de máquinas virtuales) en las zonas seleccionadas

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 estar situadas al menos a 160 kilómetros (100 millas) de distancia de la región principal.

Ejemplo de implementación activa/inactiva

En esta implementación de ejemplo, el estado activo/pasivo se refiere al del servicio de aplicación dentro de las zonas. En la capa de aplicación, los cuatro servidores de aplicaciones activos del sistema SAP se encuentran en la zona 1. Otro conjunto de cuatro servidores de aplicaciones pasivos se integra en la zona 2, pero está apagado. Solo se activan cuando son necesarios.

Los clústeres de dos nodos para Central Services y los servicios de base de datos se extienden entre dos zonas. Si se produce un error en la zona 1, Central Services y los servicios de bases de datos se ejecutarán en la zona 2. Los servidores de aplicaciones pasivos de la zona 2 se activan. Con todos los componentes de este sistema SAP coubicados ahora en la misma zona, se minimiza la latencia de red.

Ejemplo de implementación activa/activa

En una implementación activa/activa, se crean dos conjuntos de servidores de aplicaciones en dos zonas. Dentro de cada zona, dos servidores de aplicaciones en cada conjunto de servidores están inactivos (apagados). Como consecuencia, hay servidores de aplicaciones activos en ambas zonas durante el funcionamiento normal.

Central Services y los servicios de bases de datos se ejecutan en la zona 1. Los servidores de aplicaciones de la zona 2 pueden tener una latencia de red más prolongada al conectarse a Central Services y a los servicios de bases de datos, debido a la distancia física entre las zonas.

Si la zona 1 se queda sin conexión, Central Services y los servicios de bases de datos conmutarán por error a la zona 2. Puede conectar los servidores de aplicaciones inactivos para proporcionar capacidad total para el procesamiento de las aplicaciones.

Consideraciones de recuperación ante desastres

En cada nivel de la pila de aplicaciones de SAP se usa una estrategia de recuperación ante desastres diferente.

Nivel de servidores de aplicaciones

Los servidores de aplicaciones de SAP no contienen datos empresariales. En Azure, una estrategia sencilla de recuperación ante desastres es crear servidores de aplicaciones SAP en la región secundaria y luego apagarlos. Si hay algún cambio de configuración o actualizaciones del kernel en el servidor de aplicaciones principal, tiene que aplicar los mismos cambios a las máquinas virtuales de la región secundaria. Por ejemplo, deberá copiar los archivos ejecutables del kernel de SAP en las máquinas virtuales de recuperación ante desastres.

Para la replicación automática de los servidores de aplicaciones en una región secundaria, se recomienda Azure Site Recovery. También puede usar Azure Site Recovery para configurar la recuperación ante desastres para una implementación de la aplicación multinivel NetWeaver de SAP.

Central Services

Este componente de la pila de aplicaciones SAP no conserva los datos empresariales. Para una mejor recuperación ante desastres que abarque varias regiones, use la replicación. En concreto, busque el recurso compartido de archivos de Azure SMB o el disco compartido de Azure del clúster de ASCS que contiene el /sapmnt directorio y otro contenido. Replique esos datos en un recurso compartido de archivos o disco de Azure SMB correspondiente en la región de recuperación ante desastres. Si va a usar SIOS, también puede usar Site Recovery para replicar el clúster de Central Services mediante discos de SIOS DataKeeper.

Si va a crear su propio proceso de replicación sin usar ninguna herramienta, puede crear una máquina virtual en la región de recuperación ante desastres para replicar el rol y el contenido de Central Services. El único contenido del nodo principal de Central Services que se sincroniza es el /sapmntrecurso compartido. Si cambia la configuración o se actualiza el kernel en los servidores principales de Central Services, tiene que repetir los cambios en la máquina virtual de la región de recuperación ante desastres. Para obtener más información sobre la creación, copia y el proceso de conmutación por error de prueba de este método de replicación, consulte: "4.3. Capa de SAP SPOF (ASCS)" en SAP NetWeaver: Creación de una solución de recuperación ante desastres basada en Hyper-V y Microsoft Azure.

Nivel de base de datos

Para la recuperación ante desastres, es mejor usar la tecnología de replicación integrada de una base de datos. Por ejemplo, para SQL Server, se recomienda usar la característica Grupos de disponibilidad Always On para establecer una réplica en una región remota y replicar las transacciones de forma asincrónica mediante la conmutación por error manual. La replicación asincrónica que el rendimiento de las cargas de trabajo interactivas del sitio principal resulte afectado. Cuando usa una conmutación por error manual, puede evaluar luego el efecto de la recuperación ante desastres y decidir si se justifica el funcionamiento desde el sitio de recuperación ante desastres.

Si usa Azure NetApp Files para el almacenamiento de sus bases de datos, es posible que pueda usar la replicación entre regiones para replicar los datos en una región secundaria. Esta característica se encuentra actualmente en versión preliminar, por lo que debe evaluar si cumple los requisitos para las cargas de trabajo de producción.

Recuperación ante desastres de servicios compartidos

Muchos servicios de TI, como instancias de Jumpbox administrativas, servicios de directorio basados en la nube, copias de seguridad y servicios de supervisión, se comparten gracias a los recursos en la nube implementados por usted. Replique los servicios compartidos en la región de recuperación ante desastres mediante cualquier medio que proporcionen los servicios.

Recuperación ante desastres automatizada con Azure Site Recovery

Para usar Azure Site Recovery para generar de forma automática un sitio de producción totalmente replicado de la configuración original, tiene que ejecutar scripts de implementación personalizados. Por ejemplo, Site Recovery implementa primero las máquinas virtuales en conjuntos de disponibilidad. Luego ejecuta los scripts personalizados para asociar el equilibrador de carga existente (pregenerado), el cual ya tiene definido el grupo de back-end, a la NIC de las máquinas virtuales de conmutación por error. Para ver un ejemplo en GitHub de un script de runbooks de automatización de Site Recovery personalizado, consulte Runbooks de Azure Site Recovery.

Nota

En caso de que se produzca un desastre regional que provoque un evento de conmutación por error masivo para muchos clientes de Azure en una región, la capacidad de recursos de la región de destino no está garantizada. Como sucede con todos los servicios de Azure, Site Recovery no deja de mejorar sus características y funcionalidades. Para la recuperación ante desastres de máquinas virtuales de Azure de una región de Azure a otra, consulte la matriz de compatibilidad más reciente.

Consideraciones de administración y operaciones

Para ayudar a mantener el sistema en ejecución en producción, tenga en cuenta los siguientes puntos.

Copia de seguridad

Las bases de datos son cargas de trabajo críticas que requieren un objetivo de punto de recuperación (RPO) bajo y retención a largo plazo.

  • En el caso de SAP en SQL Server, un enfoque consiste en usar Azure Backup para hacer copias de seguridad de las bases de datos de SQL Server que se ejecutan en máquinas virtuales. Otra opción consiste en usar instantáneas de Azure Files para hacer una copia de seguridad de archivos de base de datos de SQL Server.

  • Para SAP en Oracle o Windows, vea la sección "Copia de seguridad y restauración" de Implementación de DBMS de máquinas virtuales de Azure para SAP.

  • En el caso de otras bases de datos, consulte las recomendaciones de copia de seguridad del proveedor de bases de datos. Si la base de datos admite el servicio de instantáneas de volumen (VSS) de Windows, use instantáneas de VSS para realizar copias de seguridad coherentes con la aplicación.

Administración de identidades

Use un sistema de administración de identidades centralizado para controlar el acceso a los recursos en todos los niveles:

Admita el acceso dentro de las propias aplicaciones mediante los servicios que ofrece SAP. O bien, use OAuth 2.0 y Azure AD.

Supervisión

Azure Monitor proporciona herramientas sofisticadas para recopilar y analizar la telemetría. Estas herramientas le ayudan a maximizar el rendimiento y la disponibilidad de los recursos y aplicaciones en el entorno local y en la nube. Azure Monitor ahora incluye Log Analytics y Application Insights. Puede utilizar Azure Monitor para supervisar las anomalías de la infraestructura y las aplicaciones, alertar a los administradores y automatizar las reacciones ante condiciones predefinidas.

Para proporcionar una supervisión basada en SAP del rendimiento de los recursos y servicios de la infraestructura de SAP, utilice la extensión Supervisión mejorada de Azure para SAP. Esta extensión introduce las estadísticas de supervisión de Azure en la aplicación de SAP para la supervisión de sistema operativo y las funciones de DBA Cockpit. Se necesita SAP Enhanced Monitoring para ejecutar SAP en Azure. Para más información, consulte la nota de SAP 2191498: "SAP on Linux with Azure: Enhanced Monitoring" (SAP en Linux con Azure: supervisión mejorada). Para acceder a las notas de SAP, debe tener una cuenta de SAP Service Marketplace.

Azure Monitor para soluciones de SAP es la dirección futura de una solución completa de supervisión nativa de Azure para SAP NetWeaver. Esta solución se encuentra actualmente en versión preliminar y solo está disponible en un conjunto limitado de regiones. Debe evaluar cuidadosamente si satisface sus requisitos.

Azure Monitor para soluciones de SAP brinda un conjunto inicial completo de métricas y telemetría para la supervisión. Las definiciones de las métricas se almacenan como consultas SQL en JSON. Puede cambiarlas para satisfacer sus requisitos. Para conocer el conjunto inicial de métricas, consulte GitHub.

Consideraciones sobre la seguridad

SAP cuenta con su propio motor de administración de usuarios (UME) para controlar el acceso y la autorización basados en roles en la aplicación y las bases de datos de SAP. Para obtener una guía detallada sobre la seguridad de las aplicaciones, consulte la Guía de seguridad de SAP NetWeaver.

Para una mayor seguridad de la red, considere la posibilidad de usar una red perimetral que utilice una aplicación virtual de red (NVA) para crear un firewall delante de la subred para Web Dispatcher.

Puede implementar una NVA para filtrar el tráfico entre redes virtuales, pero no la coloque entre la aplicación SAP y la base de datos. Además, compruebe las reglas de enrutamiento configuradas en la subred y evite dirigir el tráfico a una NVA de instancia única. En caso contrario, puede provocar tiempo de inactividad de mantenimiento y errores de red o de nodo en clústeres.

Para la seguridad de la infraestructura, los datos se cifran tanto en tránsito como en reposo. En la sección "Recomendaciones de seguridad" de Implementación y planificación de Azure Virtual Machines para SAP NetWeaver se aborda la seguridad de red. En este artículo también se especifican los puertos de red que tiene que abrir en los firewalls para permitir la comunicación de la aplicación.

Puede usar Azure Disk Encryption para cifrar discos de máquinas virtuales Windows. Este servicio utiliza la característica BitLocker de Windows para proporcionar el cifrado del volumen de los discos de datos y del sistema operativo. La solución también funciona con Azure Key Vault para ayudarle a controlar y administrar las claves y los secretos del cifrado de discos en la suscripción de Key Vault. Los datos de los discos de máquinas virtuales se cifran en reposo en Azure Storage.

Para el cifrado de datos en reposo, el cifrado de datos transparente (TDE) de SQL Server cifra los archivos de datos de SQL Server, Azure SQL Database y Azure Synapse Analytics. Para obtener más información, vea Implementación de DBMS en Azure Virtual Machines de SQL Server para SAP NetWeaver.

Para supervisar las amenazas desde dentro y fuera del firewall, considere la posibilidad de implementar Microsoft Sentinel (en versión preliminar). La solución proporciona análisis y detección continuas de amenazas para sistemas SAP implementados en Azure, en otras nubes o en el entorno local. Para obtener instrucciones de implementación, consulte: Implementación de supervisión de amenazas para SAP en Microsoft Sentinel.

Como siempre, asegúrese de administrar las actualizaciones y revisiones de seguridad para proteger los recursos de información. Le recomendamos emplear un enfoque de automatización integral para esta tarea.

Consideraciones sobre el costo

Puede usar la calculadora de precios de Azure para calcular los costos.

Para más información, consulte la sección acerca de los costos del artículo sobre elmarco de buena arquitectura de Microsoft Azure.

Si la carga de trabajo requiere más memoria y menos CPU, considere la posibilidad de usar uno de los tamaños de máquina virtual vCPU restringida para reducir los costes de las licencias de software que se cargan por vCPU.

Máquinas virtuales

En esta arquitectura se usan máquinas virtuales para la capa de aplicación y la capa de base de datos. En la capa de SAP NetWeaver se usan máquinas virtuales Windows para ejecutar servicios y aplicaciones de SAP. La capa de base de datos ejecuta AnyDB como la base de datos, como por ejemplo SQL Server, Oracle o IBM Db2. Las máquinas virtuales también se usan como instancias de jumpbox para la administración.

Existen varias opciones de pago para las máquinas virtuales:

  • Para las cargas de trabajo que no tienen un tiempo de finalización ni un consumo de recursos predecibles, considere la posibilidad de usar la opción de pago por uso.

  • Considere la posibilidad de usar Azure Reservations si es capaz de usar una máquina virtual durante un período de más de uno o tres años. Las reservas de máquinas virtuales pueden reducir significativamente los costes. Es posible que pague tan solo el 72% del coste de un servicio de pago por uso.

Use las máquinas virtuales de acceso puntual de Azure para ejecutar cargas de trabajo que se puedan interrumpir y no requieran la finalización dentro de un período de tiempo predeterminado o un Acuerdo de Nivel de Servicio. Azure implementa máquinas virtuales de acceso puntual cuando hay capacidad disponible, y las expulsa cuando necesita recuperar dicha capacidad. Los costes asociados a las máquinas virtuales de acceso puntual son inferiores a los de otras máquinas virtuales. Considere la posibilidad de usar VM de acceso puntual para estas cargas de trabajo:

  • Escenarios informáticos de alto rendimiento, trabajos de procesamiento por lotes o aplicaciones de representación visual
  • Entornos de prueba, incluidas las cargas de trabajo de integración continua y entrega continua
  • Aplicaciones sin estado a gran escala

Si necesita más control sobre los eventos de mantenimiento o el aislamiento de hardware, ya sea por rendimiento o cumplimiento, considere la posibilidad de implementar las máquinas virtuales en hosts dedicados.

Máquinas virtuales y conjuntos de disponibilidad

En todos los grupos y clústeres (Web Dispatcher, servidores de aplicaciones de SAP, Central Services y base de datos), las máquinas virtuales se agrupan en conjuntos de disponibilidad independientes. Los conjuntos de disponibilidad no representan ningún costo. Solo paga por cada instancia de máquina virtual que cree.

Si va a implementar una carga de trabajo en zonas de disponibilidad, no se requieren conjuntos de disponibilidad.

Load Balancer

En este escenario, Azure Load Balancer se usa para distribuir el tráfico a las máquinas virtuales en la subred de la capa de aplicación.

Solo se le cobra por la cantidad de reglas de equilibrio de carga y salida configuradas, más los datos procesados a través del equilibrador de carga. Las reglas de traducción de direcciones de red de entrada (NAT) son gratuitas. Cuando no hay configurada ninguna regla, la instancia de Standard Load Balancer no se cobra por hora.

ExpressRoute

En esta arquitectura, ExpressRoute es el servicio de redes que se usa para crear conexiones privadas entre una red local y redes virtuales de Azure.

Toda la transferencia de datos entrantes es gratuita. Toda la transferencia de datos de salida se cobra en función de una tasa predeterminada. Para más información, consulte Precios de Azure ExpressRoute.

Comunidades

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

Colaboradores

Microsoft mantiene este artículo. Originalmente lo escribió el siguiente colaborador.

Autor principal:

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

Pasos siguientes

Consulte los artículos siguientes para obtener más información y ejemplos de cargas de trabajo de SAP en las que se usan algunas de las mismas tecnologías que en esta arquitectura: