Planificación e implementación una implementación de SAP en Azure

En Azure, las organizaciones pueden obtener los recursos y servicios en la nube que necesitan sin tener que completar un largo ciclo de adquisición. Sin embargo, la ejecución de una carga de trabajo de SAP en Azure requiere conocimientos sobre las opciones disponibles y un planeamiento cuidadoso para elegir los componentes y la arquitectura de Azure que permita impulsar la solución.

Azure ofrece una plataforma completa para ejecutar las aplicaciones de SAP. Las ofertas de infraestructura como servicio (IaaS) y plataforma como servicio (PaaS) de Azure se combinan para ofrecer opciones óptimas para una implementación satisfactoria de todo el panorama empresarial de SAP.

En este artículo se complementa la documentación y las notas de SAP, las principales fuentes de información sobre cómo instalar e implementar software de SAP en Azure y otras plataformas.

Definiciones

A lo largo de este artículo, se usan los siguientes términos:

• Componente de SAP: una aplicación de SAP individual, como SAP S/4HANA, SAP ECC, SAP BW, o SAP Solution Manager. Un componente de SAP se puede basar en tecnologías tradicionales de programación de aplicaciones empresariales avanzadas (ABAP) o en Java, o bien puede ser una aplicación que no esté basada en SAP NetWeaver, como SAP BusinessObjects.
• Entorno de SAP: varios componentes de SAP agrupados lógicamente para desempeñar una función empresarial, como desarrollo, control de calidad, entrenamiento, recuperación ante desastres o producción.
• Entorno de SAP: todo el conjunto de recursos de SAP en el entorno de TI de una organización. La infraestructura de SAP incluye todos los entornos, tanto los que son de producción como los que no.
• Sistema SAP: combinación de una capa de sistema de administración de bases de datos (DBMS) y una capa de aplicación. Dos ejemplos son un sistema de desarrollo de SAP ERP y un sistema de prueba de SAP BW. En una implementación de Azure, estas dos capas no se pueden distribuir entre el entorno local y Azure. Un sistema SAP debe implementarse de forma local o en Azure, pero no en ambos. Sin embargo, puede operar diferentes sistemas de un entorno de SAP en Azure o de forma local.

Recursos

El punto de entrada de documentación que describe cómo hospedar y ejecutar una carga de trabajo de SAP en Azure es Introducción a SAP en una máquina virtual de Azure. En el artículo encontrará vínculos a otros artículos que incluyen información sobre:

• Detalles de la carga de trabajo de SAP para las opciones de almacenamiento, redes y soporte técnico.
• Guías de DBMS para SAP para varios sistemas DBMS en Azure.
• Guías de implementación de SAP, tanto manual como automatizada.
• Información de alta disponibilidad y recuperación ante desastres para una carga de trabajo de SAP en Azure.
• Integración de SAP en Azure con otros servicios y aplicaciones de terceros.

Importante

Para conocer los requisitos previos, el proceso de instalación y los detalles sobre la funcionalidad específica de SAP, es importante leer cuidadosamente la documentación y las guías de SAP. En este artículo solo se tratan tareas específicas para el software de SAP instalado y operado en una máquina virtual de Azure.

Las siguientes notas de SAP forman la base de la guía de Azure para las implementaciones de SAP:

Número de nota	Título
1928533	SAP Applications on Azure: Supported Products and Sizing (Aplicaciones de SAP en Microsoft Azure con Base de datos de Oracle: versiones y tamaños compatibles)
2015553	SAP en Azure: Requisitos previos de soporte técnico
2039619	Aplicaciones de SAP en Azure que usan Oracle Database
2233094	DB6: Aplicaciones de SAP en Azure que usan IBM Db2 para Linux, UNIX y Windows
1999351	Troubleshooting Enhanced Azure Monitoring for SAP (Solución de problemas de la supervisión mejorada de Azure para SAP)
1409604	Virtualization on Windows: Enhanced Monitoring (Virtualización en Windows: supervisión mejorada)
2191498	SAP on Linux with Azure: Enhanced Monitoring (Virtualización en Windows: supervisión mejorada)
2731110	Compatibilidad con aplicaciones virtuales de red (NVA) para SAP en Azure

Para conocer las limitaciones predeterminadas generales y las limitaciones máximas de las suscripciones y recursos de Azure, consulte Límites, cuotas y restricciones de suscripción y servicios de Microsoft Azure.

Escenarios

A menudo, los servicios de SAP se consideran entre las aplicaciones más importantes de una empresa. La arquitectura y las operaciones de las aplicaciones son complejas y es importante asegurarse de que se cumplen todos los requisitos de disponibilidad y rendimiento. Normalmente, una empresa piensa detenidamente en qué proveedor de servicios en la nube debe elegir para ejecutar estos procesos empresariales críticos para la empresa.

Azure es la plataforma de nube pública ideal para aplicaciones SAP críticas para la empresa y los procesos empresariales. La mayoría del software SAP actual, incluidos los sistemas SAP NetWeaver y SAP S/4HANA, se pueden hospedar en la infraestructura de Azure en la actualidad. Azure ofrece más de 800 tipos de CPU y máquinas virtuales que tienen muchos terabytes de memoria.

Para obtener descripciones de escenarios admitidos y algunos escenarios que no se admiten, consulte Escenarios admitidos con máquinas virtuales de SAP en Azure. Consulte estos escenarios y las condiciones que se indican como no admitidas a medida que planee la arquitectura que desea implementar en Azure.

Para implementar correctamente sistemas SAP en una IaaS general o en la de Azure, es importante conocer las diferencias significativas entre las ofertas de las nubes privadas tradicionales y las ofertas de IaaS. Un host o outsourcer tradicional adapta la infraestructura (red, almacenamiento y tipo de servidor) a la carga de trabajo que un cliente quiere hospedar. En una implementación de IaaS, es responsabilidad del cliente o del asociado evaluar su carga de trabajo potencial y elegir los componentes correctos de Azure de máquinas virtuales, almacenamiento y red.

Para recopilar datos para planear la implementación en Azure, es importante:

• Determinar qué productos y versiones de SAP se admiten en Azure.
• Evaluar si las versiones del sistema operativo que planea usar son compatibles con las máquinas virtuales de Azure que elegiría para los productos de SAP.
• Determinar qué versiones de DBMS se admiten en máquinas virtuales específicas para los productos de SAP.
• Evaluar si es necesario actualizar el entorno de SAP para que esté en consonancia con las versiones necesarias del sistema operativo y de DBMS para lograr una configuración admitida.
• Evaluar si necesita cambiar a sistemas operativos distintos para la implementación en Azure.

En ¿Qué software de SAP es compatible con las implementaciones de Azure? se explican los detalles de los componentes de SAP admitidos en Azure, las unidades de infraestructura de Azure compatibles y las versiones de los sistemas operativos y de DBMS relacionadas. El conocimiento que obtiene de evaluar la compatibilidad y las dependencias entre las versiones de SAP, las versiones del sistema operativo y las versiones de DBMS tiene un impacto considerable en sus esfuerzos para trasladar los sistemas SAP a Azure. Sabrá si es necesario realizar importantes preparativos, por ejemplo, si tiene que actualizar su versión de SAP o cambiar a un sistema operativo diferente.

Primeros pasos para planear una implementación

El primer paso en el planeamiento de la implementación no es buscar máquinas virtuales que estén disponibles para ejecutar aplicaciones de SAP.

Los primeros pasos para planear una implementación consisten en trabajar con los equipos de cumplimiento y seguridad de su organización para determinar cuáles son las condiciones límite para implementar cada tipo de carga de trabajo de SAP o proceso empresarial en una nube pública. El proceso puede llevar mucho tiempo, pero es fundamental que se lleve a cabo.

Si su organización ya ha implementado software en Azure, es posible que el proceso sea fácil. Sin embargo, si la empresa se encuentra al principio del recorrido, puede que se necesite un mayor análisis para averiguar las condiciones límite, las condiciones de seguridad y la arquitectura empresarial que permiten hospedar determinados datos de SAP y procesos empresariales de SAP en una nube pública.

Planeación del cumplimiento

Para obtener una lista de las ofertas de cumplimiento de Microsoft que pueden ayudarle a planear sus necesidades de cumplimiento, consulte Ofertas de cumplimiento de Microsoft.

Planear la seguridad

Para obtener información sobre los problemas de seguridad específicos de SAP, como el cifrado de datos para datos en reposo u otro cifrado de un servicio de Azure, consulte Introducción al cifrado de Azure y Seguridad del entorno de SAP.

Organización de recursos de Azure

Junto con la revisión de seguridad y cumplimiento, si aún no ha realizado esta tarea, planee cómo organizar los recursos de Azure. El proceso incluye tomar decisiones sobre:

• Convención de nomenclatura que usará para cada recurso de Azure, como las máquinas virtuales y los grupos de recursos.
• Un diseño de grupo de administración y suscripción para la carga de trabajo de SAP que incluya, por ejemplo, si se deben crear varias suscripciones por carga de trabajo, por nivel de implementación o para cada unidad de negocio.
• Uso en toda la empresa de Azure Policy para las suscripciones y grupos de administración.

Para ayudarle a tomar las decisiones correctas, se describen muchos detalles de la arquitectura empresarial en Cloud Adoption Framework para Azure.

No subestime esta fase inicial del proyecto en el planeamiento. Solo cuando tenga acuerdos y reglas en vigor sobre cumplimiento, seguridad y organización de recursos de Azure, deberá avanzar en el planeamiento de la implementación.

Los pasos siguientes son planear la ubicación geográfica y la arquitectura de red que va a implementar en Azure.

Zonas geográficas y regiones de Azure

