Migración de base datos grandes a Azure: Recomendaciónn y guía para socios (es-MX)

Artículo
17/01/2024

Artículo Original: https://blogs.msdn.microsoft.com/saponsqlserver/2018/04/10/very-large-database-migration-to-azure-recommendations-guidance-to-partners/

Los sistemas SAP movidos a la nube Azure ahora incluyen comúnmente grandes sistemas multinacionales de "instancia global única" y son mucho más grandes que los primeros sistemas de clientes implementados cuando la plataforma Azure fue certificada por primera vez para cargas de trabajo de SAP hace algunos años.

Las bases de datos muy grandes (VLDB) ahora se mueven comúnmente a Azure. Los tamaños de bases de datos de más de 20 TB requieren algunas técnicas y procedimientos adicionales para lograr una migración de local a Azure dentro de un tiempo de inactividad aceptable y bajo riesgo.

El siguiente diagrama muestra una migración de VLDB con SQL Server como el DBMS de destino. Se supone que los sistemas fuente son Oracle o DB2

Un blog futuro cubrirá la migración a HANA (DMO) en Azure. Muchos de los conceptos explicados en este blog son aplicables a las migraciones de HANA

Este blog no reemplaza la guía SAP System Copy existente y las Notas de SAP que deben revisarse y seguirse.

Introducción

Una migración de VLDB totalmente optimizada debería lograr un rendimiento de migración de aproximadamente 2TB por hora o posiblemente más.

Esto significa que el componente de transferencia de datos de una migración de 20TB se puede hacer en aproximadamente 10 horas. Varios pasos de posprocesamiento y validación tendrían que realizarse.

En general, con el tiempo adecuado para la preparación y las pruebas, casi cualquier sistema de clientes de cualquier tamaño se puede mover a Azure.

Las migraciones de VLDB requieren una considerable habilidad, atención al detalle y análisis. Por ejemplo, el impacto neto de Table Splitting se debe medir y analizar. La división de una tabla grande en más de 50 exportaciones paralelas puede disminuir considerablemente el tiempo necesario para exportar una tabla, pero demasiadas divisiones de tabla pueden dar como resultado un aumento drástico de los tiempos de importación. Por lo tanto, el impacto neto de la división de tablas debe ser calculado y probado. Un experto consultor de migración OS / DB con licencia estará familiarizado con los conceptos y herramientas. Este blog está destinado a ser un complemento para resaltar algunos contenidos específicos de Azure para las migraciones de VLDB

Este blog trata sobre la migración de OS / DB heterogénea a Azure con SQL Server como la base de datos de destino utilizando herramientas como R3load y Migmon. Los pasos que se realizan aquí no están destinados a copias homogéneas del sistema (una copia en la que el DBMS y la arquitectura del procesador (orden Endian) se mantienen iguales). En general, las copias de sistemas homogéneos deben tener un tiempo de inactividad muy bajo, independientemente del tamaño del DBMS, ya que el envío de registros se puede utilizar para sincronizar una copia de la base de datos en Azure.

A continuación se ilustra un diagrama de bloques de una migración típica de OS / DB VLDB y se mueve a Azure. Los puntos clave que se ilustran a continuación:

La fuente actual OS / DB a menudo es AIX, HPUX, Solaris o Linux y DB2 u Oracle
El sistema operativo objetivo es Windows, Suse 12.3, Redhat 7.x u Oracle Linux 7.x
El DB de destino suele ser SQL Server u Oracle 12.2
IBM pSeries, el hardware Solaris SPARC y el rendimiento de subprocesos de HP Superdome son drásticamente más bajos que los servidores básicos modernos de bajo costo de Intel, por lo tanto, R3load se ejecuta en servidores Intel separados.
VMWare requiere ajuste y configuración especiales para lograr un rendimiento de red bueno, estable y predecible. Normalmente, los servidores físicos se usan como servidores R3load y no como máquinas virtuales.
Comúnmente se usan cuatro servidores R3load de exportación, aunque no hay límite en la cantidad de servidores de exportación. Una configuración típica sería:

-Export Server # 1 - dedicado a las tablas 1-4 más grandes (dependiendo de qué tan sesgada esté la distribución de datos en la base de datos fuente)

-Export Server # 2 - dedicado a tablas con divisiones de tabla

-Export Server # 3 - dedicado a tablas con divisiones de tabla

-Export Server # 4 - todas las tablas restantes

