Lista de comprobación de planeamiento e implementación de cargas de trabajo de SAP en Azure

  • Artículo
  • Tiempo de lectura: 36 minutos

Esta lista de comprobación está diseñada para los clientes que trasladan sus aplicaciones SAP NetWeaver, S/4HANA e Hybris a la infraestructura como servicio de Azure. La lista de comprobación debe ser revisada por un cliente o partner SAP a lo largo del proyecto. Es importante señalar que muchas de las comprobaciones se realizan al principio del proyecto y en la fase de planeamiento. Una vez realizada la implementación, pueden resultar complicado efectuar cambios elementales en la infraestructura de Azure o en las versiones de software de SAP implementadas.

Revise la lista de comprobación en los hitos clave del proyecto. De este modo, podrá detectar los pequeños problemas antes de que se conviertan en problemas serios y tendrá tiempo suficiente para volver a diseñar y probar los cambios necesarios. No considere que esta lista de comprobación está completa. En función de su situación, es posible que tenga que realizar muchas más comprobaciones.

La lista de comprobación no incluye tareas que son independientes de Azure. Por ejemplo, las interfaces de aplicaciones SAP cambian durante un traslado a la plataforma Azure o a un proveedor de hospedaje.

Esta lista de comprobación puede usarse también con los sistemas ya implementados. Es posible que se hayan agregado nuevas características, como el Acelerador de escritura y Availability Zones, y nuevos tipos de máquinas virtuales desde la implementación. Por lo tanto, resulta útil revisar la lista de comprobación periódicamente para asegurarse de que está al tanto de las nuevas características de la plataforma Azure.

Fase de preparación y planificación del proyecto

Durante esta fase, se planea la migración de la carga de trabajo de SAP a la plataforma Azure. Como mínimo, durante esta fase debe crear los siguientes documentos, además de definir y analizar los siguientes elementos de la migración:

  1. Documento de diseño general. Este documento debe contener:
    • El inventario actual de componentes y aplicaciones de SAP, y el inventario de aplicaciones de destino para Azure.
    • Una matriz de asignación de responsabilidades (RACI) que defina las responsabilidades y las asignaciones de las partes implicadas. Empiece en un nivel general y continúe hacia niveles más pormenorizados durante el planeamiento y las primeras implementaciones.
    • La arquitectura general de la solución.
    • Una decisión sobre las regiones de Azure en las que se implementará. Consulte la lista de regiones de Azure. Para conocer qué servicios están disponibles en cada región, consulte Productos disponibles por región.
    • La arquitectura de redes para conectarse desde el entorno local con Azure. Empiece a familiarizarse con el plano técnico del centro de datos virtual de Azure.
    • Los principios de seguridad para la ejecución de datos empresariales de gran impacto en Azure. Para obtener información sobre la seguridad de los datos, comience consultando la documentación de seguridad de Azure.
  2. Documento de diseño técnico. Este documento debe contener:
  3. Un inventario de todas las interfaces de SAP (SAP y no SAP).
  4. Diseño de servicios básicos. Este diseño debe incluir los siguientes elementos:
    • Diseño de Active Directory y DNS.
    • La topología de red dentro de Azure y la asignación de distintos sistemas SAP.
    • La estructura del acceso basado en rol de Azure (Azure RBAC) para los equipos que administran la infraestructura y las aplicaciones de SAP en Azure.
    • La topología del grupo de recursos.
    • La estrategia de etiquetado.
    • La convención de nomenclatura para las máquinas virtuales y otros componentes de la infraestructura o los nombres lógicos.
  5. Contrato de soporte técnico Premier y Profesional de Microsoft. Identifique a su responsable técnico de cuenta (TAM) de Microsoft si tiene un contrato de soporte técnico Premier con Microsoft. Para conocer los requisitos de soporte técnico de SAP, consulte la nota de soporte técnico de SAP 2015553.
  6. El número de suscripciones de Azure y la cuota de núcleos para las suscripciones. Abra solicitudes de soporte técnico para aumentar las cuotas de suscripciones de Azure según sea necesario.
  7. Plan de reducción y migración de datos para migrar datos de SAP a Azure. SAP dispone de instrucciones para los sistemas SAP NetWeaver sobre cómo limitar el volumen de grandes cantidades de datos. Consulte esta guía de SAP sobre la administración de datos en sistemas ERP de SAP. Parte del contenido también se aplica a los sistemas NetWeaver y S/4HANA en general.
  8. Una estrategia de implementación automatizada. La automatización en las implementaciones de infraestructura en Azure tiene como objetivo implementar de manera determinista y obtener resultados deterministas. Muchos clientes usan scripts basados en PowerShell o en la CLI. Sin embargo, hay diversas tecnologías de código abierto que pueden usarse para implementar la infraestructura de Azure para SAP e incluso para instalar software de SAP. Puede encontrar ejemplos en GitHub:
  9. Defina una cadencia periódica de revisión del diseño y la implementación entre usted como cliente, el integrador de sistemas, Microsoft y otras partes implicadas.