Los servicios de Azure están disponibles en regiones de Azure independientes. Una región de Azure es una colección de centros de datos. Los centros de datos contienen el hardware y la infraestructura que permiten hospedar y ejecutar los servicios de Azure que están disponibles en la región. Esta infraestructura incluye un gran número de nodos que funcionan como nodos de proceso o de almacenamiento, o que ejecutan funcionalidades de red.

Para obtener una lista de regiones de Azure, consulte Zonas geográficas de Azure. Para obtener un mapa interactivo, consulte Infraestructura global de Azure.

No todas las regiones de Azure ofrecen los mismos servicios. Según el producto de SAP que quiera ejecutar, los requisitos de dimensionamiento y el sistema operativo y DBMS que necesite, es posible que una región determinada no ofrezca los tipos de máquina virtual necesarios para su caso. Por ejemplo, si ejecuta SAP HANA, normalmente necesita máquinas virtuales de las distintas familias de máquinas virtuales de la serie M. Estas familias de máquinas virtuales solo se implementan en un subconjunto de regiones de Azure.

A medida que empiece a planear y pensar en qué regiones elegir como región primaria y cuáles como región secundaria, tendrá que investigar si los servicios que necesita para sus escenarios están disponibles en las regiones que está considerando. Puede conocer exactamente qué tipos de máquina virtual, tipos de almacenamiento de Azure y otros servicios de Azure están disponibles en cada región en Productos disponibles por región.

Regiones emparejadas de Azure

En una región emparejada de Azure, la replicación de determinados datos está habilitada de forma predeterminada entre las dos regiones. Para obtener más información, consulte Replicación entre regiones en Azure: continuidad empresarial y recuperación ante desastres.

La replicación de datos en un par de regiones está vinculada a los tipos de almacenamiento de Azure que puede configurar para replicarse en una región emparejada. Para más información, consulte Redundancia de almacenamiento en una región secundaria.

Los tipos de almacenamiento que admiten la replicación de datos con una región emparejada son tipos de almacenamiento que no son adecuados para los componentes de SAP y una carga de trabajo de DBMS. La facilidad de uso de la replicación de Azure Storage se limita a Azure Blob Storage (con fines de copia de seguridad), al uso compartido de archivos y volúmenes, y a otros escenarios de almacenamiento de alta latencia.

Cuando consulte las regiones emparejadas y los servicios que desea utilizar en sus regiones primaria o secundaria, es posible que los servicios de Azure o los tipos de máquinas virtuales que pretende utilizar en su región primaria no estén disponibles en la región emparejada que desea utilizar como región secundaria. O bien, puede determinar que una región emparejada de Azure no es aceptable para su escenario debido a motivos de cumplimiento de datos. Para esos escenarios, tiene que usar una región no emparejada como región secundaria o de recuperación ante desastres, y que configurar parte de la replicación de datos por sí mismo.

Zonas de disponibilidad

Muchas regiones de Azure usan zonas de disponibilidad para separar físicamente ubicaciones dentro de una región de Azure. Cada zona de disponibilidad consta de uno o varios centros de datos equipados con alimentación, refrigeración y redes independientes. Un ejemplo del uso de una zona de disponibilidad para mejorar la resistencia consiste en implementar dos máquinas virtuales en dos zonas de disponibilidad independientes en Azure. Otro ejemplo es implementar un marco de alta disponibilidad para el sistema DBMS de SAP en una zona de disponibilidad e implementar SAP (A)SCS en la otra, con lo que obtendrá el mejor Acuerdo de Nivel de Servicio de Azure.

Para más información sobre los Acuerdos de Nivel de servicio de máquinas virtuales de Azure, consulte la última versión de los Acuerdos de Nivel de Servicio de máquinas virtuales. Dado que las regiones de Azure se desarrollan y amplían rápidamente, la topología de las regiones de Azure, el número de centros de datos físicos, la distancia entre estos y la distancia entre las zonas de disponibilidad de Azure evoluciona. La latencia de red cambia a medida que cambia la infraestructura.

Siga las instrucciones que se indican en Configuraciones de cargas de trabajo de SAP con Azure Availability Zones cuando elija una región que tenga zonas de disponibilidad. Determine también qué modelo de implementación zonal es más adecuado para sus requisitos, la región que elija y la carga de trabajo.

Dominios de error

Los dominios de error representan una unidad física de error. Un dominio de error está estrechamente relacionado con la infraestructura física contenida en los centros de datos. Aunque una hoja física o un bastidor se pueden considerar un dominio de error, no hay una asignación directa uno a uno entre un elemento informático físico y un dominio de error.

Cuando implementa varias máquinas virtuales como parte de un sistema SAP, puede influir indirectamente en el controlador de tejido de Azure para que implemente las máquinas virtuales en distintos dominios de error, de modo que pueda cumplir los requisitos de los SLA sobre disponibilidad. Sin embargo, no tiene control directo de la distribución de los dominios de error en una unidad de escalado de Azure (una colección de cientos de nodos de proceso o nodos de almacenamiento y redes) ni de la asignación de máquinas virtuales a un dominio de error específico. Para ordenar al controlador de tejido de Azure que implemente un conjunto de máquinas virtuales en diferentes dominios de error, tiene que asignar un conjunto de disponibilidad de Azure a las máquinas virtuales en el momento de la implementación. Para más información, consulte Conjuntos de disponibilidad.

Dominios de actualización

Los dominios de actualización representan una unidad lógica que establece cómo se actualiza una máquina virtual de un sistema SAP que consta de varias máquinas virtuales. Cuando se produce una actualización de la plataforma, Azure pasa por el proceso de actualización de estos dominios uno a uno. Al distribuir las máquinas virtuales en el momento de la implementación en diferentes dominios de actualización, se puede proteger el sistema SAP frente a posibles tiempos de inactividad. De un modo similar a los dominios de error, una unidad de escalado de Azure se divide en varios dominios de actualización. Para ordenar al controlador de tejido de Azure que implemente un conjunto de máquinas virtuales en diferentes dominios de actualización, tiene que asignar un conjunto de disponibilidad de Azure a las máquinas virtuales en el momento de la implementación. Para más información, consulte Conjuntos de disponibilidad.

Conjuntos de disponibilidad

El controlador de tejido de Azure distribuye las instancias de Azure Virtual Machines de un conjunto de disponibilidad de Azure en diferentes dominios de error. La distribución en diferentes dominios de error pretende impedir que todas las máquinas virtuales de un sistema SAP se apaguen durante un mantenimiento de la infraestructura o si se produce un error en un dominio de error. De manera predeterminada, las máquinas virtuales no forman parte de un conjunto de disponibilidad. Puede agregar una máquina virtual en un conjunto de disponibilidad solo en el momento de la implementación o cuando se vuelve a implementar una máquina virtual.

Para más información sobre los conjuntos de disponibilidad de Azure y cómo se relacionan estos con los dominios de error, consulte Conjuntos de disponibilidad de Azure.

Importante

Las zonas de disponibilidad y los conjuntos de disponibilidad en Azure son mutuamente excluyentes. Puede implementar varias máquinas virtuales en una zona de disponibilidad específica o en un conjunto de disponibilidad. Pero no se puede asignar tanto la zona de disponibilidad como el conjunto de disponibilidad a una máquina virtual.

Puede combinar conjuntos de disponibilidad y zonas de disponibilidad si usa grupos con ubicación por proximidad.

A medida que se definan los conjuntos de disponibilidad y se intenten combinar varias máquinas virtuales de distintas familias en un mismo conjunto de disponibilidad, es posible que se produzcan problemas que impidan incluir un determinado tipo de máquina virtual en un conjunto de disponibilidad. El motivo es que el conjunto de disponibilidad está enlazado a una unidad de escalado que contiene un tipo específico de hosts de proceso. Un tipo específico de host de proceso solo se puede ejecutar en determinados tipos de familias de máquinas virtuales.

Por ejemplo, cree un conjunto de disponibilidad e implemente en él la primera máquina virtual. La primera máquina virtual que agrega al conjunto de disponibilidad es de la familia de máquinas virtuales Edsv5. Al intentar implementar una segunda máquina virtual, que es de la familia M, se produce un error en la implementación. El motivo es que las máquinas virtuales de la familia Edsv5 no se ejecutan en el mismo hardware del host que las máquinas virtuales de la familia M.

Se puede producir el mismo problema si cambia el tamaño de las máquinas virtuales. Si intenta mover una máquina virtual de la familia Edsv5 a un tipo de máquina virtual de la familia M, se producirá un error en la implementación. Si se cambia el tamaño al de una familia de máquinas virtuales que no se puede hospedar en el mismo hardware del host, deberá apagar todas las máquinas virtuales del conjunto de disponibilidad y cambiarlas de tamaño para que puedan ejecutarse en el otro tipo de equipo host. Para obtener información sobre los Acuerdos de Nivel de Servicio de las máquinas virtuales que se implementan en un conjunto de disponibilidad, consulte Acuerdos de Nivel de Servicio de máquinas virtuales.

Conjuntos de escalado de máquinas virtuales con orquestación flexible

Los conjuntos de escalado de máquinas virtuales con orquestación flexible proporcionan una agrupación lógica de máquinas virtuales administradas por una plataforma. Tiene la opción de crear un conjunto de escalado dentro una región o de distribuirlo entre zonas de disponibilidad. Al crea el conjunto de escalado flexible dentro de una región con platformFaultDomainCount>1 (FD>1), las máquinas virtuales implementadas en el conjunto de escalado se distribuirían entre el número especificado de dominios de error de la misma región. Por otro lado, la creación de un conjunto de escalado flexible entre zonas de disponibilidad con platformFaultDomainCount=1 (FD=1) distribuiría las máquinas virtuales en la zona especificada y el conjunto de escalado también distribuiría las máquinas virtuales entre diferentes dominios de error dentro de la zona de la mejor manera posible.

