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 completar un largo ciclo de adquisición. Sin embargo, la ejecución de la carga de trabajo de SAP en Azure requiere conocimientos sobre las opciones disponibles y la planeación cuidadosa para elegir los componentes y la arquitectura de Azure para 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 correcta de todo el panorama empresarial de SAP.

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

Definiciones

En este artículo, usamos los siguientes términos:

• Componente de SAP: una aplicación 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 Java, o bien puede ser una aplicación que no se basa en SAP NetWeaver, como SAP BusinessObjects.
• Entorno de SAP: varios componentes de SAP que se agrupan lógicamente para realizar una función empresarial, como desarrollo, control de calidad, entrenamiento, recuperación ante desastres o producción.
• Panorama de SAP: todo el conjunto de recursos de SAP en el panorama 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 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 localmente o implementarse en Azure. Sin embargo, puede operar diferentes sistemas dentro de un entorno de SAP en Azure o en el entorno 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 tratan:

• Detalles de la carga de trabajo de SAP para las opciones de almacenamiento, redes y soporte técnico.
• Guías de DBMS de SAP para varios sistemas DBMS en Azure.
• Guías de implementación de SAP, tanto manuales como automatizadas.
• Detalles de alta disponibilidad y recuperación ante desastres para una carga de trabajo de SAP en Azure.
• Integración con 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 de SAP y las guías. En este artículo solo se tratan tareas específicas para el software de SAP instalado y operado en una máquina virtual (VM) de Azure.

Las siguientes notas de SAP forman la base de las instrucciones 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 mediante Oracle Database
2233094	DB6: Aplicaciones de SAP en Azure mediante 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 máximas y predeterminadas generales de las suscripciones y recursos de Azure, consulte Límites, cuotas y restricciones de suscripción y servicios de Azure.

Escenarios

A menudo, los servicios de SAP se consideran entre las aplicaciones más críticas 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 nube elegir ejecutar estos procesos empresariales críticos para la empresa.

Azure es la plataforma de nube pública ideal para aplicaciones y procesos empresariales críticos para la empresa. 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 compatibles con SAP en máquinas virtuales de Azure. Compruebe estos escenarios y las condiciones que se indican como no compatibles a medida que planee la arquitectura que desea implementar en Azure.

Para implementar correctamente sistemas SAP en IaaS de Azure o en IaaS en general, es importante comprender las diferencias significativas entre las ofertas de nubes privadas tradicionales y las ofertas de IaaS. Un host o externalizador 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:

• Determine qué productos y versiones de SAP se admiten en Azure.
• Evalúe 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.
• Determine qué versiones de DBMS se admiten en máquinas virtuales específicas para los productos de SAP.
• Evalúe si es necesario actualizar o actualizar el entorno de SAP para alinearse con las versiones necesarias del sistema operativo y DBMS para lograr una configuración admitida.
• Evalúe si necesita moverse a diferentes sistemas operativos para implementar en Azure.

Los detalles sobre los componentes de SAP admitidos en Azure, las unidades de infraestructura de Azure y las versiones relacionadas del sistema operativo y las versiones de DBMS se explican en el software de SAP compatible con las implementaciones de Azure. El conocimiento que obtiene de evaluar el soporte técnico 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. Aprenderá si hay importantes esfuerzos de preparación implicados, por ejemplo, si necesita actualizar la versión de SAP o cambiar a otro sistema operativo.

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 SAP.

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

Si su organización ya ha implementado software en Azure, es posible que el proceso sea fácil. Si su empresa está más al principio del recorrido, es posible que sea necesario discutir más grandes para averiguar las condiciones de 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 en un servicio de Azure, consulte Introducción al cifrado de Azure y Seguridad para el 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 se usa para cada recurso de Azure, como para máquinas virtuales y grupos de recursos.
• Un diseño de grupo de administración y suscripción para la carga de trabajo de SAP, como 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 suscripciones y grupos de administración.

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

No subestime la fase inicial del proyecto en la planificación. Solo cuando tenga acuerdos y reglas vigentes para el cumplimiento, la seguridad y la organización de recursos de Azure, debe avanzar en el planeamiento de la implementación.

