Editar

Compartir a través de

Arquitectura de entornos SAP

Azure Virtual Machines
Azure Virtual Network
Archivos de Azure
Azure Load Balancer

En este artículo se proporcionan procedimientos recomendados para diseñar un entorno SAP completo en Azure. El entorno SAP incluye varios sistemas SAP en entornos de centro, producción, no producción y recuperación ante desastres. Se proporcionan recomendaciones que se centran en el diseño de red y no en sistemas SAP específicos. El objetivo es proporcionar nuestras recomendaciones para diseñar un entorno SAP seguro, de alto rendimiento y resistente.

Architecture

Diagrama que muestra un entorno SAP general de ejemplo en Azure.

Descargue un archivo Visio de esta arquitectura.

Flujo de trabajo

  1. Red local: conexión ExpressRoute desde la red local hasta las regiones de Azure conectadas.
  2. Centros regionales de suscripción a Azure: suscripción a Azure que contiene servicios centrales para toda la empresa, no solo SAP. La suscripción al centro proporciona conectividad mediante el emparejamiento con redes virtuales de radio que contienen cargas de trabajo de SAP.
  3. Red virtual de centro: una red virtual de radio para el centro de conectividad central de la región primaria o la región A.
  4. Red virtual de recuperación ante desastres (DR) de centro: una red virtual de radio para el centro de conectividad central en la región de recuperación ante desastres. Refleja el diseño de subred de la red virtual de producción en la región primaria.
  5. Suscripción a Azure para SAP no de producción: una suscripción a Azure para todas las cargas de trabajo de SAP que no son de producción. Incluye entornos de preproducción, control de calidad, desarrollo y espacio aislado.
  6. Redes virtuales de radio para SAP no de producción: redes virtuales independientes para cargas de trabajo de SAP que no son de producción en la región primaria. Cada entorno SAP tiene su propia red virtual y subredes.
  7. Suscripción a Azure para SAP de producción; una suscripción a Azure para todas las cargas de trabajo de SAP de producción.
  8. Red virtual de radio para SAP de producción: una red virtual para el entorno de producción de SAP con varias subredes. Esta red virtual está en la región primaria.
  9. Red virtual de radio de recuperación ante desastres (DR) para SAP de producción: una red virtual para SAP de producción en la región de recuperación ante desastres, la región secundaria. Refleja el diseño de subred de la red virtual de producción en la región primaria.
  10. Servicios de Azure: un muestreo de los servicios de Azure que puede conectar al entorno SAP.
  11. SAP Business Technology Platform (BTP): el entorno SAP accede a SAP Business Technology Platform mediante Azure Private Link.

Suscripciones de Azure

Se recomienda usar un diseño de red en estrella tipo hub-and-spoke. Con este tipo de diseño, necesita al menos tres suscripciones para dividir los entornos de SAP. Debe tener una suscripción para las redes virtuales de centro regionales (1), (2) redes virtuales que no son de producción y (3) redes virtuales de producción. Las suscripciones proporcionan límites de facturación, directiva y seguridad. No hay un número correcto de suscripciones. El número de suscripciones que use depende de las necesidades de facturación, directiva y seguridad. En general, le interesará evitar el uso de demasiadas suscripciones. Demasiadas suscripciones pueden agregar sobrecarga de administración y complejidad de red innecesarias. Por ejemplo, no necesita una suscripción para cada sistema SAP. Nuestra arquitectura usa tres suscripciones:

  • Centros regionales: una suscripción de centro de red virtual de Azure donde la red virtual de centro está presente en las regiones primarias y secundarias. Esta suscripción es para todos los servicios centrales y no solo para SAP.

  • SAP no de producción: una suscripción a SAP no de producción en Azure donde residen los sistemas que no son de producción, como espacio aislado, desarrollo, control de calidad o preproducción.

  • SAP de producción; una suscripción a SAP de producción en Azure donde se han configurado los sistemas de producción y de recuperación ante desastres.

Para más información, consulte:

Diseño de red

Una topología en estrella tipo hub-and-spoke es el diseño de red recomendado para un entorno SAP. En esta topología, la red virtual de centro de producción actúa como punto central de conectividad. Se conecta a la red local y a las distintas redes virtuales de radio y permite a los usuarios y a las aplicaciones acceder a la carga de trabajo de SAP. Dentro de esta topología en estrella tipo hub-and-spoke, estas son nuestras recomendaciones para el diseño de redes SAP.