Con las cargas de trabajo de SAP, solo se admite el conjunto de escalado flexible con FD=1. La ventaja de usar conjuntos de escalado flexibles con FD=1 para la implementación entre zonas, en lugar de la implementación tradicional de zonas de disponibilidad, es que las máquinas virtuales implementadas con el conjunto de escalado se distribuirían entre dominios de error diferentes dentro de la zona de la mejor manera posible. Para más información sobre la implementación de cargas de trabajo de SAP con un conjunto de escalado, consulte la guía de implementación de conjuntos de escalado de máquinas virtuales flexibles.

Cuando implementa una carga de trabajo de SAP de alta disponibilidad en Azure, es importante tener en cuenta los distintos tipos de implementación disponibles y cómo se pueden aplicar en diferentes regiones de Azure (como, por ejemplo, entre zonas, en una sola zona o en una región sin zonas). Para más información, consulte Opciones de implementación de alta disponibilidad para cargas de trabajo de SAP.

Sugerencia

Actualmente, no hay ninguna manera directa de migrar cargas de trabajo de SAP implementadas en conjuntos de disponibilidad o zonas de disponibilidad a un conjunto de escalado flexible con FD=1. Para realizar el cambio, tiene que volver a crear la máquina virtual y el disco con restricciones de zona a partir de los recursos existentes. Un proyecto de código abierto incluye funciones de PowerShell que puede usar como ejemplo para cambiar una máquina virtual implementada en un conjunto de disponibilidad o zona de disponibilidad a un conjunto de escalado flexible con FD=1. Una entrada de blog muestra cómo modificar un sistema SAP, de alta disponibilidad o no, implementado en un conjunto de disponibilidad o una zona de disponibilidad para cambiarlo a un conjunto de escalado flexible con FD=1.

Grupos con ubicación por proximidad

La latencia de red entre máquinas virtuales de SAP individuales puede tener implicaciones significativas para el rendimiento. El tiempo de un ciclo de ida y vuelta de red entre los servidores de aplicaciones de SAP y DBMS, especialmente, puede tener un impacto significativo en las aplicaciones empresariales. Idealmente, todos los elementos de proceso que ejecutan las máquinas virtuales de SAP se encuentran lo más cerca posible. Esta opción no es posible en todas las combinaciones y puede que Azure no sepa qué máquinas virtuales mantener juntas. En la mayoría de las situaciones y regiones, la ubicación predeterminada cumple los requisitos de latencia de un ciclo de ida y vuelta de red.

Cuando la ubicación predeterminada no cumple los requisitos de ciclo de ida y vuelta de red dentro de un sistema SAP, los grupos con ubicación por proximidad pueden dar una solución a esta necesidad. Puede usar grupos con ubicación por proximidad con las restricciones de ubicación de la región de Azure, la zona de disponibilidad y el conjunto de disponibilidad para aumentar la resistencia. Con un grupo con ubicación por proximidad, es posible combinar la zona de disponibilidad y el conjunto de disponibilidad, al tiempo que establece diferentes dominios de actualización y error. Un grupo con ubicación por proximidad debe contener solo un único sistema SAP.

Aunque la implementación en un grupo con ubicación por proximidad puede dar lugar a una ubicación optimizada para la latencia, este tipo de implementación también tiene inconvenientes. Algunas familias de máquinas virtuales no se pueden combinar en un grupo con ubicación por proximidad, ya que podría tener problemas si cambia el tamaño entre familias de máquinas virtuales. Es posible que las restricciones de las familias de máquinas virtuales, las regiones y las zonas de disponibilidad no admitan la coubicación. Para obtener más información y conocer las ventajas y los posibles desafíos del uso de un grupo con ubicación por proximidad, consulte Escenarios de grupos con ubicación por proximidad.

Las máquinas virtuales que no usan grupos con ubicación por proximidad deben constituir el método de implementación predeterminado en la mayoría de las situaciones para los sistemas SAP. Este valor predeterminado es especialmente importante para las implementaciones zonales (una sola zona de disponibilidad) y entre zonas (máquinas virtuales que están distribuidas entre dos zonas de disponibilidad) de un sistema SAP. El uso de grupos con ubicación por proximidad debe limitarse a los sistemas SAP y las regiones de Azure cuando sea necesario solo por motivos de rendimiento.

Redes de Azure

Azure dispone de una infraestructura de red que se adapta a todos los escenarios que podría desear implementar una implementación SAP. En Azure, tiene las siguientes funcionalidades:

• Acceso a servicios de Azure y a puertos específicos en máquinas virtuales que usan las aplicaciones.
• Acceso directo a las máquinas virtuales a través de Secure Shell (SSH) o Escritorio remoto de Windows para la administración.
• Comunicación interna y resolución de nombres entre máquinas virtuales y servicios de Azure.
• Conectividad local entre una red local y las redes de Azure.
• Comunicación entre servicios implementados en diferentes regiones de Azure.

Para obtener información detallada sobre las redes, consulte Azure Virtual Network.

El diseño de redes suele ser la primera actividad técnica que se realiza al efectuar la implementación en Azure. Admitir una arquitectura empresarial central como SAP con frecuencia forma parte de los requisitos generales de red. En la fase de planeación, debe documentar la arquitectura de red propuesta con el máximo detalle posible. Si realiza un cambio más adelante, como cambiar una dirección de red de subred, es posible que tenga que mover o eliminar recursos implementados.

Redes virtuales de Azure

Una red virtual es un bloque de creación básico de la red privada en Azure. Puede definir el intervalo de direcciones de la red y separar el intervalo en subredes de red. Una subred de red puede estar disponible para que una máquina virtual de SAP la use o se pueda dedicar a un servicio o propósito específico. Algunos servicios de Azure, como Azure Virtual Network y Azure Application Gateway, requieren una subred dedicada.

Una red virtual actúa como límite de red. Parte del diseño que se necesita al planear la implementación consiste en definir la red virtual, las subredes y los intervalos de direcciones de la red privada. No se puede cambiar la asignación de red virtual para recursos como tarjetas de interfaz de red (NIC) de máquinas virtuales una vez que estas se implementan. Realizar un cambio en una red virtual o en un intervalo de direcciones de subred puede requerir mover todos los recursos implementados a una subred diferente.

El diseño de red debe tener en cuenta varios requisitos para la implementación de SAP:

• No hay aplicaciones virtuales de red, como un firewall, en la ruta de comunicación entre la aplicación SAP y la capa de DBMS de los productos de SAP a través del kernel de SAP, como S/4HANA o SAP NetWeaver.
• Los grupos de seguridad de red aplican restricciones de enrutamiento de red en el nivel de subred. Agrupe las direcciones IP de las máquinas virtuales en grupos de seguridad de aplicaciones (ASG) que se mantengan en las reglas de NSG y proporcione agrupaciones de roles, niveles y SID de permisos.
• Las máquinas virtuales de aplicaciones y bases de datos de SAP se ejecutan en la misma red virtual, dentro de la misma subred o en subredes diferentes de una sola red virtual. Use subredes diferentes para las máquinas virtuales de aplicaciones y las de bases de datos. O bien, use ASG de DBMS y una aplicación dedicada para agrupar reglas que sean aplicables a cada tipo de carga de trabajo dentro de la misma subred.
• Las redes aceleradas están habilitadas en todas las tarjetas de red de todas las máquinas virtuales para cargas de trabajo de SAP siempre que es técnicamente posible.
• Garantice el acceso seguro para la dependencia de los servicios centrales, incluida la resolución de nombres (DNS), la administración de identidades (dominios de Windows Server Active Directory o Microsoft Entra ID) y el acceso administrativo.
• Proporcione acceso a los puntos de conexión públicos y por medio de estos según sea necesario. Algunos ejemplos son la administración de Azure para las operaciones de ClusterLabs Pacemaker en alta disponibilidad o para servicios de Azure como Azure Backup.
• Use varias NIC solo si son necesarias para crear subredes designadas que tengan sus propias rutas y reglas de NSG.

Para obtener ejemplos de arquitectura de red para la implementación de SAP, consulte los siguientes artículos:

• SAP S/4HANA en Linux en Azure
• SAP NetWeaver en Windows en Azure
• Conexiones entrantes y salientes de Internet de SAP en Azure

Consideraciones sobre la red virtual

Algunas configuraciones de red virtual tienen consideraciones específicas a tener en cuenta.

• La configuración de aplicaciones virtuales de red en la ruta de comunicación entre el nivel de aplicación de SAP y la capa de DBMS de los componentes de SAP mediante el kernel de SAP, como S/4HANA o SAP NetWeaver, no se admite.

  Las aplicaciones virtuales de red de las rutas de comunicación pueden duplicar fácilmente la latencia de red entre dos asociados de comunicación. También pueden restringir el rendimiento en las rutas críticas entre la capa de aplicación de SAP y la capa de DBMS. En algunos escenarios, las aplicaciones virtuales de red pueden provocar un error en los clústeres de Linux de Pacemaker.

  La ruta de comunicación entre la capa de aplicación de SAP y la capa de DBMS debe ser directa. La restricción no incluye reglas de ASG y NSG si estas permiten una ruta de comunicación directa.

  Otros escenarios en los que no se admiten aplicaciones virtuales de red son:

  • Rutas de comunicación entre las máquinas virtuales de Azure que representan los nodos de clúster de Linux para Pacemaker y los dispositivos SBD, como se indica en Alta disponibilidad para SAP NetWeaver en máquinas virtuales de Azure en SUSE Linux Enterprise Server para SAP Applications.
  • Rutas de comunicación entre máquinas virtuales de Azure y un recurso compartido de archivos de escalabilidad horizontal de Windows Server configuradas como se describe en Agrupación de una instancia de ASCS/SCS de SAP en un clúster de conmutación por error de Windows con un recurso compartido de archivos en Azure.

