Migración de aplicaciones esenciales para el negocio a Oracle Database@Azure mediante una estrategia por fases

Migre una base de datos y una aplicación locales a la nube, minimizando el tiempo de inactividad con estrategias por fases o híbridas, garantizando una conectividad perfecta para las aplicaciones basadas en la nube a las bases de datos locales. Un plan bien estructurado acelera la salida del centro de datos, mitiga los riesgos y mantiene la fiabilidad. Un enfoque híbrido de dos fases permite una transición fluida mientras se mantiene la estabilidad.

Al mover una base de datos y una aplicación locales a la nube, debe abordar varios desafíos para garantizar una transición fluida. Elija una estrategia de migración que minimice el tiempo de inactividad, como la migración por fases o las soluciones de nube híbrida, para mantener el tiempo de actividad de las aplicaciones, especialmente para cargas de trabajo empresariales críticas. Asegúrese de que las aplicaciones que ya están en la nube, que se conectan a bases de datos locales, también se tengan en cuenta en el plan de migración para evitar problemas de conectividad. Para las aplicaciones SaaS, donde la aplicación reside en la nube, pero la base de datos es local, asegúrese de una estrategia completa que incluya ambos componentes. Aborde estos desafíos de forma proactiva para garantizar una transición fluida y mantener la fiabilidad de sus aplicaciones empresariales críticas. Una estrategia bien estructurada también le ayuda a agilizar la salida del centro de datos y reducir los riesgos de migración, garantizando la fiabilidad de sus aplicaciones empresariales críticas.

Oracle Database@Azure elimina la dependencia de Exadata local u Oracle Real Application Clusters (Oracle RAC) al acercar la base de datos a las cargas de trabajo de aplicaciones dentro de Microsoft Azure. Esta integración permite alojar tanto la base de datos como las aplicaciones en el mismo centro de datos, lo que reduce la latencia y minimiza la dependencia de la infraestructura física.

La implementación de esta configuración a menudo requiere una solución cuidadosamente diseñada para establecer la arquitectura de destino sin interrumpir las operaciones comerciales críticas. Muchas cargas de trabajo esenciales se despliegan en varias regiones para garantizar la continuidad del negocio mediante entornos de recuperación ante desastres o en espera. Este enfoque es compatible con una estrategia de migración híbrida en dos fases, que permite transiciones fluidas al tiempo que mantiene la estabilidad operativa.

Antes de empezar

Antes de comenzar, asegúrese de tener en cuenta lo siguiente:

  • Desactive el failover de inicio rápido en Oracle Data Guard para garantizar una transición sin problemas y controlada entre las regiones principal y en espera durante la migración.
  • OCI Database Migration proporciona migraciones validadas, entre versiones, tolerantes a fallos e incrementales de Oracle Database y MySQL para casos de uso en línea y fuera de línea, como ZDM y OCI Migration.
  • Esta arquitectura de referencia sigue el modelo de Oracle Gold Maximum Availability Architecture (MAA) en una configuración activa-en espera con despliegue entre regiones para una resiliencia mejorada. Esta arquitectura de referencia se puede ampliar para utilizar MAA platinum, donde la alta disponibilidad local se logra mediante la replicación síncrona mediante el uso de Oracle Data Guard entre zonas de disponibilidad, mientras que la recuperación ante desastres entre regiones se implementa con replicación asíncrona.

Arquitectura

Esta arquitectura describe un enfoque por fases para migrar Oracle Database local a Oracle Exadata Database Service en Oracle Database@Azure con un tiempo de inactividad mínimo.

Para simplificar esta estrategia, la desglosamos en tres aspectos clave: el estado actual, el estado futuro y las fases de migración.