Use ExpressRoute para la conexión local. En el caso de las cargas de trabajo de SAP, se recomienda usar ExpressRoute para conectar la red local a la red virtual de centro y a la red virtual de recuperación ante desastres de centro. Si tiene ubicaciones globales, puede usar la topología de Azure Virtual WAN. Considere la posibilidad de configurar una VPN de sitio a sitio (S2S) como respaldo de Azure ExpressRoute o para los requisitos de ruta de terceros.

Para más información, consulte:

Use una red virtual por entorno. Se recomienda usar una red virtual por entorno (nivel de implementación de SAP). La arquitectura usa una red virtual diferente para producción, desarrollo, control de calidad y espacio aislado. Este diseño de red es idóneo para arquitecturas empresariales de gran tamaño.

Use un firewall central. Todo el tráfico de red a las redes virtuales de radio, incluidas las conexiones de llamada a funciones remotas (RFC), debe pasar por un firewall central en la red virtual de centro. La comunicación de red entre las redes virtuales de radio (comunicación de radio a radio) pasa por el firewall de red virtual de centro en la subred de Azure Firewall de la red virtual de centro. De forma similar, la comunicación de red entre las redes virtuales de radio y la red local también pasa por el firewall de red virtual de centro. Hemos usado el emparejamiento de red virtual para conectar las distintas redes virtuales de radio a la red virtual de centro. Toda la comunicación entre las redes virtuales de radio pasa por el firewall de la red virtual del centro. También puede usar una aplicación virtual de red en lugar de un firewall. Para más información, consulte Aplicación virtual de red.

El tráfico de red que permanece en una red virtual no debe pasar por un firewall. Por ejemplo, no coloque un firewall entre la subred de la aplicación SAP y la subred de la base de datos de SAP. No puede colocar un firewall ni aplicaciones virtuales de red (NVA) entre la aplicación de SAP y la capa del sistema de administración de bases de datos (DBMS) de los sistemas SAP que ejecutan el kernel de SAP.

Evite emparejar redes virtuales de radio. Si es posible, se debe evitar el emparejamiento entre las redes virtuales de radio. El emparejamiento de red virtual de radio a radio permite que la comunicación de radio a radio omita el firewall de la red virtual del centro. Solo debe configurar el emparejamiento de red virtual de radio a radio cuando tenga requisitos de ancho de banda altos, por ejemplo, con la replicación de base de datos entre entornos de SAP. El resto del tráfico de red pasar por la red virtual y el firewall del centro. Para más información, consulte Conexiones entrantes y salientes a Internet para SAP en Azure.

Subredes

Se recomienda dividir cada entorno de SAP (producción, preproducción, desarrollo, espacio aislado) en subredes y usar las subredes para agrupar los servicios relacionados. Estas son nuestras recomendaciones para el uso de una subred en un entorno SAP.

Cantidad de subredes

La red virtual de producción de la arquitectura tiene cinco subredes. Este diseño es idóneo para soluciones empresariales de gran tamaño. El número de subredes puede ser inferior o superior. El número de recursos de la red virtual debe determinar el número de subredes de la red virtual.

Ajuste de tamaño de subred

Asegúrese de que las subredes tengan suficiente espacio de direcciones de red. Si usa nombres de host virtuales de SAP, necesita más espacio de direcciones en las subredes de SAP. A menudo, cada instancia de SAP requiere 2-3 direcciones IP e incluye una dirección IP para el nombre de host de la máquina virtual. Otros servicios de Azure pueden requerir su propia subred dedicada cuando se implementan en las redes virtuales de carga de trabajo de SAP.

Subred de aplicación

La subred de la aplicación contiene máquinas virtuales que ejecutan servidores de aplicaciones SAP, SAP Central Services (ASCS), SAP Enqueue Replication Services (ERS) e instancias de SAP Web Dispatcher. La subred también contiene un punto de conexión privado a Azure Files. En el diagrama, se han agrupado las máquinas virtuales por rol. Se recomienda usar conjuntos de escalado de máquinas virtuales con orquestación flexible, zonas de disponibilidad o conjuntos de disponibilidad para una implementación resistente. Para más información, consulte Pasos siguientes.

Subred de base de datos

La subred de base de datos contiene máquinas virtuales que ejecutan bases de datos. En el diagrama, un par de máquinas virtuales con replicación sincrónica representan todas las máquinas virtuales de base de datos de un entorno de SAP.

Subredes perimetrales

Las subredes perimetrales están orientadas a Internet e incluyen una subred perimetral de SAP y una subred de Application Gateway. Estas son nuestras recomendaciones para diseñar estas dos subredes.