Los pasos siguientes son planear la ubicación geográfica y la arquitectura de red que implemente 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 hospedan y ejecutan los servicios de Azure que están disponibles en la región. La infraestructura incluye un gran número de nodos que funcionan como nodos de proceso o nodos de almacenamiento, o que ejecutan la funcionalidad 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 ajuste de tamaño y el sistema operativo y DBMS que necesita, es posible que una región determinada no ofrezca los tipos de máquina virtual necesarios para su escenario. 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, finalmente, región secundaria, debe investigar si los servicios que necesita para sus escenarios están disponibles en las regiones que está considerando. Puede aprender exactamente qué tipos de máquina virtual, tipos de almacenamiento de Azure y otros servicios de Azure están disponibles en cada región de 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 de 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), recursos compartidos de archivos y volúmenes y otros escenarios de almacenamiento de alta latencia.

A medida que comprueba si hay regiones emparejadas y los servicios que desea usar en las regiones primarias o secundarias, es posible que los servicios de Azure o los tipos de máquina virtual que quiera usar en la región primaria no estén disponibles en la región emparejada que desea usar 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, debe usar una región no emparejada como región de recuperación ante desastres o secundaria, y debe configurar parte de la replicación de datos usted 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 se compone de uno o varios centros de datos que están equipados con alimentación, refrigeración y redes independientes. Un ejemplo de 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 otra zona de disponibilidad, por lo que obtendrá el mejor Acuerdo de Nivel de Servicio en Azure.

Para más información sobre los acuerdos de nivel de servicio de máquina virtual en Azure, consulte la versión más reciente de los Acuerdos de Nivel de Servicio de Virtual Machines. Dado que las regiones de Azure 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 los centros de datos 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 de las configuraciones de cargas de trabajo de SAP con zonas de disponibilidad de Azure 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.

Al implementar varias máquinas virtuales como parte de un sistema SAP, puede influir indirectamente en el controlador de tejido de Azure para implementar las máquinas virtuales en distintos dominios de error, de modo que pueda cumplir los requisitos de los SLA de disponibilidad. Sin embargo, no tiene control directo de la distribución de dominios de error a través de una unidad de escalado de Azure (una colección de cientos de nodos de proceso o nodos de almacenamiento y redes) o la asignación de máquinas virtuales a un dominio de error específico. Para maniobrar el controlador de tejido de Azure para implementar un conjunto de máquinas virtuales en distintos dominios de error, debe asignar un conjunto de disponibilidad de Azure a las máquinas virtuales en el momento de la implementación. Para obtener 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 en 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 de actualización uno a uno. Al distribuir máquinas virtuales en tiempo de implementación a través de diferentes dominios de actualización, puede proteger el sistema SAP frente a posibles tiempos de inactividad. De forma similar a los dominios de error, una unidad de escalado de Azure se divide en varios dominios de actualización. Para maniobrar el controlador de tejido de Azure para implementar un conjunto de máquinas virtuales en distintos dominios de actualización, debe asignar un conjunto de disponibilidad de Azure a las máquinas virtuales en el momento de la implementación. Para obtener más información, consulte Conjuntos de disponibilidad.

Conjuntos de disponibilidad

Las máquinas virtuales de Azure dentro de un conjunto de disponibilidad de Azure se distribuyen mediante el controlador de tejido de Azure en distintos dominios de error. La distribución en dominios de error diferentes es impedir que todas las máquinas virtuales de un sistema SAP se apaguen durante el mantenimiento de la infraestructura o si se produce un error en un dominio de error. De forma 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 vuelva a implementar una máquina virtual.

Para más información sobre los conjuntos de disponibilidad de Azure y cómo se relacionan los conjuntos de disponibilidad 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 tanto la zona de disponibilidad como el conjunto de disponibilidad se pueden asignar a una máquina virtual.

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