Esta arquitectura de referencia tiene cuatro componentes principales (marcados con números azules en el diagrama).
Número Componente Descripción
1 Centro de datos principal local Aloja la base de datos y la aplicación como el sistema principal antes de la migración.
2 Centro de datos en espera local Mantiene un sistema en espera replicando la base de datos primaria local.
3 Región principal de Azure Ejecuta la aplicación y la base de datos en Oracle Database@Azure, convirtiéndose en el sistema principal posterior a la migración.
4 Región en espera de Azure Un sitio de recuperación ante desastres que replica la región principal mediante Oracle Data Guard.

A continuación se muestra la descripción de logical-architecture-diagram.png
Descripción de la ilustración logical-architecture-diagram.png

logical-architecture-diagram-oracle.zip

Estado Actual

En la configuración existente, tanto el centro de datos principal (1) como el centro de datos en espera (2) se alojan de forma local, lo que admite bases de datos y cargas de trabajo de aplicaciones. El centro de datos principal gestiona todas las solicitudes, mientras que el centro de datos en espera mantiene la replicación asíncrona mediante Oracle Data Guard. Esto garantiza una alta disponibilidad, con el sistema en espera listo para el failover en caso de fallos inesperados.

Estado futuro

La arquitectura futura refleja la configuración actual, pero está totalmente alojada en la nube, abarcando dos regiones de Azure: la región principal (3) y la región en espera (4). La base de datos se migra a los servicios de Exadata de Oracle Database@Azure, con replicación asíncrona entre las bases de datos principal y en espera gestionadas a través de Oracle Data Guard a través de la red de Oracle Cloud Infrastructure (OCI).

Para una conectividad segura entre el centro de datos local y Azure, se despliega un firewall de Azure en un hub de WAN virtual (vWAN) seguro en Azure.

Fases de migración

La migración sigue un enfoque de dos fases para garantizar una transición controlada y fiable.

Fase 1: transición de la base de datos en espera local a Azure y switchover

En esta fase, el sistema en espera local (2) se migra a Azure (3). Una vez completados, se intercambian los roles principal (1) y en espera (3), lo que convierte a Azure en la nueva región principal.

  1. Establezca la conectividad entre el entorno local y Azure mediante Azure ExpressRoute.
  2. Configure el hub seguro de Azure, el firewall de Azure y vWAN para la seguridad (si aún no está en su lugar).
  3. Aprovisione Oracle Exadata Cloud Infrastructure en la región principal de Azure y, a continuación:
    1. Configure un cluster de máquina virtual (VM) de Oracle Exadata y cree la base de datos de destino.
    2. Active los archive logs y el registro forzado en la base de datos primaria (si aún no está activada).
  4. Configure la Red de Oracle para el listener y los nombres TNS para la detección.
  5. Restaure del servicio para configurar una base de datos en espera en la región principal de Azure (3).
  6. Realice un switchover, convirtiendo la base de datos de Azure (3) en la nueva base de datos principal.
  7. Migre aplicaciones a la región principal de Azure (3) y actualice las rutas DNS.
  8. Verifique la configuración de Data Guard y supervise el estado de replicación.

Fase 2: establecimiento de la base de datos en espera en Azure y desmantelamiento local

En esta fase, se configura un sistema en espera (4) en Azure y se desactivan los recursos locales (1 y 2).

  1. Aprovisione Oracle Exadata Cloud Infrastructure en la región en espera (4) con Oracle Database@Azure.
  2. Configure un cluster de VM de Oracle Exadata y cree la base de datos en espera.
  3. Active Oracle Data Guard para asociar la base de datos de región principal (3) a la base de datos en espera (4).
  4. Utiliza redes OCI para la replicación de alto rendimiento, aprovechando el intercambio de tráfico local y remoto dentro de una topología de hub y radios entre las bases de datos principal y en espera.
  5. Migre las cargas de trabajo de la aplicación a la región en espera de Azure (4).
  6. Pare la sincronización con los recursos locales y, a continuación, retire los recursos de la base de datos y la aplicación locales de los centros de datos principales (1) y en espera (2).

El siguiente diagrama ilustra esta arquitectura de referencia.