Subred perimetral de SAP: la subred perimetral de SAP es una red perimetral que contiene aplicaciones accesibles desde Internet, como SAProuter, SAP Cloud Connector, SAP Analytics Cloud Agent y Application Gateway. Estos servicios tienen dependencias de sistemas SAP que un equipo de SAP debe implementar, administrar y configurar. Un equipo de TI central no debe administrar los servicios de la subred perimetral de SAP. Por este motivo, debe colocar estos servicios en la red virtual de radio de SAP y no en la red virtual de centro. El diagrama de arquitectura solo muestra una red perimetral de SAP de producción. No tiene una subred perimetral de SAP en las redes virtuales que no son de producción. Las cargas de trabajo de la suscripción de SAP que no es de producción usan los servicios de la subred perimetral de SAP.

Puede crear una subred perimetral de SAP independiente en la suscripción que no es de producción. Solo se recomienda este enfoque para cargas de trabajo o cargas de trabajo críticas que cambien con frecuencia. Un perímetro de SAP dedicado que no sea de producción es útil para probar e implementar nuevas características. Las aplicaciones menos críticas o las aplicaciones que solo vayan a tener algunas modificaciones con el tiempo no necesitan una subred perimetral de SAP independiente que no sea de producción.

Subred de Application Gateway: Azure Application Gateway requiere su propia subred. Úsela para permitir el tráfico desde la red Internet que los servicios de SAP, como SAP Fiori, puedan usar. La arquitectura recomendada coloca Azure Application Gateway junto con su IP pública de front-end en la red virtual de centro. Application Gateway requiere al menos un tamaño de subred /29. Se recomienda un tamaño /27 o superior. No se pueden usar ambas versiones de Application Gateway (v1 y v2) en la misma subred. Para más información, consulte Subred de Azure Application Gateway.

Colocar las subredes perimetrales en una red virtual independiente para aumentar la seguridad: para aumentar la seguridad, puede colocar la subred perimetral de SAP y la subred de Application Gateway en una red virtual independiente dentro de la suscripción de producción de SAP. La red virtual de radio perimetral de SAP está emparejada con la red virtual de centro y todo el tráfico de red a las redes públicas fluye a través de la red virtual perimetral. Este enfoque alternativo muestra Azure Application Gateway con su IP pública para las conexiones entrantes colocadas en una red virtual de radio para el uso exclusivo de SAP.

Diagrama que muestra el flujo de red entre los radios de red virtual a través de la red virtual de centro.

Descargue un archivo Visio con esta arquitectura alternativa.

Este diseño de red proporciona mejores funcionalidades de respuesta a incidentes y control de acceso de red pormenorizado. Sin embargo, también aumenta la complejidad de la administración, la latencia de red y el costo de la implementación. Vamos a analizar cada punto.

Mejor respuesta a incidentes: la red virtual de radio perimetral de SAP permite un aislamiento rápido de los servicios en peligro si detecta una infracción. Puede eliminar el emparejamiento de la red virtual de radio perimetral de SAP con el centro y aislar inmediatamente las cargas de trabajo perimetrales de SAP y las aplicaciones de red virtual de aplicaciones de SAP de Internet. No quiere depender de los cambios en las reglas del grupo de seguridad de red (NSG) para la respuesta a incidentes. Cambiar o quitar una regla de NSG solo afecta a las nuevas conexiones y no interrumpe las conexiones malintencionadas existentes.

Control de acceso de red pormenorizado: la red virtual perimetral de SAP proporciona un control de acceso de red más estricto hacia la red virtual de radio de producción de SAP y desde esta.

Mayor complejidad, latencia y costo: la arquitectura aumenta la complejidad, el costo y la latencia de la administración. La comunicación vinculada a Internet desde la red virtual de producción de SAP se empareja dos veces, una vez con la red virtual de centro y nuevamente con la red virtual perimetral de SAP fuera de Internet. El firewall de la red virtual de centro es el que más efecto tiene sobre la latencia. Se recomienda medir la latencia para ver si es admisible en su escenario.

Para más información, consulte Procedimientos recomendados de la arquitectura de red.

Subred de Azure NetApp Files

Si usa NetApp Files, debe tener una subred delegada para proporcionar recursos compartidos de archivos del sistema de archivos de red (NFS) o del bloque de mensajes del servidor (SMB) para diferentes escenarios de SAP en Azure. Una subred /24 es el tamaño predeterminado de una subred de NetApp Files, pero puede cambiarlo para satisfacer sus necesidades. Use sus propios requisitos para determinar el tamaño adecuado. Para más información, consulte Subred delegada.

