Topología de red y conectividad para una migración de SAP

  • Artículo

Este artículo se basa en las consideraciones y recomendaciones definidas en el área de diseño de la zona de aterrizaje de Azure para la topología de red y la conectividad. En las instrucciones de este artículo se examinan las principales consideraciones de diseño y los procedimientos recomendados en relación con las redes y la conectividad hacia, desde y dentro de Microsoft Azure y las implementaciones de SAP. Dado que SAP es una plataforma crítica, el diseño también debe seguir las instrucciones sobre las áreas de diseño de zonas de aterrizaje de Azure.

Planeamiento para la dirección IP

Una planificación del direccionamiento IP en Azure es fundamental para asegurarse de que:

  • El espacio de direcciones IP no se superpone con las ubicaciones locales y las regiones de Azure.
  • La red virtual contenga el espacio de direcciones correcto.
  • Los planes de configuración de subredes se realicen con antelación.

El siguiente diagrama de arquitectura muestra las consideraciones de red en SAP sobre el acelerador de zonas de aterrizaje de Azure:

A diagram of networking considerations in SAP on an Azure landing zone accelerator.

Consideraciones de diseño para la implementación de SAP:

Puede dedicar y delegar subredes para determinados servicios y, a continuación, crear instancias de esos servicios dentro de las subredes. Aunque Azure le ayuda a crear varias subredes delegadas en una red virtual, solo puede tener una subred delegada en una red virtual para Azure NetApp Files. Si usa más de una subred delegada para Azure NetApp Files, no podrá crear un nuevo volumen.

Caso de uso:

Necesita subredes delegadas para implementar Azure NetApp Files. Este enfoque es popular para las implementaciones de SAP que comparten sistemas de archivos. Necesita una subred delegada solo para una puerta de enlace de aplicaciones durante el equilibrio de carga o para SAP BusinessObjects Business Intelligence, que es un servidor de aplicaciones web de SAP con equilibrio de carga.

Configuración de DNS y la resolución de nombres para los recursos locales y de Azure

El sistema de nombres de dominio (DNS) es una parte fundamental de la arquitectura de zonas de aterrizaje de Azure. Es posible que algunas organizaciones deseen usar sus inversiones existentes en DNS. Otros usuarios podrían ver la adopción de la nube como una oportunidad para modernizar su infraestructura DNS interna y usar las funcionalidades nativas de Azure.

Recomendaciones de diseño para la implementación de SAP:

Utilice las siguientes recomendaciones de casos de uso cuando el nombre DNS o el nombre virtual de una máquina virtual no cambia durante la migración.

Caso de uso:

  • Los nombres DNS y virtuales en segundo plano conectan muchas interfaces del sistema en el panorama de SAP y los clientes solo reconocen en algunas ocasiones las interfaces que los desarrolladores definen a lo largo del tiempo. Cuando los nombres DNS o virtuales cambian después de las migraciones, surgen desafíos de conexión entre varios sistemas. Por simplicidad, se recomienda conservar los alias DNS.

  • Use diferentes zonas DNS para distinguir cada entorno, incluidos los entornos de espacio aislado, desarrollo, preproducción y producción, de los demás. Una excepción es para las implementaciones de SAP, que tienen su propia red virtual. En este escenario, es posible que las zonas de DNS privado no sean necesarias.

Definición de una topología de red de Azure

Las zonas de aterrizaje a escala empresarial admiten dos topologías de red. Una topología se basa en Azure Virtual WAN. La otra es una topología de red tradicional que se basa en una arquitectura de tipo hub-and-spoke. En esta sección se describen las configuraciones y procedimientos de SAP recomendados para ambos modelos de implementación.

Use una topología de red basada en Virtual WAN si la organización planea:

  • Implementar recursos en varias regiones de Azure y conectar las ubicaciones globales a Azure y a los entornos locales.
  • Integrar totalmente implementaciones de WAN definidas por software con Azure.
  • Implementar hasta 2000 cargas de trabajo de máquinas virtuales en todas las redes virtuales conectadas a un centro de conectividad de Virtual WAN.

Las organizaciones usan Virtual WAN para cumplir los requisitos de interconectividad a gran escala. Microsoft administra este servicio, lo que ayuda a reducir la complejidad general de la red y a modernizar la red de la organización.

Use una topología de red de Azure tradicional basada en una arquitectura tipo hub-and-spoke si la organización:

  • Planea implementar recursos solo en regiones de Azure seleccionadas.
  • No necesita una red interconectada global.
  • Tiene pocas ubicaciones remotas o de sucursales por cada región y necesita menos de 30 túneles de protocolo de seguridad de Internet (IPsec).
  • Requiere control total y granularidad para configurar manualmente la red de Azure.

