Más información sobre la recuperación ante desastres para bases de datos locales y regionales

Garantizar la continuidad del negocio es fundamental para el éxito a la hora de diseñar aplicaciones. Para lograrlo se necesita una estrategia de recuperación ante desastres que pueda restaurar rápidamente el servicio durante las interrupciones.
Durante décadas, las organizaciones han confiado en Oracle Exadata Database Machine y en Oracle Data Guard, la principal tecnología de recuperación ante desastres de Oracle, para admitir aplicaciones esenciales, ya sean locales o dentro de Oracle Cloud Infrastructure (OCI). Oracle Exadata Database Service on Dedicated Infrastructure en Oracle Database@AWS ofrece el mismo rendimiento, conjunto de funciones y paridad de precios líderes del sector que Exadata en OCI. El hardware reside en los centros de datos de AWS para proporcionar baja latencia a las aplicaciones de AWS, además de capacidades inigualables de alta disponibilidad y recuperación ante desastres, lo que garantiza operaciones perfectas durante el mantenimiento y en caso de interrupción.

En este manual de soluciones, aprenderá a implantar la recuperación ante desastres con bases de datos en espera locales y regionales en Oracle Database@AWS.

Antes de empezar

Antes de comenzar, debe asegurarse de que:
  • La infraestructura de Exadata y los clusters de VM de Exadata se despliegan en la zona de disponibilidad y la región en espera.
  • Los rangos de CIDR de IP de red para los clusters de VM de Exadata principales y en espera no se superponen.

Revise las siguientes soluciones:

Revise estos recursos relacionados:

Arquitectura

Esta arquitectura muestra Oracle Exadata Database Service en Oracle Database@AWS en una topología de recuperación ante desastres que utiliza dos bases de datos en espera:
  • Una base de datos en espera local en la misma región que la principal, pero en una zona de disponibilidad diferente.
  • Una base de datos en espera remota en una región diferente.

Descripción de exadb-dbaws-dr-arch.png a continuación
Descripción de la ilustración exadb-dbaws-dr-arch.png

exadb-dbaws-dr-arch-oracle.zip

Oracle Database se ejecuta en un cluster de VM de Exadata en el Region 1 principal. Para la protección de datos y la recuperación ante desastres, Active Data Guard replica los datos en los dos clusters de VM de Exadata siguientes:

  • Una en la misma región pero en una zona de disponibilidad diferente (local en espera). Una base de datos en espera local es ideal para escenarios de failover, ya que no ofrece pérdida de datos para fallos locales mientras las aplicaciones siguen funcionando sin la sobrecarga de rendimiento que supone comunicarse con una región remota.
  • Una segunda base de datos en espera en una región diferente (base de datos en espera remota). Una base de datos en espera remota se utiliza normalmente para la recuperación ante desastres o para descargar cargas de trabajo de solo lectura.

Aunque el tráfico de red de Active Data Guard puede recorrer el eje central de AWS, Oracle recomienda esta arquitectura que lo enruta a través de OCI para obtener un rendimiento y una latencia optimizados.