Los archivos de volcado de exportación se transfieren desde el disco local en el servidor R3load basado en Intel a Azure usando AzCopy a través de internet público (esto es típicamente más rápido que a través de ExpressRoute, aunque no en todos los casos)
El control y la secuencia de la importación se realiza a través del archivo de señal (SGN) que se genera automáticamente cuando se completan todos los paquetes de exportación. Esto permite una exportación / importación semi-paralela
Importar a SQL Server u Oracle está estructurado de manera similar a la exportación, aprovechando cuatro servidores de importación. Estos servidores serían servidores R3load dedicados separados con redes aceleradas. Se recomienda no usar los servidores de aplicaciones de SAP para esta tarea
Las bases de datos de VLDB normalmente usarían máquinas virtuales E64v3, m64 o m128 con Almacenamiento Premium. El Registro de transacciones se puede colocar en el disco SSD local para acelerar las anotaciones del Registro de transacciones y eliminar el IOPS del registro de transacciones y el ancho de banda IO de la cuota VM. Después de la migración, el Registro de transacciones debe colocarse en un disco persistente.

https://msdnshared.blob.core.windows.net/media/2018/04/040518_0153_VeryLargeDa1.png

Optimizaciones del sistema fuente

Se debe seguir la siguiente guía para la fuente de exportación de sistemas VLDB:

Tablas técnicas de purga y datos innecesarios - revisar la Nota de SAP 2388483 - Cómo hacer: Gestión de datos para tablas técnicas
Separar los procesos de R3load del servidor DBMS es un paso esencial para maximizar el rendimiento de las exportaciones
R3load debe ejecutarse en la nueva y rápida CPU Intel. No ejecute R3load en servidores UNIX ya que el rendimiento es muy bajo. Los servidores Intel de 2 zócalos con 128 GB de RAM cuestan poco y le ahorrarán días o semanas de ajuste / optimización o tiempo de consulta
Red de alta velocidad, idealmente 10 Gb con mínimos saltos de red entre el servidor de base de datos fuente y los servidores de Intel R3load
Se recomienda utilizar servidores físicos para los servidores de exportación R3load: los servidores R3load virtualizados en algunos sitios de los clientes no demostraron buen rendimiento o confiabilidad a un rendimiento de red extremadamente alto (Nota: un ingeniero VMWare muy experimentado puede configurar VMWare para que funcione bien)
Secuencia de tablas más grandes al inicio de Orderby.txt
Configure la exportación / importación semi-paralela utilizando archivos de señal
Las exportaciones grandes se beneficiarán de la exportación sin clasificar en tablas más grandes. Es importante revisar el impacto neto de las exportaciones no clasificadas, ya que la importación de exportaciones no ordenadas a bases de datos que tienen un índice agrupado en la clave principal será más lento
Configure Jumbo Frames entre el servidor de origen de origen y los servidores de Intel R3load. Consulte la sección "Optimización de red" más adelante
Ajuste la configuración de la memoria en el servidor de la base de datos de origen para optimizar las tareas secuenciales de lectura / exportación 936441 - Configuración de Oracle para la copia del sistema basado en R3load

Optimizaciones avanzadas del sistema de origen

División de la tabla de ID de Oracle Splitting

SAP ha publicado SAP Note 1043380 que contiene una secuencia de comandos que convierte la cláusula WHERE en un archivo WHR en un valor ID de ROW. Alternativamente, las últimas versiones de SAPInst generarán automáticamente ROW ID dividir archivos WHR si SWPM está configurado para la migración de Oracle a R3load de Oracle. Los archivos STR y WHR generados por SWPM son independientes de OS / DB (como lo son todos los aspectos del proceso de migración de OS / DB).

La nota de OSS contiene la declaración "NO se puede usar la división de tablas ROWID si la base de datos de destino no es una base de datos Oracle". Técnicamente, los archivos de volcado R3load son completamente independientes de la base de datos y del sistema operativo. Sin embargo, hay una restricción, el reinicio de un paquete durante la importación no es posible en SQL Server. En este escenario, se deberá descartar toda la tabla y reiniciar todos los paquetes de la tabla. Siempre se recomienda eliminar las tareas de R3load para una tabla de división específica, TRUNCATE la tabla y reinicia todo el proceso de importación si se cancela una R3load dividida. La razón para esto es que el proceso de recuperación integrado en R3load implica hacer declaraciones DELETE individuales fila por fila para eliminar los registros cargados por el proceso R3load que aborta. Esto es extremadamente lento y a menudo causará situaciones de bloqueo / bloqueo en la base de datos. La experiencia ha demostrado que es más rápido comenzar la importación de esta tabla específica desde el principio, por lo tanto, la limitación mencionada en la Nota 1043380 no es en absoluto una limitación.