Recomendaciones de diseño para la implementación de SAP:

  • Utilice Virtual WAN para implementaciones de Azure en redes grandes o globales, en las que se requiere conectividad de tránsito global entre las regiones de Azure y las ubicaciones locales. Con este enfoque, no tendrá que configurar manualmente el enrutamiento transitivo para las redes de Azure y puede seguir un estándar para las implementaciones de SAP en Azure.

  • Considere la posibilidad de implementar aplicaciones virtuales de red (NVA) entre regiones solo si se usan NVA de asociados. No son necesarias NVA entre regiones o redes virtuales si están presentes NVA nativas. Al implementar las tecnologías de redes y las NVA de los asociados, siga las instrucciones del proveedor para identificar configuraciones en conflicto con las redes de Azure.

  • Virtual WAN administra la conectividad entre redes virtuales de radio para topologías basadas en Virtual WAN, por lo que no es necesario configurar rutas definidas por el usuario (UDR) ni NVA. El rendimiento máximo de red para el tráfico de red a red en el mismo centro virtual es de 50 Gbps. Para superar esta limitación de ancho de banda, las zonas de aterrizaje de SAP pueden usar el emparejamiento de red virtual para conectarse a otras zonas de aterrizaje.

  • Ninguna topología admite implementaciones de NVA entre una aplicación SAP y un servidor de bases de datos.

  • El emparejamiento de red virtual local y global proporciona conectividad y es el enfoque preferido para garantizar la conectividad entre las zonas de aterrizaje para implementaciones de SAP en varias regiones de Azure.

Planeamiento de la conectividad de Internet entrante y saliente

En esta sección se describen los modelos de conectividad recomendados para las conexiones entrantes y salientes con la red pública de Internet como origen y destino. Los servicios de seguridad de red nativos de Azure, como Azure Firewall, Azure Web Application Firewall en Azure Application Gateway y Azure Front Door, son servicios totalmente administrados, por lo que no incurre en los costos operativos y de administración asociados con las implementaciones de infraestructura.

Recomendaciones de diseño para la implementación de SAP:

  • En el caso de los clientes que tienen una superficie global, Azure Front Door facilita las implementaciones de SAP mediante directivas de Azure Web Application Firewall para ofrecer y proteger aplicaciones HTTP y HTTPS globales entre regiones de Azure.

  • Aproveche las ventajas de las directivas de Web Application Firewall en Azure Front Door cuando use Azure Front Door y Application Gateway para proteger las aplicaciones HTTP y HTTPS. Bloquee el tráfico a Application Gateway para que solo reciba tráfico de Azure Front Door.

  • Application Gateway y Web Application Firewall tienen limitaciones cuando Application Gateway actúa como proxy inverso para las aplicaciones web de SAP. Dado que SAP Web Dispatcher y NetScaler son más inteligentes que Application Gateway, debe realizar pruebas exhaustivas si los reemplaza por Application Gateway. Compruebe el estado más reciente y enumere todos los escenarios admitidos y no admitidos, o probados y no probados, si es posible.

  • Use un firewall de aplicaciones web para examinar el tráfico cuando se exponga a Internet. Otra opción consiste en usarlo con el equilibrador de carga o con recursos como Application Gateway o soluciones de terceros, que tienen funcionalidades de firewall integradas.

  • Para evitar la fuga de datos, use Azure Private Link para acceder de forma segura a los recursos de plataforma como servicio (PaaS), como Azure Blob Storage, Azure Files, Azure Data Lake Storage Gen2 y Azure Data Factory. Los puntos de conexión privados también puede ayudar a proteger el tráfico entre redes virtuales y servicios como Azure Storage y Azure Backup. El tráfico entre la red virtual y el servicio habilitado para el punto de conexión privado viaja a través de la red global de Microsoft, lo que evita su exposición a la red pública de Internet.

Implementación de Azure ExpressRoute con alta disponibilidad

Azure ExpressRoute está diseñado para ofrecer una alta disponibilidad y así poder proporcionar conectividad de red privada a nivel de operador a los recursos de Microsoft. No hay un único punto de error en la ruta de acceso de ExpressRoute dentro de la red de Microsoft. Para maximizar la disponibilidad, el segmento del cliente y del proveedor de servicios de su circuito de ExpressRoute también debe crearse para ofrecer una alta disponibilidad.

Recomendaciones de diseño para implementaciones de SAP:

Definición de los requisitos de cifrado de red

En esta sección se analizan las principales recomendaciones para cifrar redes entre los entornos local y Azure, y entre regiones de Azure.

Consideraciones de diseño para las implementaciones de SAP:

  • De forma predeterminada, el tráfico no se cifra cuando se usa ExpressRoute para configurar el emparejamiento privado.

  • No necesita cifrar el tráfico de ExpressRoute para las implementaciones de SAP. El tráfico de SAP normalmente consume mucho ancho de banda y es sensible al rendimiento. Los túneles IPsec cifran el tráfico de Internet de manera predeterminada y el cifrado o descifrado podría afectar negativamente al rendimiento del tráfico.

  • El cliente determina si se debe cifrar el tráfico de SAP. Para obtener más información sobre las opciones de cifrado de red en zonas de aterrizaje a escala empresarial, consulte Topología de red y conectividad.