• La separación de la capa de aplicación de SAP y la capa de DBMS en diferentes redes virtuales de Azure no se admite. Se recomienda separar la capa de aplicación de SAP y la capa de DBMS mediante subredes dentro de la misma red virtual de Azure, en lugar de usar diferentes redes virtuales de Azure.

  Si configura un escenario no admitido que separa dos capas del sistema SAP en redes virtuales diferentes, las dos redes virtuales deben estar emparejadas.

  El tráfico entre dos redes virtuales de Azure emparejadas está sujeto a costos de transferencia. A diario, un enorme volumen de datos de muchos terabytes se intercambia entre la capa de aplicación de SAP y la capa de DBMS. Puede incurrir en costos sustanciales si la capa de aplicación de SAP y la capa de DBMS se separan entre dos redes virtuales de Azure emparejadas.

Resolución de nombres y servicios de dominio

La resolución del nombre de host en la dirección IP mediante DNS suele ser un elemento fundamental para las redes de SAP. Tiene muchas opciones para configurar la resolución de nombres e IP en Azure.

A menudo, una empresa tiene una solución DNS central que forma parte de la arquitectura general. Hay varias opciones para implementar la resolución de nombres en Azure de forma nativa, en lugar de configurar sus propios servidores DNS, y estas se describen en Resolución de nombres de recursos en redes virtuales de Azure.

Al igual que con los servicios DNS, puede haber un requisito para que Windows Server Active Directory sea accesible para las máquinas virtuales o los servicios de SAP.

Asignación de dirección IP

Una dirección IP de una NIC permanece reclamada y usada durante la existencia de la NIC de una máquina virtual. La regla se aplica a la asignación de IP dinámicas y estáticas. Esto sigue siendo así tanto si la máquina virtual se está ejecutando como si está apagada. La asignación de IP dinámica se efectúa si se elimina la NIC, si cambia la subred o si el método de asignación cambia a estático.

Se pueden asignar direcciones IP fijas a las máquinas virtuales de una red virtual de Azure. Las direcciones IP suelen reasignarse para los sistemas SAP que dependen de servidores DNS externos y entradas estáticas. La dirección IP permanece asignada hasta que la máquina virtual y su NIC se eliminen o hasta que la asignación de la dirección IP se anule. Tiene que tener en cuenta el número total de máquinas virtuales (en ejecución y detenidas) al definir el intervalo de direcciones IP de la red virtual.

Para más información, consulte Creación de una máquina virtual que tenga una dirección IP privada estática.

Nota:

Debe decidir entre la asignación de direcciones IP estáticas y dinámicas para las máquinas virtuales de Azure y sus NIC. El sistema operativo invitado de la máquina virtual obtendrá la dirección IP asignada a la NIC cuando se inicie la máquina virtual. No debe asignar direcciones IP estáticas en el sistema operativo invitado a una NIC. Algunos servicios de Azure como Azure Backup se basan en el hecho de que al menos la NIC principal está establecida en DHCP y no en direcciones IP estáticas dentro del sistema operativo. Para más información, consulte Solución de problemas de copia de seguridad de máquinas virtuales de Azure.

Direcciones IP secundarias para la virtualización del nombre de host de SAP

La NIC de cada máquina virtual de Azure puede tener asignadas varias direcciones IP. Se puede usar una dirección IP secundaria para un nombre de host virtual de SAP, que se asigna a un registro D o un registro PTR de DNS. Se debe asignar una dirección IP secundaria a la configuración de IP de la NIC de Azure. Una dirección IP secundaria también debe configurarse dentro del sistema operativo estáticamente ya que las direcciones IP secundarias no se asignan normalmente a través de DHCP. Cada dirección IP secundaria debe ser de la misma subred a la que está enlazada la NIC. Una dirección IP secundaria se puede agregar o eliminar de una NIC de Azure sin necesidad de detener ni desasignar la máquina virtual. Para agregar o eliminar la dirección IP principal de una NIC, la máquina virtual debe desasignarse.

Las arquitecturas de alta disponibilidad de SAP usan Azure Load Balancer con clústeres de Pacemaker. En este escenario, el equilibrador de carga habilita los nombres de host virtuales de SAP. Para obtener instrucciones generales sobre el uso de nombres de host virtuales, consulte la nota de SAP 962955.

Azure Load Balancer con máquinas virtuales que ejecutan SAP

Normalmente, un equilibrador de carga se usa en arquitecturas de alta disponibilidad para proporcionar direcciones IP flotantes entre los nodos de clúster activos y pasivos. También puede usar un equilibrador de carga para una sola máquina virtual para mantener una dirección IP virtual para un nombre de host virtual de SAP. El uso de un equilibrador de carga para una sola máquina virtual es una alternativa al uso de una dirección IP secundaria en una NIC o al uso de varias NIC en la misma subred.

Standard Load Balancer modifica la ruta de acceso de salida predeterminada porque su arquitectura es segura de manera predeterminada. Es posible que las máquinas virtuales que están detrás de una instancia de Standard Load Balancer ya no puedan alcanzar los mismos puntos de conexión públicos. Algunos ejemplos son un punto de conexión de un repositorio de actualizaciones del sistema operativo o un punto de conexión público de los servicios de Azure. Para obtener opciones para proporcionar conectividad de salida, consulte Conectividad de punto de conexión público para máquinas virtuales mediante Azure Standard Load Balancer.

Sugerencia

Basic Load Balancer no debe usarse con ninguna arquitectura de SAP en Azure. Basic Load Balancer está programado para su retirada.

Varias NIC virtuales por máquina virtual

Puede definir varias tarjetas de interfaz de red virtuales (vNIC) para una máquina virtual de Azure, y asignar cada una de ellas a cualquier subred de la misma red virtual que la vNIC principal. Con la posibilidad de tener varias NIC virtuales, puede empezar a configurar la separación del tráfico de red, si es necesario. Por ejemplo, el tráfico de cliente se enruta a través de la vNIC principal y algo del tráfico de administrador o back-end se enruta a través de una segunda vNIC. Según el sistema operativo y la imagen que use, es posible que sea necesario configurar las rutas de tráfico de las NIC dentro del sistema operativo para un enrutamiento correcto.

El tipo y el tamaño de una máquina virtual determinan cuántas NIC virtuales puede tener asignadas. Para más información sobre la funcionalidad y las restricciones, consulte Asignación de varias direcciones IP a máquinas virtuales mediante Azure Portal.

Agregar NIC virtuales a una máquina virtual no aumenta el ancho de banda de red disponible. Todas las interfaces de red comparten el mismo ancho de banda. Se recomienda usar varias NIC solo si las máquinas virtuales necesitan acceder a subredes privadas. Se recomienda un patrón de diseño que se basa en la funcionalidad del grupo de seguridad de red y que simplifica los requisitos de red y subred. El diseño debe usar la menor cantidad posible de interfaces de red e, idealmente, usar solo una. Una excepción es la escalabilidad horizontal de HANA, en la que se requiere una NIC virtual secundaria para la red interna de HANA.

Advertencia

Si usa varias NIC virtuales en una máquina virtual, se recomienda usar la subred de una NIC principal para controlar el tráfico de red de usuario.

Redes aceleradas

Para reducir aún más la latencia de red entre máquinas virtuales de Azure, se recomienda confirmar que las redes aceleradas de Azure están habilitadas en cada máquina virtual que ejecuta una carga de trabajo de SAP. Aunque las redes aceleradas estén habilitadas de manera predeterminada para las nuevas máquinas virtuales, según la lista de comprobación de la implementación, debe comprobar su estado. Las ventajas de las redes aceleradas son unos rendimientos y latencias de red considerablemente mejores. Use esta opción al implementar máquinas virtuales de Azure para cargas de trabajo de SAP en todas las máquinas virtuales admitidas, especialmente para la capa de aplicación de SAP y la capa de DBMS de SAP. La documentación vinculada contiene dependencias de compatibilidad sobre las versiones del sistema operativo y las instancias de máquina virtual.

Conectividad local

La implementación de SAP en Azure supone que hay una arquitectura de red y un centro de comunicación centrales y para toda la empresa, que permite habilitar la conectividad local. La conectividad de red local es esencial para permitir que los usuarios y las aplicaciones accedan al entorno de SAP en Azure para acceder a otros servicios centrales de la organización, como el DNS, el dominio y la infraestructura de administración de seguridad y revisiones centrales.

Tiene muchas opciones para proporcionar conectividad local para la implementación de SAP en Azure. La implementación de red suele ser una topología de red en estrella tipo hub-and-spoke o una extensión de esta, una instancia de Virtual WAN global.

En el caso de las implementaciones de SAP locales, se recomienda usar una conexión privada a través de Azure ExpressRoute. Para cargas de trabajo de SAP más pequeñas, regiones remotas u oficinas más pequeñas, la conectividad local de VPN está disponible. El uso de ExpressRoute con una VPN de sitio a sitio como ruta de acceso de conmutación por error es una posible combinación de ambos servicios.

Conectividad de Internet entrante y saliente

El entorno de SAP requiere conectividad a Internet, ya sea para recibir actualizaciones del repositorio del sistema operativo, para establecer una conexión con las aplicaciones SaaS de SAP en sus puntos de conexión públicos o para acceder a un servicio de Azure mediante su punto de conexión público. Del mismo modo, es posible que tenga que proporcionar acceso a los clientes a aplicaciones de SAP Fiori, con usuarios de Internet que acceden a los servicios que proporciona el entorno de SAP. La arquitectura de red de SAP requiere que planee la ruta de acceso hacia Internet y para todas las solicitudes entrantes.

Proteja la red virtual con reglas de NSG, mediante etiquetas de servicio de red para los servicios conocidos y estableciendo el enrutamiento y el direccionamiento IP hacia el firewall u otra aplicación virtual de red. Todas estas tareas o consideraciones forman parte de la arquitectura. Los recursos de las redes privadas deben protegerse mediante firewalls de nivel 4 y 7 de red.