ROW ID tiene la desventaja de que el cálculo de las divisiones se debe realizar durante el tiempo de inactividad; consulte la nota SAP 1043380.

Vamos a crear múltiples "clones" de la base de datos fuente y exporte en paralelo

Un método para aumentar el rendimiento de exportación es exportar desde copias múltiples de la misma base de datos. Siempre que la infraestructura subyacente, como servidor, red y almacenamiento sea escalable, este enfoque es linealmente escalable. Exportar desde dos copias de la misma base de datos será el doble de rápido, 4 copias serán 4 veces más rápido. Migration Monitor está configurado para exportar en un número selecto de tablas de cada "clon" de la base de datos. En el caso siguiente, la carga de trabajo de exportación se distribuye aproximadamente en un 25% en cada uno de los 4 servidores de bases de datos.

-DB Server1 & Export Server # 1 - dedicado a las tablas 1-4 más grandes (dependiendo de qué tan sesgada esté la distribución de datos en la base de datos fuente)

-DB Server2 & Export Server # 2 - dedicado a tablas con divisiones de tabla

-DB Server3 y Export Server # 3 - dedicado a tablas con divisiones de tabla

-DB Server4 y Export Server # 4 - todas las tablas restantes

Se debe tener mucho cuidado para asegurar que las bases de datos estén exactamente sincronizadas, de lo contrario podría ocurrir una pérdida de datos o inconsistencias en los datos. Siempre que se sigan con precisión los pasos a continuación, se proporciona integridad de datos.

Esta técnica es simple y barata con el hardware estándar de Intel, pero también es posible para los clientes que ejecutan hardware propietario de UNIX. Los recursos de hardware sustanciales están libres hacia la mitad de un proyecto de migración de OS / DB cuando los sistemas Sandbox, Desarrollo, QAS, Capacitación y DR ya se han trasladado a Azure. No existe un requisito estricto de que los servidores "clonados" tengan recursos de hardware idénticos. Siempre que haya un rendimiento adecuado de CPU, RAM, disco y red, la adición de cada clon aumenta el rendimiento

Si aún se requiere un rendimiento de exportación adicional, abra un incidente de SAP en BC-DB-MSS para pasos adicionales para aumentar el rendimiento de las exportaciones (consultores muy avanzados solamente)

Pasos para implementar una exportación paralela múltiple:

Haga una copia de seguridad de la base de datos primaria y restaure en "n" cantidad de servidores (donde n = número de clones). En el caso ilustrado 3 se elige haciendo un total de 4 servidores de bases de datos
Restaure la copia de seguridad en 3 servidores
Establezca el envío de registros desde el servidor de bases de datos primarios a 3 servidores "clónicos" de destino
Supervise el envío de registros durante varios días y asegúrese de que el envío de registros funcione de manera confiable
Al inicio del tiempo de inactividad, apague todos los servidores de aplicaciones SAP, excepto el PAS. Asegúrese de que todo el procesamiento por lotes se detiene y todo el tráfico RFC se detiene
En la transacción SM02 ingrese el texto "Punto de verificación PAS en ejecución". Esta tabla de actualizaciones TEMSG
Detenga el servidor de aplicaciones principal. SAP ahora está completamente apagado. No más actividad de escritura puede ocurrir en el DB fuente. Asegúrese de que ninguna aplicación que no sea SAP esté conectada al DB de origen (nunca debe haber, pero verifique si hay sesiones que no sean de SAP en el nivel DB)
Ejecute esta consulta en el servidor de base de datos primaria SELECT EMTEXT FROM <schema> .TEMSG;
Ejecute la instrucción de nivel de DBMS nativo INSERT INTO <schema> .TEMSG "CHECKPOINT R3LOAD EXPORT STOP dd: mm: yy hh: mm: ss" (la sintaxis exacta depende del DBMS de origen. INSERTAR en EMTEXT)
Detenga las copias de seguridad automáticas del registro de transacciones. Ejecute manualmente una copia de seguridad de registro de transacciones final en el servidor de base de datos primaria. Asegúrese de que la copia de seguridad del registro se copie a los servidores clónicos
Restaure la copia de seguridad final del registro de transacciones en los 3 nodos
Recuperar la base de datos en los 3 nodos "clonados"
Ejecute la siguiente instrucción SELECT en * todos * 4 nodos SELECT EMTEXT FROM <schema> .TEMSG;
Con un teléfono o una cámara, vamos a tomar una captura de los resultados de la pantalla de la declaración SELECT para cada uno de los 4 servidores de bases de datos (el primario y los 3 clones). Asegúrese de incluir cuidadosamente cada nombre de host en la foto; estas fotografías son prueba de que el clon DB y el primario son idénticos y contienen los mismos datos del mismo momento. Conserve estas fotos y solicite al cliente que firme el estado de replicación de DB
Iniciamos export_monitor.bat en cada servidor de exportación Intel R3load
Iniciamos la copia del archivo de volcado en el proceso de Azure (ya sea AzCopy o Robocopy)
Iniciamos import_monitor.bat en las máquinas virtuales R3load Azure