Seguridad de subred

El uso de subredes para agrupar recursos de SAP que tienen los mismos requisitos de reglas de seguridad facilita la administración de la seguridad.

Grupos de seguridad de red (NSG): las subredes permiten implementar grupos de seguridad de red a nivel de subred. La agrupación de recursos en la misma subred que requieren reglas de seguridad diferentes precisa de grupos de seguridad de red a nivel de subred y de interfaz de red. Con esta configuración de dos niveles, las reglas de seguridad entran en conflicto fácilmente y pueden causar problemas de comunicación inesperados que son difíciles de solucionar. Las reglas de NSG también afectan al tráfico dentro de la subred. Para más información sobre los grupos de seguridad de red, consulte Grupos de seguridad de red.

Grupos de seguridad de aplicaciones (ASG): se recomienda usar grupos de seguridad de aplicaciones para agrupar interfaces de red de máquinas virtuales y hacer referencia a los grupos de seguridad de aplicaciones en las reglas de grupo de seguridad de red. Esta configuración facilita la creación y administración de reglas para las implementaciones de SAP. Cada interfaz de red puede pertenecer a varios grupos de seguridad de aplicaciones con diferentes reglas de grupo de seguridad de red. Para más información, consulte Grupos de seguridad de aplicaciones.

Se recomienda usar Azure Private Link para mejorar la seguridad de las comunicaciones de red. Azure Private Link usa puntos de conexión privados con direcciones IP privadas para comunicarse con los servicios de Azure. Azure Private Links evita el envío de comunicaciones de red a través de Internet a puntos de conexión públicos. Para más información, consulte Puntos de conexión privados en Azure Backup.

Usar puntos de conexión privados en la subred de la aplicación: se recomienda usar puntos de conexión privados para conectar la subred de la aplicación a los servicios de Azure admitidos. En la arquitectura, hay un punto de conexión privado para Azure Files en la subred Aplicación de cada red virtual. Puede ampliar este concepto a cualquier servicio de Azure compatible.

Usar Azure Private Link para SAP Business Technology Platform (BTP): Azure Private Link para SAP Business Technology Platform (BTP) ya está disponible con carácter general. SAP Private Link Service admite conexiones desde SAP BTP, el entorno de ejecución de Cloud Foundry y otros servicios. Entre los escenarios de ejemplo se incluyen SAP S/4HANA o SAP ERP que se ejecutan en la máquina virtual. Pueden conectarse a servicios nativos de Azure, como Azure Database for MariaDB y Azure Database for MySQL.

En la arquitectura se muestra una conexión de SAP Private Link Service a entornos de SAP BTP. SAP Private Link Service establece una conexión privada entre servicios específicos de SAP BTP y servicios específicos de cada red con cuentas del proveedor de servicios. Private Link permite que los servicios BTP accedan a su entorno SAP mediante conexiones de red privada. Este servicio mejora la seguridad, puesto que no se usa la red pública de Internet para comunicarse.

Para más información, consulte:

Recursos compartidos de archivos de sistema de archivos de red (NFS) y bloque de mensajes de servidor (SMB)

Los sistemas SAP suelen depender de recursos compartidos de volúmenes del sistema de archivos de red o de bloques de mensajes de servidor. Estos recursos compartidos de archivos mueven archivos entre máquinas virtuales o funcionan como una interfaz de archivo con otras aplicaciones. Se recomienda usar servicios nativos de Azure, como Azure Premium Files y Azure NetApp Files, como recursos compartidos de archivos del sistema de archivos de red (NFS) y del bloque de mensajes del servidor (SMB). Los servicios de Azure tienen una mejor disponibilidad, resistencia y acuerdos de nivel de servicio (SLA) combinados que las herramientas basadas en el sistema operativo.

Para más información, consulte:

Al diseñar la solución de SAP, debe ajustar correctamente el tamaño de los volúmenes de recursos compartidos de archivos individuales y saber a qué recurso compartido de archivos del sistema SAP se conecta. Tenga en cuenta los objetivos de escalabilidad y rendimiento del servicio de Azure durante el planeamiento. En la tabla siguiente se describen los recursos compartidos de archivos de SAP comunes y se proporciona una breve descripción y el uso recomendado en un entorno SAP completo.