A medida que defina conjuntos de disponibilidad e intente mezclar varias máquinas virtuales de diferentes familias de máquinas virtuales dentro de un conjunto de disponibilidad, podría encontrarse con problemas que impiden incluir un tipo de máquina virtual específico 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 host 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 la primera máquina virtual en el conjunto de disponibilidad. La primera máquina virtual que agregue al conjunto de disponibilidad se encuentra en la familia de máquinas virtuales Edsv5. Al intentar implementar una segunda máquina virtual, se produce un error en una máquina virtual que se encuentra en la familia M. El motivo es que las máquinas virtuales de la familia Edsv5 no se ejecutan en el mismo hardware 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 y a un tipo de máquina virtual que se encuentra en la familia M, se produce un error en la implementación. Si cambia el tamaño a una familia de máquinas virtuales que no se puede hospedar en el mismo hardware host, debe apagar todas las máquinas virtuales que están en el conjunto de disponibilidad y cambiar su tamaño para poder ejecutarse en el otro tipo de máquina 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 Virtual Machines.

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 la plataforma. Tiene una opción para crear un conjunto de escalado dentro de la región o abarcarlo entre zonas de disponibilidad. Al crear, 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 del conjunto de escalado flexible entre zonas de disponibilidad con platformFaultDomainCount=1 (FD=1) distribuiría las máquinas virtuales entre la zona especificada y el conjunto de escalado también distribuiría las máquinas virtuales entre distintos dominios de error dentro de la zona de la mejor manera posible.

Para la carga 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 de zona de disponibilidad tradicional 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 una manera de mejor esfuerzo. 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 escalado de máquinas virtuales flexibles.

Al implementar 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 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 la carga de trabajo de SAP.

Sugerencia

Actualmente no hay ninguna manera directa de migrar la carga de trabajo de SAP implementada en conjuntos de disponibilidad o zonas de disponibilidad a escala flexible con FD=1. Para realizar el cambio, debe volver a crear la máquina virtual y el disco con restricciones de zona 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 una 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 ha implementado en un conjunto de disponibilidad o una zona de disponibilidad en un conjunto de escalado flexible con FD=1.

Grupos de selección de ubicación de proximidad

La latencia de red entre máquinas virtuales SAP individuales puede tener implicaciones significativas para el rendimiento. El tiempo 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. De forma óptima, 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 Es posible 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 ida y vuelta de red.

Cuando la ubicación predeterminada no cumple los requisitos de ida y vuelta de red dentro de un sistema SAP, los grupos de selección de ubicación de proximidad pueden abordar esta necesidad. Puede usar grupos de selección de 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 de selección de ubicación de proximidad, es posible combinar la zona de disponibilidad y el conjunto de disponibilidad, al establecer diferentes dominios de actualización y error. Un grupo de selección de ubicación de proximidad debe contener solo un único sistema SAP.

Aunque la implementación en un grupo de selección de ubicación por proximidad puede dar lugar a la selección de ubicación optimizada para la latencia, la implementación mediante un grupo de selección de ubicación por proximidad también tiene inconvenientes. Algunas familias de máquinas virtuales no se pueden combinar en un grupo de selección de ubicación por proximidad, o 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 colocación. Para obtener más información y conocer las ventajas y los posibles desafíos del uso de un grupo de selección de ubicación por proximidad, consulte Escenarios de grupos de selección de ubicación de proximidad.

Las máquinas virtuales que no usan grupos de selección de ubicación por proximidad deben ser el método de implementación predeterminado en la mayoría de las situaciones para los sistemas SAP. Este valor predeterminado es especialmente cierto para las implementaciones zonales (una sola zona de disponibilidad) y entre zonas (máquinas virtuales que se distribuyen entre dos zonas de disponibilidad) de un sistema SAP. El uso de grupos de selección de 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 tiene una infraestructura de red que se asigna a todos los escenarios que puede querer implementar en una implementación de SAP. En Azure, tiene las siguientes funcionalidades:

• Acceso a servicios de Azure y acceso 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 (RDP) para la administración y 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 redes de Azure.
• Comunicación entre servicios que se implementan 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 realizar 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 fundamental para 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 use o se pueda dedicar a un servicio o propósito específico. Algunos servicios de Azure, como Azure Virtual Network y App de Azure lication Gateway, requieren una subred dedicada.

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

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

