Explorar la migración de bases de datos de gran tamaño
Los sistemas SAP que se migran a la nube de Azure suelen incluir ahora grandes sistemas multinacionales de "instancia global única". A menudo, estos sistemas son mucho más grandes que los primeros sistemas de clientes que se implementaron cuando la plataforma Azure se certificó por primera vez para cargas de trabajo SAP.
Las bases de datos de gran tamaño (VLDB) ahora se suelen trasladar a Azure. Para los tamaños de base de datos superiores a 20 TB se necesitan técnicas y procedimientos adicionales a fin de realizar una migración desde el entorno local a Azure con un tiempo de inactividad aceptable y un riesgo bajo.
Información general de alto nivel
Una migración de base de datos de gran tamaño totalmente optimizada debe lograr un rendimiento de migración aproximado de 2 TB por hora o incluso más. Esto significa que el componente de transferencia de datos de una migración de 20 TB se puede realizar en unas 10 horas. Es necesario realizar varios pasos posteriores al proceso y de validación. En general, con el tiempo adecuado para la preparación y las pruebas, prácticamente todos los sistemas de cliente de cualquier tamaño pueden trasladarse a Azure.
Las migraciones de VLDB exigen conocimientos, atención al detalle y análisis considerables. Por ejemplo, el impacto neto de una división de tablas debe medirse y analizarse. Las divisiones de una tabla grande en más de 50 exportaciones paralelas pueden reducir considerablemente el tiempo necesario para exportar una tabla, pero la existencia de demasiadas divisiones de tabla puede hacer que los tiempos de importación aumenten radicalmente. Por tanto, el impacto neto de las divisiones de tablas se debe calcular y probar. Un asesor experto de migración de sistemas operativos y bases de datos con licencia debe estar familiarizado con los conceptos y las herramientas. Destacamos contenido específico de Azure para las migraciones de VLDB.
En concreto, tratamos la migración a Azure de bases de datos o sistemas operativos heterogéneos con SQL Server como base de datos de destino mediante herramientas como R3load y Migmon. Los pasos de migración no están pensados para copias homogéneas del sistema, una copia en la que el SGBD y la arquitectura del procesador (Orden Endian) permanecen inalterados. En general, las copias homogéneas del sistema deben tener un tiempo de inactividad mínimo, con independencia del tamaño de DBMS, ya que se puede usar el trasvase de registros para sincronizar una copia de la base de datos en Azure.
Después de los puntos clave, se ilustra un diagrama de bloques de una migración típica de OS/DB de una base de datos de gran tamaño y su traslado a Azure:
La base de datos o el sistema operativo de origen actual suele ser AIX, HPUX, Solaris o Linux y DB2 u Oracle.
El sistema operativo de destino es Windows, Suse 12.3, Redhat 7.x u Oracle Linux 7.x.
La base de datos de destino suele ser SQL Server u Oracle 12.2.
El rendimiento de los subprocesos de IBM pSeries, el hardware Solaris SPARC y HP Superdome es drásticamente inferior al de los servidores de productos Intel modernos de bajo costo, por lo que R3load se ejecuta en servidores Intel independientes.
VMware necesita un ajuste y una configuración especiales para lograr un rendimiento de red adecuado, estable y predecible. Normalmente, los servidores físicos se usan como servidor R3load y no como máquinas virtuales.
Normalmente se utilizan cuatro servidores R3load de exportación, aunque no hay límite en el número de servidores de exportación. Una configuración típica sería la siguiente:
- Servidor de exportación 1: dedicado a las tablas 1-4 de mayor tamaño (en función de la asimetría de la distribución de datos en la base de datos de origen).
- Servidor de exportación 2: dedicado a tablas con divisiones de tabla.
- Servidor de exportación 3: dedicado a tablas con divisiones de tabla.
- Servidor de exportación 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 mediante AzCopy por medio de la red pública de Internet. Este procedimiento suele ser más rápido que el uso de ExpressRoute.
El control y la secuencia de la importación se realizan mediante el archivo de señal (SGN) que se genera automáticamente cuando se completan todos los paquetes de exportación. Esto permite una exportación o importación semiparalela.
La importación a SQL Server u Oracle se estructura de manera similar a la exportación y se usan cuatro servidores de importación. Serán servidores R3load dedicados independientes con redes aceleradas. Se recomienda que los servidores de aplicaciones de SAP no sean para esta tarea.
Las bases de datos de VLDB normalmente usarían máquinas virtuales E64v3, m64 o m128 con Premium Storage. El registro de transacciones puede colocarse en el disco SSD local a fin de acelerar las escrituras del registro de transacciones y quitar las IOPS del registro de transacciones y el ancho de banda IO de la cuota de la máquina virtual. Después de la migración, el registro de transacciones debe colocarse en un disco persistente.