Las rutas de comunicación con Internet son el foco de una arquitectura de procedimientos recomendados.

Máquinas virtuales de Azure para cargas de trabajo de SAP

Algunas familias de máquinas virtuales de Azure son especialmente adecuadas para cargas de trabajo de SAP y algunas más concretamente para una carga de trabajo de SAP HANA. La forma de encontrar el tipo de máquina virtual correcto y su capacidad para respaldar a una carga de trabajo de SAP se describe en ¿Qué software de SAP es compatible con las implementaciones de Azure?. Además, en la nota SAP 1928533 se enumeran todas las máquinas virtuales Azure certificadas y sus capacidades de rendimiento según el banco de pruebas y las limitaciones de SAP Application Performance Standard (SAPS), si se aplican. En los tipos de máquina virtual certificados de una carga de trabajo de SAP no use el sobreaprovisionamiento de los recursos de CPU y de memoria.

Aparte de seleccionar los tipos de máquina virtual admitidos, tiene que comprobar si están disponibles en una región específica según se describe en Productos disponibles por región. Igual de importante es determinar si las siguientes funcionalidades de una máquina virtual se adaptan a su escenario:

• Recursos de CPU y memoria
• Ancho de banda para operaciones de entrada y salida por segundo (IOPS)
• Funcionalidades de red
• Número de discos que se pueden conectar
• Capacidad de usar algunos tipos de almacenamiento de Azure

Para obtener esta información sobre una familia y un tipo de FM específicos, consulte Tamaños de máquinas virtuales en Azure.

Modelos de precios para máquinas virtuales de Azure

Para un modelo de precios de máquina virtual, puede elegir la opción que prefiera usar:

• Un modelo de precios de pago por uso
• Un plan de ahorro o de reservas de un año
• Un plan de ahorro o de reservas de tres años
• Un modelo de precios puntual

Para obtener información detallada sobre los precios de las máquinas virtuales para diferentes servicios de Azure, sistemas operativos y regiones, consulte Precios de máquinas virtuales.

Para más información sobre los precios y la flexibilidad de los planes de ahorro de un año y tres años y las instancias reservadas, consulte estos artículos:

• ¿Qué son los planes de ahorro de Azure para proceso?
• ¿Qué es Azure Reservations?
• Flexibilidad en el tamaño de las máquinas virtuales con Azure Reserved VM Instances
• Aplicación del descuento por reserva de Azure en las máquinas virtuales

Para más información sobre los precios al contado, consulte Azure Spot Virtual Machines.

Los precios de un mismo tipo de máquina virtual pueden variar entre las regiones de Azure. Algunos clientes se benefician de la implementación en una región de Azure más barata, por lo que la información sobre los precios por región puede ser útil durante el planeamiento.

Azure también ofrece la opción de usar un host dedicado. El uso de un host dedicado proporciona más control sobre los ciclos de aplicación de revisiones para los servicios de Azure. Puede programar la aplicación de revisiones para que respalde su propia programación y ciclos. Esta oferta es específica para los clientes que tienen una carga de trabajo que no sigue el ciclo normal de una carga de trabajo. Para más información, consulte Hosts dedicados de Azure.

El uso de un host dedicado de Azure se admite con una carga de trabajo de SAP. Varios clientes de SAP que quieren tener más control sobre los planes de aplicación de revisiones y mantenimiento de la infraestructura usan hosts dedicados de Azure. Para más información sobre cómo Microsoft mantiene y aplica las revisiones de la infraestructura de Azure que hospeda máquinas virtuales, consulte Mantenimiento de máquinas virtuales en Azure.

Sistema operativo de máquinas virtuales

Al implementar nuevas máquinas virtuales para un entorno de SAP en Azure, ya sea para instalar o migrar un sistema SAP, es importante elegir el sistema operativo correcto para la carga de trabajo. Azure ofrece una gran selección de imágenes de sistema operativo para Linux y Windows y muchas opciones adecuadas para sistemas SAP. También puede crear o cargar imágenes personalizadas desde el entorno local, o puede usarlas o generalizarlas a partir de galerías de imágenes.

Para más información sobre las opciones disponibles:

• Busque imágenes de Azure Marketplace mediante la CLI de Azure o Azure PowerShell.
• Cree imágenes personalizadas para Linux o Windows.
• Use Azure VM Image Builder.

Planee una infraestructura de actualización del sistema operativo y sus dependencias para la carga de trabajo de SAP, si es necesario. Considere la posibilidad de usar un entorno de ensayo de repositorio para mantener sincronizados todos los niveles de un entorno de SAP (espacio aislado, desarrollo, preproducción y producción) mediante las mismas versiones de las revisiones y actualizaciones durante el período de actualización.

Máquinas virtuales de generación 1 y generación 2

En Azure, puede implementar una máquina virtual como generación 1 o generación 2. En Compatibilidad con máquinas virtuales de generación 2 en Azure se muestran las familias de máquinas virtuales de Azure que puede implementar como generación 2. En el artículo también se indican las diferencias funcionales entre las máquinas virtuales de la generación 1 y la generación 2 en Azure.

Cuando implementa una máquina virtual, la imagen del sistema operativo que elija determina si la máquina virtual será de generación 1 o de generación 2. Las versiones más recientes de todas las imágenes de sistema operativo para SAP que están disponibles en Azure (Red Hat Enterprise Linux, SuSE Enterprise Linux y Windows u Oracle Enterprise Linux) están disponibles tanto en la generación 1 como en la 2. Es importante seleccionar cuidadosamente una imagen según la descripción de la misma para implementar la generación correcta de la máquina virtual. Del mismo modo, puede crear imágenes de sistema operativo personalizadas como generación 1 o generación 2 y estas afectan a la generación de la máquina virtual cuando se implementa la máquina virtual.

Nota:

Se recomienda usar máquinas virtuales de generación 2 en todas las implementaciones de SAP en Azure, independientemente del tamaño de la máquina virtual. Todas las máquinas virtuales de Azure más recientes para SAP son compatibles con la generación 2 o se limitan exclusivamente a la generación 2. Actualmente, algunas familias de máquinas virtuales solo admiten máquinas virtuales de generación 2. Algunas familias de máquinas virtuales que estarán disponibles en un futuro próximo podrían admitir solo la generación 2.

Puede determinar si una máquina virtual es de la generación 1 o solo de la generación 2 en función de la imagen del sistema operativo seleccionada. No se puede cambiar una máquina virtual existente de una generación a otra.

No es posible cambiar una máquina virtual implementada de la generación 1 a la generación 2 en Azure. Para cambiar la generación de máquinas virtuales, debe implementar una nueva máquina virtual que sea de la generación que desee y volver a instalar el software en la nueva generación de la máquina virtual. Este cambio afecta solo a la imagen del disco duro virtual base de la máquina virtual y no tiene ningún impacto en los discos de datos ni en los recursos compartidos de sistema de archivos de red (NFS) o bloque de mensajes del servidor (SMB). Los discos de datos, los recursos compartidos de NFS o de SMB asignados originalmente a una máquina virtual de generación 1 se pueden conectar a una máquina virtual de nueva generación 2.

Algunas familias de máquinas virtuales, como la serie Mv2, solo admiten la generación 2. El mismo requisito puede ser cierto para las nuevas familias de máquinas virtuales en el futuro. En ese escenario, no se puede cambiar el tamaño de una máquina virtual de generación 1 existente para trabajar con la nueva familia de máquinas virtuales. Además de los requisitos de generación 2 de la plataforma Azure, los componentes de SAP pueden tener requisitos relacionados con la generación de una máquina virtual. Para obtener información sobre los requisitos de generación 2 para la familia de máquinas virtuales que elija, consulte la nota de SAP 1928533.

Límites de rendimiento para máquinas virtuales de Azure

Como nube pública, Azure depende del uso compartido de la infraestructura de forma segura en toda su base de clientes. Para habilitar el escalado y la capacidad, se definen límites de rendimiento para cada recurso y servicio. En el lado de proceso de la infraestructura de Azure, es importante tener en cuenta los límites definidos para cada tamaño de máquina virtual.

Cada máquina virtual tiene una cuota diferente de rendimiento de disco y de red, el número de discos que se pueden conectar, si tiene almacenamiento temporal local que tiene sus propios límites de rendimiento e IOPS, el tamaño de la memoria y cuántas vCPU están disponibles.

Nota:

Cuando tome decisiones sobre el tamaño de la máquina virtual para una solución de SAP en Azure, debe tener en cuenta los límites de rendimiento de cada tamaño de máquina virtual. Las cuotas que se describen en la documentación representan los valores máximos alcanzables teóricos. El límite de rendimiento de IOPS por disco podría lograrse con valores pequeños de entrada/salida (E/S), (por ejemplo, 8 KB), pero podría no lograrse con valores de E/S grandes (por ejemplo, 1 MB).

Al igual que las máquinas virtuales, existen los mismos límites de rendimiento para cada tipo de almacenamiento de una carga de trabajo de SAP y para todos los demás servicios de Azure.

Cuando planee y elija las máquinas virtuales que se van a usar en la implementación de SAP, tenga en cuenta estos factores:

• Comience por los requisitos de memoria y CPU. Separe los requisitos de SAPS relacionados con la potencia de CPU en el elemento de DBMS y los elementos de la aplicación SAP. Para los sistemas existentes, los SAPS relacionados con el hardware que se usa se suelen poder determinar o calcular mediante los bancos de pruebas de aplicaciones estándar de SAP existentes. En el caso de los sistemas SAP recién implementados, complete un ejercicio de dimensionamiento para determinar los requisitos de SAPS del sistema.