• No se colocan 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 (NSG) aplican restricciones de enrutamiento de red en el nivel de subred. Agrupa las direcciones IP de las máquinas virtuales en grupos de seguridad de aplicaciones (ASG) que se mantienen en las reglas de NSG y proporcionan agrupaciones de roles, niveles y SID de permisos.
• Las máquinas virtuales de base de datos y aplicaciones de SAP se ejecutan en la misma red virtual, dentro de las mismas subredes o diferentes de una sola red virtual. Use subredes diferentes para máquinas virtuales de aplicaciones y bases de datos. Como alternativa, use asG de DBMS y aplicaciones dedicadas para agrupar reglas que se aplican 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 sea técnicamente posible.
• Asegúrese de que 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 el id. de Microsoft Entra) y el acceso administrativo.
• Proporcione acceso a los puntos de conexión públicos y a los puntos de conexión públicos 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
• Comunicación entrante y saliente de Internet para SAP en Azure

Consideraciones sobre la red virtual

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

• No se admite 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.

  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 Pacemaker Linux.

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

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

  • Rutas de comunicación entre máquinas virtuales de Azure que representan nodos de clúster de Pacemaker Linux y dispositivos SBD, tal como se describe en Alta disponibilidad para SAP NetWeaver en máquinas virtuales de Azure en SUSE Linux Enterprise Server para aplicaciones SAP.
  • Rutas de comunicación entre máquinas virtuales de Azure y un recurso compartido de archivos de escalabilidad horizontal de Windows Server configurado 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 mediante un recurso compartido de archivos en Azure.

• No se admite la separación de la capa de aplicación de SAP y la capa de DBMS en diferentes redes virtuales de Azure. 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 mediante 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 emparejarse.

  El tráfico de red entre dos redes virtuales de Azure emparejadas está sujeto a costos de transferencia. Cada día, se intercambia un gran volumen de datos que consta de muchos terabytes entre la capa de aplicación de SAP y la capa de DBMS. Puede incurrir en un costo considerable 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 a la dirección IP a través de 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. Varias opciones para implementar la resolución de nombres en Azure de forma nativa, en lugar de configurar sus propios servidores DNS, se describen en Resolución de nombres para 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 por 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ámica y estática. Sigue siendo cierto si la máquina virtual se está ejecutando o se cierra. La asignación de IP dinámica se libera si se elimina la NIC, si cambia la subred o si el método de asignación cambia a estático.

Es posible asignar direcciones IP fijas a máquinas virtuales dentro de una red virtual de Azure. Las direcciones IP suelen reasignarse para sistemas SAP que dependen de servidores DNS externos y entradas estáticas. La dirección IP permanece asignada, ya sea hasta que la máquina virtual y su NIC se eliminen o hasta que la dirección IP no esté asignada. Debe 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 de nombres 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 DNS A o un registro PTR 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 porque las direcciones IP secundarias a menudo no se asignan a través de DHCP. Cada dirección IP secundaria debe ser de la misma subred a la que está enlazada la NIC. Se puede agregar y quitar una dirección IP secundaria de una NIC de Azure sin detener ni desasignar la máquina virtual. Para agregar o quitar la dirección IP principal de una NIC, la máquina virtual debe desasignarse.

Nota:

En las configuraciones ip secundarias, no se admite la dirección IP flotante del equilibrador de carga de Azure. Las arquitecturas de alta disponibilidad de SAP usan el equilibrador de carga de Azure con clústeres de Pacemaker. En este escenario, el equilibrador de carga habilita los nombres de host virtual 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 nodos de clúster activos y pasivos. También puede usar un equilibrador de carga para una sola máquina virtual para contener 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.

El equilibrador de carga estándar modifica la ruta de acceso de salida predeterminada porque su arquitectura es segura de forma predeterminada. Es posible que las máquinas virtuales que están detrás de un equilibrador de carga estándar ya no puedan acceder a los mismos puntos de conexión públicos. Algunos ejemplos son un punto de conexión para 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 el equilibrador de carga estándar de Azure.

Sugerencia