Puede ejecutar una prueba piloto antes o durante el planeamiento y la preparación del proyecto. También puede utilizar la fase piloto para probar las estrategias y los diseños realizados durante la fase de planeamiento y preparación. Además, puede ampliar la fase piloto para que sea una prueba de concepto real.

Se recomienda configurar y validar una solución completa de alta disponibilidad y recuperación ante desastres, así como el diseño de la seguridad durante una implementación piloto. Algunos clientes realizan pruebas de escalabilidad durante esta fase. Otros clientes usan implementaciones de sistemas de espacio aislado de SAP como fase piloto. Se supone que ya ha identificado un sistema que desea migrar a Azure para la prueba piloto.

  1. Optimice la transferencia de datos a Azure. La opción óptima depende en gran medida del escenario específico. La transferencia desde el entorno local a través de Azure ExpressRoute es más rápida si el circuito ExpressRoute tiene suficiente ancho de banda. En otros escenarios, es más rápida la transferencia a través de Internet.
  2. En el caso de una migración de plataforma heterogénea de SAP, que implica la exportación e importación de datos, pruebe y optimice las fases de exportación e importación. Para migraciones de gran tamaño en las que SQL Server es la plataforma de destino, puede encontrar recomendaciones. Puede usar Migration Monitor/SWPM si no necesita una actualización de versión combinada. Puede usar el proceso SAP DMO si combina la migración con una actualización de la versión de SAP. Para ello, debe cumplir ciertos requisitos respecto a la combinación de las plataforma DBMS de origen y destino. Este proceso se documenta en Database Migration Option (DMO) of SUM 2.0 SP03 (Opción de migración de base de datos [DMO] de SUM 2.0 SP03).
    1. Rendimiento de la exportación al origen, la carga de archivos de exportación en Azure y la importación. Maximice la superposición entre la exportación y la importación.
    2. Evalúe el volumen de la base de datos en las plataformas de origen y destino con el fin de ajustar el tamaño de la infraestructura.
    3. Valide y optimice los tiempos.
  3. Validación técnica.
    1. Tipos de VM.
      • Revise los recursos en las notas de soporte técnico de SAP, en el directorio de hardware de SAP HANA y, de nuevo, en SAP PAM. Asegúrese de que no hay cambios en las máquinas virtuales compatibles con Azure, las versiones admitidas del sistema operativo para esos tipos de máquinas virtuales, y las versiones admitidas de SAP y DBMS.
      • Valide de nuevo el tamaño de la aplicación y la infraestructura que implementa en Azure. Si traslada aplicaciones existentes, a menudo puede derivar los valores de SAPS necesarios de la infraestructura que utiliza y de la página web del banco de pruebas de SAP, y compararlos con los números de SAPS que aparecen en la nota de soporte técnico de SAP 1928533. Tenga en cuenta también este artículo sobre las puntuaciones SAPS.
      • 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 en los tipos de máquina virtual que eligió en la fase de planeamiento. Puede encontrar los datos aquí:
    2. Almacenamiento.
    3. Redes.
      • Pruebe y evalúe la infraestructura de red virtual y la distribución de las aplicaciones de SAP a través o dentro de las distintas redes virtuales de Azure.
      • Evalúe la aplicación de una estrategia de arquitectura de red virtual de concentrador y radio o bien de una estrategia de microsegmentación dentro de una única red virtual Azure. Base esta evaluación en: 1. Los costos del intercambio de datos entre redes virtuales de Azure emparejadas. Para información sobre los costos, consulte Precios de Virtual Network. 2. Las ventajas de una desconexión rápida del emparejamiento entre las redes virtuales de Azure respecto al cambio del grupo de seguridad de red para aislar una subred dentro de una red virtual. Esta evaluación se aplica en los casos en los que las aplicaciones o las máquinas virtuales hospedadas en una subred de la red virtual se convierten en un riesgo para la seguridad. 3. El registro y la auditoría centralizados del tráfico de red entre el entorno local, el mundo exterior y el centro de datos virtual que creó en Azure.
      • Evalúe y pruebe la ruta de acceso de datos entre el nivel de aplicación de SAP y el nivel de DBMS de SAP.
      • Asegúrese de que se habilitan redes aceleradas de Azure en las máquinas virtuales que se usan en el nivel de aplicación de SAP y en el nivel de DBMS de SAP. Tenga en cuenta que se necesitan distintos niveles de sistema operativo para admitir redes aceleradas en Azure:
        • Windows Server 2012 R2 o posterior.
        • SUSE Linux 12 SP3 o posterior.
        • RHEL 7.4 o posterior.
        • Oracle Linux 7.5. Si usa el kernel de RHCKL, se requiere la versión 3.10.0-862.13.1.el7. Si usa el kernel de Oracle UEK, se requiere la versión 5.
      • Pruebe y evalúe la latencia de red entre las máquinas virtuales del nivel de aplicación de SAP y las máquinas virtuales de DBMS según la notas de soporte técnico de SAP 500235 y 1100926. Evalúe los resultados respecto a la guía de latencia de red de la nota de soporte técnico de SAP 1100926. La latencia de red debe estar en el intervalo de moderada a buena. Se aplican excepciones al tráfico entre las máquinas virtuales y las unidades de instancias grandes de HANA, tal y como se describe en este artículo.
      • Asegúrese de que las implementaciones de ILB se configuran para usar Direct Server Return. Este valor reducirá la latencia en los casos en que se usen los ILB de Azure para las configuraciones de alta disponibilidad en el nivel de DBMS.
      • Si usa Azure Load Balancer junto con sistemas operativos invitados de Linux, compruebe que el parámetro de red de Linux net.ipv4.tcp_timestamps esté establecido en 0. Esta recomendación entra en conflicto con las recomendaciones de las versiones anteriores de la nota de SAP 2382421. Esta nota de SAP se ha actualizado para indicar que el parámetro debe establecerse en 0 para trabajar con equilibradores de carga de Azure.
      • Considere la posibilidad de usar los grupos de selección de ubicación de proximidad de Azure para conseguir una latencia de red óptima. Para más información, consulte Grupos de selección de ubicación de proximidad de Azure para una latencia de red óptima con aplicaciones SAP.
    4. Implementaciones de alta disponibilidad y recuperación ante desastres.
      • Si implementa el nivel de aplicación de SAP sin definir una zona de disponibilidad de Azure concreta, asegúrese de que todas las máquinas virtuales que ejecutan instancias de diálogo SAP o instancias middleware de un único sistema SAP se implementan en un conjunto de disponibilidad.
      • Si no necesita alta disponibilidad para SAP Central Services y DBMS, puede implementar estas máquinas virtuales en el mismo conjunto de disponibilidad que el nivel de aplicación de SAP.
      • Si protege la alta disponibilidad de SAP Central Services y el nivel de DBMS con réplicas pasivas, sitúe los dos nodos de SAP Central Services en un único conjunto de disponibilidad independiente y los dos nodos de DBMS en otro conjunto de disponibilidad.
      • Si implementa en Azure Availability Zones, no puede usar los conjuntos de disponibilidad. Sin embargo, tiene que asegurarse de que implementa los nodos activo y pasivo de Central Services en dos zonas de disponibilidad diferentes. Use zonas de disponibilidad que tengan la menor latencia entre ellas. Tenga en cuenta que deberá usar Azure Standard Load Balancer en caso de que establezca clústeres de conmutación por error de Windows o Pacemaker para el nivel de SAP Central Services y DBMS en las zonas de disponibilidad. No se puede usar Load Balancer básico con implementaciones zonales.
    5. Configuración del tiempo de espera.
      • 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 los niveles de aplicación de SAP implementados en Azure, compruebe si están establecidos los parámetros siguientes en default.pfl o en el perfil de la instancia:
        • rdisp/keepalive_timeout = 3600
        • rdisp/keepalive = 20
      • Para evitar la interrupción de las conexiones establecidas entre el proceso de puesta en cola de SAP y los procesos de trabajo de SAP, debe establecer el parámetro enque/encni/set_so_keepalive en true. Consulte también la nota de SAP 2743751.
      • Si usa una configuración de clúster de conmutación por error de Windows, asegúrese de que el tiempo para reaccionar en nodos que no responden se configura correctamente para Azure. En el artículo sobre el ajuste de los umbrales de red en clúster de conmutación por error se muestran los parámetros y cómo afectan a las sensibilidades de la conmutación por error. Suponiendo que los nodos del clúster estén en la misma subred, debe cambiar estos parámetros:
        • SameSubNetDelay = 2000
        • SameSubNetThreshold = 15
        • RoutingHistorylength = 30
    6. Correcciones o configuraciones del sistema operativo
  4. Pruebe los procedimientos de alta disponibilidad y recuperación ante desastres.
    1. Simule situaciones de conmutación por error apagando las máquinas virtuales (sistemas operativos invitados de Windows) o colocando los sistemas operativos en modo de pánico (sistemas operativos invitados de Linux). Este paso le ayudará a averiguar si las configuraciones de conmutación por error funcionan según lo previsto.
    2. Mida cuánto tiempo se tarda en ejecutar una conmutación por error. Si tarda demasiado, considere las siguientes opciones:
      • Para SUSE Linux, use dispositivos SBD en lugar del agente de barrera de Azure para acelerar la conmutación por error.
      • Para SAP HANA, si la recarga de datos tarda demasiado, considere la posibilidad de aprovisionar más ancho de banda de almacenamiento.
    3. Pruebe la secuencia de copia de seguridad y restauración, y el tiempo que lleva; realice correcciones si es necesario. Asegúrese de que las horas de copia de seguridad son suficientes. También debe probar las actividades de restauración y los tiempos. Asegúrese de que los tiempos de restauración están dentro del objetivo de tiempo de recuperación del contrato de nivel de servicio en los casos en que este objetivo se basa en un proceso de restauración de base de datos o de máquina virtual.
    4. Pruebe la funcionalidad y la arquitectura de la recuperación ante desastres entre regiones.
  5. Comprobaciones de seguridad.
    1. Pruebe la validez de la arquitectura de control de acceso basado en rol de Azure (Azure RBAC). El objetivo es separar y limitar el acceso y los permisos de los diferentes equipos. Por ejemplo, los miembros del equipo de SAP Basis deberían poder implementar máquinas virtuales y asignar discos de Azure Storage a una red virtual Azure determinada. Este equipo, sin embargo, no debería poder crear sus propias redes virtuales ni modificar la configuración de las redes virtuales existentes. Por otra parte, los miembros del equipo de red no deberían poder implementar máquinas virtuales en redes virtuales donde se ejecuten máquinas virtuales de DBMS y aplicaciones de SAP. Tampoco deberían poder cambiar los atributos de las máquinas virtuales ni eliminar máquinas virtuales o discos.
    2. Compruebe que las reglas del grupo de seguridad de red y de ASC funcionan según lo previsto y blindan los recursos protegidos.
    3. Asegúrese de que se cifren todos los recursos que deben cifrarse. Defina e implemente procesos para realizar copias de seguridad de los certificados, almacenarlos y acceder a ellos, y para restaurar las entidades cifradas.
    4. Utilice Azure Disk Encryption para los discos del sistema operativo siempre que sea posible desde el punto de vista de la compatibilidad con el sistema operativo.
    5. Asegúrese de que no está usando demasiados niveles de cifrado. En algunos casos, tiene sentido usar Azure Disk Encryption con uno de los métodos de Cifrado de datos transparente del DBMS para proteger distintos discos o componentes en el mismo servidor. Por ejemplo, en un servidor de DBMS de SAP, Azure Disk Encryption (ADE) puede estar habilitado en el disco de arranque del sistema operativo (si el sistema operativo admite ADE) y en los discos de datos no utilizados por los archivos de persistencia de datos de DBMS. Un ejemplo consiste en usar ADE en el disco que contiene las claves de cifrado TDE de DBMS.
  6. Pruebas de rendimiento. Basándose en las medidas y el seguimiento de SAP, realice estas comparaciones en SAP:
    • Si procede, compare los diez principales informes en línea con la implementación actual.
    • Si procede, compare los diez principales trabajos por lotes con la implementación actual.
    • Compare las transferencias de datos a través de las interfaces en el sistema SAP. Céntrese en las interfaces en las que sepa que la transferencia se está llevando a cabo entre distintas ubicaciones; por ejemplo, desde el entorno local a Azure.

