Examen de los procedimientos recomendados para la migración de bases de datos de gran tamaño

Completado

Las directrices siguientes se basan en proyectos de clientes reales y en los conocimientos obtenidos de estos proyectos. Estas directrices identifican escenarios que no han funcionado correctamente en el pasado. Un ejemplo es la recomendación de no usar servidores UNIX ni virtualizados como servidores de exportación R3load:

• Con frecuencia, el rendimiento de la exportación es un factor restrictivo en el tiempo de inactividad global. A menudo, el hardware existente tiene más de 4 o 5 años de antigüedad y su actualización supone un costo prohibitivo.
• Por lo tanto, es importante obtener el máximo rendimiento de exportación que resulta práctico lograr.
• En proyectos anteriores, se han dedicado semanas o incluso meses a intentar ajustar el rendimiento de exportación de R3load en plataformas UNIX o virtualizadas, antes de desistir y empezar a usar servidores Intel R3load.
• Los servidores Intel estándar de dos sockets son baratos y ofrecen importantes mejoras del rendimiento, en ocasiones superiores a las obtenidas de los pequeños ajustes posibles en servidores UNIX o virtualizados.
• Los clientes suelen tener granjas de máquinas virtuales existentes, pero a menudo no admiten la descarga moderna ni las tecnologías SR-IOV. La versión de VMware suele ser antigua, no se le han aplicado revisiones o no está configurada para ofrecer un rendimiento de red alto y una latencia baja. Los servidores de exportación de R3load requieren un rendimiento rápido de subprocesos y un rendimiento de red extremadamente alto. Estos servidores pueden ejecutarse entre 10 y 15 horas con un uso de CPU y de red de prácticamente el 100 %. Este no es el caso de uso típico de la mayoría de las granjas de VMware y, en la mayor parte de los casos, las implementaciones de VMware no se han diseñado para controlar una carga de trabajo como R3load.

Sugerencia

No invierta tiempo en optimizar el rendimiento de exportación de R3load en plataformas UNIX o virtualizadas. Si lo hace, no solo perderá el tiempo, sino que le costará mucho más que comprar servidores Intel de bajo costo al principio del proyecto. Por lo tanto, a los clientes de migración de VLDB se les pide que se aseguren de que el equipo del proyecto tenga servidores de exportación R3load modernos y rápidos disponibles al principio del proyecto. Esto reducirá el costo total y los riesgos del proyecto.

Procedimientos recomendados