Descripción de la arquitectura física diagram.png
Descripción de la ilustración physical-architecture-diagram.png

físico-arquitectura-diagrama-oracle.zip

Microsoft Azure proporciona los siguientes componentes:

  • Región de Azure

    Una región de Azure es un área geográfica en la que residen uno o más centros de datos físicos de Azure, denominados zonas de disponibilidad. Las regiones son independientes entre sí y pueden separarse grandes distancias (entre países o incluso continentes).

    Las regiones de Azure y OCI son áreas geográficas localizadas. Para Oracle Database@Azure, una región de Azure está conectada a una región de OCI, con zonas de disponibilidad (AZ) en Azure conectadas a dominios de disponibilidad (AD) en OCI. Se seleccionan los pares de regiones de Azure y OCI para minimizar la distancia y la latencia.

  • Zona de disponibilidad de Azure

    Las zonas de disponibilidad de Azure son ubicaciones físicamente separadas dentro de una región de Azure, diseñadas para garantizar una alta disponibilidad y resiliencia al proporcionar energía, refrigeración y redes independientes.

  • Azure VNet

    Microsoft Azure Virtual Network (VNet) es el componente fundamental de su red privada en Azure. VNet permite que muchos tipos de recursos de Azure, como máquinas virtuales (VM) de Azure, se comuniquen de forma segura entre sí, Internet y redes locales.

  • Subred delegada de Azure

    La delegación de subred es la capacidad de Microsoft para inyectar un servicio gestionado, específicamente un servicio de plataforma como servicio (PaaS), directamente en la red virtual. Esto le permite designar o delegar una subred para que sea el directorio raíz de un servicio gestionado externo dentro de la red virtual, de modo que el servicio externo actúe como recurso de red virtual, aunque sea un servicio PaaS externo.

  • VNIC de Azure

    Los servicios de los centros de datos de Azure tienen tarjetas de interfaz de red (NIC) físicas. Las instancias de máquina virtual se comunican mediante NIC virtuales (VNIC) asociadas con las NIC físicas. Cada instancia tiene una VNIC primaria que se crea y asocia automáticamente durante el inicio y que está disponible durante el ciclo de vida de la instancia.

  • Gateway de red virtual de Azure

    Azure Virtual Network Gateway establece una conectividad segura entre instalaciones entre una red virtual de Azure y una red local. Le permite crear una red híbrida que abarque su centro de datos y Azure.

  • WAN virtual de Azure

    Microsoft Azure Virtual WAN (VWAN) es un servicio de red que reúne muchas funcionalidades de red, seguridad y enrutamiento para proporcionar una única interfaz operativa.

  • Hub seguro de Azure

    Un hub seguro de Azure, también conocido como hub virtual seguro, es un hub WAN virtual de Azure mejorado con políticas de seguridad y enrutamiento gestionadas por Azure Firewall Manager. Simplifica la creación de arquitecturas de red transitivas y de hub y radios mediante la integración de servicios de seguridad nativos para la gobernanza y protección del tráfico. Esta configuración automatiza el enrutamiento de tráfico, eliminando la necesidad de rutas definidas por el usuario (UDR). Las organizaciones pueden utilizar un hub seguro para filtrar y proteger el tráfico entre redes virtuales, sucursales e Internet, lo que garantiza una seguridad sólida y una gestión de red optimizada.

  • Administrador de firewall de Azure

    Azure Firewall Manager es un servicio de gestión de seguridad centralizado que simplifica el despliegue y la configuración de Azure Firewall en varias regiones y suscripciones. Permite la gestión jerárquica de políticas, lo que permite que las políticas de firewall globales y locales se apliquen de forma consistente. Cuando se integra con Azure Virtual WAN (vWAN) y un hub seguro, Azure Firewall Manager mejora la seguridad mediante la automatización del enrutamiento y el filtrado de tráfico sin necesidad de rutas definidas por el usuario (UDR). Esta integración garantiza que el tráfico entre redes virtuales, sucursales e Internet se gestione y controle de forma segura, proporcionando una solución de seguridad de red sólida y optimizada.

  • Azure ExpressRoute

    Azure ExpressRoute es un servicio que permite conexiones privadas entre centros de datos locales y Microsoft Azure, omitiendo la red pública de Internet. Esto da como resultado una mayor seguridad, fiabilidad y velocidades más rápidas con latencias coherentes. Las conexiones ExpressRoute se pueden establecer a través de un proveedor de conectividad mediante varios métodos, como Ethernet punto a punto, cualquier a cualquier (IP VPN) o interconexiones virtuales. Al integrarse con centros de datos locales, ExpressRoute permite una extensión perfecta de su red a la nube, lo que facilita los escenarios de nube híbrida, la recuperación ante desastres y la migración de datos con un rendimiento y seguridad mejorados.

