Migración de cargas de trabajo de Oracle a Azure
Como parte del recorrido de adopción de la nube, debe migrar las cargas de trabajo existentes a la nube. Las cargas de trabajo de Oracle son similares a otras cargas de trabajo y requieren un enfoque metódico para ayudar a garantizar una migración correcta. Para más detalles sobre la metodología de migración, consulte Migración en la nube en Cloud Adoption Framework para Azure. En este artículo se describen las restricciones y consideraciones específicas de las cargas de trabajo de Oracle.
Escenarios de migración de Oracle
Al migrar cargas de trabajo de Oracle, debe realizar la transición de bases de datos y aplicaciones. En este artículo se describe el enfoque lift-and-shift para las migraciones de aplicaciones y bases de datos. El enfoque lift-and-shift incluye la implementación de aplicaciones de Oracle en Azure Virtual Machines. Para la migración de bases de datos, hay varias opciones disponibles. En este artículo se proporcionan instrucciones que se aplican a Oracle Database@Azure.
Aplicaciones en máquinas virtuales: ejecutar aplicaciones empresariales de Oracle, como Siebel, PeopleSoft, JD Edwards, E-Business Suite o aplicaciones personalizadas de WebLogic Server en la infraestructura de Azure.
Bases de datos Oracle Standard Edition o Enterprise Edition en Máquinas Virtuales: En este escenario, desplegará su base de datos Oracle en una máquina virtual. Hay varias opciones disponibles, desde bases de datos autoadministradas a administradas. Si prefiere una solución de base de datos administrada, revise Tessell .
oracle Database@Azure: Oracle Database@Azure es un servicio de base de datos de Oracle que se ejecuta en Oracle Cloud Infrastructure (OCI) y que se coloca en centros de datos de Microsoft.
Nota
Para determinar los sistemas operativos admitidos para la versión de base de datos específica, consulte bases de datos y sistemas operativos compatibles.
El proceso de migración de Oracle
Debe volver a evaluar continuamente los requisitos de infraestructura para mejorar el rendimiento y reducir los costos mediante el uso del tipo pertinente de servicio para las cargas de trabajo. Por ejemplo, para todos los escenarios mencionados anteriormente, asegúrese de que haya suficiente ancho de banda disponible para la migración. Le recomendamos encarecidamente que revise el ancho de banda necesario cuando realice una prueba de concepto (PoC).
Si mueve la carga de trabajo a Oracle en Máquinas virtuales, asegúrese de que los tamaños de la máquina virtual cumplan sus requisitos. Para obtener más información, consulte Planeamiento de capacidad para migrar cargas de trabajo de Oracle a zonas de aterrizaje de Azure.
Revise los recursos de migración para definir el proceso de migración de Oracle a Azure. También puede:
- Compruebe los límites de cuota de la suscripción de Azure: Asegúrese de que los límites de cuota de la suscripción de Azure pueden adaptarse a los tamaños de máquina virtual de destino que elija si migra a Oracle en Máquinas virtuales.
Nota
Si aloja su carga de trabajo en Oracle Database@Azure y necesita un aumento de cuota, consulte a su contacto de Oracle.
Identificar un modelo de implementación: Automatice la implementación de componentes de la solución tanto como sea posible mediante el uso de infraestructura como código, integración continua y canalizaciones de entrega continua y otras prácticas de DevOps.
Determinar las dependencias de la aplicación: Asegúrese de que las actividades de migración sean lo menos disruptivas posible.
Identificar la capacidad de datos: Identificar la cantidad de datos que se van a migrar y evaluar la capacidad de conectividad de red disponible actual desde entornos locales a Azure. Utilice esta información para decidir si puede copiar los datos directamente desde entornos locales a Azure. Es posible que necesite un dispositivo de transferencia de datos físico, como Azure Data Box, para la carga inicial de datos.
Determinar los requisitos de disponibilidad: Determinar los requisitos de disponibilidad de la carga de trabajo, ya que podrían afectar a las herramientas de migración que puede usar. Defina el tiempo de inactividad máximo aceptable. Esta métrica le ayuda a definir las herramientas y el enfoque de migración.
Esta consideración se aplica igualmente a tu solicitud. Si no puede aceptar una interrupción en las operaciones diarias, debe realizar una migración en línea.
- Determine las herramientas necesarias para migrar su carga de trabajo a Oracle en máquinas virtuales de Azure: Las dos rutas principales de migración son sin conexión y en línea.
| Migración sin conexión | Migración en línea |
|---|---|
| Copia directa única de la base de datos. | Copia inicial de la base de datos seguida de la captura de datos modificados durante la migración. |
| Requiere que la aplicación afectada esté sin conexión durante la migración. | La aplicación puede permanecer en línea durante la migración. |
| Herramientas usadas: Data Box, DataPump, Oracle Recovery Manager (RMAN) | Herramientas de utilizadas: DataGuard, Oracle Recovery Manager (RMAN), GoldenGate |
Nota
Si decide realizar una migración en línea, asegúrese de configurar reglas de firewall para permitir la transferencia de datos.
Actividades específicas de cargas de trabajo de migración de Oracle
En la sección siguiente se describe más en detalle el proceso de migración. Los pasos no son secuenciales necesariamente. Puede seguir algunos pasos en paralelo.
Evaluar las versiones del sistema de origen y destino: Evaluar si las versiones del sistema operativo (SO) locales, las versiones de aplicación y las versiones de base de datos son las mismas locales y en Azure.
Si necesita actualizar uno o varios recursos, actualícelos antes de la migración para simplificar el proceso de migración.
Si la base de datos local se ejecuta en un sistema operativo big endian, como Oracle Solaris, IBM Advanced Interactive eXecutive o Hewlett Packard Unix, el proceso de migración de bases de datos incluye una conversión endian. Azure solo admite sistemas operativos little endian. Esta limitación reduce el número de herramientas disponibles para la migración. En concreto, no puede utilizar Oracle Data Guard ni ningún otro método de copia de archivos. Los métodos de migración compatibles con la conversión endian incluyen Oracle Data Pump Export u Oracle Data Pump Import, Oracle cross-platform transportable tablespaces (XTTS), o utilidades de replicación de datos como Oracle GoldenGate, Quest SharePlex y Striim.
Puede modernizar o migrar servidores de aplicaciones locales, en función de los requisitos y la compatibilidad. Para obtener más información, consulte Escenarios de adopción de la nube.
Evaluar los requisitos de disponibilidad de la carga de trabajo durante el proceso de migración: Si necesita minimizar el tiempo de inactividad de la carga de trabajo, es posible que los métodos de migración como Data Pump Export o Data Pump Import no se adapten a la carga de trabajo. En ese caso, siga este proceso de cuatro pasos:
Use RMAN para realizar copias de seguridad y, a continuación, restaurar toda la base de datos en Azure. Realizar una conversión endian a través de XTTS si es necesario. Esto dará como resultado una base de datos que es una copia en un momento dado de la base de datos de origen local. Para obtener más información, consulte Transporte de datos entre plataformas.
Si ambos orígenes tienen formato little-endian, use Oracle Data Guard para sincronizar la base de datos recién restaurada en Azure con la base de datos de origen. No puede usar Data Guard si la migración incluye la conversión de big-endian a little-endian. En su lugar, use una utilidad de replicación de datos basada en SQL, como Oracle GoldenGate, Quest SharePlex o Striim para sincronizar la base de datos recién restaurada en Azure con la base de datos de origen.
Después de sincronizar la base de datos de destino en Azure con la base de datos de origen local, puede programar una transición. Una transición apaga la base de datos local de origen y vacía las últimas transacciones en la base de datos de destino en Azure. A continuación, puede abrir la base de datos de destino en Azure como nueva base de datos de origen. Una transición puede tardar tan solo unos minutos, en función del método de sincronización que use.
En función del enfoque de migración que elija para los servicios de aplicación, es posible que tenga que completar varias tareas de servicio de aplicaciones antes de migrar completamente la aplicación a Azure.
Evaluar las licencias necesarias: La base de datos puede requerir varias licencias, en función de las herramientas de migración. Por ejemplo:
Oracle Data Guard requiere Oracle Database Enterprise Edition.
Oracle GoldenGate requiere licencias de Oracle GoldenGate.
Para obtener más información sobre las licencias de Oracle en Azure, consulte Licencias de software de Oracle en el entorno de informática en la nube.
Guía de migración de Oracle Database@Azure
Comprobar que la solución de Oracle Database@Azure esté disponible en la región donde desea implementar la solución. Para obtener más información, consulte Regiones disponibles.
Considere la posibilidad de utilizar Oracle Zero Downtime Migration (ZDM) para el proceso de migración. Evalúe las estrategias de migración para determinar el enfoque más adecuado para sus requisitos de migración específicos. Para obtener más información, consulte Migración de tiempo de inactividad cero (ZDM). ZDM proporciona la capacidad de elegir escenarios de migración lógica o física. Para más información, consulte Migración ZDM.
Nota
Si elige Servicio de base de datos autónomo (ADB-S), tenga en cuenta que solo se admiten escenarios de migración lógicos.
Otras instrucciones
La siguiente sección puede ayudarle a elegir la opción de migración adecuada para sus requisitos y tamaños de datos.
Referencia de duración de migración basada en ExpressRoute
La tabla siguiente solo sirve como línea base. No tiene en cuenta otras cargas de trabajo de producción que se ejecutan a través de la misma conexión de Azure ExpressRoute.
VMware puede necesitar más ancho de banda de lo indicado. Evalúe sus necesidades de ancho de banda durante la fase PoC. Si necesita soporte técnico, póngase en contacto con su contacto local.
| Tamaño de los datos | Ancho de banda de 1 gpbs | Ancho de banda de 10 Gbps |
|---|---|---|
| 1 TB | 3 horas | 15 minutos |
| 10 TB | 1 día | 3 horas |
| 35 TB | 4 días | 9 horas |
| 80 terabytes | 8 días | 20 horas |
| 100 TB | 11 días | 1 día |
| 200 TB | 21 días | 2 días |
| 500 TB | 53 días | 5 días |
Si tiene previsto usar ExpressRoute para la migración, asegúrese de que su resistencia cumple los requisitos.