Diagrama que muestra el envío de registros del servidor de DB de producción existente para "clonar" bases de datos. Cada servidor de bases de datos tiene uno o más servidores de Intel R3load

https://msdnshared.blob.core.windows.net/media/2018/04/040518_0153_VeryLargeDa2.png

Optimizaciones de carga de red

Los marcos Jumbo son marcos de Ethernet más grandes que los 1500 bytes predeterminados. Los tamaños típicos de marcos jumbo son 9000 bytes. Al aumentar el tamaño de fotograma en el servidor de base de datos fuente, todos los dispositivos de red intermedios, como los conmutadores y los servidores Intel R3load, reducen el consumo de CPU y aumentan el rendimiento de la red. El tamaño de fotograma debe ser idéntico en todos los dispositivos; de lo contrario, se producirá una conversión de gran intensidad de recursos.

Se pueden activar o configurar las características de red adicionales como Receive Side Scaling (RSS) para distribuir el procesamiento de red entre múltiples procesadores. La ejecución de servidores R3load en VMWare ha demostrado que hacer ajustes de red para Jumbo Frames y RSS es más complejo y no se recomienda nivel de habilidad disponible

R3load exporta datos de tablas DBMS y comprime estos datos independientes de formato sin formato en archivos de volcado. Estos archivos de volcado deben cargarse en Azure e importarse a la base de datos Target SQL Server.

El rendimiento de la copia y subida a Azure de estos archivos de volcado es un componente crítico en el proceso general de migración.

Hay dos enfoques básicos para cargar archivos de volcado R3load:

1.Copiemos desde los servidores de exportación R3load local al almacenamiento de blobs de Azure a través de Internet público con AzCopy

En cada uno de los servidores R3load, ejecutemos una copia de AzCopy con esta línea de comando:

AzCopy / source: C: \ ExportServer_1 \ Dumpfiles / dest: https: // <storage_account> / ExportServer_1 / Dumpfiles / destkey: xxxxxx / S / NC: xx / blobtype: page

https://msdnshared.blob.core.windows.net/media/2018/04/040518_0153_VeryLargeDa3.png

El valor para / NC: determina cuántas sesiones paralelas se utilizan para transferir archivos. En general, AzCopy tendrá un mejor rendimiento con un mayor número de archivos más pequeños y valores / NC entre 24-48. Si un cliente tiene un servidor potente y una conexión a Internet muy rápida, este valor puede aumentarse. Si se aumenta este valor, la conexión demasiado alta al servidor de exportación R3load se perderá debido a la saturación de la red. Controle el rendimiento de la red en el Administrador de tareas de Windows. Se puede lograr fácilmente un rendimiento de copiado de más de 1 Gigabit por segundo por R3load Export Server. El rendimiento de la copia se puede ampliar teniendo más servidores R3load (4 se muestran en el diagrama anterior)

Será necesario ejecutar una secuencia de comandos similar en los servidores de importación R3load en Azure para copiar los archivos de Blob en un sistema de archivos al que R3load pueda acceder.

Copiemos de los servidores de exportación R3load local en una VM de Azure o almacenamiento de blob a través de una conexión ExpressRoute dedicada utilizando AzCopy, Robocopy o una herramienta similar.

Robocopy C: \ Export1 \ Dump1 \ az_imp1 \ Dump1 / MIR / XF * .SGN / R: 20 / V / S / Z / J / MT: 8 / MON: 1 / TEE / UNILOG +: C: \ Export1 \ Robo1 .Iniciar sesión

El siguiente diagrama de bloques ilustra 4 servidores Intel R3load que ejecutan R3load. En el fondo, Robocopy comenzó a cargar archivos de volcado. Cuando se completan tablas y paquetes completos, el archivo SGN se copia manualmente o mediante un script. Cuando el archivo SGN para un paquete llega al servidor de importación R3load, esto activará la importación de este paquete automáticamente.

https://msdnshared.blob.core.windows.net/media/2018/04/040518_0153_VeryLargeDa4.png