El equilibrador de carga básico no debe usarse con ninguna arquitectura de SAP en Azure. El equilibrador de carga básico está programado para retirarse.

Varias NIC virtuales por máquina virtual

Puede definir varias tarjetas de interfaz de red virtual (vNIC) para una máquina virtual de Azure, con cada vNIC asignada a cualquier subred de la misma red virtual que la vNIC principal. Con la capacidad 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 algún 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 el enrutamiento correcto.

El tipo y el tamaño de una máquina virtual determinan cuántos vNIC puede haber asignado una máquina virtual. Para obtener información sobre la funcionalidad y las restricciones, consulte Asignación de varias direcciones IP a máquinas virtuales mediante Azure Portal.

Agregar vNIC 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 base 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 y, de forma óptima, solo una. Una excepción es el escalado horizontal de HANA, en el que se requiere una vNIC secundaria para la red interna de HANA.

Advertencia

Si usa varias VNIC 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 forma predeterminada para las nuevas máquinas virtuales, según la lista de comprobación de implementación, debe comprobar el estado. Las ventajas de las redes aceleradas se mejoran considerablemente el rendimiento y las latencias de las redes. Úselo al implementar máquinas virtuales de Azure para cargas de trabajo de SAP en todas las máquinas virtuales compatibles, especialmente para la capa de aplicación de SAP y la capa de DBMS de SAP. La documentación vinculada contiene dependencias de compatibilidad en 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 de toda la empresa para 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 de la organización central, como el DNS central, el dominio y la infraestructura de administración de revisiones y seguridad.

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-spoke o una extensión de la topología en estrella tipo hub-spoke, una WAN virtual 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 o oficinas más pequeñas, la conectividad VPN local está disponible. El uso de ExpressRoute con una conexión vpn de sitio a sitio como ruta de acceso de conmutación por error es una posible combinación de ambos servicios.

Conectividad saliente e entrante a Internet

El entorno de SAP requiere conectividad a Internet, ya sea que reciba actualizaciones del repositorio del sistema operativo, para establecer una conexión a las aplicaciones SaaS de SAP en sus puntos de conexión públicos o para acceder a un servicio de Azure a través de 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 proporcionados por el entorno de SAP. La arquitectura de red de SAP requiere que planee la ruta de acceso hacia Internet y para las solicitudes entrantes.

Proteja la red virtual mediante reglas de NSG, mediante etiquetas de servicio de red para servicios conocidos y estableciendo el enrutamiento y el direccionamiento IP al 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 específicamente para una carga de trabajo de SAP HANA. La manera de encontrar el tipo de máquina virtual correcto y su capacidad para admitir la carga de trabajo de SAP se describe en ¿Qué software de SAP se admite para las implementaciones de Azure? Además, la nota de SAP 1928533 enumera todas las máquinas virtuales de Azure certificadas y sus funcionalidades de rendimiento medida por la prueba comparativa y las limitaciones de SAP Application Performance Standard (SAPS), si se aplican. Los tipos de máquina virtual certificados para una carga de trabajo de SAP no usan el aprovisionamiento excesivo para los recursos de CPU y memoria.

Más allá de examinar solo la selección de tipos de máquina virtual compatibles, debe comprobar si esos tipos de máquina virtual están disponibles en una región específica basada en Productos disponibles por región. Al menos lo importante es determinar si las siguientes funcionalidades para una máquina virtual se ajustan a su escenario:

• Recursos de CPU y memoria
• Ancho de banda de las operaciones de entrada y salida por segundo (IOPS)
• Funcionalidades de red
• Número de discos que se pueden conectar
• Capacidad de usar determinados 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 reservado de un año
• Un plan de ahorro o reservado 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 obtener 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 el 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 puntuales, consulte Azure Spot Virtual Machines.

Los precios del 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 menos costosa, por lo que la información sobre los precios por región puede ser útil a medida que planee.

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 admitir 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 es compatible con una carga de trabajo de SAP. Varios clientes de SAP que quieren tener más control sobre los planes de revisión y mantenimiento de la infraestructura usan hosts dedicados de Azure. Para más información sobre cómo Microsoft mantiene y aplica revisiones a la infraestructura de Azure que hospeda máquinas virtuales, consulte Mantenimiento de máquinas virtuales en Azure.

