Planificar la migración
La arquitectura admite varios escenarios de migración.
Considerar las opciones de migración
Con Oracle Exadata Database Service u Oracle Database Exadata Cloud at Customer, hay cuatro modelos de despliegue comunes que se deben tener en cuenta:
- Mueva su base de datos local grande a Oracle Database Exadata Cloud at Customer "tal cual" y proporcione una instancia de recuperación ante desastres (DR) de OCI conectada por Oracle Data Guard.
Componente Ubicaciones locales Exadata (medio rack) Tamaño de la base de datos 47 TB 47 TB Núcleos 24 16 Área global de sistema y área global de programa 4 TB 1,5 TB - Consolide varias bases de datos locales en varias bases de datos de conexión (PDB) en Oracle Exadata Database Service u Oracle Database Exadata Cloud at Customer, además de proporcionar una instancia de DR de OCI conectada por Oracle Data Guard.
Componente Ubicaciones locales Exadata (10 rack completo) Bases de datos 1000 1000 Configuración de base de datos 2-16 TB por base de datos CDB = 29 PDB = 1000 de diferentes tamaños
- Ejecute cargas de trabajo de producción de forma local mediante Oracle Database Exadata Cloud at Customer y proporcione DR u Oracle Exadata Database Service en OCI con las instancias de base de datos conectadas por Oracle Data Guard.
Componente Ubicaciones locales Exadata (medio rack) Tamaño de la base de datos 19.5 TB 19.5 TB Núcleos 24 12 Área global de sistema y área global de programa 2.5 TB 1,5 TB - Ejecute cargas de trabajo de producción en Oracle Exadata Database Service en OCI y DR mediante hardware local con las instancias de base de datos conectadas por Oracle Data Guard.
Componente Ubicaciones locales Exadata (medio rack) Tamaño de la base de datos 19.5 TB 19.5 TB Núcleos 24 12 Área global de sistema y área global de programa 2.5 TB 1,5 TB
Usar servicios de migración sin tiempo de inactividad
Para migrar sus bases de datos locales de gran tamaño a Oracle Cloud Infrastructure (OCI), considere utilizar los servicios Zero Downtime Migration (ZDM).
Tanto si utiliza Oracle Exadata Database Service como Oracle Database Exadata Cloud at Customer, ambos implican la creación de una copia de seguridad de la base de datos de origen y la restauración en la base de datos de destino. A continuación, debe ejecutar RMAN, realizar una sincronización de Oracle Active Data Guard y cambiar el rol principal de la base de datos origen a la base de datos destino. Zero Downtime Migration también soporta varios métodos de migración, según el medio de copia de seguridad elegido. El medio de copia de seguridad puede ser Oracle Cloud Infrastructure Object Storage, Zero Data Loss Recovery Appliance o el almacenamiento del sistema de archivos de red (NFS).
En la siguiente tabla, se muestran los requisitos y las condiciones de varios escenarios de migración sin tiempo de inactividad (ZDM).
| Método de migración | Tiempo de migración | Requisito de tiempo de inactividad* | Herramientas de Oracle utilizadas | Cuándo se Utiliza |
|---|---|---|---|---|
| ZDM: física en línea | 8 horas |
2-5 minutos (independiente del tamaño de la base de datos) |
|
|
| ZDM: Físico fuera de línea | 8 horas | ~8 horas por TB |
|
|
| ZDM: lógico en línea | 12 horas |
2-5 minutos (independiente del tamaño de la base de datos) |
|
|
| ZDM: lógico fuera de línea | 16 horas | ~16 horas por TB |
|
|
* Estos números de tiempo de inactividad se derivan de nuestra experiencia y se deben utilizar como orientación general, no como números exactos. Los requisitos de tiempo de inactividad pueden variar considerablemente, por lo que es necesario realizar análisis y pruebas exhaustivos antes de planificar cualquier migración total a la producción.
Recomendaciones
Sus requisitos pueden diferir de la arquitectura descrita aquí. Utilice las siguientes recomendaciones como punto de partida.
- VCN
Al crear una VCN, determine el número de bloques CIDR necesarios y el tamaño de cada bloque según el número de recursos que planea asociar a subredes en la VCN. Utilice bloques CIDR que estén dentro del espacio de dirección IP privada estándar.
Seleccione bloques CIDR que no se solapen con ninguna otra red (en Oracle Cloud Infrastructure, su centro de datos local u otro proveedor en la nube) en la que desea configurar conexiones privadas.
Después de crear una VCN, puede cambiar, agregar y eliminar sus bloques CIDR.
Al diseñar las subredes, tenga en cuenta los requisitos de seguridad y flujo de tráfico. Conecte todos los recursos de un nivel o rol específico a la misma subred, que puede servir como límite de seguridad.
Utilice subredes regionales.
- Cloud Guard
Clone y personalice las recetas por defecto proporcionadas por Oracle para crear recetas de detector y responsable de respuesta personalizadas. Estas recetas permiten especificar qué tipo de violaciones de seguridad generan una advertencia y qué acciones se pueden realizar en ellas. Por ejemplo, puede que desee detectar bloques de Object Storage que tengan una visibilidad definida como pública.
Aplique Cloud Guard en el nivel del arrendamiento para abarcar el ámbito más amplio y reducir la carga administrativa que supone el mantenimiento de varias configuraciones.
También puede utilizar la función de lista gestionada para aplicar determinadas configuraciones a los detectores.
- Zonas de seguridad
Para los recursos que requieren máxima seguridad, Oracle recomienda utilizar zonas de seguridad. Una zona de seguridad es un compartimento asociado a una receta definida por Oracle de políticas de seguridad que se basan en las mejores prácticas. Por ejemplo, no se debe poder acceder a los recursos de una zona de seguridad desde la red pública de Internet y se deben cifrar mediante claves gestionadas por el cliente. Al crear y actualizar recursos en una zona de seguridad, Oracle Cloud Infrastructure valida las operaciones con las políticas de la receta de zona de seguridad y deniega operaciones que violan cualquiera de las políticas.
Consideraciones
Al desplegar bases de datos locales en Oracle Cloud mediante Oracle Exadata Database Service, tenga en cuenta lo siguiente:
- Migración sin tiempo de inactividad (ZDM)
ZDM puede ejecutarse tanto en entornos locales como en la nube. ZDM soporta la migración de bases de datos locales a una variedad de destinos:
- Oracle Base Database Service
- Oracle Exadata Database Service en infraestructura dedicada
- Oracle Exadata Database Service Cloud at Customer
- Oracle Exadata local
- Oracle Autonomous Database
- Oracle Autonomous Transaction Processing (dedicado y compartido)
- Oracle Autonomous Data Warehouse (dedicado y compartido)
- Servicio de migración de base de datos (DMS) de ZDM y Oracle Cloud Infrastructure
Las principales diferencias entre ZDM y DMS son:
-
ZDM funciona como motor principal que admite la mayoría de métodos, orígenes y destinos, y se basa en una interfaz de línea de comandos (CLI).
-
DMS utiliza ZDM bajo las cubiertas y permite la migración lógica fuera de línea/en línea con una interfaz de usuario a servicios de base de datos nativa de OCI.
-
La migración de base de datos es un servicio totalmente gestionado que proporciona una experiencia de autoservicio de alto rendimiento para migrar bases de datos a Oracle Cloud Infrastructure (OCI).
-
La migración de base de datos de OCI se ejecuta como un servicio gestionado en la nube independiente del arrendamiento y los recursos. El servicio funciona como un servicio multi-inquilino en un arrendamiento de servicio de migración de base de datos y se comunica con sus recursos mediante puntos finales privados (PEs). Los PE se gestionan mediante Database Migration.
-
- Tamaño de la base de datos
No hay restricciones de tamaño para ZDM o DMS. La restricción teórica será el tamaño máximo de Oracle Database que su sistema operativo puede tener. El número máximo de archivos de datos y el tamaño máximo de un archivo de datos dependen del sistema operativo.
Para una migración de base de datos de terabytes pequeña (<1) a una instancia de Autonomous Database, puede utilizar el método lógico ZDM fuera de línea o en línea, según los requisitos de tiempo de inactividad. La opción lógica en línea solo requiere un par de minutos de tiempo de inactividad, mientras que la opción lógica fuera de línea tarda unas horas de tiempo de inactividad, según el tamaño de la base de datos.
Para un tamaño de base de datos local de 400 TB o más, la migración será de un entorno local a Oracle Exadata Database Service Cloud at Customer (que también estará en el centro de datos del cliente). Utilice la migración física en línea de ZDM para mantener su tiempo de inactividad bajo y reducir el riesgo durante la migración con el uso de Data Guard. Sin embargo, las bases de datos de origen y destino tendrán que tener la misma versión. Si desea realizar una actualización en curso de una versión inferior a una versión superior, utilice el método lógico en línea ZDM. Cualquier método fuera de línea producirá un gran tiempo de inactividad que puede no ser aceptable para su negocio.
- Data Guard y Active Data Guard
Tanto Data Guard (DG) como Active Data Guard (ADG) proporcionan un conjunto completo de servicios que crean, mantienen, gestionan y controlan una o más bases de datos en espera para permitir que las bases de datos Oracle primarias sobreviven a desastres y corrupciones de datos. Las bases de datos en espera se mantienen como copias de la base de datos de producción. Sin embargo, con ADG, puede tener la base de datos en espera abierta para solo lectura (por ejemplo, para fines de generación de informes) mientras se mantiene sincronizada con la base de datos primaria. Con DG, debe pausar el proceso de sincronización para abrir la base de datos en espera en modo de solo lectura.
- Virtualización de Exadata
Puede virtualizar Exadata en una máquina virtual o puede realizar una instalación con hardware dedicado. La arquitectura de las opciones puede ser significativamente diferente. Con una instalación con hardware dedicado, tiene un cluster de Oracle para toda una máquina de Exadata, a menos que realice una partición física de la máquina de Exadata. Con una máquina de Exadata virtualizada, tiene un dominio de gestión (dom0) y al menos un dominio de usuario (domU), según el número de clusters de VM que se desplieguen.
- Prueba de aplicación real (RAT)
Consulte el enlace de la sección Explorar más.