La red de Oracle Exadata Database Service en Oracle Database@AWS está conectada a la subred del cliente de Exadata mediante un gateway de direccionamiento dinámico (DRG) gestionado por Oracle. También se necesita un DRG para crear una conexión de peer entre las redes virtuales en la nube en diferentes regiones. Dado que solo se permite un DRG por VCN en OCI, se necesita una segunda VCN con su propio DRG para conectar las redes virtuales en la nube principal y en espera en cada región.

  • El cluster de VM de Exadata principal se despliega en Region 1, availability zone 1 en VCN1 con el CIDR 10.10.0.0/16 y la subred del cliente CIDR 10.10.1.0/24.
  • VCN1 tiene gateways de intercambio de tráfico locales (LPG) LPG1 remote y LPG1 local.
  • La VCN del hub de la Region 1 principal es Hub VCN1 con CIDR 10.11.0.0/16.
  • El primer cluster de VM de Exadata en espera se despliega en Region 1, availability zone 2 en VCN2 con CIDR 10.20.0.0/16 y subred de cliente CIDR 10.20.1.0/24.
  • VCN2 tiene dos LPG LPG2 remote y LPG2 local.
  • La VCN del hub es la misma que la VCN del hub para la base de datos principal, Hub VCN1, ya que reside en la misma región.
  • Hub VCN1 tiene el LPG Hub LPG1, Hub LPG2 y DRG1.
  • El segundo cluster de VM de Exadata en espera se despliega en Region 2 en VCN3 con el CIDR 10.30.0.0/16 y la subred de cliente CIDR 10.30.1.0/24.
  • VCN3 tiene un LPG LPG3 remote.
  • La VCN del hub en la base de datos en espera remota Region 2 es Hub VCN3 con CIDR 10.33.0.0/16.
  • Hub VCN3 tiene un LPG Hub LPG3 y un DRG DRG3.
  • No se necesita ninguna subred para que las VCN de hub activen el enrutamiento en tránsito. Por lo tanto, estas redes virtuales en la nube pueden utilizar rangos de CIDR IP muy pequeños.

Esta arquitectura admite los siguientes componentes:

  • Región de AWS

    Las regiones de AWS son áreas geográficas separadas. Consisten en varias zonas de disponibilidad aisladas, separadas físicamente y conectadas con redes de baja latencia, alto rendimiento y altamente redundantes.

  • Zona de disponibilidad de AWS

    Las zonas de disponibilidad son centros de datos de alta disponibilidad en cada región de AWS.

  • Red virtual en la nube y subred de OCI

    Una red virtual en la nube (VCN) es una red personalizable y definida por software que se configura en una región de OCI. Al igual que las Redes de los Centros de Datos Tradicionales, las Redes Virtuales le proporcionan el control sobre 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.

  • 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 OCI, puede controlar el tráfico de red dentro de una VCN. Un NSG está formado por un conjunto de reglas para la entrada y salida que se aplican sólo a los conjuntos especificados de tarjetas de interfaz de red virtual (VNIC) en una única VCN.

  • Intercambio de tráfico local

    El intercambio de tráfico local permite que dos redes virtuales en la nube de la misma región de OCI se comuniquen directamente mediante direcciones IP privadas. Esta comunicación no atraviesa Internet ni su red local. El intercambio de tráfico local lo activa un gateway de intercambio de tráfico local (LPG), que sirve como punto de conexión entre las redes virtuales en la nube. Configure un LPG en cada VCN y establezca una relación de intercambio de tráfico para permitir que las instancias, los equilibradores de carga y otros recursos de una VCN accedan de forma segura a los recursos de otra VCN de la misma región.

  • Gateway de enrutamiento dinámico (DRG)

    The DRG is a virtual router that provides a path for private network traffic between VCNs in the same region, between a VCN and a network outside the region, such as a VCN in another OCI region, an on-premises network, or a network in another cloud provider.

  • Intercambio de tráfico Remoto

    El intercambio de tráfico remoto permite la comunicación privada entre recursos de diferentes redes virtuales en la nube, que se pueden ubicar en la misma región de OCI o en distintas regiones. Cada VCN utiliza su propio gateway de direccionamiento dinámico (DRG) para el intercambio remoto. Los DRG enrutan de forma segura el tráfico entre las VCN a través de la red troncal privada de OCI, lo que permite a los recursos comunicarse mediante direcciones IP privadas sin enrutar el tráfico a través de Internet o a través de redes locales. El intercambio de tráfico remoto elimina la necesidad de gateways de Internet o direcciones IP públicas para instancias que necesitan conectarse entre regiones.

  • Oracle Exadata Database Service on Dedicated Infrastructure

    Oracle Exadata Database Service on Dedicated Infrastructure permite aprovechar la potencia de Exadata en la nube. Oracle Exadata Database Service ofrece capacidades probadas de Oracle AI Database en una infraestructura de Oracle Exadata optimizada y diseñada específicamente 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 AI Database te ayudan a simplificar la gestión y reducir los costos.

  • Oracle Data Guard

    Oracle Data Guard y Active Data Guard proporcionan un completo juego de servicios que permiten crear, mantener, gestionar y controlar una o más bases de datos en espera para que las bases de datos Oracle de producción puedan sobrevivir ante desastres y corrupciones de datos de producció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, lo que minimiza el tiempo de inactividad asociado a la interrupción. Oracle Active Data Guard proporciona la capacidad adicional de descargar cargas de trabajo de lectura en su mayoría en bases de datos en espera y también proporciona funciones avanzadas de protección de datos.