Sistema operativo para 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 consumir o generalizar desde galerías de imágenes.

Para más información e 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 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 revisiones y actualizaciones durante el período de tiempo 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. La compatibilidad con máquinas virtuales de generación 2 en Azure enumera las familias de máquinas virtuales de Azure que puede implementar como generación 2. En el artículo también se enumeran las diferencias funcionales entre las máquinas virtuales de generación 1 y generación 2 en Azure.

Al implementar 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 o Oracle Enterprise Linux) están disponibles tanto en la generación 1 como en la generación 2. Es importante seleccionar cuidadosamente una imagen basada en la descripción de la imagen 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 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 están limitadas a solo 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 pronto podrían admitir solo la generación 2.

Puede determinar si una máquina virtual es de la generación 1 o solo la generación 2 en función de la imagen de 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 la generación que quiera y vuelva a instalar el software en la nueva generación de máquinas virtuales. Este cambio afecta solo a la imagen de 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 NFS o los recursos compartidos 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, los límites de rendimiento se definen 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 en el rendimiento de disco y red, el número de discos que se pueden conectar, ya sea que tenga almacenamiento temporal local que tenga sus propios límites de rendimiento e IOPS, tamaño de memoria y cuántas vCPU están disponibles.

Nota:

Al tomar decisiones sobre el tamaño de 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 para una carga de trabajo de SAP y para todos los demás servicios de Azure.

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

• Comience con los requisitos de memoria y CPU. Separe los requisitos de SAPS para la potencia de CPU en el elemento DBMS y los elementos de la aplicación SAP. En el caso de los sistemas existentes, los SAPS relacionados con el hardware que use a menudo se pueden determinar o estimar en función de las pruebas comparativas de aplicaciones estándar de SAP existentes. Para los sistemas SAP recién implementados, complete un ejercicio de ajuste de tamaño para determinar los requisitos de SAPS para el 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, el ejercicio de ajuste de tamaño del nuevo sistema también debe darle una idea general de los requisitos de E/S en el lado de DBMS. Si no está seguro, finalmente debe llevar a cabo una prueba de concepto.

• Compare el requisito de SAPS para el servidor DBMS con sapS que pueden proporcionar los distintos tipos de máquina virtual de Azure. La información sobre SAPS de los distintos tipos de máquina virtual de Azure se documenta en la nota de SAP 1928533. El enfoque debe estar primero en la máquina virtual de DBMS porque la capa de base de datos es la capa de un sistema SAP NetWeaver que no se escala horizontalmente en la mayoría de las implementaciones. En cambio, el nivel de aplicación de SAP se puede escalar horizontalmente. Las guías individuales de DBMS describen las configuraciones de almacenamiento recomendadas.

• Resumir 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 para 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 de gran escala o escalabilidad 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 HANA (instancias grandes) está en modo de puesta de sol y no acepta clientes nuevos. Todavía es posible proporcionar unidades para los clientes existentes de HANA (instancias grandes).

Almacenamiento para SAP en Azure

Las máquinas virtuales de Azure usan varias opciones de almacenamiento para la persistencia. En términos simples, las máquinas virtuales se pueden dividir en tipos de almacenamiento persistentes y 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 Azure Storage para cargas de trabajo de SAP. En el artículo se describe la arquitectura de almacenamiento para 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.

Disco temporal 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 expendibles. 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 página del sistema operativo.

No se deben almacenar datos de aplicación o de sistema operativo confiables 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 obtener más información, consulte 1928533 de la nota de SAP. En el caso de las máquinas virtuales que tienen un disco temporal, obtenga información sobre el tamaño de disco temporal y los límites de IOPS y rendimiento de cada serie de máquinas virtuales en Tamaños para 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 una serie de máquinas virtuales que no tenga discos temporales. Actualmente, se produce un error en el cambio de tamaño entre dos familias de máquinas virtuales de este tipo. Una resolución consiste en volver a crear la máquina virtual que no tiene un disco temporal en el nuevo tamaño mediante una instantánea de disco del 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 haga.