Nota: Copiar archivos a través de NFS o protocolos SMB de Windows no es tan rápido o robusto como mecanismos como AzCopy. Se recomienda probar el rendimiento de ambas técnicas de carga de archivos. Se recomienda notificar al Soporte de Microsoft sobre proyectos de migración de VLDB ya que las operaciones de red de muy alto rendimiento podrían identificarse erróneamente como ataques de denegación de servicio.

Optimizaciones del sistema de destino

Usemos el último sistema operativo posible con los últimos parches
Utilicemos la última base de datos posible con los últimos parches
Utilicemos el Kernel de SAP más reciente posible con los parches más recientes (por ejemplo, actualización de 7.45 kernel a 7.49 o 7.53)
Consideremos usar la VM de Azure más grande disponible. El tipo de máquina virtual se puede bajar a una máquina virtual más pequeña después del proceso de importación
Vamos a crear varios archivos de registro de transacciones con el primer archivo de registro de transacciones en el SSD no persistente local. Se pueden crear archivos de registro de transacciones adicionales en discos P50. Las migraciones de VLDB podrían requerir más de 5TB de espacio en el Registro de transacciones. Se recomienda encarecidamente asegurarse de que siempre haya una gran cantidad de espacio en el Registro de transacciones libre en todo momento (20% es una cifra segura). No se recomienda extender los archivos de registro de transacciones durante una importación y esto afectará el rendimiento
SQL Server Max Degree of Parallelism generalmente debe establecerse en 1. Solo ciertas operaciones de compilación de índices se beneficiarán de MAXDOP y luego solo para tablas específicas
La red acelerada es obligatoria para los servidores DB y R3load
Se recomienda usar m128 3.8TB como servidor de bases de datos y E64v3 como servidores de carga R3 (a marzo de 2018)
Limitemos la memoria máxima que una única consulta de SQL Server puede solicitar a Resource Governor. Esto es necesario para evitar que las operaciones de creación de índices soliciten grandes cantidades de memoria.
Los índices secundarios para tablas muy grandes se pueden eliminar del archivo STR y compilarse EN LÍNEA con scripts después de que la parte principal de la importación haya finalizado y de que se estén realizando tareas posteriores al procesamiento, como la configuración de STMS.
Se recomienda a los clientes que usan SQL Server TDE crear previamente la base de datos y los archivos de registro de transacciones, luego habilitar TDE antes de comenzar la importación. TDE se ejecutará durante un período de tiempo similar en una base de datos llena de datos o vacía. Habilitar TDE en un VLDB puede conducir a problemas de bloqueo / bloqueo y, en general, se recomienda importar a una base de datos TDE. La sobrecarga de importación a una base de datos TDE es relativamente baja
Revise las últimas preguntas frecuentes sobre migración de OS / DB

Documentos recomendados del proyecto de migración

Las migraciones de VLDB OS / DB requieren niveles adicionales de habilidad técnica y también documentación y procedimientos adicionales. El propósito de esta documentación es reducir el tiempo de inactividad y eliminar la posibilidad de pérdida de datos. La documentación mínima aceptable incluiría los siguientes temas:

Nombre actual de la aplicación SAP, versión, parches, tamaño de base de datos, tablas de Top 100 por tamaño, uso de compresión de base de datos, CPU de hardware de servidor actual, memoria RAM y disco
Se completaron las actividades de archivado / depuración de datos y el ahorro de espacio logrado
Detalles sobre cualquier actualización, conversión Unicode o paquetes de soporte que se aplicarán durante la migración
Objetivo de la versión SAP Application, Support Pack Level, tamaño del DB objetivo estimado (después de la compresión), Top 100 tablas por tamaño, versión DB y parche, versión del sistema operativo y parche, VM sku, opciones de configuración de VM como caché de disco, acelerador de escritura, red acelerada, tipo y cantidad de discos, tamaño y disposición de los archivos de la base de datos, opciones de configuración DBMS como memoria, traceflags, gobernador de recursos
La seguridad suele ser un tema separado, pero los grupos de seguridad de la red, la configuración del firewall, la directiva de grupo, la configuración de cifrado DBMS
Aproximación y tecnologías de HA / DR, además de los pasos especiales para establecer HA / DR una vez finalizada la importación inicial
Enfoque de diseño de migración OS / DB:

-Cómo muchos servidores de exportación Intel R3load

-Cómo muchas máquinas virtuales de importación R3load

-Cuántos procesos R3load por VM

-Table dividir ajustes

-Ajustes de división de paquetes

-Exportar e importar la configuración del monitor

-Lista de índices secundarios que deben eliminarse de los archivos STR y creados manualmente

