Lista de comprobación de planeamiento e implementación de cargas de trabajo de SAP en Azure
Artículo
Esta lista de comprobación está diseñada para los clientes que trasladan sus aplicaciones de SAP a la infraestructura como servicio de Azure. Las aplicaciones de SAP de este documento representan productos de SAP que ejecutan el kernel de SAP, como SAP NetWeaver, S/4HANA, BW, BW/4 y otros. 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 la situación, es posible que tenga que realizar más comprobaciones adicionales.
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. La documentación de SAP y las notas de soporte técnico también contendrán más tareas, que no son específicas de Azure, pero que deben formar parte de la lista de comprobación general del planeamiento.
Esta lista de comprobación puede usarse también con los sistemas ya implementados. Es posible que se hayan aplicado nuevas características o cambios en las recomendaciones para su entorno. Resulta útil revisar la lista de comprobación periódicamente para asegurarse de estar al tanto de las nuevas características de la plataforma de Azure.
El contenido principal de este documento está organizado en pestañas, en el orden cronológico de un proyecto típico. Consulte el contenido de cada pestaña y considere cada pestaña siguiente para basarse en las acciones realizadas y los aprendizajes obtenidos en la fase anterior. Para una migración de producción, se debe tener en cuenta el contenido de todas las pestañas y no solo en la pestaña de producción. Para ayudarle a asignar las fases de un proyecto típico con la definición de fase utilizada en este artículo, consulte la tabla siguiente.
Fases de la lista de comprobación de implementación
Fases o hitos del proyecto de ejemplo
Fase de preparación y planeamiento
Fase de inicio, diseño y definición del proyecto
Fase piloto
Validación temprana/ prueba de concepto/piloto
Fase de no producción
Finalización de la fase de diseño detallada/ compilaciones de entornos que no son de producción/ pruebas
Fase de preparación de producción
Ensayo general / pruebas de aceptación de usuario / simulación de migración final / comprobaciones para la puesta en directo
Fase de puesta en marcha
Migración final y puesta en directo en producción
Fase posterior a la producción
Hypercare / transición al negocio como de costumbre
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. Se deben consultar los procedimientos recomendados y las arquitecturas de ejemplo del Centro de arquitectura de SAP en 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.
Estrategia de almacenamiento para cubrir dispositivos de bloques (disco administrado) y sistemas de archivos compartidos (como Azure Files o Azure NetApp Files) que se deben refinar aún más en los tamaños y diseños del sistema de archivos en el documento de diseño técnico.
Documento de diseño técnico
Este documento debe contener:
Un diagrama de bloques de la solución que muestre las aplicaciones y servicios de SAP y que no son de SAP
Un proyecto de SAP Quicksizer basado en los volúmenes de documentos empresariales. A continuación, se asigna la salida de Quicksizer a los componentes de proceso, almacenamiento y redes en Azure. Como alternativa a SAP Quicksizer, un dimensionamiento diligente en función de la carga de trabajo actual de los sistemas SAP de origen. Teniendo en cuenta la información disponible, como los informes de la carga de trabajo de DBMS, los informes de SAP EarlyWatch y los indicadores de rendimiento de proceso y almacenamiento.
La arquitectura de continuidad empresarial y recuperación ante desastres.
Información detallada sobre las versiones del sistema operativo, la base de datos, el kernel y los paquetes de soporte de SAP. El hecho de que SAP NetWeaver o S/4HANA admitan una versión de sistema operativo determinada no implica necesariamente que también la admitan las máquinas virtuales de Azure. Lo mismo puede decirse de las versiones de DBMS. Compruebe las siguientes fuentes para alinear y, si es necesario, actualizar las versiones de SAP, DBMS y sistema operativo para garantizar la compatibilidad de SAP y Azure. Para obtener soporte técnico completo de SAP y Microsoft debe tener combinaciones de versiones compatibles con SAP y Azure. Si es necesario, deberá planear la actualización de algunos componentes de software. Aquí se documentan más detalles sobre el software SAP, sistema operativo y DBMS compatibles:
Nota de SAP 2039619. En esta nota se define la matriz de compatibilidad de Oracle para Azure. Oracle solo admite Windows y Oracle Linux como sistemas operativos invitados en Azure para cargas de trabajo de SAP. Esta declaración de soporte técnico se aplica también a la capa de aplicación de SAP que ejecuta instancias de SAP, siempre que contengan el cliente de Oracle.
Las máquinas virtuales de Azure compatibles con SAP HANA se enumeran en el sitio web de SAP. Los detalles de cada entrada contienen requisitos y especificaciones, incluida la versión del sistema operativo admitida. Esta podría no coincidir con la versión más reciente del sistema operativo según la nota de SAP 2235581.
Discos administrados conectados a cada máquina virtual
Diseños y dimensionamiento del sistema de archivos
Tamaños y diseño del volumen SMB o NFS, puntos de montaje cuando corresponda
Arquitectura de alta disponibilidad, copia de seguridad y recuperación ante desastres
Basándose en el RTO y el RPO, defina cómo debe ser la arquitectura de alta disponibilidad y recuperación ante desastres.
Comprenda el uso de diferentes tipos de implementación para una protección óptima.
Consideraciones para la implementación del DBMS de Azure Virtual Machines para las cargas de trabajo de SAP y documentos relacionados. En Azure, no se admite el uso de una configuración de disco compartido para la capa de DBMS como, por ejemplo, se ha descrito para SQL Server. En su lugar, use soluciones como:
Para la recuperación ante desastres en regiones de Azure, revise las soluciones que ofrecen los distintos proveedores de DBMS. La mayoría de ellos admiten replicación asincrónica o trasvase de registros.
Para el nivel de aplicación de SAP, determine si va a ejecutar sistemas de prueba de regresión empresarial, que en condiciones ideales son réplicas de las implementaciones de producción, en la misma región de Azure o en la región de recuperación ante desastres. En el segundo caso, puede utilizar ese sistema de regresión empresarial como destino de recuperación ante desastres para las implementaciones de producción.
En el caso de los proyectos que tengan que permanecer en una sola región por motivos de cumplimiento, considere la posibilidad de usar una configuración combinada de HADR mediante Azure Availability Zones.
Un inventario de todas las interfaces de SAP y los sistemas conectados (SAP y no SAP).
Operaciones de seguridad para recursos de Azure y las cargas de trabajo contenidas
Concepto de seguridad para proteger la carga de trabajo de SAP. Esto debe incluir todos los aspectos: redes y supervisión perimetral, seguridad de aplicaciones y bases de datos, sistemas operativos que protegen y cualquier medida de infraestructura necesaria, como el cifrado. Identifique los requisitos con los equipos de cumplimiento y seguridad.
Microsoft recomienda el contrato de soporte técnico Professional Direct, Premier o Unificado. Identifique las rutas de derivación de problemas y los contactos para obtener soporte técnico con Microsoft. Para conocer los requisitos de soporte técnico de SAP, consulte la nota de SAP 2015553.
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.
Una estrategia de implementación automatizada. Muchos clientes comienzan con scripts, mediante una combinación de PowerShell, la CLI, Ansible y Terraform.
Las soluciones desarrolladas por Microsoft para la automatización de la implementación de SAP son:
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.
Fase piloto (expresamente recomendada)
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.
Optimice la transferencia de datos a Azure. La opción óptima depende en gran medida del escenario específico. Si se requiere conectividad privada para la replicación de bases de datos, Azure ExpressRoute es más rápido si el circuito de ExpressRoute tiene suficiente ancho de banda. En cualquier otro escenario, es más rápida la transferencia mediante Internet. Opcionalmente, use una VPN de migración dedicada para la conectividad privada con Azure. Cualquier ruta de acceso de red de migración durante el piloto debe reflejar el uso de los sistemas de producción futuros, lo que elimina cualquier impacto en las cargas de trabajo (SAP o no SAP) que ya se ejecutan en Azure.
En el caso de una migración heterogénea de SAP que implique la exportación e importación de datos, pruebe y optimice las fases de exportación e importación. Para la migración de entornos de SAP de gran tamaño, siga los procedimientos recomendados disponibles. Use la herramienta adecuada para el escenario de migración, en función de las versiones de SAP de origen y destino, el DBMS y si combina la migración con otras tareas como una actualización de versión o incluso la conversión de Unicode o S/4HANA. SAP proporciona monitor de migración/SWPM, SAP DMO o DMO con movimiento del sistema, además de otros enfoques para minimizar el tiempo de inactividad disponible como servicio independiente de SAP. En las versiones más recientes de SAP DMO con movimiento del sistema, también se admite el uso de azcopy para la transferencia de datos mediante Internet, lo que permite la ruta de acceso de red más rápida de forma nativa.
Migración de bases de datos de gran tamaño (VLDB) a Azure para SAP
Validación técnica
Tipos de proceso y máquina virtual
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 hacer coincidir 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 el DBMS.
Valide de nuevo el tamaño de la aplicación y la infraestructura que implementa en Azure. Si va a trasladar las aplicaciones existentes, a menudo puede derivar los SAPS necesarios de la infraestructura que utiliza y de la página web del punto de referencia de SAP, y compararlos con los números SAPS que aparecen en la nota de SAP 1928533. Tenga en cuenta también este artículo sobre las puntuaciones SAPS.
Evalúe y pruebe el dimensionamiento de las máquinas virtuales de Azure en relación con el rendimiento máximo del almacenamiento y de la red de los tipos de máquina virtual que eligió en la fase de planeamiento. Están disponibles los detalles de los límites de rendimiento de las máquinas virtuales; para el almacenamiento, es importante tener en cuenta el límite de rendimiento máximo de disco sin almacenamiento en caché para el dimensionamiento. Considere detenidamente el dimensionamiento y los efectos temporales de la expansión de nivel de disco y máquina virtual.
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 conocida como 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.
El uso de imágenes del sistema operativo propias permite almacenar las dependencias empresariales necesarias, como los agentes de seguridad, la protección y las personalizaciones, directamente en la imagen. De esta forma, se implementan inmediatamente con cada máquina virtual. Si decide crear sus propias imágenes del sistema operativo, puede encontrar documentación en estos artículos:
Si usa imágenes de Linux de Azure Compute Gallery y agrega protección como parte de la canalización de implementación, debe usar las imágenes adecuadas para SAP proporcionadas por los proveedores de Linux.
La elección de una imagen del sistema operativo determina el tipo de generación de la máquina virtual de Azure. Azure admite máquinas virtuales de Hyper-V de generación 1 y 2. Algunas familias de máquinas virtuales solo están disponibles como generación 2, algunas familias de máquinas virtuales están certificadas para uso de SAP solo como generación 2 (nota de SAP 1928533) incluso si Azure permite ambas generaciones. Se recomienda usar la máquina virtual de generación 2 para cada máquina virtual del entorno de SAP.
Para ver los distintos tipos de DBMS, consulte la documentación genérica de DBMS relacionada con SAP y las documentaciones específicas del DBMS a las que apunta el primer documento. Use el seccionamiento de discos en varios discos con Premium Storage (v1 o v2) para los datos de base de datos y el área de registro. Compruebe que el seccionamiento de disco de lvm esté activo y con el tamaño de franja correcto con el comando "lvs -a -o+lv_layout,lv_role,stripes,stripe_size,devices" en Linux; consulte las propiedades de los espacios de almacenamiento en Windows.
Use LVM para todos los discos de las máquinas virtuales Linux, ya que permite una administración y una expansión en línea más sencillas. Esto incluye los volúmenes en discos individuales, por ejemplo, /usr/sap.
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 el enfoque de arquitectura de red virtual WAN virtual de tipo hub-and-spoke con radios de red virtual discretos para la carga de trabajo de SAP. Para una escala menor, un enfoque de microsegmentación dentro de una única red virtual de Azure. Base esta evaluación en:
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.
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.
No se admite la inclusión de aplicaciones virtuales de red de Azure en la ruta de comunicación entre la aplicación de SAP y la capa de DBMS de los sistemas SAP que ejecutan el kernel de SAP.
No se admite la colocación del nivel de aplicación de SAP y del DBMS de SAP en diferentes redes virtuales de Azure que no están emparejadas.
Asegúrese de que las redes aceleradas estén habilitadas en todas las máquinas virtuales que se usan para SAP.
Pruebe y evalúe la latencia de red entre las máquinas virtuales de la capa de aplicación de SAP y las máquinas virtuales de DBMS según la notas de SAP 500235 y 1100926. Además de la herramienta niping de SAP, puede usar herramientas como sockperf o ethr para la medición de la latencia de TCP. Evalúe los resultados respecto a la guía sobre latencia de red de la nota de SAP 1100926. La latencia de red debe estar en el intervalo de moderada a buena.
Optimice el rendimiento de red en las máquinas virtuales de vCPU elevadas, que normalmente se usan para los servidores de bases de datos. Especialmente importante para el escalado horizontal de HANA y cualquier sistema SAP de gran tamaño. Siga las recomendaciones de este artículo para la optimización.
Para obtener una latencia de red óptima, considere la posibilidad de seguir las instrucciones de los escenarios de ubicación por proximidad del artículo. No se hace uso de los grupos con ubicación por proximidad para patrones de implementación zonales o entre zonas.
Compruebe la disponibilidad, el enrutamiento y el acceso seguro correctos desde el entorno de SAP a cualquier punto de conexión de Internet necesario, como los repositorios de revisiones del sistema operativo, las herramientas de implementación o el punto de conexión de servicio. De forma similar, si el entorno de SAP proporciona un servicio accesible públicamente, como SAP Fiori o SAProuter, compruebe que sea accesible y esté protegido.
Implementaciones de alta disponibilidad y recuperación ante desastres
Use siempre Standard Load Balancer para entornos en clúster. Basic Load Balancer se va a retirar.
Seleccione las opciones de implementación adecuadas en función de la configuración del sistema preferida dentro de una región de Azure, independientemente de si implica la expansión entre zonas, residir dentro de una sola zona o trabajar en una región sin zona.
En la implementación regional, para proteger los servicios centrales de SAP y las capas de DBMS para alta disponibilidad mediante la replicación pasiva, coloque los dos nodos para SAP Central Services en un conjunto de disponibilidad independiente y los dos nodos de DBMS en otro conjunto de disponibilidad. No mezcle roles de máquina virtual de aplicación dentro de un conjunto de disponibilidad.
Para la implementación entre zonas, configure el sistema mediante un conjunto de escalado flexible con FD=1 e implemente los nodos de servicios centrales activos y pasivos y la capa de DBMS en dos zonas de disponibilidad diferentes. Use dos zonas de disponibilidad que tengan la menor latencia entre ellas.
Para la implementación entre zonas, se recomienda usar un conjunto de escalado flexible con FD=1 a través de la implementación de zona de disponibilidad estándar.
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.
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. Puede evitar estos saltos de conexión 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 GUI entre las interfaces de GUI de SAP locales y las capas de aplicación de SAP implementadas en Azure, compruebe si estos parámetros se establecen en default.pfl o en el perfil de 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 (número de milisegundos entre "latidos")
SameSubNetThreshold = 15 (número máximo de latidos consecutivos perdidos)
Correcciones o configuraciones del sistema operativo
Para ejecutar HANA en SAP, lea estas notas y documentación, además de la documentación no específica de SAP y otras notas de soporte técnico:
Notas de SAP específicas de Azure vinculadas a los componentes de soporte técnico de SAP BC-OP-NT-AZR o BC-OP-LNX-AZR. Recorra las notas con detenimiento, ya que contienen soluciones actualizadas.
Prueba de los procedimientos de alta disponibilidad y recuperación ante desastres
Simule situaciones de conmutación por error mediante una herramienta como NotMyFault (Windows) o mediante la puesta de los sistemas operativos en modo de pánico o la deshabilitación de la interfaz de red con ifdown (Linux). Este paso le ayudará a averiguar si las configuraciones de conmutación por error funcionan según lo previsto.
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.
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.
Pruebe la funcionalidad y la arquitectura de recuperación ante desastres entre regiones y compruebe que el RPO y el RTO coincidan con sus expectativas.
Comprobaciones de seguridad
Pruebe la validez de la arquitectura de control de acceso basado en rol de Azure (Azure RBAC). La separación de deberes requiere separar y limitar el acceso y los permisos de los diferentes equipos. Por ejemplo, los miembros del equipo base de SAP deberían poder implementar máquinas virtuales y asignar discos de Azure Storage a una máquina 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.
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.
Para el cifrado del almacenamiento, está habilitado de manera predeterminada el cifrado del lado servidor con clave administrada por la plataforma (SSE-PMK) para todos los servicios de almacenamiento que se usan para SAP en Azure, incluidos los discos administrados, Azure Files y Azure NetApp Files. Puede considerarse la posibilidad de usar la administración de claves con claves administradas por el cliente, si es necesario para la rotación de claves de propiedad del cliente.
La mayoría de los clientes de SAP en Azure implementan el cifrado nativo de bases de datos para proteger los datos y las copias de seguridad del DBMS. El Cifrado de datos transparente (TDE) normalmente no tiene ninguna sobrecarga de rendimiento notable, aumenta considerablemente la seguridad y se debe tener en cuenta. La ubicación y la administración de claves de cifrado deben estar protegidas. El cifrado de base de datos se realiza dentro de la máquina virtual y es independiente de cualquier cifrado de almacenamiento, como SSE.
Pruebas de rendimiento Basándose en las medidas y el seguimiento de SAP, realice estas comparaciones en SAP:
Inventario y línea base del sistema local actual.
Informes de SAR/perfmon.
STAT trace top 10 online reports.
Recopilar historial de trabajos por lotes.
Pruebas de enfoque para comprobar el rendimiento de los procesos empresariales. No compare los KPI de hardware inicialmente y en vacío, solo cuando se solucionan problemas sobre diferencias de rendimiento.
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. Estas son algunas tareas que debe completar durante esta fase:
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. Adapte el dimensionamiento y el diseño con los datos capturados. Se deben utilizar herramientas como syststat, KSAR, nmon y el analizador de nmon para Excel para capturar y presentar el uso de los recursos en los períodos de valores máximos.
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.
Vuelva a evaluar la opción de imagen del sistema operativo, la generación de las máquinas virtuales (generación 2 en todo el entorno de SAP) y la estrategia de revisión del sistema operativo.
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 SAP 2015553.
Consulte las notas de SAP relacionadas con Azure, como la nota 1928533, para informarse sobre las nuevas SKU de máquina virtual y las nuevas versiones admitidas del sistema operativo y el 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.
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.
Consulte en el sitio web de SAP las nuevas SKU certificadas para 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.
Adapte la automatización de la implementación para usar los nuevos tipos de máquina virtual e incorporar las nuevas características de Azure que quiera usar.
Después de la implementación de la infraestructura, pruebe y evalúe la latencia de red entre las máquinas virtuales de la capa de aplicación de SAP y las máquinas virtuales del DBMS, según la nota de SAP 500235. Evalúe los resultados respecto a la guía sobre latencia de red de la nota de SAP 1100926. La latencia de red debe estar en el intervalo de moderada a buena. Además de usar herramientas como niping, sockperf o ethr, use la herramienta HCMT de SAP para las mediciones de red entre las máquinas virtuales de HANA para el escalado horizontal y la replicación del sistema.
Si ve una latencia superior a la esperada entre máquinas virtuales, considere la posibilidad de seguir las instrucciones del artículo escenarios de selección de ubicación de proximidad.
Antes de aplicar la carga de trabajo, realice todas las demás comprobaciones enumeradas para la fase de prueba de concepto.
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 el almacenamiento y el anchos de banda red de las máquinas virtuales.
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.
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.
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.
Lleve a cabo las actualizaciones de versiones de SAP necesarias en los sistemas de producción antes de pasar a Azure.
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.
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.
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, incluidas las interfaces y las aplicaciones que no son de SAP conectadas.
Estos son algunos métodos comunes:
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 el proceso SAP DMO para escenarios admitidos para el traslado o si necesita combinar la migración con una actualización de la versión de SAP y/o el traslado a HANA. 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, Opción de migración de base de datos (DMO) de SUM 2.0 SP15.
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.
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.
Vuelva a consultar las notas 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.
Actualice la automatización de la 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.
Cree un cuaderno de estrategias para reaccionar ante los eventos de mantenimiento planeado de Azure. Determine el orden en el que los sistemas y las máquinas virtuales deben reiniciarse para el mantenimiento planeado.
Ejercite, pruebe y documente los procedimientos de alta disponibilidad y recuperación ante desastres para permitir que el personal ejecute estas tareas durante la migración e inmediatamente después de la decisión de puesta en directo.
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:
Compruebe que la supervisión de Azure Portal y otras herramientas de supervisión funcionan. Use herramientas de Azure como Azure Monitor para la supervisión de la infraestructura. Azure Monitor para SAP para una combinación de KPI de sistema operativo y de aplicación, lo que le permite integrar todo en un panel para obtener visibilidad durante y después de la puesta en directo.
Para los indicadores clave de rendimiento del sistema operativo:
En Linux, asegúrese de que la herramienta sysstat esté instalada y capturando detalles a intervalos regulares.
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.
Compruebe si las interfaces funcionan y si otras aplicaciones pueden comunicarse con los sistemas de producción recién implementados.
Compruebe el sistema de transporte y corrección mediante STMS de transacciones de SAP.
Realice copias de seguridad de las bases de datos una vez que el sistema esté listo para producción.
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.
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:
Revise las facturas de Azure para detectar sistemas con cargos elevados. Instale una referencia cultural de finOps y cree una funcionalidad de optimización de costos de Azure en su organización.
Optimice la eficiencia de precio/rendimiento en las máquinas virtuales y en el almacenamiento.
Una vez que SAP en Azure se haya estabilizado, el enfoque debe cambiar a una referencia cultural de revisiones continuas de dimensionamiento y capacidad. A diferencia del entorno local, donde se determina el tamaño para un largo período, el ajuste de tamaño adecuado es una ventaja clave de la ejecución de la carga de trabajo de SAP en Azure y un planeamiento diligente de la capacidad será clave.
Optimice las horas en las que puede apagar los sistemas.
Una vez que la solución se haya estabilizado en Azure, considere la posibilidad de alejarse de un modelo comercial de Pago por uso y aprovechar las instancias reservadas de Azure.
Planee y ejecute simulacros de recuperación ante desastres regulares.
Defina e implemente su estrategia en torno a "mantenerse siempre a la última" para alinear su propia hoja de ruta con la hoja de ruta de SAP en Azure de Microsoft para beneficiarse del avance de la tecnología.
Lista de comprobación de la infraestructura de SAP en Azure
Después de implementar la infraestructura y las aplicaciones, y antes de que se inicie cada migración, valide lo siguiente:
Se han implementado los tipos correctos de máquina virtual, con los atributos y la configuración de almacenamiento correctos.
Las máquinas virtuales tienen una versión del sistema operativo, el DBMS y el kernel de SAP actualizada y se revisan el sistema operativo, la base de datos y el kernel de SAP de manera uniforme en todo el entorno.
Las máquinas virtuales están protegidas y protegidas según sea necesario y de manera uniforme en el entorno respectivo.
Las máquinas virtuales se implementaron en un conjunto de escalado flexible con FD=1 en zonas de disponibilidad o en un conjunto de disponibilidad.
Se han implementado máquinas virtuales de generación 2. Las máquinas virtuales de generación 1 no deben usarse para nuevas implementaciones.
Asegúrese de que, dentro de las máquinas virtuales, los espacios de almacenamiento o los conjuntos de franjas se hayan creado correctamente en los sistemas de archivos que requieren más disco, como los datos del DBMS y las áreas de registro.
Se han utilizado el tamaño de franja y el tamaño de bloque del sistema de archivos correctos, si se indica en las guías del DBMS correspondientes.
El almacenamiento y el almacenamiento en caché de máquinas virtuales de Azure se usan correctamente
Asegúrese de que solo los discos que contienen registros en línea del DBMS se almacenen en caché con el Acelerador de escritura None+.
Otros discos con Premium Storage usan la configuración de caché o None o ReadOnly, según el uso.
Uso de servicios de Azure (Azure Files o Azure NetApp Files) para cualquier volumen o recurso compartido SMB o NFS. Los volúmenes NFS o los recursos compartidos SMB son accesibles por el entorno de SAP respectivo o los sistemas SAP individuales. El enrutamiento de red al servidor NFS/SMB pasa por el espacio de direcciones de red privada, mediante un punto de conexión privado si es necesario.
Las redes aceleradas de Azure están habilitadas en cada interfaz de red para todas las máquinas virtuales de SAP.
No hay aplicaciones virtuales de red en la ruta de comunicación entre la capa de aplicación de SAP y la del DBMS en sistemas SAP basados en SAP NetWeaver o la plataforma ABAP.
Todos los equilibradores de carga para los componentes de alta disponibilidad de SAP usan Standard Load Balancer con dirección IP flotante y los puertos de alta disponibilidad habilitados.
Las máquinas virtuales del DBMS y la aplicación de SAP se han colocado en las misma subred o en subredes diferentes de una red virtual o en redes virtuales emparejadas directamente.
Las reglas del grupo de seguridad de red y del grupo de seguridad de aplicación permiten la comunicación deseada y planeada, y bloquean la comunicación cuando es necesario.
La configuración del tiempo de espera se ha establecido de forma correcta, tal y como se describió anteriormente.
Si se usan grupos con ubicación por proximidad, compruebe si los conjuntos de disponibilidad y sus máquinas virtuales se han implementado en el grupo con ubicación por proximidad correcto.
La latencia de red entre las máquinas virtuales de la capa de aplicación de SAP y las máquinas virtuales del DBMS se han probado y validado según se describe en las notas de SAP 500235 y 1100926. Evalúe los resultados respecto a la guía sobre latencia de red de la nota de SAP 1100926. La latencia de red debe estar en el intervalo de moderada a buena.
El cifrado se implementó donde era necesario y con el método de cifrado adecuado.
Las propias claves de cifrado están protegidas contra la pérdida, la destrucción o el uso malintencionado.
Las interfaces y otras aplicaciones pueden conectarse a la infraestructura recién implementada.
Comprobaciones e información automatizadas en el entorno de SAP
Varias de las comprobaciones anteriores se comprueban de forma automatizada con la Herramienta de comprobación de calidad de SAP en Azure. Estas comprobaciones se pueden ejecutar de forma automatizada con el proyecto de código abierto proporcionado. Aunque no se realiza ninguna corrección automática de los problemas encontrados, la herramienta advertirá sobre una configuración contraria a las recomendaciones de Microsoft.
Otras herramientas para permitir comprobaciones de implementación más sencillas y documentar los hallazgos, planear los siguientes pasos de corrección y optimizar en general el entorno de SAP en Azure son:
Revisión del Marco de buena arquitectura de Azure Una evaluación de la carga de trabajo centrada en los cinco pilares principales de confiabilidad, seguridad, optimización de costos, excelencia operativa y eficiencia del rendimiento. Admite cargas de trabajo de SAP y se recomienda ejecutar una revisión al principio y después de cada fase del proyecto.
Comprobaciones de inventario de Azure para SAP Un libro de código abierto de Azure Monitor que muestra el inventario de Azure con inteligencia para resaltar el desfase de la configuración y mejorar la calidad.