Oracle Cloud Infrastructure proporciona los siguientes componentes:

  • Región

    Una región de Oracle Cloud Infrastructure es un área geográfica localizada que contiene uno o más centros de datos, que alojan dominios de disponibilidad. Las regiones son independientes entre sí y pueden separarse grandes distancias (entre países o incluso continentes).

  • Dominio de disponibilidad

    Los dominios de disponibilidad son centros de datos independientes dentro de una región. Los recursos físicos de cada dominio de disponibilidad están aislados de los recursos de los otros dominios de disponibilidad, lo que proporciona tolerancia a fallos. Los dominios de disponibilidad no comparten infraestructura, como la alimentación o la refrigeración, ni la red interna del dominio de disponibilidad. Por tanto, un fallo en un dominio de disponibilidad no debería afectar a los demás dominios de disponibilidad de la región.

  • Red y subred virtuales en la nube (VCN)

    Una VCN es una red personalizable definida por software que se configura en una región de Oracle Cloud Infrastructure. Al igual que las redes de los centros de datos tradicionales, las redes virtuales le proporcionan el control de su entorno de red. Una VCN puede tener varios bloques de CIDR no superpuestos que puede cambiar después de crear la VCN. Puede segmentar una VCN en subredes, las cuales se pueden acotar a una región o a un dominio de disponibilidad. Cada subred está formada por un rango contiguo de direcciones que no se solapan con las demás subredes de la VCN. Puede cambiar el tamaño de una subred después de la creación. Una subred puede ser pública o privada.

  • Tabla de rutas

    Las tablas de rutas virtuales contienen reglas para enrutar el tráfico de subredes a destinos fuera de una VCN, normalmente a través de gateways.

  • Lista de seguridad

    Para cada subred, puede crear reglas de seguridad que especifiquen el origen, el destino y el tipo de tráfico que se permite dentro y fuera de la subred.

  • Grupo de seguridad de red (NSG)

    Los NSG actúan como firewalls virtuales para sus recursos en la nube. Con el modelo de seguridad de confianza cero de Oracle Cloud Infrastructure, puede controlar el tráfico de red dentro de una VCN. Un NSG está formado por un juego de reglas de seguridad de entrada y salida que se aplican solo a un juego especificado de VNIC en una única VCN.

  • Oracle Database Autonomous Recovery Service

    Oracle Database Autonomous Recovery Service es un servicio de Oracle Cloud que protege las bases de datos de Oracle. La automatización de copias de seguridad y las capacidades mejoradas de protección de datos para bases de datos OCI le permiten descargar todos los requisitos de procesamiento y almacenamiento de copias de seguridad en Oracle Database Autonomous Recovery Service, lo que reduce los costos de infraestructura de copia de seguridad y la sobrecarga de administración manual.

  • Servicio de base de datos de Exadata

    le permite aprovechar la potencia de Exadata en la nube. Oracle Exadata Database Service ofrece capacidades probadas de Oracle Database en una infraestructura de Oracle Exadata optimizada y específica en la nube pública. La automatización incorporada en la nube, la ampliación flexible de recursos, la seguridad y el rendimiento rápido para todas las cargas de trabajo de Oracle Database le ayudan a simplificar la gestión y reducir los costos.

  • Oracle Database@Azure

    Oracle Database@Azure es el servicio de Oracle Database (Oracle Exadata Database Service on Dedicated Infrastructure y Oracle Autonomous Database Serverless) que se ejecuta en Oracle Cloud Infrastructure (OCI), desplegado en centros de datos de Microsoft Azure. El servicio ofrece funciones y paridad de precios con OCI. Adquiera el servicio en Azure Marketplace.

    Oracle Database@Azure integra tecnologías de Oracle Exadata Database Service, Oracle Real Application Clusters (Oracle RAC) y Oracle Data Guard en la plataforma Azure. Los usuarios gestionan el servicio en la consola de Azure y con las herramientas de automatización de Azure. El servicio se despliega en Azure Virtual Network (VNet) e integrado con el sistema de gestión de identidad y acceso de Azure. Las métricas genéricas de OCI y Oracle Database y los logs de auditoría están disponibles de forma nativa en Azure. El servicio requiere que los usuarios tengan una suscripción a Azure y un arrendamiento de OCI.

    Autonomous Database se basa en la infraestructura de Oracle Exadata, es autogestionada, autoprotegida y autorreparable, lo que ayuda a eliminar la gestión manual de bases de datos y los errores humanos. Autonomous Database permite el desarrollo de aplicaciones escalables basadas en IA con cualquier dato mediante capacidades de IA integradas utilizando su elección de modelo de lenguaje grande (LLM) y ubicación de despliegue.

    Tanto Oracle Exadata Database Service como Oracle Autonomous Database Serverless se aprovisionan fácilmente a través del portal nativo de Azure, lo que permite el acceso al ecosistema más amplio de Azure.

  • Data Guard

    Oracle Data Guard y Oracle Active Data Guard proporcionan un juego completo de servicios que crean, mantienen, gestionan y supervisan una o más bases de datos en espera y que permiten que las bases de datos Oracle de producción permanezcan disponibles sin interrupción. Oracle Data Guard mantiene estas bases de datos en espera como copias de la base de datos de producción mediante la replicación en memoria. Si la base de datos de producción deja de estar disponible debido a una interrupción planificada o no planificada, Oracle Data Guard puede cambiar cualquier base de datos en espera al rol de producción, minimizando el tiempo de inactividad asociado a la interrupción. Oracle Active Data Guard proporciona la capacidad adicional de descargar cargas de trabajo de lectura principalmente en bases de datos en espera y también proporciona funciones avanzadas de protección de datos.

  • Intercambio de tráfico local

    El intercambio de tráfico local permite intercambiar tráfico entre una VCN y otra VCN de la misma región. El intercambio de tráfico significa que las redes virtuales en la nube se comunican mediante direcciones IP privadas, sin que el tráfico recorra Internet ni se enrute a través de su red local.

  • Intercambio de tráfico remoto

    El intercambio de tráfico remoto permite que los recursos de diferentes redes virtuales en la nube se comuniquen mediante direcciones IP privadas. El intercambio de tráfico remoto elimina la necesidad de un gateway de Internet o direcciones IP públicas para las instancias que deben comunicarse con otra VCN en una región diferente.

  • Red de nube virtual de hub

    Una red virtual en la nube (VCN) con hub actúa como punto central para gestionar y enrutar el tráfico entre varias redes virtuales en la nube, tanto en la misma región como en distintas regiones. Mediante gateways de intercambio de tráfico local (LPG), la VCN de hub se conecta a varias VCN radiales en la misma región, lo que facilita una comunicación eficiente y una gestión centralizada. Para la conectividad entre regiones, se utilizan grupos de intercambio de tráfico remoto (RPG), donde cada VCN se asocia a un gateway de direccionamiento dinámico (DRG) y establece conexiones de intercambio de tráfico remoto (RPC). Esta configuración resulta especialmente útil para direccionar el tráfico de Oracle Data Guard, lo que garantiza que los redo logs y otros datos de sincronización se transmitan de forma eficaz desde la base de datos primaria de una región a la base de datos en espera de otra región, manteniendo así la consistencia de los datos y la alta disponibilidad.