• En el caso de los sistemas existentes, se debe medir el rendimiento de E/S e IOPS en el servidor DBMS. En el caso de los nuevos sistemas, la tarea de dimensionamiento del nuevo sistema también debe aportar una idea aproximada de los requisitos de E/S para DBMS. Si no está seguro, tendrá que terminar realizando una prueba de concepto.

• Compare el requisito de SAPS del servidor de DBMS con los SAPS que pueden proporcionar los distintos tipos de máquinas virtuales de Azure. La información sobre los SAPS de los diferentes tipos de máquinas virtuales de Azure se incluye en la nota de SAP 1928533. Primero hay que centrarse en la máquina virtual de DBMS, puesto que la de la base de datos es la capa de un sistema SAP NetWeaver que no se escala horizontalmente en la mayoría de las implementaciones. Por el contrario, la capa de aplicaciones de SAP se puede escalar horizontalmente. Las guías individuales de DBMS describen las configuraciones de almacenamiento recomendadas.

• Resuma los resultados de:

  • Número de máquinas virtuales de Azure que espera usar.
  • Familia de máquinas virtuales individuales y SKU de máquina virtual de cada capa de SAP: DBMS, (A)SCS y servidor de aplicaciones.
  • El rendimiento de E/S mide o calcula los requisitos de capacidad de almacenamiento.

Servicio HANA (instancias grandes)

Azure ofrece funcionalidades de proceso para ejecutar una base de datos de HANA grande con escalabilidad vertical u horizontal en una oferta dedicada denominada SAP HANA en Azure (instancias grandes). Esta oferta amplía las máquinas virtuales que están disponibles en Azure.

Nota:

El servicio de HANA (instancias grandes) ha llegado a su final y no acepta nuevos clientes. Todavía se pueden proporcionar unidades para los clientes existentes de instancias grandes de HANA.

Almacenamiento de SAP en Azure

Las máquinas virtuales de Azure usan varias opciones de almacenamiento para obtener persistencia. En términos simples, las máquinas virtuales se pueden dividir en tipos de almacenamiento persistentes y en temporales o no persistentes.

Puede elegir entre varias opciones de almacenamiento para cargas de trabajo de SAP y para componentes de SAP específicos. Para más información, consulte Almacenamiento de Azure para cargas de trabajo de SAP. En el artículo se describe la arquitectura de almacenamiento de cada parte de SAP: sistema operativo, archivos binarios de aplicaciones, archivos de configuración, datos de base de datos, archivos de registro y seguimiento e interfaces de archivo con otras aplicaciones, ya sea almacenadas en disco o a las que se accede en recursos compartidos de archivos.

Discos temporales en máquinas virtuales

La mayoría de las máquinas virtuales de Azure para SAP ofrecen un disco temporal que no es un disco administrado. Use un disco temporal solo para datos prescindibles. Es posible que los datos de un disco temporal se pierdan durante eventos de mantenimiento imprevistos o durante la reimplementación de la máquina virtual. Las características de rendimiento del disco temporal hacen que sean ideales para los archivos de intercambio o paginación del sistema operativo.

No se deben almacenar datos de aplicación o de sistema operativo imprescindibles en un disco temporal. En entornos de Windows, normalmente se accede a la unidad temporal como unidad D. En los sistemas Linux, el punto de montaje suele ser el dispositivo /dev/sdb, /mnt o /mnt/resource.

Algunas máquinas virtuales no ofrecen una unidad temporal. Si planea usar estos tamaños de máquina virtual para SAP, es posible que tenga que aumentar el tamaño del disco del sistema operativo. Para más información, consulte la nota de SAP 1928533. En el caso de las máquinas virtuales que tienen un disco temporal, obtenga información sobre el tamaño de este y los límites de IOPS y de rendimiento de cada serie de máquinas virtuales en Tamaños de las máquinas virtuales en Azure.

No se puede cambiar el tamaño directamente entre una serie de máquinas virtuales que tenga discos temporales y otra que no los tenga. Actualmente, se produce un error en el cambio de tamaño entre dos familias de máquinas virtuales de este tipo. Una solución consiste en volver a crear la máquina virtual que no tiene un disco temporal con el nuevo tamaño mediante una instantánea del disco de sistema operativo. Mantenga todos los demás discos de datos y la interfaz de red. Aprenda a cambiar el tamaño de una máquina virtual que tenga un disco temporal local a un tamaño de máquina virtual que no lo tenga.

Recursos compartidos de red y volúmenes de SAP

Normalmente, los sistemas SAP requieren uno o varios recursos compartidos de archivos de red. Los recursos compartidos de archivos suelen consistir en una de las siguientes opciones:

• Directorio de transporte de SAP (/usr/sap/trans o TRANSDIR).
• Volúmenes de SAP o volúmenes sapmnt o saploc compartidos para implementar varios servidores de aplicaciones.
• Volúmenes de arquitectura de alta disponibilidad para SAP (A)SCS, SAP ERS o una base de datos (/hana/shared).
• Interfaces de archivo que ejecutan aplicaciones de terceros para la importación y exportación de archivos.

En estos escenarios, se recomienda usar un servicio de Azure, como Azure Files o Azure NetApp Files. Si estos servicios no están disponibles en las regiones que elija o si no están disponibles para la arquitectura de la solución, las alternativas consisten en proporcionar recursos compartidos de archivos NFS o SMB desde aplicaciones autoadministradas basadas en máquinas virtuales o desde servicios de terceros. Consulte la nota de SAP 2015553 sobre las limitaciones de la compatibilidad con SAP si usa servicios de terceros para las capas de almacenamiento de un sistema SAP en Azure.

Debido a la naturaleza a menudo crítica de los recursos compartidos de red y, dado que a menudo constituyen un único punto de error en un diseño (para alta disponibilidad) o proceso (para la interfaz de archivo), se recomienda confiar en cada servicio nativo de Azure para obtener su propia disponibilidad, SLA y resistencia. En la fase de planeación, es importante tener en cuenta estos factores:

• El diseño de recursos compartidos de NFS o SMB, incluidos los recursos compartidos que se usarán por identificador de sistema SAP (SID), por entorno y por región.
• El dimensionamiento de la subred, incluido el requisito de IP para puntos de conexión privados o subredes dedicadas de servicios como Azure NetApp Files.
• El enrutamiento de red a sistemas SAP y aplicaciones conectadas.
• El uso de un punto de conexión público o privado para Azure Files.

Para más información sobre los requisitos y cómo usar un recurso compartido de NFS o SMB en un escenario de alta disponibilidad, consulte Alta disponibilidad.

Nota:

Si usa Azure Files para los recursos compartidos de red, se recomienda que use un punto de conexión privado. En el improbable caso de que se produzca un error en una zona, el cliente NFS se redirigirá automáticamente a una zona correcta. No será necesario que vuelva a montar los recursos compartidos de NFS o SMB en las máquinas virtuales.

Seguridad del entorno de SAP

Para proteger la carga de trabajo de SAP en Azure, debe planear varios aspectos de la seguridad:

• Segmentación de red y seguridad de cada subred e interfaz de red.
• Cifrado en cada capa dentro del entorno de SAP.
• Solución de identidades para el acceso administrativo y del usuario final, y servicios de inicio de sesión único.
• Supervisión de amenazas y operaciones.

Los temas de este capítulo no son una lista exhaustiva de todos los servicios, opciones y alternativas disponibles. Muestra varios procedimientos recomendados que se deben tener en cuenta para todas las implementaciones de SAP en Azure. Hay otros aspectos que se tratan en función de los requisitos de la empresa o de la carga de trabajo. Para más información sobre el diseño de seguridad, consulte los siguientes recursos para obtener instrucciones generales de Azure:

• Marco de buena arquitectura de Azure: Pilar de seguridad
• Azure Cloud Adoption Framework: Seguridad

Protección de redes virtuales mediante grupos de seguridad

La planeación del entorno de SAP en Azure debe incluir cierto grado de segmentación de red, con redes virtuales y subredes dedicadas solo a cargas de trabajo de SAP. Los procedimientos recomendados para la definición de subred se describen en Redes y en otras guías de arquitectura de Azure. Se recomienda usar NSG con ASG dentro de grupos de seguridad de red para permitir la conectividad entrante y saliente. Al diseñar ASG, cada NIC de una máquina virtual se puede asociar a varios ASG, por lo que puede crear grupos diferentes. Por ejemplo, cree un ASG para máquinas virtuales de DBMS que contenga todos los servidores de base de datos del entorno. Cree otro ASG para todas las máquinas virtuales (aplicación y DBMS) de un único SID de SAP. De este modo, puede definir una regla de NSG para el ASG de base de datos general y otra regla más específica solo para el ASG con el SID específico.

Los grupos de seguridad de red no restringen el rendimiento con las reglas que defina para este. Para supervisar el flujo de tráfico, puede activar opcionalmente el registro de flujos de NSG con registros evaluados por un sistema de administración de eventos e información de seguridad (SIEM) o un sistema de detección de intrusiones (IDS) de su elección para supervisar y actuar en actividades de red sospechosas.

Sugerencia

Active los grupos de seguridad de red solo en el nivel de subred. Aunque los NSG se pueden activar en el nivel de subred y en el de NIC, la activación en ambos suele ser un obstáculo en situaciones de solución de problemas al analizar las restricciones de tráfico de red. Use grupos de seguridad de red en el nivel de NIC solo en situaciones excepcionales y cuando sea necesario.

Puntos de conexión privados de servicios

Se accede a muchos servicios PaaS de Azure de manera predeterminada a través de un punto de conexión público. Aunque el punto de conexión de comunicación se encuentra en la red back-end de Azure, el punto de conexión está expuesto a la red pública de Internet. Los puntos de conexión privados son una interfaz de red dentro de su propia red virtual privada. A través de Azure Private Link, el punto de conexión privado proyecta el servicio en la red virtual. A continuación, se accede de forma privada a los servicios PaaS seleccionados mediante la dirección IP dentro de la red. En función de la configuración, el servicio se puede establecer para que se comunique solo a través del punto de conexión privado.