-Lista de tareas previas a la exportación, como la eliminación de actualizaciones

Análisis del último ciclo de exportación / importación. ¿Qué configuraciones fueron cambiadas? ¿Cuál fue el impacto en el "plan de vuelo"? ¿El cambio de configuración es aceptado o rechazado? ¿Qué afinación y configuración se planean para el próximo ciclo de prueba?
Procedimientos de recuperación y manejo de excepciones: procedimientos para deshacer, cómo manejar excepciones / problemas que han ocurrido durante ciclos de prueba previos.

Por lo general, es responsabilidad del consultor principal de migración de OS / DB preparar esta documentación. En ocasiones, otros consultores se encargan de temas tales como Seguridad, HA / DR y redes. La calidad de dicha documentación ha demostrado ser un muy buen indicador del nivel de habilidades y la capacidad del equipo del proyecto y del nivel de riesgo del proyecto para el cliente.

Monitoreo de Migración

Uno de los componentes más importantes de una migración de VLDB es el monitoreo, registro y diagnóstico que se configura durante las migraciones de desarrollo, prueba y "ejecución en seco".

Se recomienda encarecidamente a los clientes que debatan con su implementación de consultor de migración OS / DB y el uso de los pasos en esta sección del blog. No hacerlo expone a un cliente a un riesgo significativo.

La implementación de la monitorización e interpretación necesarias de los resultados de monitorización y diagnóstico después de cada ciclo de prueba es obligatoria y esencial para optimizar la migración y planificar la transición de producción. Los resultados obtenidos en las migraciones de prueba también son necesarios para poder juzgar si la migración de producción real sigue los mismos patrones y líneas de tiempo que las migraciones de prueba. Los clientes deben solicitar puntos de revisión de proyectos regulares con el socio de SAP. Póngase en contacto con Microsoft para obtener una lista de consultores que han demostrado las habilidades técnicas y de organización necesarias para un proyecto exitoso.

Sin una supervisión y un registro exhaustivos, sería casi imposible lograr migraciones de tiempo de inactividad seguras, repetibles, consistentes y bajas con la garantía de que no se perderían datos. Si se producen problemas tales como largos tiempos de ejecución de algunos paquetes, es casi imposible para Microsoft y / o SAP ayudar con la consulta puntual sin supervisar los datos y la documentación de diseño de migraci��n.

Durante el tiempo de ejecución de una migración de OS / DB:

Parámetros de nivel de sistema operativo en hosts DB y R3load: CPU por hilo, tiempo del núcleo por hilo, memoria libre (GB), página en / seg, salida de páginas / seg, lecturas de IO de disco / seg, escritura IO de disco / seg., Lectura de disco KB / segundo, disco escribir KB / seg

Parámetros de nivel de base de datos en el destino de SQL Server: filas de BCP / segundo, KB / seg de BCP,% de registro de transacciones, concesiones de memoria, concesiones de memoria pendientes, bloqueos, memoria de bloqueo, bloqueo / bloqueo

Monitoreo de red normalmente manejado por el equipo de red. La configuración exacta de la supervisión de la red depende de la situación específica del cliente.

Durante el tiempo de ejecución de la importación de DB, se recomienda ejecutar esta declaración de SQL cada pocos minutos y captura de pantalla cualquier cosa anormal (como tiempos de espera altos)

select session_id, request_id,start_time,
status, command, wait_type, wait_resource, wait_time, last_wait_type, blocking_session_id from  sys.dm_exec_requests
where session_id >49 orderby wait_time desc;

Durante todos los ciclos de prueba de migración, un "plan de vuelo" que muestre el número de paquetes exportados e importados (eje y) debe trazarse en función del tiempo (eje x). El objetivo de este gráfico es establecer una tasa de progreso esperada durante la transición de migración de producción final. La desviación (positiva o negativa) del "plan de vuelo" esperado durante la prueba o la migración final de la producción se detecta fácilmente utilizando este método. Otros parámetros como CPU, disco y R3load rows / sec se pueden superponer sobre el "Flight Plan"

https://msdnshared.blob.core.windows.net/media/2018/04/040518_0153_VeryLargeDa5.png

Al finalizar la exportación e importación, los informes de tiempo de migración deben recopilarse (export_time.html e import_time.html) https://blogs.sap.com/2016/11/17/time-analyzer-reports-for-osdb- migraciones /

Migración de VLDB, lo que se debe Hacer y no hacer