El sistema local tiene los siguientes componentes:

  • Centro de datos principal

    Un centro de datos local que aloja aplicaciones y una base de datos Oracle sirve como sitio principal para las operaciones de negocio, lo que garantiza un alto rendimiento y disponibilidad de datos. Para mejorar la recuperación ante desastres y la continuidad del negocio, este centro de datos principal está asociado a un centro de datos en espera, que a menudo se encuentra en una región geográfica diferente. El centro de datos en espera mantiene una copia sincronizada de la base de datos Oracle mediante Oracle Data Guard, que replica continuamente los cambios de la base de datos principal a la base de datos en espera. En caso de fallo o desastre en la ubicación primaria, el centro de datos en espera puede tomar el control rápidamente, lo que minimiza el tiempo de inactividad y la pérdida de datos, garantizando así operaciones de negocio ininterrumpidas.

  • Centro de datos en espera

    Un centro de datos en espera es un componente fundamental de una estrategia de recuperación ante desastres, diseñada para garantizar la continuidad del negocio en condiciones imprevistas. Aloja una réplica de las aplicaciones principales y Oracle Database, que se mantiene sincronizada a través de tecnologías como Oracle Data Guard. En caso de fallo o desastre en el centro de datos principal, el centro de datos en espera puede asumir sin problemas las operaciones, lo que minimiza el tiempo de inactividad y la pérdida de datos. Esta configuración garantiza que los procesos de negocio continúen funcionando sin problemas, proporcionando resiliencia frente a las interrupciones y manteniendo la disponibilidad del servicio para los usuarios y clientes.

  • Base de Datos

    Una base de datos Oracle alojada en un centro de datos local desempeña un papel crucial en el almacenamiento y la gestión de datos empresariales. Proporciona un entorno seguro y de alto rendimiento para gestionar operaciones de negocio esenciales, lo que garantiza la integridad y disponibilidad de los datos. Esta configuración permite a las organizaciones mantener un control total sobre su infraestructura de datos, personalizar las configuraciones para satisfacer necesidades específicas y cumplir con los requisitos normativos. Al aprovechar las sólidas funciones de base de datos de Oracle, las empresas pueden procesar transacciones de manera eficiente, generar informes y respaldar los procesos de toma de decisiones.

  • Aplicaciones

    Las aplicaciones que se ejecutan en un centro de datos local sobre una base de datos Oracle son parte integral de las operaciones empresariales. Estas aplicaciones aprovechan la sólida y fiable base de datos Oracle para procesar transacciones, gestionar datos de clientes y generar estadísticas empresariales críticas. Al operar en un entorno seguro y controlado, garantizan un alto rendimiento, integridad de los datos y cumplimiento de los estándares normativos. Esta configuración permite a las empresas personalizar su infraestructura para satisfacer necesidades específicas, proporcionando una base estable para las operaciones diarias y la toma de decisiones estratégicas.