El uso de un punto de conexión privado aumenta la protección contra la pérdida de datos y, a menudo, simplifica el acceso desde redes locales y emparejadas. En muchas situaciones, el enrutamiento de red y el proceso para abrir puertos de firewall, que a menudo son necesarios para los puntos de conexión públicos, se simplifica. Los recursos ya están dentro de la red porque un punto de conexión privado accede a ellos.

Para más información sobre qué servicios de Azure ofrecen la opción de usar un punto de conexión privado, consulte Servicios disponibles de Private Link. Para NFS o SMB con Azure Files, se recomienda usar siempre puntos de conexión privados para cargas de trabajo de SAP. Para obtener información sobre los costos en los que se incurre por el uso del servicio, consulte Precios de puntos de conexión privados. Algunos servicios de Azure pueden incluir opcionalmente el costo con el servicio. Esta información se incluye en la información de precios de un servicio.

Cifrado

En función de las directivas corporativas, un cifrado más allá de las opciones predeterminadas de Azure podría ser necesario para las cargas de trabajo de SAP.

Cifrado de recursos de infraestructura

De manera predeterminada, los discos administrados y el almacenamiento de blobs en Azure se cifran con una clave administrada por la plataforma (PMK). Además, se admite el cifrado Bring Your Own Key (BYOK) para discos administrados y almacenamiento de blobs para cargas de trabajo de SAP en Azure. Para el cifrado de discos administrados, puede elegir entre diferentes opciones, en función de los requisitos de seguridad corporativos. Entre las opciones de cifrado de Azure se incluyen:

• PMK de cifrado en el lado de almacenamiento (SSE) (SSE-PMK)
• Clave administrada por el cliente de SSE (SSE-CMK)
• Cifrado doble en reposo
• Cifrado basado en host

Para más información, incluida una descripción de Azure Disk Encryption, consulte una comparación entre las opciones de cifrado de Azure.

Nota:

En la actualidad, no use el cifrado basado en host en una máquina virtual de la familia de máquinas virtuales de la serie M cuando se ejecute con Linux debido a una posible limitación de rendimiento. Al uso del cifrado SSE-CMK para discos administrados no le afecta esta limitación.

En el caso de las implementaciones de SAP en sistemas Linux, no use Azure Disk Encryption. Azure Disk Encryption implica el cifrado que se ejecuta dentro de las máquinas virtuales de SAP mediante CMK de Azure Key Vault. En el caso de Linux, Azure Disk Encryption no admite las imágenes del sistema operativo que se usan para las cargas de trabajo de SAP. Azure Disk Encryption se puede usar en sistemas Windows con cargas de trabajo de SAP, pero no combine Azure Disk Encryption con el cifrado nativo de bases de datos. Se recomienda usar el cifrado nativo de bases de datos en lugar de Azure Disk Encryption. Para obtener más información, vea la siguiente sección.

De forma similar al cifrado de discos administrados, el cifrado de Azure Files en reposo (SMB y NFS) está disponible con PMK o CMK.

En el caso de los recursos compartidos de red de SMB, repase cuidadosamente Azure Files y las dependencias del sistema operativo con versiones de SMB porque la configuración afecta a la compatibilidad con el cifrado en tránsito.

Importante

Nunca se insistirá lo suficiente en la importancia de un plan cuidadoso para almacenar y proteger las claves de cifrado si se utiliza el cifrado administrado por el cliente. Sin claves de cifrado, los recursos cifrados como los discos son inaccesibles y pueden provocar la pérdida de datos. Considere cuidadosamente la posibilidad de proteger las claves y permitir el acceso a estas solo para usuarios o servicios con privilegios.

Cifrado para componentes de SAP

El cifrado en el nivel de SAP se puede dividir en dos capas:

• Cifrado de DBMS
• Cifrado de transporte

En el caso del cifrado de DBMS, cada base de datos compatible con una implementación de SAP NetWeaver o SAP S/4HANA admite el cifrado nativo. El cifrado de bases de datos transparente es completamente independiente de cualquier cifrado de infraestructura que esté en vigor en Azure. Puede usar SSE y el cifrado de bases de datos al mismo tiempo. Cuando se usa el cifrado, la ubicación, el almacenamiento y el mantenimiento seguro de las claves de cifrado es fundamental. Cualquier pérdida de las claves de cifrado conduce a la pérdida de datos porque no podrá iniciar ni recuperar la base de datos.

Es posible que algunas bases de datos no tengan un método de cifrado de bases de datos o que no requieran que se habilite una configuración dedicada. En el caso de otras bases de datos, las copias de seguridad de DBMS se pueden cifrar implícitamente cuando se activa el cifrado de base de datos. Consulte la siguiente documentación de SAP para aprender a habilitar y usar el cifrado de base de datos transparente:

• Cifrado del volumen de datos y registro de SAP HANA
• SQL Server: Nota de SAP 1380493
• Oracle: Nota de SAP 974876
• IBM Db2: Nota de SAP 1555903
• SAP ASE: Nota de SAP 1972360

Póngase en contacto con SAP o el proveedor de DBMS para obtener soporte técnico sobre cómo habilitar, usar o solucionar problemas de cifrado de software.

Importante

Nunca se insistirá lo suficiente en lo importante que es tener un plan cuidadoso para almacenar y proteger sus claves de cifrado. Sin claves de cifrado, es posible que la base de datos o el software de SAP no sean accesibles y que pierda datos. Considere detenidamente cómo proteger las claves. Permita el acceso a las claves solo a usuarios o servicios con privilegios.

El cifrado de transporte o comunicación se puede aplicar a las conexiones de SQL Server entre los motores de SAP y DBMS. Del mismo modo, puede cifrar las conexiones en la capa de presentación de SAP (conexión de red segura de SAPGui o SNC) o una conexión HTTPS con un front-end web. Consulte la documentación del proveedor de aplicaciones para habilitar y administrar el cifrado en tránsito.

Supervisión y alertas ante amenazas

Para implementar y usar soluciones de supervisión y alertas ante amenazas, empiece por usar la arquitectura de la organización. Los servicios de Azure proporcionan protección contra amenazas y una vista de seguridad que puede incorporar en el plan de implementación general de SAP. Microsoft Defender for Cloud aborda el requisito de protección contra amenazas. Defender for Cloud normalmente forma parte de un modelo de gobernanza general de toda una implementación de Azure, no solo para los componentes de SAP.

Para más información sobre las soluciones de administración de eventos e información de seguridad (SIEM) y las de respuesta automatizada de orquestación de seguridad (SOAR), consulte Soluciones de Microsoft Sentinel para la integración de SAP.

Software de seguridad dentro de las máquinas virtuales de SAP

La nota de SAP 2808515 para Linux y la nota de SAP 106267 para Windows describen los requisitos y los procedimientos recomendados al usar escáneres de virus o software de seguridad en servidores de SAP. Se recomienda seguir las recomendaciones de SAP al implementar componentes de SAP en Azure.

Alta disponibilidad

La alta disponibilidad de SAP en Azure tiene dos componentes:

• Alta disponibilidad de la infraestructura de Azure: alta disponibilidad de los servicios de proceso (máquinas virtuales), redes y almacenamiento de Azure, y cómo pueden aumentar la disponibilidad de las aplicaciones de SAP.

• Alta disponibilidad de aplicaciones de SAP: cómo se puede combinar con la alta disponibilidad de la infraestructura de Azure mediante la recuperación del servicio. Un ejemplo que usa alta disponibilidad en los componentes de software de SAP:

  • Una instancia de SAP (A)SCS y SAP ERS
  • El servidor de bases de datos

Para más información sobre la alta disponibilidad de SAP en Azure, consulte los siguientes artículos:

• Escenarios admitidos: Protección de alta disponibilidad para el nivel de DBMS de SAP
• Escenarios admitidos: Alta disponibilidad para servicios centrales de SAP
• Escenarios admitidos: Almacenamiento admitido para escenarios de servicios centrales de SAP
• Escenarios admitidos: Clústeres de conmutación por error de servicios centrales de SAP con varios SID
• Alta disponibilidad de Azure Virtual Machines para SAP NetWeaver
• Escenarios y arquitectura de alta disponibilidad para SAP NetWeaver
• Utilización del reinicio de VM de la infraestructura de Azure para lograr una "mayor disponibilidad" de un sistema SAP sin agrupación en clústeres
• Configuraciones de cargas de trabajo de SAP con Azure Availability Zones
• Conectividad del punto de conexión público para las máquinas virtuales mediante el uso de Azure Standard Load Balancer en escenarios de alta disponibilidad de SAP

Pacemaker en Linux y los clústeres de conmutación por error de Windows Server son los únicos marcos de alta disponibilidad para cargas de trabajo de SAP compatibles con Microsoft directamente en Azure. Microsoft no admite ningún otro marco de alta disponibilidad y necesitará compatibilidad con el diseño, los detalles de implementación y las operaciones del proveedor. Para más información, consulte Escenarios admitidos para SAP en Azure.

Recuperación ante desastres

A menudo, las aplicaciones SAP se encuentran entre los procesos más críticos de una empresa. En función de su importancia y el tiempo necesario para volver a funcionar después de una interrupción imprevista, los escenarios de continuidad empresarial y recuperación ante desastres (BCDR) deben planearse cuidadosamente.

Para aprender a abordar este requisito, consulte Introducción a la recuperación ante desastres e instrucciones de infraestructura para la carga de trabajo de SAP.

Backup

