Exploración de la fase piloto

  • 20 minutos

El piloto puede ejecutarse en paralelo al planeamiento y la preparación del proyecto. Esta fase también se puede usar para probar las opciones identificadas en la fase de planeación y preparación. Como parte del proyecto piloto, se recomienda configurar y validar una solución completa de alta disponibilidad y de recuperación ante desastres, así como realizar el diseño de seguridad. En algunos casos, también es posible usar esta fase para realizar pruebas de escalabilidad o implementar sistemas de espacio aislado de SAP. Para ejecutar una prueba piloto, los clientes deben identificar primero un sistema no crítico que quieran migrar a Azure y realizar las siguientes tareas:

1. Optimización de la transferencia de datos a Azure

El enfoque y el resultado dependen en gran medida de la conectividad de un cliente con Azure. En función de la cantidad de datos, es posible usar para este propósito ExpressRoute, un VPN de sitio a sitio o servicios de transferencia de datos sin conexión, como Azure Data Box o el servicio Azure Import/Export.

2. Migración de plataforma heterogénea de SAP

En el caso de querer realizar una migración de plataforma heterogénea de SAP que implique una exportación e importación de los datos de la base de datos, se deben probar y optimizar las fases de exportación e importación. Si va a realizar migraciones heterogéneas de gran tamaño a SQL Server, consulte Migración de un sistema operativo o una base de datos de SAP a SQL Server: preguntas frecuentes. Si no necesita combinar la migración con una actualización de la versión, puede usar Migration Monitor o SWPM; de lo contrario, use Database Migration Option (DMO), de SAP. Para más información, consulte Opción de migración de base de datos (DMO) de SUM: introducción. En cualquier caso, siga estos pasos:

  • Mida el tiempo de exportación desde el origen, cargue el contenido exportado en Azure y realice la importación. Maximice la superposición entre la exportación y la importación.
  • Use la comparación entre las bases de datos de origen y de destino para ajustar correctamente el tamaño de la infraestructura de destino.
  • Valide y optimice los tiempos.

3. Realización de la validación técnica

Tipos de máquina virtual

  • Consulte las notas de soporte técnico de SAP, el directorio de hardware de SAP HANA y la matriz de disponibilidad de productos (PAM) de SAP para tener la certeza de que la información relativa a las SKU de Azure Virtual Machine admitidas, las versiones de sistema operativo compatibles con estas SKU de Azure Virtual Machine y las versiones admitidas de SAP y DBMS es precisa.
  • Valide el tamaño de la infraestructura y los componentes de la aplicación que vaya a implementar en Azure. Al migrar aplicaciones existentes, debe poder obtener los SAP necesarios en función de la telemetría existente. Recupere el punto de referencia de SAP y compárelo con los números de SAP que aparecen en la Nota de SAP 1928533. Además, haga referencia a la información proporcionada en las clasificaciones de SAPS en Microsoft Azure Virtual Machines: dónde buscar y dónde puede confundirse.
  • Evalúe y pruebe el tamaño de las máquinas virtuales de Azure, en relación con el rendimiento máximo de almacenamiento y el rendimiento de la red de los distintos tipos de máquina virtual que eligió en la fase de planeamiento. Estos datos se pueden encontrar en Tamaños de las máquinas virtuales en Azure. Cuando el sistema operativo invitado de la máquina virtual de Azure es Windows, es importante tener en cuenta el rendimiento máximo del disco sin almacenar en caché a la hora de determinar el tamaño. Y lo mismo en el caso de Linux.

Storage

  • Use el almacenamiento SSD estándar de Azure como el mínimo para las máquinas virtuales que representan capas de aplicación de SAP, así como para la implementación de DBMS que detecta la falta de rendimiento y use Azure Premium Storage para las máquinas virtuales de DBMS que detecten el rendimiento.
  • Evite usar discos HDD estándar de Azure.
  • Utilice discos administrados de Azure.
  • Habilite el Acelerador de escritura de Azure para las unidades de registro de DBMS con las máquinas virtuales de Azure de la serie M. Tenga en cuenta los límites y las restricciones de uso documentados del Acelerador de escritura.
  • Para información sobre el almacenamiento relacionado con DBMS, consulte Consideraciones para la implementación de DBMS de máquinas virtuales de Azure para la carga de trabajo de SAP, así como la documentación específica de DBMS a la que se hace referencia en ese documento.
  • En el caso de implementaciones de SAP HANA, consulte Configuraciones y operaciones de infraestructura de SAP HANA en Azure.
  • No utilice el id. de dispositivo para montar discos de datos de Azure en una máquina virtual Linux de Azure. En su lugar, use el identificador único universal (UUID). Tenga cuidado al usar herramientas gráficas para montar un disco de datos de Azure. Compruebe las entradas de /etc/fstab para asegurarse de que los discos se montan con el UUID. Para más información, consulte Conexión a la máquina virtual con Linux para montar el nuevo disco.