Recomendaciones

Utilice las siguientes recomendaciones como punto de partida al realizar una recuperación ante desastres para Oracle Exadata Database Service en Oracle Database@AWS. Sus requisitos pueden diferir de la arquitectura que se describe aquí.
  • Utilice Active Data Guard para una prevención completa de la corrupción de datos con reparación automática de bloques, actualizaciones y migraciones en línea, y para descargar la carga de trabajo a la base de datos en espera con una ampliación en su mayoría de lectura.
  • Active Application Continuity para enmascarar las interrupciones de la base de datos durante los eventos planificados y no planificados de los usuarios finales.
  • Configure copias de seguridad automáticas en Oracle Database Autonomous Recovery Service en OCI. Aunque los datos están protegidos por Oracle Data Guard, minimice la carga de trabajo de copia de seguridad en la base de datos mediante la implantación de la estrategia de copia de seguridad incremental-forever que elimina las copias de seguridad completas semanales. También puede utilizar Amazon Simple Storage Service para realizar copias de seguridad automáticas.
  • Ejecute copias de seguridad desde la base de datos en espera para lograr la replicación de copia de seguridad entre regiones.
  • Utilice Full Stack DR de OCI para orquestar operaciones de switchover y failover de bases de datos.
  • Almacene las claves de Cifrado de datos transparente (TDE) de la base de datos en OCI Vault con claves gestionadas por el cliente.

Consideraciones

Al realizar una recuperación ante desastres local y regional para Oracle Exadata Database Service en Oracle Database@AWS, tenga en cuenta lo siguiente:

  • Cuando se crean clusters de VM de Exadata en el sitio secundario de Oracle Database@AWS, cada cluster de VM de Exadata se aprovisiona en su propia VCN de OCI. Conecte las redes virtuales en la nube y evite la superposición de CIDR, y asegúrese de que las bases de datos se comuniquen entre sí para que Data Guard pueda enviar datos redo.
  • La latencia entre regiones suele ser demasiado alta para el transporte síncrono en aplicaciones de misión crítica. Por lo tanto, utilice la replicación ASYNC de Data Guard entre regiones. Agregue la sincronización a distancia de Active Data Guard para garantizar que no se pierdan datos entre regiones.
  • Configure OCI como la red preferida para un mejor rendimiento, una menor latencia, un mayor rendimiento y un costo reducido; los primeros 10 TB/mes de salida de datos son gratuitos en todas las regiones.
  • Puede crear hasta seis bases de datos en espera por base de datos principal mediante las herramientas en la nube.

Acerca de los servicios y los roles necesarios

Esta solución requiere los siguientes servicios y roles:

  • Oracle Cloud Infrastructure Networking
  • Oracle Exadata Database Service

Estos son los roles necesarios para cada servicio.

Nombre de servicio: Rol Obligatorio para...
Oracle Exadata Database Service: manage database-family Gestionar la base de datos, incluida la adición y el funcionamiento de despliegues de Active Data Guard
OCI Networking: manage vcn-family Gestionar los componentes de red, incluidas las redes virtuales en la nube, las subredes, las reglas de seguridad y el intercambio de VCN

Consulte Productos, soluciones y servicios de Oracle para obtener lo que necesita.