Como parte de la estrategia de BCDR, la copia de seguridad de la carga de trabajo de SAP debe ser parte integral de cualquier implementación planeada. La solución de copia de seguridad debe abarcar todas las capas de una pila de soluciones de SAP: VM, sistema operativo, capa de aplicación de SAP, capa de DBMS y cualquier solución de almacenamiento compartido. La copia de seguridad de los servicios de Azure que usa la carga de trabajo de SAP y de otros recursos cruciales, como las claves de cifrado y acceso, también debe formar parte del diseño de la estrategia de copia de seguridad y BCDR.

Azure Backup ofrece soluciones PaaS de copia de seguridad:

• Configuración de máquinas virtuales, sistema operativo y capa de aplicación de SAP (cambio de tamaño de datos en discos administrados) mediante Azure Backup para máquina virtual. Revise la matriz de compatibilidad para comprobar que la arquitectura puede usar esta solución.
• Copia de seguridad de datos y registros de base de datos de SQL Server y SAP HANA. Incluye compatibilidad con tecnologías de replicación de bases de datos, como la replicación del sistema de HANA o Always On de SQL, y la compatibilidad entre regiones en el caso de las regiones emparejadas.
• Copia de seguridad del recurso compartido de archivos mediante Azure Files. Compruebe la compatibilidad con NFS o SMB y otros detalles de configuración.

Como alternativa, si implementa Azure NetApp Files, las opciones de copia de seguridad están disponibles en el nivel de volumen, incluida la integración del DBMS de SAP HANA y Oracle con una copia de seguridad programada.

Las soluciones de Azure Backup ofrecen una opción de eliminación temporal para evitar la eliminación malintencionada o accidental y la consiguiente pérdida de datos. La eliminación temporal también está disponible para los recursos compartidos de archivos que se implementan mediante Azure Files.

Las opciones de copia de seguridad están disponibles tanto para una solución de su propia creación y administración, como si usa software de terceros. Una opción consiste en usar los servicios con Azure Storage, incluido el uso del almacenamiento inmutable de los datos de blobs. Esta opción autoadministrada sería necesaria actualmente como opción de copia de seguridad de DBMS para algunas bases de datos como SAP ASE o IBM Db2.

Use las recomendaciones de los procedimientos recomendados de Azure para proteger y validar frente a ataques de ransomware.

Sugerencia

Asegúrese de que la estrategia de copia de seguridad incluye la protección de la automatización de la implementación, las claves de cifrado de los recursos de Azure y el cifrado de base de datos transparente si se usa.

Copia de seguridad entre regiones

Para cualquier requisito de copia de seguridad entre regiones, determine el objetivo de tiempo de recuperación (RTO) y el objetivo de punto de recuperación (RPO) que ofrece la solución y si este se adapta a sus necesidades y al diseño de la estrategia de BCDR.

Migración de SAP a Azure

No es posible describir todos los enfoques y opciones de migración para la gran variedad de productos de SAP, dependencias de versiones y sistemas operativos nativos y tecnologías de DBMS disponibles. El equipo de proyecto de su organización y los representantes del proveedor de servicios deben tener en cuenta varias técnicas para una migración fluida de SAP a Azure.

• Pruebe el rendimiento durante la migración. Una parte importante del planeamiento de la migración de SAP es la prueba técnica de rendimiento. El equipo de migración debe permitir suficiente tiempo y disponibilidad para que el personal clave ejecute la aplicación y las pruebas técnicas del sistema SAP migrado, incluidas las interfaces y aplicaciones conectadas. Para una migración correcta de SAP, es fundamental comparar el entorno de ejecución previo y posterior a la migración y la precisión de los procesos empresariales clave en un entorno de prueba. Use la información para optimizar los procesos antes de migrar al entorno de producción.

• Use los servicios de Azure para la migración de SAP. Algunas cargas de trabajo basadas en máquinas virtuales se migran sin cambiar a Azure mediante servicios como Azure Migrate o Azure Site Recovery, o una herramienta de terceros. Confirme con seguridad que el servicio admite la versión del sistema operativo y la carga de trabajo de SAP que ejecuta.

  A menudo, no se admite intencionadamente ninguna carga de trabajo de base de datos porque un servicio no puede garantizar la coherencia de la base de datos. Si el servicio de migración admite el tipo de DBMS, el cambio de la base de datos o el abandono suelen ser demasiado altos. La mayoría de los sistemas SAP ocupados no cumplirán la tasa de cambios que permiten las herramientas de migración. Es posible que no se vean o detecten problemas hasta la migración a producción. En muchas situaciones, algunos servicios de Azure no son adecuados para migrar sistemas SAP. Azure Site Recovery y Azure Migrate no tienen validación para una migración de SAP a gran escala. Una metodología de migración de SAP de eficacia probada consiste en confiar en la replicación de DBMS o en las herramientas de migración de SAP.

  Una implementación en Azure en lugar de una migración básica de máquina virtual es preferible y más fácil de lograr que una migración local. Los marcos de implementación automatizados, como Azure Center for SAP solutions y el marco de automatización de implementación de Azure, permiten la ejecución rápida de tareas automatizadas. Para migrar el entorno de SAP a una nueva infraestructura implementada mediante tecnologías de replicación nativas de DBMS, como la replicación del sistema HANA, la copia de seguridad y restauración de DBMS, o las herramientas de migración de SAP, se usan conocimientos técnicos establecidos del sistema SAP.

• Escalabilidad vertical de la infraestructura. Durante una migración de SAP, disponer de una mayor capacidad de infraestructura puede ayudarle a implementar más rápidamente. El equipo del proyecto debe considerar la posibilidad de escalar verticalmente el tamaño de la máquina virtual para proporcionar más CPU y memoria. El equipo también debe considerar la posibilidad de escalar verticalmente el almacenamiento agregado de máquinas virtuales y el rendimiento de red. Del mismo modo, en el nivel de máquina virtual, considere la posibilidad de usar elementos de almacenamiento como discos individuales para aumentar el rendimiento con niveles de expansión y rendimiento a petición para SSD prémium v1. Aumente los valores de IOPS y rendimiento con SSD prémium v2 por encima de los valores configurados. Amplíe los recursos compartidos de archivos de NFS y SMB para aumentar los límites de rendimiento. Tenga en cuenta que los discos de administración de Azure no se pueden reducir de tamaño y que esa reducción del tamaño, los niveles de rendimiento y los KPI de rendimiento podrían suponer tiempos de recuperación.

• Optimice la red y la copia de datos. La migración de un sistema SAP a Azure siempre implica mover una gran cantidad de datos. Los datos pueden ser copias de seguridad o replicación de bases de datos y archivos, una transferencia de datos de aplicación a aplicación o una exportación de migración de SAP. En función del proceso de migración que use, debe elegir la ruta de acceso de red correcta para mover los datos. Para muchas operaciones de movimiento de datos, el uso de Internet en lugar de una red privada es la ruta de acceso más rápida para copiar datos de forma segura en Azure Storage.

  El uso de ExpressRoute o una VPN puede provocar cuellos de botella:

  • Los datos de migración usan demasiado ancho de banda e interfieren con el acceso de los usuarios a las cargas de trabajo que se ejecutan en Azure.
  • Los cuellos de botella de red locales, como un firewall o una limitación de rendimiento, a menudo solo se detectan durante la migración.

  Independientemente de la conexión de red que se use, el rendimiento de red de un solo flujo para un movimiento de datos suele ser bajo. Para aumentar la velocidad de transferencia de datos a través de varios flujos TCP, use herramientas que puedan admitir varios flujos. Aplique las técnicas de optimización que se describen en la documentación de SAP y en muchas entradas de blog sobre este tema.

Sugerencia

En la fase de planeación, es importante tener en cuenta las redes de migración dedicadas que usará para las transferencias de datos de gran tamaño a Azure. Algunos ejemplos son las copias de seguridad o la replicación de bases de datos, o el uso de un punto de conexión público para las transferencias de datos a Azure Storage. Es previsible, y se debe mitigar, el impacto de la migración en las rutas de acceso de red para los usuarios y aplicaciones. Como parte del planeamiento de red, tenga en cuenta todas las fases de la migración y el costo de una carga de trabajo parcialmente productiva en Azure durante la migración.

Compatibilidad y operaciones para SAP

Es importante tener en cuenta otros aspectos antes y durante la implementación de SAP en Azure.

Extensión de la máquina virtual de Azure para SAP

La extensión de supervisión de Azure, la supervisión mejorada y la extensión de Azure para SAP hacen referencia a una extensión de máquina virtual que debe implementar para proporcionar algunos datos básicos sobre la infraestructura de Azure al agente del host de SAP. Puede que las notas de SAP hagan referencia a ella como Extensión de supervisión o Supervisión mejorada. En Azure, se denomina extensión de Azure para SAP. Con fines de soporte técnico, la extensión debe instalarse en todas las máquinas virtuales de Azure que ejecutan una carga de trabajo de SAP. Para más información, consulte Extensión de máquina virtual de Azure para SAP.

SAProuter para la compatibilidad con SAP

El funcionamiento de un entorno de SAP en Azure requiere conectividad con SAP y desde este con fines de soporte técnico. Normalmente, la conectividad adopta la forma de una conexión SAProuter, ya sea a través de un canal de red cifrado en Internet o mediante una conexión VPN privada a SAP. Para conocer los procedimientos recomendados y para obtener un ejemplo de implementación de SAProuter en Azure, consulte el escenario de arquitectura en Conexiones entrantes y salientes a Internet para SAP en Azure.

Pasos siguientes

• Implementación de una carga de trabajo de SAP en Azure
• Consideraciones para la implementación de DBMS de Azure Virtual Machines para la carga de trabajo de SAP
• Lista de comprobación de planeamiento e implementación de cargas de trabajo de SAP en Azure
• Conjuntos de escalado de máquinas virtuales para cargas de trabajo de SAP