Nombre del recurso compartido de archivos Uso Recomendación
sapmnt Directorios globales, de perfil y del sistema SAP distribuido Recurso compartido dedicado para cada sistema SAP, sin reutilización
cluster Recursos compartidos de alta disponibilidad para ASCS, ERS y base de datos por diseño respectivo Recurso compartido dedicado para cada sistema SAP, sin reutilización
saptrans Directorio de transporte de SAP Una recurso compartido para uno o unos cuantos entornos de SAP (ERP, Business Warehouse)
interface Intercambio de archivos con aplicaciones que no son de SAP Requisitos específicos del cliente, recursos compartidos de archivos independientes por entorno (producción, no producción)

Solo puede compartir saptrans entre diferentes entornos de SAP y, como tal, debe considerar cuidadosamente su ubicación. Evite consolidar demasiados sistemas SAP en un recurso compartido saptrans por motivos de escalabilidad y rendimiento.

Las directivas de seguridad corporativa impulsarán la arquitectura y la separación de volúmenes entre entornos. Un directorio de transporte con separación por entorno o nivel necesita la comunicación RFC entre entornos de SAP para permitir grupos de transporte de SAP o vínculos de dominio de transporte. Para más información, consulte:

Servicios de datos

La arquitectura contiene servicios de datos de Azure que le ayudan a ampliar y mejorar la plataforma de datos de SAP. Para ayudar a desbloquear información empresarial, se recomienda usar servicios como Azure Synapse Analytics, Azure Data Factory y Azure Data Lake Storage. Estos servicios de datos le ayudan a analizar y visualizar datos de SAP y datos que no son de SAP.

En muchos escenarios de integración de datos, se requiere un entorno de ejecución de integración. El entorno de ejecución de integración de Azure es la infraestructura de proceso que usan las canalizaciones de Azure Data Factory y Azure Synapse Analytics para proporcionar capacidades de integración de datos. Se recomienda la implementación de máquinas virtuales en tiempo de ejecución para estos servicios para cada entorno por separado. Para más información, consulte:

Servicios compartidos

Las soluciones de SAP se basan en servicios compartidos. Ejemplos de servicios que usan varios sistemas SAP son el equilibrador de carga y las puertas de enlace de aplicaciones. La arquitectura y sus necesidades organizativas deben determinar cómo diseñar los servicios compartidos. Esta es la guía general que debe seguir.

Equilibradores de carga: se recomienda un equilibrador de carga por sistema SAP. Esta configuración ayuda a minimizar la complejidad. Quiere evitar demasiados grupos y reglas en un único equilibrador de carga. Esta configuración también garantiza que la nomenclatura y la selección de ubicación se alineen con el sistema SAP y el grupo de recursos. Cada sistema SAP con una arquitectura de alta disponibilidad en clúster (HA) debe tener al menos un equilibrador de carga. La arquitectura usa un equilibrador de carga para las máquinas virtuales ASCS y un segundo equilibrador de carga para las máquinas virtuales de base de datos. Es posible que algunas bases de datos no requieran equilibradores de carga para crear una implementación de alta disponibilidad. Pero, SAP HANA sí. Consulte la documentación específica de la base de datos para más información.

Application Gateway: se recomienda al menos una puerta de enlace de aplicaciones por entorno SAP (producción, no producción y espacio aislado), a menos que la complejidad y el número de sistemas conectados sean demasiado altos. Puede usar una puerta de enlace de aplicaciones para varios sistemas SAP para reducir la complejidad, ya que no todos los sistemas SAP del entorno requieren acceso público. Una sola puerta de enlace de aplicaciones podría atender a varios puertos de Web Dispatcher en un único sistema SAP S/4HANA o se podría usar en diferentes sistemas SAP.

Máquinas virtuales de SAP Web Dispatcher: la arquitectura muestra un grupo de dos o más máquinas virtuales de SAP Web Dispatcher. Se recomienda no reutilizar máquinas virtuales de SAP Web Dispatcher entre distintos sistemas SAP. Al mantenerlas separadas, puede ajustar el tamaño de las máquinas virtuales de Web Dispatcher para que satisfagan las necesidades de cada sistema SAP. Para soluciones de SAP más pequeñas, se recomienda insertar los servicios de Web Dispatcher en la instancia de ASCS.

Servicios de SAP: los servicios de SAP, como SAProuter, Cloud Connector y Analytics Cloud Agent, se implementan en función de los requisitos de la aplicación, ya sea de forma centralizada o dividida. No hay ninguna recomendación sobre la reutilización entre sistemas SAP debido a diversos requisitos de los clientes. La decisión principal que hay que tomar se menciona en la sección de redes: si se debe usar la subred perimetral de SAP para entornos que no son de producción y cuándo hacerlo. De lo contrario, solo con la subred perimetral de producción para SAP, todo el entorno de SAP consume los servicios perimetrales de SAP.