• Realice una encuesta y un inventario sobre el entorno de SAP actual. Identifique los niveles de los paquetes de soporte técnico de SAP y determine si es necesario aplicar revisiones para admitir instancias de DBMS de destino. En general, la compatibilidad del sistema operativo viene determinada por el kernel de SAP y la compatibilidad de DBMS viene determinada por el nivel de revisión SAP_BASIS.
• Cree una lista de notas sobre el OSS de SAP que deba aplicarse en el sistema de origen, como actualizaciones de SMIGR_CREATE_DDL. Considere la posibilidad de actualizar los kernels de SAP en los sistemas de origen, ya que así evita un gran cambio durante la migración a Azure (por ejemplo, si un sistema ejecuta un kernel antiguo de la versión 7.41, actualice a la versión 7.45 en el sistema de origen para evitar un cambio grande durante la migración).
• Desarrolle y documente la solución de alta disponibilidad y recuperación ante desastres. La documentación debe dividir la solución en la capa de base de datos, la capa de ASCS y la capa del servidor de aplicaciones de SAP. Es posible que se requieran soluciones distintas para las soluciones independientes como TREX o liveCache.
• Desarrolle un documento de ajuste de tamaño y configuración que detalla los tipos de máquina virtual de Azure y la configuración de almacenamiento. Indique la cantidad de discos Prémium, la cantidad de archivos de datos, cómo se distribuyen los archivos de datos entre los discos, el uso de los espacios de almacenamiento y el tamaño del formato NTFS de 64 kb. Asimismo, documente la configuración de copia de seguridad/restauración y la de DBMS, como la configuración de la memoria, el grado máximo de paralelismo y las marcas de seguimiento.
• Desarrolle un documento de diseño de red que incluya la configuración de la red virtual, subred, NSG y UDR.
• Documente e implemente el concepto de seguridad y protección. Quite Internet Explorer, cree un contenedor de Active Directory para servidores y cuentas de servicio SAP y aplique una directiva de firewall que bloquee todos los puertos, salvo un número limitado de puertos requeridos.
• Cree un documento de diseño de la migración de sistema operativo o base de datos que detalle el concepto de división de paquetes y tablas, el número de cargas R3load, las marcas de seguimiento de SQL Server, la ordenación o no ordenación, la configuración RowID de Oracle, la configuración SMIGR_CREATE_DDL, los contadores PerfMon (como filas de BCP/s y rendimiento de BCP en kb/s, CPU, memoria), la configuración RSS, la configuración de redes aceleradas, la configuración del archivo de registro, la configuración de BPE y la configuración de TDE.
• Cree un gráfico del "plan piloto" que muestre el progreso de la exportación o importación de R3load en cada ciclo de prueba. Esto permite que el equipo de migración pueda validar si los ajustes y los cambios mejoran el rendimiento de la exportación o importación de R3load. El eje X refleja el número de paquetes completados y el eje Y es el tiempo transcurrido. Este plan piloto es también fundamental durante la migración de producción, para poder comparar el progreso planeado con el progreso real y con cualquier problema identificado al principio.
• Cree un plan de pruebas de rendimiento. Identifique los 20 informes principales en línea, trabajos por lotes e interfaces principales. Documente los parámetros de entrada (como el intervalo de fechas, la oficina de ventas, la planta, el código de la compañía, etc.) y los entornos de ejecución en el sistema de origen original. Compare con el entorno de ejecución de Azure. Si hay diferencias de rendimiento, ejecute SAT, ST05 y otras herramientas SAP para identificar las instrucciones ineficaces.
• Audite la implementación y la configuración y asegúrese de que los tiempos de espera del clúster, los kernels, la configuración de red y el tamaño de formato NTFS sean coherentes con los documentos del diseño. Establezca contadores PerfMon en los servidores importantes para registrar parámetros de estado básicos cada 90 segundos. Compruebe que los servidores SAP estén en un contenedor de AD independiente y que a dicho contenedor se le haya aplicado una directiva de grupo con la configuración del firewall.
• Compruebe que el consultor principal de la migración del sistema operativo o la base de datos tenga licencia. Solicite el nombre del consultor, su usuario y la fecha de certificación. Abra un mensaje de OSS en BC-INS-MIG y pida a SAP que confirme que el consultor tiene una licencia vigente.
• Si es posible, establezca que todo el equipo del proyecto asociado al proyecto de migración de VLDB esté en una misma ubicación física, no disperso geográficamente en varios continentes y zonas horarias.
• Asegúrese de contar con un plan de reserva adecuado y de que este forme parte de la programación general.
• Seleccione modelos de CPU de Intel de recuento rápido de subprocesos para los servidores de exportación R3load. No use modelos de CPU que "ahorren energía", ya que tienen un rendimiento menor y no usan servidores de cuatro sockets. Intel Xeon E5 Platinum 8158 es un buen ejemplo.

Procedimientos recomendados para evitar problemas

• No subcontrate una consultoría para realizar la exportación y subcontrate otra para realizar la importación. En ocasiones, el sistema de origen está externalizado y lo administra una organización o un asociado que ofrecen consultoría y un cliente quiere migrar a Azure y cambiar a otro asociado. Debido al acoplamiento estricto entre la optimización y la configuración de exportación e importación, es poco probable que la asignación de estas tareas a diferentes organizaciones genere un buen resultado.
• No ahorre en recursos de hardware de Azure durante la migración y la puesta en marcha. Azure Virtual Machines se cobra por minuto y se puede reducir fácilmente. Durante una migración de VLDB, use la máquina virtual más eficaz disponible. Hay clientes que se han puesto en marcha correctamente con sistemas muy grandes (entre un 200  y un 250 %) y posteriormente se han estabilizado durante la ejecución de estos sistemas sobredimensionados. Después de supervisar el uso del sistema durante 4 a 6 semanas, las máquinas virtuales con exceso de capacidad se reducen en tamaño o apagado para reducir los costos.