Fase de no producción

En esta fase se supone que, después de completar una prueba piloto o una prueba de concepto correctamente, se empiezan a implementar sistemas SAP que no son de producción en Azure. Incorpore en esta implementación todo lo que aprendió y experimentó durante la POC. Todos los criterios y los pasos indicados para las pruebas de concepto se aplican también a esta implementación.

En esta fase, normalmente se implementan sistemas de desarrollo, sistemas de pruebas unitarias y sistemas de pruebas de regresión empresarial en Azure. Se recomienda que al menos un sistema de no producción en una línea de aplicación de SAP tenga la configuración de alta disponibilidad completa que va a tener el futuro sistema de producción. Estos son algunos pasos adicionales que debe completar durante esta fase:

  1. Antes de pasar los sistemas de la plataforma anterior a Azure, recopile datos de consumo de recursos, como el uso de CPU, el rendimiento de almacenamiento y los datos de E/S por segundo. Recopile estos datos especialmente en las unidades del nivel de DBMS, pero también en las unidades del nivel de aplicación. Mida también la latencia de la red y del almacenamiento.
  2. Registre los patrones de tiempo de uso de disponibilidad de los sistemas. El objetivo es averiguar si los sistemas de no producción deben estar disponibles permanentemente o si hay sistemas de no producción que se pueden apagar durante ciertas fases de una semana o un mes.
  3. Pruebe y determine si quiere crear imágenes de sistema operativo propias para las máquinas virtuales en Azure o si quiere utilizar una imagen de Azure Compute Gallery (anteriormente denominada Shared Image Gallery). Si usa una imagen de Azure Compute Gallery, asegúrese de utilizar una que refleje el contrato de soporte técnico con el proveedor del sistema operativo. En el caso de algunos proveedores de sistemas operativos, Azure Compute Gallery permite traer imágenes de licencia propias. Para otras imágenes de sistema operativo, el soporte técnico se incluye en el precio presupuestado por Azure. Si decide crear sus propias imágenes de sistema operativo, encontrará documentación en estos artículos:
  4. Si usa imágenes de SUSE o de Red Hat Linux procedentes de Azure Compute Gallery, tendrá que usar las imágenes para SAP que proporcionan los proveedores de Linux en esta galería.
  5. Asegúrese de cumplir los requisitos de soporte técnico de SAP para los contratos de soporte técnico de Microsoft. Consulte la nota de soporte técnico de SAP 2015553. Para instancias grandes de HANA, consulte Requisitos de incorporación.
  6. Asegúrese de que las personas adecuadas obtienen las notificaciones de mantenimiento planeado, para que pueda elegir los mejores tiempos de inactividad.
  7. Busque con cierta frecuencia presentaciones de Azure en canales como Channel 9, para conocer las nuevas funciones que pueden aplicarse a sus implementaciones.
  8. Compruebe las notas de SAP relacionadas con Azure, como la nota de soporte técnico 1928533, para informarse sobre nuevas SKU de máquina virtual y las nuevas versiones compatibles del sistema operativo y DBMS. Compare los precios de los nuevos tipos de máquinas virtuales con los tipos de máquinas virtuales anteriores, de modo que pueda implementar máquinas virtuales con la mejor relación precio/rendimiento.
  9. Vuelva a comprobar las notas de soporte técnico de SAP, el directorio de hardware de SAP HANA y SAP PAM. Asegúrese de que no hay cambios en las máquinas virtuales compatibles con Azure, las versiones admitidas del sistema operativo para esas máquinas virtuales, y las versiones admitidas de SAP y DBMS.
  10. Busque en el sitio web de SAP nuevas SKU con certificación HANA en Azure. Compare los precios de las nuevas SKU con las que planeó usar. Realice los cambios necesarios para usar las que ofrezcan la mejor relación precio/rendimiento.
  11. Adapte los scripts de implementación para usar los nuevos tipos de máquina virtual e incorporar las nuevas características de Azure que quiere usar.
  12. Tras la implementación de la infraestructura, pruebe y evalúe la latencia de red entre las máquinas virtuales del nivel de aplicación de SAP y las máquinas virtuales de DBMS, según la notas de soporte técnico de SAP 500235 y 1100926. Evalúe los resultados respecto a la guía de latencia de red de la nota de soporte técnico de SAP 1100926. La latencia de red debe estar en el intervalo de moderada a buena. Se aplican excepciones al tráfico entre las máquinas virtuales y las unidades de instancias grandes de HANA, tal y como se describe en este artículo. Asegúrese de que ninguna de las restricciones mencionadas en Consideraciones para la implementación de DBMS de Azure Virtual Machines para la carga de trabajo de SAP y Configuraciones y operaciones de infraestructura de SAP HANA en Azure se aplican a la implementación.
  13. Asegúrese de que las máquinas virtuales se implementan en el grupo de selección de ubicación de proximidad de Azure correcto, tal como se describe en Grupos de selección de ubicación de proximidad de Azure para una latencia de red óptima con aplicaciones SAP.
  14. Antes de aplicar la carga de trabajo, realice las demás comprobaciones indicadas para la fase de prueba de concepto.
  15. A medida que se aplique la carga de trabajo, registre el consumo de recursos de los sistemas en Azure. Compare este consumo con los registros de la plataforma anterior. Si observa grandes diferencias, ajuste el tamaño de las máquinas virtuales de las futuras implementaciones. Tenga en cuenta que si reduce el tamaño, también se reducirán los anchos de banda de almacenamiento y red de las máquinas virtuales.
  16. Realice pruebas con la funcionalidad y los procesos de copia del sistema. El objetivo es facilitar la copia de un sistema de desarrollo o un sistema de pruebas, para que los equipos de proyecto puedan obtener rápidamente los nuevos sistemas.
  17. Optimice y perfeccione los accesos basados en rol, los permisos y los procesos de Azure de su equipo para asegurarse de conseguir la separación de funciones. Al mismo tiempo, asegúrese de que todos los equipos pueden realizar sus tareas en la infraestructura de Azure.
  18. Practique, pruebe y documente los procedimientos de alta disponibilidad y recuperación ante desastres para permitir que su personal ejecute estas tareas. Identifique las deficiencias y adapte la nueva funcionalidad de Azure que va a integrar en las implementaciones.