Redes

Pruebe y evalúe la infraestructura de la red virtual y la distribución de las aplicaciones de SAP entre las redes virtuales de Azure o dentro de ellas.

  1. Evalúe el enfoque de la arquitectura de red virtual radial o la microsegmentación de una única red virtual de Azure según los siguientes criterios:

    • Costos debidos al intercambio de datos entre redes virtuales de Azure emparejadas (para más información, consulte Precios de Azure Virtual Network).
    • La comparación entre la capacidad para terminar el emparejamiento entre las redes virtuales de Azure y el uso de NSG para aislar las subredes de una red virtual cuando las aplicaciones o máquinas virtuales hospedadas en una subred de la red virtual se conviertan en un riesgo para la seguridad.
    • El registro y la auditoría centralizados del tráfico de red entre el entorno local, Internet y el centro de datos virtual que creó en Azure.

  2. Evalúe y pruebe la ruta de acceso a los datos entre la capa de aplicación de SAP y la capa de DBMS de SAP. Como parte de su evaluación, tenga en cuenta lo siguiente:

    • No se admite la colocación de aplicaciones virtuales de red en la ruta de comunicación entre la aplicación de SAP y la capa DBMS de un sistema SAP NetWeaver, Hybris o S/4HANA.
    • No se admite la colocación del nivel de aplicación de SAP y del DBMS de SAP en redes virtuales de Azure diferentes que no estén emparejadas.
    • Se admite el uso de grupos de seguridad de Aplicación de Azure (ASG) y grupos de seguridad de red (NSG) para controlar el flujo de tráfico entre la capa de aplicación de SAP y la capa de DBMS de SAP.

  3. Asegúrese de que se han habilitado las redes aceleradas de Azure en las máquinas virtuales de Azure que se usan tanto en la capa de aplicación de SAP como en la capa DBMS de SAP. Tenga en cuenta los requisitos del sistema operativo para la compatibilidad de redes aceleradas en Azure:

    • Windows Server 2012 R2 o versiones más recientes
    • SUSE Linux 12 SP3 o versiones más recientes
    • RHEL 7.4 o versiones más recientes
    • Oracle Linux 7.5. El kernel de RHCKL requiere la versión 3.10.0-862.13.1.el7. El kernel de Oracle UEK requiere la versión 5.

  4. Pruebe y evalúe la latencia de red entre la máquina virtual de capa de aplicación de SAP y la máquina virtual de DBMS, para lo que debe seguir los datos de Nota de SAP #500235 y nota de SAP #1100926. Evalúe los resultados con las instrucciones de latencia de red de la nota de SAP 1100926. La latencia de red debe estar en el intervalo de moderada a buena.

  5. Asegúrese de que las implementaciones del equilibrador de carga interno de Azure (ILB) estén configuradas para usar Direct Server Return. Esta configuración reducirá la latencia en los casos en los que se usan equilibradores de carga internos para configuraciones de alta disponibilidad en la capa de DBMS.

  6. Si usa Azure Load Balancer junto con sistemas operativos invitados de Linux, compruebe que el valor del parámetro de red de Linux net.ipv4.tcp_timestamps sea 0. Tenga en cuenta que esto contradice las recomendaciones generales de la Nota de SAP 2382421. La nota de SAP se ha actualizado para reflejar el hecho de que el parámetro debe establecerse en 0 para que funcione junto con los equilibradores de carga de Azure.

Implementaciones de alta disponibilidad y recuperación ante desastres.

  • Si implementa la capa de aplicación de SAP sin que el destino sea ninguna instancia específica de Azure Availability Zones, asegúrese de que todas las máquinas virtuales que ejecutan alguna instancia de diálogo de SAP o instancias de middleware del mismo sistema SAP se implementan en el mismo conjunto de disponibilidad.

    • Si no requiere alta disponibilidad para SAP Central Services y DBMS, estas máquinas virtuales se pueden implementar en el mismo conjunto de disponibilidad en el que se encuentra la capa de aplicación de SAP.

  • Si necesita proteger los servicios centrales de SAP y la capa de DBMS con réplicas pasivas para conseguir alta disponibilidad, implemente los dos nodos de SAP Central Services en un conjunto de disponibilidad y los dos nodos de DBMS en otro conjunto de disponibilidad.

  • Si realiza la implementación en zonas de disponibilidad de Azure, no puede usar los conjuntos de disponibilidad. En su lugar, debe asegurarse de implementar los nodos activos y pasivos de Central Services en dos zonas de disponibilidad diferentes, ya que así es como se logra la mínima latencia posible entre las zonas.

  • Tenga en cuenta que debe usar Azure Standard Load Balancer al crear clústeres de conmutación por error basados en Windows Server o Pacemaker para la capa de SAP Central Services y DBMS en las distintas zonas de disponibilidad. La instancia básica de Load Balancer no admite implementaciones por zona.