Las pautas contenidas en este blog se basan en proyectos de clientes reales y en los aprendizajes derivados de estos proyectos. Este blog instruye a los clientes a evitar ciertos escenarios porque no han tenido éxito en el pasado. Un ejemplo es la recomendación de no utilizar servidores UNIX o servidores virtualizados como servidores de exportación R3load:

Muy a menudo, el rendimiento de exportación es un factor decisivo en el tiempo de inactividad general. A menudo, el hardware actual tiene más de 4-5 años y es prohibitivamente costoso actualizarlo
Por lo tanto, es importante obtener el máximo rendimiento de exportación que sea práctico para lograr
Los proyectos anteriores han dedicado semanas-hombre o incluso meses-hombre para tratar de ajustar el rendimiento de exportación de R3load en plataformas UNIX o virtualizadas, antes de abandonar y utilizar servidores Intel R3load.
Los servidores Intel de dos sockets son muy económicos e inmediatamente brindan ganancias sustanciales de rendimiento, en algunos casos muchos órdenes de magnitud mayores que las mejoras menores de ajuste posibles en UNIX o servidores virtualizados.
Los clientes a menudo tienen granjas de máquinas virtuales existentes, pero la mayoría de las veces no son compatibles con la descarga moderna o las tecnologías SRIOv. A menudo, la versión de VMWare es antigua, no está parcheada o no está configurada para un rendimiento de red muy alto y baja latencia. Los servidores de exportación R3load requieren un rendimiento de subproceso muy rápido y un rendimiento de red extremadamente alto. Los servidores de exportación R3load pueden ejecutarse durante 10-15 horas con casi el 100% de utilización de la CPU y la red. Este no es el caso típico de uso de la mayoría de las granjas de VMWare y la mayoría de las implementaciones de VMWare nunca fueron diseñadas para manejar una carga de trabajo como R3load.

RECOMENDACIÓN: No invierta tiempo en optimizar el rendimiento de exportación R3load en plataformas UNIX o virtualizadas. Si lo hace, perderá no solo el tiempo, sino que costará mucho más que comprar servidores Intel de bajo costo al inicio del proyecto. Por lo tanto, se solicita a los clientes de migración de VLDB que se aseguren de que el equipo del proyecto cuente con servidores rápidos y modernos de exportación R3load disponibles al inicio del proyecto. Esto reducirá el costo total y el riesgo del proyecto.

Lo que se debe Hacer:

Encuesta e inventario del panorama actual de SAP. Identifique los niveles del paquete de soporte de SAP y determine si es necesario aplicar parches para admitir el DBMS de destino. En general, la compatibilidad de los sistemas operativos está determinada por el Kernel SAP y la compatibilidad DBMS está determinada por el nivel de parche SAP_BASIS.

Cree una lista de notas de SAP OSS que deben aplicarse en el sistema de origen, como las actualizaciones de SMIGR_CREATE_DDL. Considere actualizar los núcleos de SAP en los sistemas fuente para evitar un gran cambio durante la migración a Azure (por ejemplo, si un sistema está ejecutando un kernel antiguo 7.41, actualice al último 7.45 en el sistema fuente para evitar un gran cambio durante la migración)