Recursos compartidos de red y volúmenes para SAP

Normalmente, los sistemas SAP requieren uno o varios recursos compartidos de archivos de red. Los recursos compartidos de archivos suelen ser 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 son 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 capas de almacenamiento en un sistema SAP en Azure.

Debido a la naturaleza a menudo crítica de los recursos compartidos de red y, dado que a menudo son 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 su propia disponibilidad, SLA y resistencia. En la fase de planificación, es importante tener en cuenta estos factores:

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

Para obtener información sobre los requisitos y cómo usar un recurso compartido 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 usar un punto de conexión privado. En el improbable caso de un error zonal, el cliente NFS redirige automáticamente a una zona correcta. No es necesario volver a montar los recursos compartidos NFS o SMB en las máquinas virtuales.

Seguridad para el 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 identidad para el acceso administrativo y el usuario final y los 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. Enumera 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 trabajo bien diseñado 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 grupos de seguridad de red con grupos de seguridad de red dentro de grupos de seguridad de red para permitir la conectividad entrante y saliente. Al diseñar GRUPOS de disponibilidad, cada NIC de una máquina virtual se puede asociar a varios GRUPOS de disponibilidad, por lo que puede crear grupos diferentes. Por ejemplo, cree un ASG para máquinas virtuales de DBMS, que contiene todos los servidores de base de datos en todo el 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 específico del SID.