Configuración del tiempo de expiración

  • Compruebe los seguimientos de desarrollador de SAP NetWeaver de las instancias de SAP para asegurarse de que no se producen interrupciones de conexión entre el servidor de puesta en cola y los procesos de trabajo de SAP. Estas interrupciones de conexión se pueden evitar estableciendo estos dos parámetros del Registro:

    • HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\KeepAliveTime = 120000. Para más información, consulte KeepAliveTime.
    • HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\KeepAliveInterval = 120000. Para más información, consulte KeepAliveInterval.

  • Para evitar tiempos de espera de la interfaz gráfica de usuario entre las interfaces GUI de SAP implementadas en un entorno local y las capas de aplicación de SAP implementadas en Azure, establezca los parámetros siguientes en default.pfl o en el perfil de la instancia:

    • rdisp/keepalive_timeout = 3600
    • rdisp/keepalive = 20

  • Si usa clústeres de conmutación por error de Windows, asegúrese de que se hayan establecido correctamente los parámetros que determinan si la conmutación por error se desencadena mediante nodos que no responden. En el artículo de Microsoft TechCommunity Ajuste de umbrales de red de clúster de conmutación por error se enumeran los parámetros y su impacto en el comportamiento de la conmutación por error. Por ejemplo, suponiendo que los nodos del clúster estén en la misma subred, asegúrese de configurar los parámetros de conmutación por error de la siguiente manera:

    • SameSubNetDelay = 2000

    • SameSubNetThreshold = 15

    • RoutingHistorylength = 30

    • Pruebe los procedimientos de alta disponibilidad y recuperación ante desastres.

      • Simule operaciones de conmutación por error, para lo que debe apagar las máquinas virtuales de Azure (sistema operativo invitado de Windows) o colocar los sistemas operativos en modo de pánico (sistema operativo invitado de Linux).

      • Mida los tiempos que se tardan en completar las conmutaciones por error. Si tarda demasiado, considere las siguientes opciones:

        • En SUSE Linux, use dispositivos SBD en lugar del agente de barrera de Azure para acelerar la conmutación por error.
        • En el caso de SAP HANA, si la recarga de datos tarda demasiado, considere la posibilidad de mejorar el rendimiento del almacenamiento.

      • Pruebe la secuencia y temporización de la copia de seguridad y restauración, y ajústela si es necesario. Asegúrese de que las horas de copia de seguridad sean suficientes. Además, pruebe la restauración y anote el tiempo empleado de las actividades de restauración. Asegúrese de que los tiempos de restauración estén dentro de los contratos de nivel de servicio de RTO, donde su tiempo objetivo de recuperación (RTO) utiliza un proceso de restauración de la base de datos o de la máquina virtual.

      • Pruebe la funcionalidad y la arquitectura de la recuperación ante desastres.

4. Realización de comprobaciones de seguridad

  • Pruebe la validez del enfoque referente al acceso basado en roles (RBAC) que implementó. El objetivo es separar y limitar el acceso y los permisos delegados a diferentes equipos. Por ejemplo, los miembros del equipo de SAP Basis deberían poder implementar máquinas virtuales de Azure en una red virtual Azure determinada y asignarles discos. Sin embargo, el equipo de SAP Basis no debería poder crear redes virtuales ni modificar las opciones de las redes virtuales existentes. Por el contrario, los miembros del equipo de red no deberían poder implementar máquinas virtuales de Azure en aquellas redes virtuales en las que se ejecuten la aplicación de SAP y máquinas virtuales de DBMS. Tampoco deberían poder cambiar los atributos de las máquinas virtuales ni eliminar ni las máquinas ni sus discos.
  • Compruebe que las reglas de NSG funcionan según lo previsto y asegure los recursos protegidos.
  • Compruebe el cifrado en reposo y en tránsito. Defina e implemente procesos para realizar copias de seguridad, almacenar y obtener acceso a los certificados, así como para validar el proceso de restauración de entidades cifradas.
  • Use Azure Disk Encryption para discos del sistema operativo.
  • Considere un enfoque pragmático al decidir si implementar un mecanismo de cifrado. Por ejemplo, evalúe si es necesario aplicar el cifrado de discos de Azure y el cifrado de base de datos transparente de DBMS.

5. Prueba del rendimiento

En escenarios de migración, use el seguimiento y las medidas de SAP para comparar el piloto con la implementación actual en función de:

  • Los 10 informes en línea principales.
  • Los 10 trabajos por lotes principales.
  • Las transferencia de datos mediante interfaces al sistema SAP, con énfasis en el tráfico entre entornos locales.