Desarrollar la solución de Alta Disponibilidad y Recuperación de Desastres. Cree una presentación de PowerPoint que detalle el concepto de HA / DR. El diagrama debe dividir la solución en la capa DB, la capa ASCS y la capa del servidor de aplicaciones SAP. Se pueden requerir soluciones independientes para soluciones independientes como TREX o Livecache
Desarrolle un documento de dimensionamiento y configuración que detalle los tipos de VM de Azure y la configuración de almacenamiento. Cuántos discos Premium, cuántos archivos de datos, cómo se distribuyen los archivos de datos en los discos, uso de espacios de almacenamiento, tamaño de formato NTFS = 64kb. También documenta la copia de seguridad / restauración y la configuración de DBMS, como la configuración de la memoria, el grado máximo de paralelismo y las marcas de seguimiento.
Documento de diseño de red que incluye la configuración de VNet, subred, NSG y UDR
Concepto de seguridad y endurecimiento. Eliminemos Internet Explorer, creeemos un contenedor de Active Directory para servidores y cuentas de servicio SAP y apliquemos una política de firewall que bloquee todos los puertos requeridos menos un número limitado
Creemos un documento de diseño de migración de OS / DB detallando el concepto de división de Paquetes y Tablas, número de R3 cargas, trazabilidad de SQL Server, ordenado / sin clasificar, configuración de Oracle RowID, configuración de SMIGR_CREATE_DDL, contadores de Perfmon (como Filas de BCP / sec y rendimiento de BCP kb / seg, CPU, memoria), configuración de RSS, configuración de red acelerada, configuración de archivo de registro, configuración de BPE, configuración de TDE
Creemos un gráfico de "Plan de vuelo" que muestre el progreso de la exportación / importación R3load en cada ciclo de prueba. Esto le permite al consultor de migración validar si las modificaciones y los cambios mejoran la carga de exportación o el rendimiento de importación. Eje X = número de paquetes completados. Eje Y = horas Este plan de vuelo también es crítico durante la migración de producción para que el progreso planificado se pueda comparar con el progreso real y cualquier problema identificado temprano.
Creamos un plan de prueba de rendimiento. Identifique los 20 mejores informes en línea, trabajos por lotes e interfaces. Documentemos los parámetros de entrada (tales como el rango de fechas, la oficina de ventas, la planta, el código de la compañía, etc.) y los tiempos de ejecución en el sistema fuente original. Compare con el tiempo de ejecución en Azure. Si hay diferencias de rendimiento, ejecute SAT, ST05 y otras herramientas SAP para identificar declaraciones ineficientes
SAP BW en SQL Server. Visite este blog regularmente para conocer las nuevas funciones de los sistemas BW, incluida Column Store
Implementación y configuración de auditoría, asegúrese de que los tiempos de espera del clúster, los kernels, la configuración de red, el tamaño del formato NTFS son consistentes con los documentos de diseño. Configure los contadores de perfmon en servidores importantes para registrar los parámetros básicos de mantenimiento cada 90 segundos. Audite que los servidores SAP están en un Contenedor AD separado y que el contenedor tiene una Política aplicada con la configuración del Firewall.
¡Verifique que el asesor principal de migración de OS / DB tenga licencia! Solicite el nombre del consultor, el usuario s y la fecha de certificación. Abra un mensaje OSS a BC-INS-MIG y solicite a SAP que confirme que el consultor es actual y tiene licencia.
Si es posible, tenga todo el equipo del proyecto asociado con el proyecto de migración de VLDB dentro de una ubicación física y no disperso geográficamente en varios continentes y zonas horarias.
Asegúrese de que exista un plan de respaldo adecuado y que sea parte del cronograma general.
Seleccione los modelos de CPU Intel de subprocesos rápidos para los servidores de exportación R3load. No utilice los modelos de CPU "Energy Saver" ya que tienen un rendimiento mucho menor y no usan servidores de 4 sockets. Intel Xeon E5 Platinum 8158 es un buen ejemplo

Lo que NO se debe hacer:

La migración de VLDB OS / DB requiere un conjunto de habilidades técnicas avanzadas y un proceso, control de cambio y documentación muy sólido. No hagas "entrenamiento en el trabajo" con migraciones de VLDB
No subcontrate una organización de consultoría para hacer la exportación y subcontrate a otra organización de consultoría para hacer la importación. Ocasionalmente, el sistema de origen es subcontratado y gestionado por una organización de consultoría o socio y un cliente desea migrar a Azure y cambiar a otro socio. Debido al estrecho acoplamiento entre la configuración y el ajuste Export and Import, es muy poco probable que la asignación de estas tareas a diferentes organizaciones produzca un buen resultado.
No economice en los recursos de hardware de Azure durante la migración y entre en funcionamiento. Las máquinas virtuales Azure se cobran por minuto y se pueden reducir de forma muy sencilla. Durante una migración de VLDB aproveche la VM más potente disponible. Los clientes se han lanzado exitosamente en sistemas de gran tamaño de 200-250%, y luego se estabilizaron al ejecutar sistemas de gran tamaño. Después de monitorear la utilización durante 4-6 semanas, las VM se reducen en tamaño o se apagan para reducir los costos

Lectura obligatoria, documentación y consejos

A continuación, se incluyen algunas recomendaciones para quienes configuran esta solución en función de las implementaciones de prueba:

Consulte periódicamente el blog de SAP en Microsoft Azure https://blogs.msdn.microsoft.com/saponsqlserver/

Lea las últimas preguntas frecuentes sobre migración de OS / DB de SAP https://blogs.msdn.microsoft.com/saponsqlserver/tag/migration/

Un blog útil sobre DMO está aquí https://blogs.sap.com/2017/10/05/your-sap-on-azure-part-2-dmo-with-system-move/

Información sobre DMO https://blogs.sap.com/2013/11/29/database-migration-option-dmo-of-sum-introduction/

Contenido de sitios web de terceros, SAP y otras fuentes reproducidas de acuerdo con las críticas, comentarios, informes de noticias, enseñanza, becas e investigaciones de Uso

Compartir a través de