Los grupos de seguridad de red no restringen el rendimiento con las reglas que defina para el grupo de seguridad de red. Para supervisar el flujo de tráfico, puede activar opcionalmente el registro de flujo de NSG con registros evaluados por una administración de eventos de información (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 nivel 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 para servicios

Se accede a muchos servicios PaaS de Azure de forma 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 se expone 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 a los servicios PaaS seleccionados de forma privada a través de la dirección IP dentro de la red. En función de la configuración, el servicio se puede establecer para comunicarse 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 obtener 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 cargos que se incurren mediante el servicio, consulte Precios del punto de conexión privado. 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, el cifrado más allá de las opciones predeterminadas en Azure podría ser necesario para las cargas de trabajo de SAP.

Cifrado de recursos de infraestructura

De forma 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 blob storage 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:

• Cifrado del lado de almacenamiento (SSE) PMK (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 de las opciones de Cifrado de Azure.

Nota:

Actualmente, no use el cifrado basado en host en una máquina virtual que se encuentra en la familia de máquinas virtuales de la serie M cuando se ejecuta con Linux debido a una posible limitación de rendimiento. El uso del cifrado SSE-CMK para discos administrados no se ve afectado por 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. Para Linux, Azure Disk Encryption no admite las imágenes del sistema operativo que se usan para 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 cifrado nativo de base de datos. Se recomienda usar el cifrado nativo de base 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 disco administrado, 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 SMB, revise cuidadosamente Azure Files y las dependencias del sistema operativo con versiones SMB porque la configuración afecta a la compatibilidad con el cifrado en tránsito.

Importante

La importancia de un plan cuidadoso para almacenar y proteger las claves de cifrado si usa el cifrado administrado por el cliente no se puede sobrestatar. 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 el acceso a las claves solo a 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

Para el 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 base de datos transparente es completamente independiente de cualquier cifrado de infraestructura que esté en su lugar en Azure. Puede usar SSE y cifrado de base 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 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 base de datos o que no requieran una configuración dedicada para habilitar. 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 de volumen de datos y registro de SAP HANA
• SQL Server: nota de SAP 1380493
• Oracle: 974876 de la nota de SAP
• IBM Db2: nota de SAP 1555903
• SAP ASE: 1972360 de la nota de SAP

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

No se puede sobrestatar lo importante que es tener un plan cuidadoso para almacenar y proteger las 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. Permitir el acceso a las claves solo por parte de usuarios o servicios con privilegios.

El cifrado de transporte o comunicación se puede aplicar a las conexiones de SQL Server entre motores de SAP y DBMS. Del mismo modo, puede cifrar las conexiones desde la capa de presentación de SAP (conexión de red segura de SAPGui o SNC) o una conexión HTTPS a 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 de amenazas

Para implementar y usar soluciones de supervisión y alertas de 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 general de implementación 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 para toda una implementación de Azure, no solo para los componentes de SAP.

Para obtener más información sobre la administración de eventos de información de seguridad (SIEM) y las soluciones 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 máquinas virtuales de SAP

La nota de SAP 2808515 para Linux y SAP Note 106267 for Windows describe los requisitos y los procedimientos recomendados al usar escáneres de virus o software de seguridad en servidores 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 (VM) de Azure, red y almacenamiento, 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
  • Servidor de bases de datos

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

• Escenarios admitidos: protección de alta disponibilidad para la capa de DBMS de SAP
• Escenarios admitidos: alta disponibilidad para SAP Central Services
• Escenarios admitidos: almacenamiento admitido para escenarios de SAP Central Services
• Escenarios admitidos: clústeres de conmutación por error de SAP Central Services con varios SID
• Alta disponibilidad de Azure Virtual Machines para SAP NetWeaver
• Escenarios y arquitectura de alta disponibilidad para SAP NetWeaver
• Uso del reinicio de máquinas virtuales de 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 de punto de conexión público para máquinas virtuales mediante Azure Standard Load Balancer en escenarios de alta disponibilidad de SAP

Pacemaker en Linux y clústeres de conmutación por error de Windows Server son los únicos marcos de alta disponibilidad para cargas de trabajo de SAP que microsoft admite 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 para la empresa en 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 obtener información sobre cómo 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 una parte integral de cualquier implementación planeada. La solución de copia de seguridad debe cubrir 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 para otros recursos cruciales, como el cifrado y las claves de acceso, también deben formar parte del diseño de la copia de seguridad y BCDR.

Azure Backup ofrece soluciones PaaS para la 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) a través de Azure Backup para VM. Revise la matriz de compatibilidad para comprobar que la arquitectura puede usar esta solución.
• Copia de seguridad de registros y datos 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 SQL AlwaysOn, y la compatibilidad entre regiones para 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 de 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 para evitar la 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 para una solución que cree y administre usted mismo, o si usa software de terceros. Una opción consiste en usar los servicios con Azure Storage, incluido el almacenamiento inmutable para los datos de blobs. Esta opción autoadministrada actualmente sería necesaria 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 para 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 coincide con el diseño y las necesidades 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 dbMS disponibles. El equipo de proyecto de su organización y representantes del lado del proveedor de servicios debe 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 conectadas y las aplicaciones. Para una migración correcta de SAP, es fundamental comparar el entorno de ejecución de migración previa 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 el 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 diligentemente 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 DBMS, la tasa de cambio o renovación de la base de datos suele ser demasiado alta. 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 de 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 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 para soluciones de SAP 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 usan conocimientos técnicos establecidos del sistema SAP.

• Escalado vertical de la infraestructura. Durante una migración de SAP, tener más 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 Premium v1. Aumente los valores de IOPS y rendimiento si usa SSD Premium v2 por encima de los valores configurados. Amplíe los recursos compartidos de archivos 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 en tamaño y que esa reducción del tamaño, los niveles de rendimiento y los KPI de rendimiento pueden tener varios tiempos de enfriamiento.

• 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 de base de datos y archivos o replicación, 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 flujo único 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 pueden admitir varias secuencias. Aplique 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 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. Se debe esperar y mitigar el impacto de la migración en rutas de acceso de red para los usuarios y las 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

Algunas otras áreas son importantes tener en cuenta 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 en el agente host de SAP. Las notas de SAP pueden referirse a la extensión como Extensión de supervisión o Supervisión mejorada. En Azure, se denomina extensión de Azure para SAP. Para 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 y desde SAP con fines de soporte técnico. Normalmente, la conectividad está en forma de una conexión SAProuter, ya sea si se realiza a través de un canal de red de cifrado a través de Internet o a través de 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 de Internet entrantes y salientes 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
• Cargas de trabajo de SAP en Azure: lista de comprobación de planeación e implementación
• Conjuntos de escalado de máquinas virtuales para la carga de trabajo de SAP