Recomendaciones

Utilice las siguientes recomendaciones como punto de partida. Sus requisitos pueden diferir de la arquitectura descrita aquí.

Rendimiento

Se recomienda encarecidamente una red OCI para la replicación de recuperación ante desastres (DR). La infraestructura de red de alto rendimiento de OCI garantiza una conectividad de gran ancho de banda y baja latencia, lo que es esencial para una replicación y sincronización de datos eficientes entre las bases de datos principal y en espera. Aprovechar las redes de OCI para Oracle Data Guard con Oracle Database@Azure ofrece ventajas significativas en rendimiento, seguridad y fiabilidad.

Esta configuración refuerza la DR al permitir una transmisión rápida y segura de redo logs y datos críticos, minimizando la pérdida de datos y el tiempo de inactividad durante los escenarios de failover. Además, las funciones de seguridad integradas de OCI, incluido el cifrado de red y los controles de acceso avanzados, proporcionan una protección sólida para los datos confidenciales.

Al integrar las redes de OCI con Oracle Database@Azure, las organizaciones pueden lograr una arquitectura de base de datos fluida, resistente y de alta disponibilidad que mejore la continuidad del negocio y la eficiencia operativa.

Consideraciones

Tenga en cuenta los siguientes puntos al desplegar esta arquitectura de referencia.

  • Continuidad del negocio

    La integración de Oracle Database Autonomous Recovery Service con Oracle Data Guard crea una estrategia de protección de datos completa y resiliente para las configuraciones de bases de datos principal y en espera. Oracle Data Guard garantiza una alta disponibilidad y una recuperación ante desastres mediante el mantenimiento de una base de datos en espera sincronizada que puede asumir el control en caso de fallo de la base de datos primaria, minimizando así el tiempo de inactividad y la pérdida de datos.

    Como complemento de esto, Oracle Database Autonomous Recovery Service proporciona una solución de copia de seguridad totalmente gestionada y centralizada con protección sin pérdida de datos y capacidades de recuperación en tiempo real. Esta combinación garantiza una protección continua de los datos a través de la replicación en tiempo real y mecanismos de copia de seguridad sólidos, lo que mejora la integridad de los datos y la continuidad del negocio.

  • Disponibilidad

    El despliegue de varias instancias de Oracle Database en diferentes zonas de disponibilidad (AZ) dentro de una región, junto con Active Data Guard, mejora significativamente las capacidades de alta disponibilidad y recuperación ante desastres. Las AZ están aisladas entre sí, lo que garantiza que los fallos en uno no afecten a los demás. Al distribuir instancias de base de datos entre varias AZ, las organizaciones pueden mitigar los riesgos asociados a fallos localizados, como interrupciones de energía o problemas de hardware.

    Active Data Guard refuerza aún más esta configuración manteniendo una réplica sincronizada en tiempo real de la base de datos principal, lo que permite una conmutación por error sin problemas en caso de fallo de una instancia principal. Este enfoque garantiza una protección continua de los datos, un tiempo de inactividad mínimo y una sólida estrategia de recuperación ante desastres, proporcionando una infraestructura resiliente para aplicaciones esenciales.

  • Rendimiento Global

    Al migrar bases de datos de entornos locales a Azure, es crucial tener en cuenta el ancho de banda de Azure ExpressRoute para garantizar una transferencia fluida y eficiente. Por ejemplo, si va a migrar una base de datos pequeña de 100 GB, un circuito ExpressRoute de 200 Mbps puede manejar la transferencia en aproximadamente 1 hora y 10 minutos, suponiendo condiciones óptimas y sin sobrecarga. Sin embargo, para una base de datos más grande de 1 TB, el mismo circuito de 200 Mbps tardaría alrededor de 11 horas y 40 minutos. La actualización a un circuito de 1 Gbps reduciría significativamente este tiempo a aproximadamente 2 horas y 20 minutos. Planifique en consecuencia para que no se consuma todo el ancho de banda; de lo contrario, otras aplicaciones que se comunican entre las ubicaciones locales y la nube podrían verse afectadas.

Explorar más

Para obtener más información sobre Oracle Database y las herramientas relacionadas, consulte los siguientes recursos.

Revise estos recursos de despliegue para implantar esta arquitectura de referencia:

Revise estos recursos adicionales:

Confirmaciones

  • Autores: Neeraj Tyagi, Thomas Van Buggenhout
  • Contribuyentes: Emiel Ramakers, John Sulyok