Fase de preparación de producción

En esta fase recopilará lo que experimentó y aprendió durante las implementaciones que no son de producción y lo aplicará a las futuras implementaciones de producción. También deberá preparar el trabajo de la transferencia de datos entre la ubicación actual de hospedaje y Azure.

  1. Lleve a cabo las actualizaciones de versiones de SAP necesarias en los sistemas de producción antes de pasar a Azure.
  2. Póngase de acuerdo con los propietarios de empresas sobre las pruebas funcionales y empresariales que deben realizarse después de la migración del sistema de producción.
  3. Asegúrese de que todas estas pruebas se llevan a cabo con los sistemas de origen en la ubicación de hospedaje actual. Evite realizar pruebas por primera vez después de que el sistema se mueva a Azure.
  4. Pruebe el proceso de migración de los sistemas de producción a Azure. Si no traslada todos los sistemas de producción a Azure en el mismo plazo de tiempo, cree grupos de sistemas de producción que deben estar en la misma ubicación de hospedaje. Pruebe la migración de datos. Estos son algunos métodos habituales:
    • Use métodos de DBMS, como la copia de seguridad y restauración en combinación con SQL Server Always On, la replicación del sistema de HANA o el trasvase de registros para inicializar y sincronizar el contenido de base de datos en Azure.
    • Use la copia de seguridad y restauración para las bases de datos más pequeñas.
    • Use SAP Migration Monitor, integrado en SAP SWPM, para realizar migraciones heterogéneas.
    • Use el proceso SAP DMO si tiene que combinar la migración con una actualización de la versión de SAP. Tenga en cuenta que no todas las combinaciones de DBMS de origen y de destino son compatibles. Encontrará más información en las notas de soporte técnico de SAP específicas para las diferentes versiones de DMO. Por ejemplo, Database Migration Option (DMO) of SUM 2.0 SP04 (Opción de migración de base de datos [DMO] de SUM 2.0 SP04).
    • Compruebe si el rendimiento de la transferencia de datos es mejor a través de Internet o de ExpressRoute, en caso de que tenga que mover copias de seguridad o archivos de exportación de SAP. Si va a mover datos a través de Internet, es posible que deba cambiar algunas de las reglas del grupo de seguridad de red o del grupo de seguridad de aplicación que necesitará aplicar en los futuros sistemas de producción.
  5. Antes de mover los sistemas de la plataforma anterior a Azure, recopile los datos de consumo de recursos. Entre los datos útiles se incluyen el uso de CPU, el rendimiento de almacenamiento y los datos de IOPS. Recopile estos datos especialmente en las unidades del nivel de DBMS, pero también en las unidades del nivel de aplicación. Mida también la latencia de la red y del almacenamiento.
  6. Vuelva a consultar las notas de soporte técnico de SAP y la configuración necesaria del sistema operativo, el directorio de hardware de SAP HANA, y SAP PAM. Asegúrese de que no hay cambios en las máquinas virtuales compatibles con Azure, las versiones admitidas del sistema operativo para esas máquinas virtuales, y las versiones admitidas de SAP y DBMS.
  7. Actualice los scripts de implementación para tener en cuenta las decisiones más recientes que ha adoptado en lo que respecta a los tipos de máquina virtual y la funcionalidad de Azure.
  8. Después de implementar la infraestructura y las aplicaciones, compruebe lo siguiente:
    • Se implementaron los tipos correctos de máquina virtual, con los atributos y los tamaños de almacenamiento correctos.
    • Las máquinas virtuales tienen las versiones de sistema operativo y las revisiones correctas que desea, y son uniformes.
    • Las máquinas virtuales están protegidas según es necesario y de forma uniforme.
    • Se han instalado e implementado las versiones y revisiones correctas de las aplicaciones.
    • Las máquinas virtuales se implementaron en conjuntos de disponibilidad de Azure según lo previsto.
    • Se usó Azure Premium Storage para los discos sensibles a la latencia o cuando se requiere el contrato de nivel de servicio del 99,9 % para una única máquina virtual.
    • El Acelerador de escritura de Azure se implementó correctamente.
    • Se usaron exclusivamente discos administrados de Azure.
    • Las máquinas virtuales se implementaron en los conjuntos y las zonas de disponibilidad correctos.
    • Las redes aceleradas de Azure están habilitadas en las máquinas virtuales que se usan en el nivel de aplicación de SAP y el nivel de DBMS de SAP.
    • No existen aplicaciones virtuales de red de Azure en la ruta de comunicación entre el nivel de aplicación de SAP y de DBMS de un sistema SAP basado en SAP NetWeaver, Hybris o S/4HANA.
    • Las reglas de grupo de seguridad de aplicación y de grupo de seguridad de red permiten la comunicación deseada y planeada, y bloquean la comunicación donde es necesario.
    • La configuración del tiempo de espera se ha establecido de forma correcta, tal y como se describió anteriormente.
    • Las máquinas virtuales se implementan en el grupo de selección de ubicación de proximidad de Azure correcto, tal como se describe en Grupos de selección de ubicación de proximidad de Azure para una latencia de red óptima con aplicaciones SAP.
    • La latencia de red entre las máquinas virtuales del nivel de aplicación de SAP y las máquinas virtuales del DBMS se prueba y se valida según se describe en las notas de soporte técnico de SAP 500235 y 1100926. Evalúe los resultados respecto a la guía de latencia de red de la nota de soporte técnico de SAP 1100926. La latencia de red debe estar en el intervalo de moderada a buena. Se aplican excepciones al tráfico entre las máquinas virtuales y las unidades de instancias grandes de HANA, tal y como se describe en este artículo.
    • El cifrado se implementó donde era necesario y con el método de cifrado adecuado.
    • Las interfaces y otras aplicaciones pueden conectarse la infraestructura recién implementada.
  9. Cree un cuaderno de estrategias para reaccionar ante el mantenimiento planeado de Azure. Determine el orden en el que los sistemas y las máquinas virtuales deben reiniciarse para el mantenimiento planeado.