Recuperación ante desastres

La recuperación ante desastres (DR) aborda el requisito de continuidad empresarial en caso de que la región primaria de Azure no esté disponible o esté en peligro. Desde una perspectiva general del entorno SAP y que se muestra en el diagrama, estas son nuestras recomendaciones para el diseño de la recuperación ante desastres.

Usar intervalos de direcciones IP diferentes: las redes virtuales solo abarcan una sola región de Azure. Las soluciones de recuperación ante desastres deben usar una región diferente. Debe crear una red virtual diferente en la región secundaria. La red virtual del entorno de recuperación ante desastres necesita un intervalo de direcciones IP diferente para permitir la sincronización de bases de datos mediante la tecnología nativa de la base de datos.

Servicios centrales y conectividad con el entorno local: debe haber conectividad con servicios locales y centrales clave (DNS o firewalls) en la región de recuperación ante desastres. La disponibilidad y la configuración de los cambios de los servicios de TI centrales deben formar parte del plan de recuperación ante desastres. Los servicios de TI centrales son componentes esenciales para que un entorno SAP funcione.

Usar Azure Site Recovery: Azure Site Recovery replica y protege las configuraciones de discos administrados y máquinas virtuales para los servidores de aplicaciones en la región de recuperación ante desastres.

Garantizar la disponibilidad de los recursos compartidos de archivos: SAP depende de la disponibilidad de los recursos compartidos de archivos de clave. Es necesaria la copia de seguridad o la replicación continua de recursos compartidos de archivos para proporcionar datos sobre estos recursos compartidos de archivos con una pérdida de datos mínima en el escenario de recuperación ante desastres.

Replicación de la base de datos: Azure Site Recovery no puede proteger los servidores de bases de datos de SAP debido a la alta tasa de cambios y la falta de compatibilidad con la base de datos por parte del servicio. Debe configurar la replicación continua y asincrónica de la base de datos en la región de recuperación ante desastres.

Para más información, consulte Introducción a la recuperación ante desastres e instrucciones de infraestructura para la carga de trabajo de SAP.

Arquitectura de SAP más pequeña

Para soluciones de SAP más pequeñas, puede resultar beneficioso simplificar el diseño de red. Las redes virtuales de cada entorno SAP serían entonces subredes dentro de dicha red virtual combinada. Cualquier simplificación de las necesidades de diseño de red y suscripción puede afectar a la seguridad. Debe volver a evaluar el enrutamiento de red, el acceso a las redes públicas y desde estas, el acceso a los servicios compartidos (recursos compartidos de archivos) y el acceso a otros servicios de Azure. Estas son algunas opciones para reducir la arquitectura a fin de satisfacer mejor las necesidades de la organización.

Combine las subredes de base de datos y de aplicación de SAP en una sola. Puede combinar las subredes de aplicación y de base de datos para crear una red SAP grande. Este diseño de red refleja muchas redes SAP locales. La combinación de estas dos subredes requiere una mayor atención a la seguridad de la subred y a las reglas de grupo de seguridad de red. Los grupos de seguridad de aplicaciones son importantes cuando se usa una sola subred para subredes de aplicación y de base de datos de SAP.

Combine la subred perimetral y la subred de aplicación de SAP. Puede combinar la subred perimetral y la subred de aplicación de SAP. Se debe prestar mayor atención a las reglas de grupo de seguridad de red y al uso del grupo de seguridad de aplicaciones. Solo se recomienda este enfoque de simplificación para pequeños patrimonios de SAP.

Combinar redes virtuales de radio de SAP entre diferentes entornos SAP: la arquitectura usa diferentes redes virtuales para cada entorno SAP (centro, producción, no producción y recuperación ante desastres). En función del tamaño del entorno SAP, puede combinar las redes virtuales de radio de SAP en menos redes o incluso en un solo radio de SAP. Sin embargo, aún tendrá que distinguir entre entornos de producción y que no son de producción. Cada entorno de producción de SAP se convierte en una subred en una red virtual de producción de SAP. Cada entorno que no es de producción de SAP se convierte en una subred de una red virtual que no es de producción de SAP.

Colaboradores

Microsoft se encarga del mantenimiento de este artículo. Originalmente lo escribieron los siguientes colaboradores.

Creadores de entidad de seguridad:

Pasos siguientes