Segregación de sistemas

En un escenario de SAP existen entornos diferentes, como desarrollo, pruebas, calidad, preproducción y producción, y los clientes tienden a clasificar estos sistemas en construcciones lógicas o físicas para mantener los estándares de seguridad y cumplimiento. La idea es administrar todos los sistemas que tienen el mismo ciclo de vida en un grupo de recursos común. Puede definir estos grupos en varios niveles, como en el nivel de suscripción o grupo de recursos.

Su organización también deben tener en cuenta la seguridad y la estructura de directivas al agrupar los recursos de un panorama de SAP. Sin embargo, para que los transportes de SAP fluyan entre los entornos de desarrollo, pruebas, calidad y producción, su organización podría necesitar:

  • Emparejamiento de red virtual.
  • Aperturas de puertos de firewall entre redes virtuales.
  • UDR y reglas del grupo de seguridad de red (NSG).

No se recomienda hospedar el sistema de administración de bases de datos (DBMS) y las capas de aplicación de los sistemas SAP en diferentes redes virtuales y conectarlos mediante el emparejamiento de red virtual. El tráfico de red excesivo entre las capas puede acumular costos sustanciales.

Recomendaciones adicionales para las implementaciones de SAP:

  • Ninguna topología admite la colocación de la capa de aplicación de SAP y del DBMS de SAP en diferentes redes virtuales de Azure que no están emparejadas.

  • Puede usar las reglas del grupo de seguridad de aplicaciones (ASG) y del NSG para definir listas de control de acceso de seguridad de red entre las capas de aplicación y de DBMS de SAP. Puede añadir máquinas virtuales a ASG para ayudar a administrar su seguridad.

  • Habilite las redes aceleradas de Azure en las máquinas virtuales que usa en las capas de aplicación SAP y DBMS. Los siguientes niveles de sistema operativo admiten redes aceleradas en Azure:

    • Windows Server 2012 R2 o versiones posteriores
    • SUSE Linux Enterprise Desktop 12 SP3 o posterior
    • Red Hat Enterprise Linux 7.4 o posterior.
    • Oracle Linux 7.5
      • El kernel que es compatible con Red Hat Enterprise Linux requiere la versión 3.10.0-862.13.1.el7.
      • El kernel de Oracle Unbreakable Enterprise requiere la versión 5.

  • Asegúrese de que configura las implementaciones internas de Azure Load Balancer para usar la función Direct Server Return. Esta función reduce la latencia cuando se usan las configuraciones del equilibrador de carga interno para las configuraciones de alta disponibilidad en la capa de DBMS.

  • Si usa Load Balancer con sistemas operativos invitados Linux, asegúrese de que el parámetro de red de Linux net.ipv4.tcp_timestamps esté establecido en 0.

  • Para una latencia de red óptima con aplicaciones de SAP, considere la posibilidad de usar grupos con ubicación por proximidad de Azure.

  • Para los proyectos de migración, considere la posibilidad de ajustar los parámetros de red. Por ejemplo, puede mejorar el rendimiento deshabilitando las confirmaciones durante el período de migración.

  • Consulte Portal de soporte técnico de SAP y Nota de SAP 2391465 para más información sobre la implementación de SAP.

Consideraciones de diseño para implementaciones de RISE

Al ejecutar implementaciones de RISE de SAP en Azure, la integración del entorno administrado por SAP con su propio ecosistema de Azure es primordial. Para obtener más información sobre los procedimientos recomendados y las instrucciones, consulte Integración de Azure con cargas de trabajo administradas de RISE de SAP.

La implementación de RISE de SAP suele tener dos opciones, VPN de sitio a sitio o emparejamiento de red virtual, para la conectividad. Si no tiene ninguna carga de trabajo anterior de Azure, la VPN de sitio a sitio podría ser la opción más fácil. Sin embargo, si prevé adoptar Azure como una plataforma estratégica, es posible que le interese configurar una zona de aterrizaje de Azure adecuada y usar el emparejamiento de red virtual con el inquilino de SAP RISE. Para estos escenarios, una zona de aterrizaje simplificada, como la zona de aterrizaje de migración de Cloud Adoption Framework, podría ser una buena opción. Puede adaptar fácilmente este plano técnico a los requisitos del cliente, con un enfoque específico en los parámetros de la red virtual.

La implementación del emparejamiento de red virtual entre inquilinos en el inquilino de RISE de SAP también requiere más trabajo. Debe planear cuidadosamente la arquitectura de red virtual para asegurarse de que no haya intervalos de enrutamiento entre dominios sin clases superpuestos. También debe emparejar correctamente DNS con el inquilino de RISE de SAP.

Por último, si decide configurar una solución de Virtual WAN y también necesita conexiones VPN o ExpressRoute de sitio a sitio, debe tener en cuenta los límites y limitaciones.