Fase de puesta en marcha

Durante la fase de puesta en marcha, asegúrese de seguir los cuadernos de estrategias que desarrolló en las fases anteriores. Ejecute los pasos que probó y entrenó; no acepte cambios de última hora en las configuraciones y los procesos. Complete también los siguientes pasos:

  1. Compruebe que la supervisión de Azure Portal y otras herramientas de supervisión funcionan. Se recomiendan el Monitor de rendimiento (perfmon) para Windows y SAR para Linux.
    • Contadores de CPU.
      • Tiempo medio de CPU, total (todas las CPU)
      • Tiempo medio de CPU, cada procesador individual (128 procesadores en máquinas virtuales M128)
      • Tiempo de kernel de CPU, cada procesador individual
      • Tiempo de usuario de CPU, cada procesador individual
    • Memoria.
      • Memoria libre
      • Entrada de páginas en memoria/segundo
      • Salida de páginas de memoria/segundo
    • disco.
      • Lectura de disco en Kbps, por disco individual
      • Lecturas de disco/segundo, por disco individual
      • Lectura de disco en microsegundos/lectura, por disco individual
      • Escritura en disco en Kbps, por disco individual
      • Escritura en disco/segundo, por disco individual
      • Escritura en disco en microsegundos/lectura, por disco individual
    • Red.
      • Entrada de paquetes en red/segundo
      • Salida de paquetes de red/segundo
      • kB de entrada en red/segundo
      • kB de salida de red/segundo
  2. Después de la migración de datos, realice todas las pruebas de validación acordadas con los propietarios de empresas. Acepte únicamente los resultados de pruebas de validación si dispone de los resultados de los sistemas de origen originales.
  3. Compruebe si las interfaces funcionan y si otras aplicaciones pueden comunicarse con los sistemas de producción recién implementados.
  4. Compruebe el sistema de transporte y corrección mediante STMS de transacciones de SAP.
  5. Realice copias de seguridad de las bases de datos una vez que el sistema esté listo para producción.
  6. Realice copias de seguridad de las máquinas virtuales en el nivel de aplicación de SAP una vez que el sistema está listo para producción.
  7. Para los sistemas SAP que no formaban parte de la fase de puesta en marcha actual, pero que se comunican con los sistemas SAP que trasladó a Azure en esta fase de puesta en marcha, debe restablecer el búfer de nombres de host en SM51. Este paso eliminará las direcciones IP anteriores almacenadas en caché, asociadas a los nombres de las instancias de aplicación que trasladó a Azure.

Postproducción

En esta fase se trata de la supervisión, el funcionamiento y la administración del sistema. Desde el punto de vista de SAP, se aplican las tareas habituales que era necesario realizar en la anterior ubicación de hospedaje. Complete también estas tareas específicas de Azure:

  1. Revise las facturas de Azure para detectar sistemas con cargos elevados.
  2. Optimice la eficiencia de precio/rendimiento en las máquinas virtuales y en el almacenamiento.
  3. Optimice las horas en las que puede apagar los sistemas.

Pasos siguientes

Consulte estos artículos: