Preparación para Oracle Exadata Database Service en infraestructura de Exascale

Revise OCI, así como los requisitos de sitio, red y almacenamiento para preparar y desplegar Oracle Exadata Database Service en la infraestructura de Exascale en su centro de datos.

Requisitos de Oracle Cloud Infrastructure (OCI) para Oracle Exadata Database Service en infraestructura de Exascale
Aprenda los conceptos básicos para comenzar a utilizar Oracle Cloud Infrastructure.
Configuración de red para Oracle Exadata Database Service en instancias de infraestructura de Exascale
En este tema se describe la configuración recomendada para la VCN y varios requisitos relacionados para la instancia de Oracle Exadata Database Service en la infraestructura de Exascale.
Interoperabilidad entre servicios entre ExaDB-D y ExaDB-XS: Data Guard, copia de seguridad y restauración
Ahora puede crear un grupo de Oracle Data Guard entre servicios de base de datos.

Requisitos de Oracle Cloud Infrastructure (OCI) para Oracle Exadata Database Service en la infraestructura de Exascale

Conozca los conceptos básicos para empezar a utilizar Oracle Cloud Infrastructure.

Oracle Exadata Database Service en Exascale Infrastructure se gestiona en el plano de control de Oracle Cloud Infrastructure (OCI). Los recursos de Oracle Exadata Database Service en la infraestructura de Exascale se despliegan en su arrendamiento de OCI.

Para poder aprovisionar Oracle Exadata Database Service en la infraestructura de Exascale, el arrendamiento de Oracle Cloud Infrastructure debe estar activado para utilizar Oracle Exadata Database Service en la infraestructura de Exascale. Revise la información de esta publicación para obtener más detalles.

Las siguientes tareas son comunes para todos los despliegues de OCI. Consulte los enlaces de Temas relacionados para buscar la documentación asociada de Oracle Cloud Infrastructure.

Introducción a OCI.
Si no está familiarizado con OCI, conozca los conceptos básicos para comenzar siguiendo OCI Getting Started Guide.
Configuración del arrendamiento.
Una vez que Oracle haya creado el arrendamiento en OCI, un administrador de su compañía tendrá que realizar algunas tareas de configuración y establecer un plan de organización de sus usuarios y recursos en la nube. La información de este tema le ayudará a comenzar.
Gestión de regiones
En este tema se describen los conceptos básicos de la gestión de las suscripciones a su región.
Gestión de compartimentos
En este tema se describen los conceptos básicos del trabajo con compartimentos.
Gestión de usuarios
En este tema se describen los conceptos básicos del trabajo con usuarios.
Gestión de Grupos
En este tema se describen los conceptos básicos del trabajo con grupos.

Política de IAM necesaria para Oracle Exadata Database Service en infraestructura de Exascale
Revise la política de gestión de identidad y acceso (IAM) para aprovisionar sistemas Oracle Exadata Database Service en infraestructura de Exascale.

Temas relacionados

Tema principal: Preparación para Oracle Exadata Database Service en infraestructura de Exascale

Política de IAM necesaria para Oracle Exadata Database Service en la infraestructura de Exascale

Revise la política de gestión de identidad y acceso (IAM) para aprovisionar sistemas Oracle Exadata Database Service en infraestructura de Exascale.

Una política es un documento de IAM que especifica quién tiene qué tipo de acceso a los recursos. Se utiliza de distintas formas:

Sentencia individual escrita en el lenguaje de la política
Recopilación de sentencias en un documento único denominado "política", que tiene un ID de Oracle Cloud (OCID) asignado
Conjunto general de políticas que utiliza la organización para controlar el acceso a los recursos

Un compartimentoes una recopilación de recursos relacionados a los que solo pueden acceder ciertos grupos que hayan recibido permiso para ello por parte de un administrador de la organización.

Para utilizar Oracle Cloud Infrastructure, se le debe conceder el tipo de acceso necesario en una política escrita por un administrador, tanto si utiliza la consola como la API de REST con un software development kit (SDK), una interfaz de línea de comandos (CLI) o alguna otra herramienta. Si intenta realizar una acción y recibe un mensaje que indica que no tiene permiso o que no está autorizado, confirme con el administrador del arrendamiento el tipo de acceso que se le ha otorgado y en qué compartimento debe trabajar.

Para administradores: la política de "Permitir a los administradores de bases de datos gestionar sistemas de base de datos" permite al grupo especificado realizar todas las acciones en las bases de datos y los recursos de base de datos relacionados.

Si no está familiarizado con las políticas, consulte "Introducción a las políticas" y "Políticas comunes". Si desea profundizar en la escritura de políticas para bases de datos, consulte "Detalles del servicio Database".

Para obtener más información sobre la escritura de políticas específicas para los recursos de Exadata Cloud@Customer, consulte "Detalles de políticas para Oracle Exadata Database Service en la infraestructura de Exascale".

Temas relacionados

Tema principal: Requisitos de Oracle Cloud Infrastructure (OCI) para Oracle Exadata Database Service en infraestructura de Exascale

Configuración de red para Oracle Exadata Database Service en instancias de infraestructura de Exascale

En este tema se describe la configuración recomendada para la VCN y varios requisitos relacionados para la instancia de Oracle Exadata Database Service on Exascale Infrastructure.

Antes de configurar una instancia de Oracle Exadata Database Service en la infraestructura de Exascale, debe configurar una red virtual en la nube (VCN) y otros componentes del servicio de redes.

VCN y subredes
Para iniciar un cluster de VM de Oracle Exadata Database Service en la infraestructura de Exascale, debe tener una red virtual en la nube y al menos dos subredes.
Acceso de nodo a Object Storage: ruta estática
Para poder realizar copias de seguridad de bases de datos y aplicar parches y actualizar herramientas en la nube en una instancia de Oracle Exadata Database Service on Exascale Infrastructure, Oracle recomienda configurar Autonomous Recovery Service.
Gateway de servicio para la VCN
Su VCN necesita acceso tanto a Object Storage para las copias de seguridad como a los repositorios de Oracle YUM para las actualizaciones del sistema operativo.
Reglas de seguridad para Oracle Exadata Database Service en la infraestructura de Exascale
En esta sección se muestran las reglas de seguridad que se deben utilizar con Oracle Exadata Database Service en la infraestructura de Exascale.
Formas de implantar las reglas de seguridad
Aprenda a implantar las reglas de seguridad en la VCN mediante el servicio de red.
Requisitos de red para Oracle Database Autonomous Recovery Service
Oracle Database Autonomous Recovery Service requiere una subred del servicio de recuperación registrada dedicada a las operaciones de copia de seguridad y recuperación en la red virtual en la nube (VCN) de la base de datos.

Tema principal: Preparación para Oracle Exadata Database Service en infraestructura de Exascale

VCN y subredes

Para iniciar un cluster de VM de Oracle Exadata Database Service en la infraestructura de Exascale, debe tener una red virtual en la nube y al menos dos subredes.

Para iniciar un cluster de VM de Oracle Exadata Database Service en la infraestructura de Exascale, debe tener una red virtual en la nube, al menos dos subredes y seleccionar el tipo de resolución DNS que utilizará:

Una VCN en la región en la que desea el cluster de VM de Oracle Exadata Database Service en la infraestructura de Exascale
Al menos dos subredes en la VCN. Las dos subredes son:
- subred de cliente
- subred de copia de seguridad
Elija qué método de resolución de nombres DNS utilizará. Consulte Opciones de DNS en la VCN

En general, Oracle recomienda el uso de subredes regionales que abarquen todos los dominios de disponibilidad de la región. Para obtener más información, consulte Visión general de las VCN y las subredes.

Se deberán crear tablas de rutas personalizadas para cada subred. También creará reglas de seguridad para controlar el tráfico hacia y desde la red de cliente y la red de copia de seguridad de los nodos de cálculo de Exadata (para el recurso de cluster de VM en la nube, los nodos se denominan máquinas virtuales). A continuación se ofrece más información sobre estos elementos.

Opción 1: subred de cliente pública con gateway de internet
Esta opción puede ser útil al realizar un trabajo de desarrollo o de prueba de concepto.
Opción 2: subredes privadas
Oracle recomienda las subredes privadas para un sistema de producción.
Requisitos para el espacio de direcciones IP
Debe crear una VCN con dos subredes y asegurarse de que hay suficientes direcciones para el tamaño del cluster de VM.
Configuración de una ruta estática para acceder al almacén de objetos
Para enrutar el tráfico de copia de seguridad a la interfaz de copia de seguridad (BONDETH1), se debe configurar una ruta estática en cada uno de los nodos de cálculo del cluster.
Configuración de DNS para una instancia de Oracle Exadata Database Service en infraestructura de Exascale
DNS permite utilizar nombres de host en lugar de direcciones IP para comunicarse con una instancia de Exadata Cloud Infrastructure.
DNS: nombres cortos para la VCN, las subredes y Oracle Exadata Database Service en la instancia de infraestructura de Exascale
El solucionador de Internet y VCN permite la asignación de nombre de host a los nodos y la resolución de DNS de esos nombres de host por recursos en la VCN.
Configuración de DNS privada
Revise los requisitos necesarios para utilizar la DNS privada.

Temas relacionados

Tema principal: Configuración de red para Oracle Exadata Database Service en instancias de infraestructura de Exascale

Opción 1: subred de cliente pública con gateway de internet

Esta opción puede ser útil cuando se realiza una prueba de concepto o un trabajo de desarrollo.

Puede utilizar esta configuración en producción si desea utilizar un gateway de internet con la VCN o si tiene servicios que solo se ejecutan en una red pública y requieren acceso a la base de datos. Consulte el siguiente diagrama y descripción.

A continuación se incluye la descripción de network_exa_public_client.png

Descripción de la ilustración network_exa_public_client.png

Debe configurar lo siguiente:

Subredes:
- Subred de cliente pública ( pública significa que los recursos de la subred pueden tener direcciones IP públicas a su discreción).
- Subred de copia de seguridad privada ( privada significa que los recursos de la subred no pueden tener direcciones IP públicas y, por lo tanto, no pueden recibir conexiones entrantes de internet).
Gateways para la VCN:
- Gateway de internet (para su uso en la subred del cliente).
- Gateway de servicio (para su uso en la subred de copia de seguridad) .
Tablas de rutas:
- Tabla de rutas personalizadas para la subred de cliente pública, con una ruta para 0.0.0.0/0, y el destino = el gateway de internet.
- Separe la tabla de rutas personalizadas para la subred de copia de seguridad privada, con una regla de ruta para las etiquetas CIDR de servicio (consulte sobre las etiquetas CIDR en Visión general de los gateways de servicio y las etiquetas CIDR de servicio disponible, y el destino = el gateway de servicio).
Reglas de seguridad para activar el tráfico deseado hacia y desde los nodos de cálculo de las máquinas virtuales de Exadata.
Acceso del nodo a Object Storage: ruta estática en los nodos de cálculo de la instancia de Exadata Cloud Service (para permitir el acceso a los servicios de OCI mediante la subred de copia de seguridad).

Nota

Consulte esta incidencia conocida para obtener información sobre la configuración de las reglas de rutas con el gateway de servicio como destino en las tablas de rutas asociadas a subredes públicas.

Tema principal: VCN y subredes

Opción 2: subredes privadas

Oracle recomienda subredes privadas para un sistema de producción.

Ambas redes son privadas y no se puede acceder a ellas desde internet. Consulte el siguiente diagrama y descripción.

A continuación se incluye la descripción de network_exa_private_client.png

Descripción de la ilustración network_exa_private_client.png

Debe configurar lo siguiente:

Subredes:
- subred de cliente privada.
- subred de copia de seguridad privada.
Gateways para la VCN:
- Gateway de enrutamiento dinámico (DRG), con FastConnect o una VPN de IPSec a la red local (para su uso en la subred del cliente).
- Gateway de servicio Para que lo utilicen las subredes de cliente y copia de seguridad para acceder a los servicios de OCI, como Object Storage para copias de seguridad, YUM para actualizaciones del sistema operativo, IAM (Identiy Access Management) y OCI Vault (integración de KMS). Consulte también Opción 2: acceso del gateway de servicio a Object Storage y al repositorio de YUM.
- Gateway de NAT(opcional) Para su uso por parte de la subred del cliente para acceder a los puntos finales públicos no soportados por el gateway de servicio.
Tablas de rutas:
- Tabla de rutas personalizadas para la subred de cliente privada con las siguientes reglas:
  - Una regla para el CIDR de la red local y el destino = DRG.
  - Una regla para la etiqueta CIDR del servicio denominada Todos los servicios de <region> en Oracle Services Network y el destino = el gateway de servicio. Oracle Services Network es una red conceptual de Oracle Cloud Infrastructure reservada para los servicios de Oracle. La regla permite a la subred de cliente acceder al repositorio regional de Oracle YUM para las actualizaciones del sistema operativo. Consulte también Opción 2: acceso del gateway de servicio a Object Storage y al repositorio de YUM.
  - Opcionalmente, una regla para 0.0.0.0/0, y el destino = gateway de NAT.
- Separe la tabla de rutas personalizadas para la subred de copia de seguridad privada con una regla:
  - La misma regla que para la subred de cliente: para la etiqueta CIDR de servicio denominada Todos los servicios de <region> en Oracle Services Network, y el destino = el gateway de servicio. Esta regla permite que la subred de copia de seguridad acceda a la instancia de Object Storage regional para copias de seguridad.
Reglas de seguridad para activar el tráfico deseado hacia y desde los nodos de Exadata. Consulte Reglas de seguridad para la instancia de Exadata Cloud Service.
Opcionalmente, agregue una ruta estática en los nodos de cálculo a otros servicios de OCI (para los clusters de VM, las máquinas virtuales) para activar el acceso, si solo se puede acceder a los servicios en la subred de copia de seguridad y no a través de la subred de cliente, por ejemplo, cuando se utiliza un gateway de NAT.

Tema principal: VCN y subredes

Requisitos para el espacio de direcciones IP

Debe crear una VCN con dos subredes y asegurarse de que haya suficientes direcciones para el tamaño del cluster de VM.

Nota

Las direcciones IP no se deben solapar, especialmente cuando las instancias de Exadata Cloud Infrastructure (y, por lo tanto, las VCN) están en más de una región.

Si está configurando clusters de VM (y, por lo tanto, redes virtuales en la nube) en más de una región, asegúrese de que el espacio de direcciones IP de las redes virtuales en la nube no se superponga. Esto es importante si desea configurar la recuperación ante desastres con Oracle Data Guard.

Para la subred de cliente, cada nodo requiere cuatro direcciones IP y, además, se reservan tres direcciones para los nombres de acceso de cliente únicos (SCAN). Para la subred de copia de seguridad, cada nodo requiere tres direcciones. El servicio Redes reserva tres direcciones IP en cada subred.

Utilice la siguiente fórmula para calcular el número mínimo de direcciones IP en las que la variable n es el número de máquinas virtuales del cluster de VM:

El número mínimo de direcciones de cliente = 4*n+6

Número mínimo de direcciones de copia de seguridad = 3*n+3

Nota

La asignación de un espacio más grande para la subred que el mínimo necesario (por ejemplo, /25 en lugar de /28) puede reducir el impacto relativo de esas direcciones reservadas en el espacio disponible de la subred. Para planificar el crecimiento futuro, agregue las direcciones que espera que necesiten a medida que escala verticalmente el cluster de VM, no solo el número de máquinas virtuales que planea aprovisionar para necesidades inmediatas.

Tema principal: VCN y subredes

Configuración de una ruta estática para acceder al almacén de objetos

Por defecto, todo el tráfico de una instancia de Oracle Exadata Database Service en la infraestructura de Exascale se envía a través de la red de datos. Para enrutar el tráfico de copia de seguridad a la interfaz de copia de seguridad (BONDETH1), se debe configurar una ruta estática en cada uno de los nodos de cálculo del cluster.

Para obtener instrucciones, consulte Acceso del nodo a Object Storage: ruta estática.

Tema principal: VCN y subredes

Configuración de DNS para una instancia de Oracle Exadata Database Service en la infraestructura de Exascale

El DNS permite utilizar nombres de host en lugar de direcciones IP para comunicarse con una instancia de Exadata Cloud Infrastructure.

Puede utilizar el Solucionador de Internet y VCN (funcionalidad de DNS integrada en la VCN), como se describe en DNS en su red virtual en la nube. Oracle recomienda utilizar un solucionador de VCN para la resolución de nombres de DNS para la subred de cliente. Este resuelve automáticamente los puntos finales de Swift necesarios para realizar copias de seguridad de bases de datos, aplicar parches y actualizar las herramientas en la nube en una instancia de Exadata.

Tema principal: VCN y subredes

DNS: nombres abreviados para la VCN, las subredes y Oracle Exadata Database Service en la instancia de infraestructura de Exascale

Para que los nodos se comuniquen, la VCN debe utilizar el solucionador de internet y VCN. El solucionador de Internet y VCN permite la asignación de nombre de host a los nodos y la resolución de DNS de esos nombres de host por parte de los recursos de la VCN.

El solucionador de Internet y VCN permite la resolución de asignación en rueda de los SCAN de la base de datos. También permite la resolución de los puntos finales de servicio importantes necesarios para realizar copias de seguridad de bases de datos, aplicar parches y actualizar las herramientas en la nube en una instancia de Oracle Exadata Database Service on Exascale Infrastructure. El solucionador de internet y VCN es la opción por defecto de la VCN para el DNS de la VCN. Para obtener más información, consulte DNS en su red virtual en la nube y también Opciones de DHCP.

Al crear la VCN, las subredes y Exadata, se deben definir cuidadosamente los siguientes identificadores, que están relacionados con el DNS de la VCN:

Etiqueta de dominio de la VCN
Etiqueta de dominio de la subred
Prefijo de nombre de host para Oracle Exadata Database Service en el cluster de VM en la nube o el recurso del sistema de base de datos de la instancia de la infraestructura de Exascale

Estos valores conforman el nombre de dominio completo (FQDN) del nodo:

<hostname_prefix>-######.<subnet_domain_label>.<vcn_domain_label>.oraclevcn.com

Por ejemplo:

exacs-abcde1.clientpvtad1.acmevcniad.oraclevcn.com

En este ejemplo, se asigna exacs como prefijo del nombre de host al crear el cluster de VM en la nube o el sistema de base de datos. El servicio de base de datos agrega automáticamente un guion y una cadena de cinco letras con el número de nodo al final. Por ejemplo:

Nodo 1: exacs-abcde1.clientpvtad1.acmevcniad.oraclevcn.com
Nodo 2: exacs-abcde2.clientpvtad1.acmevcniad.oraclevcn.com
Nodo 3: exacs-abcde3.clientpvtad1.acmevcniad.oraclevcn.com
Etc.

Requisitos para el prefijo del nombre de host:

Máximo recomendado: 12 caracteres. Para obtener más información, consulte el ejemplo en la siguiente sección, "Requisitos para las etiquetas de la VCN y el dominio de subred".
No puede ser la cadena localhost

Requisitos para las etiquetas de la VCN y el dominio de subred:

Máximo recomendado: 14 caracteres cada una. El requisito real subyacente es de un total de 28 caracteres en ambas etiquetas de dominio (sin incluir el punto entre las etiquetas). Por ejemplo, las dos siguientes son aceptables: subnetad1.verylongvcnphx o verylongsubnetad1.vcnphx. Para que sea más sencillo, la recomendación es de 14 caracteres cada una.
Sin guiones ni guiones bajos.
Recomendado: incluya el nombre de región en la etiqueta de dominio de la VCN y el nombre del dominio de disponibilidad en la etiqueta de dominio de la subred.
En general, el nombre de dominio completo tiene un límite total máximo de 63 caracteres. Esta es una regla general segura:

<12_chars_max>-######.<14_chars_max>.<14_chars_max>.oraclevcn.com

Los máximos anteriores no se aplican cuando crea la VCN y las subredes. Sin embargo, si las etiquetas exceden el máximo, fallará el despliegue de Exadata.

DNS: entre la red local y la VCN
Oracle recomienda utilizar un solucionador de DNS privado para activar el uso de nombres de host cuando los recursos de VCN y los hosts locales se comuniquen entre sí.

Tema principal: VCN y subredes

DNS: entre la red local y la VCN

Oracle recomienda utilizar un solucionador de DNS privado para activar el uso de nombres de host cuando los hosts locales y los recursos de VCN se comuniquen entre sí.

Consulte Solucionadores de DNS privados para obtener información sobre la creación y el uso de solucionadores privados. Para ver una arquitectura de referencia, consulte Uso de DNS privado en la VCN en Oracle Architecture Center.

Tema principal: DNS: nombres cortos para la VCN, las subredes y la instancia de Oracle Exadata Database Service en infraestructura de Exascale

Configuración de DNS privado

Revise los requisitos necesarios para utilizar el DNS privado.

Se deben crear la vista privada y la zona privada antes de iniciar el aprovisionamiento del sistema de base de datos. Para obtener más información, consulte Solucionadores de DNS privados.
El reenvío a otro servidor DNS se debe configurar de antemano en la consola de DNS. Para ello, vaya al solucionador de la VCN, cree el punto final y, a continuación, las reglas. Para obtener más información, consulte DNS en su red virtual en la nube.
El nombre de la zona privada no puede tener más de 4 etiquetas. Por ejemplo, se permite a.b.c.d mientras que a.b.c.d.e no.
También es necesario agregar la vista privada al solucionador de la VCN. Para obtener más información, consulte Adición de una vista privada a un solucionador.
Al aprovisionar un cluster de VM de Exadata mediante la función de DNS privado, Exadata debe crear zonas de DNS inverso en el compartimento del cluster de VM de Exadata. Si el compartimento ha definido etiquetas o valores por defecto de etiquetas, se necesitan políticas adicionales relacionadas con la gestión de etiquetas. Para obtener información, consulte:
- Permisos necesarios para trabajar con etiquetas definidas
- Permisos necesarios para trabajar con valores por defecto de etiquetas

Tema principal: VCN y subredes

Acceso del nodo a Object Storage: ruta estática

Para poder realizar copias de seguridad de bases de datos y aplicar parches y actualizar herramientas en la nube en una instancia de Oracle Exadata Database Service on Exascale Infrastructure, Oracle recomienda configurar Autonomous Recovery Service. Independientemente de cómo configure la VCN con ese acceso (por ejemplo, con un gateway de servicio), si utiliza Object Storage, también puede que tenga que configurar una ruta estática a Object Storage en cada Uno de los nodos informáticos del cluster. Esto solo es necesario si no utiliza copias de seguridad automáticas. Si utiliza copias de seguridad personalizadas mediante las API de copia de seguridad, debe enrutar el tráfico destinado a Object Storage a través de la interfaz de copia de seguridad (BONDETH1). Esto no es necesario si utiliza las copias de seguridad automáticas creadas con la consola, las API o las CLI.

Nota

A partir del 06 de agosto de 2025, para los arrendamientos creados en las regiones FRA, PHX o NRT, Autonomous Recovery Service será el único destino de copia de seguridad cuando active la copia de seguridad automática en las bases de datos.

Atención:

Debe configurar una ruta estática para el acceso a Object Storage en cada nodo de cálculo de una instancia de Oracle Exadata Database Service en la infraestructura de Exascale si no crea copias de seguridad automáticas con la consola, las API o las CLI. De lo contrario, es posible que fallen los intentos de realizar copias de seguridad de bases de datos y aplicar parches o actualizar herramientas en el sistema.

Nota

Si activa la primera copia de seguridad automática para una base de datos, la configuración de la ruta estática se realizará automáticamente en el servicio.

Si desea aplicar parches al servicio antes de crear una base de datos, la ruta estática manual es necesaria para poder aplicar parches al directorio raíz de base de datos o a GI.

La ruta estática también puede ser necesaria para acceder a otros servicios (IAM, KMS) si no se puede acceder a ellos a través de la subred de cliente y solo la subred de copia de seguridad utiliza la configuración para acceder a todos los servicios de una región.

Tema principal: Configuración de red para Oracle Exadata Database Service en instancias de infraestructura de Exascale

Asignaciones de IP de Object Storage

Tema principal: Acceso del nodo a Object Storage: ruta estática

Configurar una ruta estática para el acceso a Object Storage

Utilice SSH para acceder a un nodo de cálculo en la instancia de Oracle Exadata Database Service en la infraestructura de Exascale.
```
ssh -i <private_key_path> opc@<node_ip_address>
```
Conéctese como opc y, a continuación, utilice sudo para el usuario root. Utilice sudo su - con un guion para llamar al perfil del usuario root.
```
login as: opc
			
[opc@dbsys ~]$ sudo su - 
```

Identifique el gateway configurado para la interfaz BONDETH1.

[root@dbsys ~]# grep GATEWAY /etc/sysconfig/network-scripts/ifcfg-bondeth1 |awk -F"=" '{print $2}'


10.0.4.1

Agregue la siguiente regla estática para BONDETH1 al archivo /etc/sysconfig/network-scripts/route-bondeth1:

10.0.X.0/XX dev bondeth1 table 211
default via <gateway> dev bondeth1 table 211
134.70.0.0/17 via <gateway_from_previous_step> dev bondeth1

Reinicie la interfaz.
```
[root@dbsys ~]# ifdown bondeth1; ifup bondeth1;
```
Los cambios en el archivo del paso anterior se aplican inmediatamente después de ejecutarse los comandos ifdown e ifup.
Repita los pasos anteriores en cada nodo de cálculo de la instancia de Oracle Exadata Database Service en la infraestructura de Exascale.

Tema principal: Acceso del nodo a Object Storage: ruta estática

Gateway de servicio para la VCN

Su VCN necesita acceder tanto a Object Storage para las copias de seguridad como a los repositorios de Oracle YUM para las actualizaciones del sistema operativo.

Opción 1: acceso del gateway de servicio a los servicios de OCI
Configure la subred de copia de seguridad para utilizar el gateway de servicio para acceder únicamente a Object Storage.
Opción 2: acceso del Gateway de servicio a Object Storage y a los repositorios YUM
Configure tanto la subredes del cliente como de copia de seguridad para utilizar el Gateway de servicio para acceder a Oracle Services Network, que incluye tanto el almacenamiento de objetos como los repositorios Oracle YUM.

Tema principal: Configuración de red para Oracle Exadata Database Service en instancias de infraestructura de Exascale

Opción 1: acceso de gateway de servicio a los servicios de OCI

Temas relacionados

Tema principal: Gateway de servicio para la VCN

Opción 2: acceso del gateway de servicio a Object Storage y al repositorio de YUM

Puede configurar la subred del cliente y la subredes de copia de Seguridad para utilizar el gateway de servicio a fin de acceder a Oracle Services Network, que incluye tanto el almacenamiento de objetos como los Repositorios de Oracle YUM.

Nota

Consulte estas Incidencias conocidas para obtener información sobre el acceso a los servicios de Oracle YUM a través del gateway de servicio.

Como recordatorio, a continuación se incluye el diagrama para la opción 2, una configuración de red con subredes privadas:

En esta imagen se muestra la configuración de red con subredes de cliente privadas, como se describió anteriormente.

En general, debe:

Realice las tareas para configurar un gateway de servicio en una VCN y active específicamente la etiqueta CIDR del servicio denominada Todos los servicios de <region> en Oracle Services Network.
En la tarea para actualizar el enrutamiento de cada subred, agregue una regla a la tabla de rutas personalizadas de cada subred. Para el servicio de destino, utilice Todos los servicios de <region> en Oracle Services Network y el destino = el gateway de servicio.
En la tarea para actualizar las reglas de seguridad de la subred, realice la tarea en el grupo de seguridad de red (NSG) de la red de copia de seguridad o en la lista de seguridad personalizada. Configure una regla de seguridad con el servicio de destino ajustado en OCI <region> Object Storage. Consulte Reglas de seguridad. Tenga en cuenta que la subred de cliente ya tiene una regla de salida amplia que abarca el acceso a los repositorios de YUM.

Estos son algunos detalles adicionales sobre el uso del gateway de servicio para la opción 2:

La subred de cliente y la subred de copia de seguridad utilizan el gateway de servicio, pero para acceder a diferentes servicios. No puede activar ni la etiqueta de CIDR de servicio OCI <region> Object Storage ni Todos los servicios de <region> en Oracle Services Network para el gateway de servicio. Para cubrir las necesidades de ambas subredes, debe activar Todos los servicios de <region> en Oracle Services Network para el gateway de servicio. La VCN solo puede tener un único gateway de servicio.
Cualquier regla de ruta que tenga el destino en un gateway de servicio determinado debe utilizar una etiqueta CIDR de servicio activada y no un bloque de CIDR como destino de la regla. Esto significa que, para la opción 2, las tablas de rutas de ambas subredes deben utilizar Todos los servicios de <region> en Oracle Services Network para sus reglas de gateway de servicio.
A diferencia de las reglas de ruta, las reglas de seguridad pueden utilizar cualquier etiqueta CIDR de servicio (tanto si la VCN tiene un gateway de servicio como si no) o un bloque de CIDR como CIDR de origen o de destino para la regla. Por lo tanto, si bien la subred de copia de seguridad tiene una regla de ruta que utiliza Todos los servicios de <region> en Oracle Services Network, la subred puede tener una regla de seguridad que utilice OCI <region> Object Storage. Consulte Reglas de seguridad para la instancia de Exadata Cloud Service.

Temas relacionados

Tema principal: Gateway de servicio para la VCN

Reglas de seguridad para la infraestructura de Oracle Exadata Database Service en Exascale

En esta sección se muestran las reglas de seguridad que se deben utilizar con Oracle Exadata Database Service en la infraestructura de Exascale.

Las reglas de seguridad controlan los tipos de tráfico permitido para la red del cliente y la red de copia de seguridad de las máquinas virtuales. Las reglas se dividen en tres secciones.

Hay diferentes formas de implantar estas reglas. Para obtener más información, consulte Formas de implantar las reglas de seguridad.

Nota

Para los sistemas X8M y X9M, Oracle recomienda que todos los puertos de la subred de cliente estén abiertos para el tráfico de entrada y salida. Se trata de un requisito para agregar servidores de base de datos adicionales al sistema.

Reglas necesarias para la red del cliente y la red de copia de seguridad

Existen varias reglas generales que permiten la conectividad esencial de los hosts de la VCN.

Si utiliza listas de seguridad para implantar sus reglas de seguridad, tenga en cuenta que las reglas siguientes están incluidas por defecto en la lista de seguridad por defecto. Actualice o reemplace la lista para satisfacer sus necesidades de seguridad específicas. Las dos reglas de ICMP (reglas generales de entrada 2 y 3) son necesarias para el funcionamiento correcto del tráfico de red en el entorno de Oracle Cloud Infrastructure. Ajuste la regla general de entrada 1 (la regla SSH) y la regla general de salida 1 para permitir el tráfico solo hacia y desde los hosts que requieren comunicarse con los recursos de su VCN.

Reglas necesarias específicamente para la red del cliente

Las siguientes reglas de seguridad son importantes para la red de cliente.

Nota

Las reglas de entrada de cliente 1 y 2 solo cubren las conexiones iniciadas desde la subred de cliente. Si tiene un cliente que reside fuera de la VCN, Oracle recomienda configurar dos reglas similares adicionales que, por el contrario, tengan el CIDR de origen configurado en la dirección IP pública del cliente.
Las reglas de entrada de cliente 3 y 4 y las reglas de salida de cliente 1 y 2 permiten el tráfico TCP e ICMP dentro de la red de cliente y permiten que los nodos se comuniquen entre sí. Si la conectividad TCP falla en los nodos, el recurso de sistema de base de datos o de cluster de VM de Exadata no se podrá aprovisionar.

Regla de entrada del cliente 3: permite aplicar parches al tráfico desde la subred del cliente

Sin estado: No (todas las reglas deben tener un estado)
Tipo de origen: CIDR
CIDR de origen: CIDR de la subred de cliente
Protocolo IP: TCP
Rango de puertos de origen: Todo
Rango de puertos de destino: 7085
Descripción: opcionalmente, agregue una descripción significativa de la regla. Por ejemplo: "Permitir acceso al punto final privado de actualización de conjunto de Exadata en la subred".

Políticas de IAM necesarias para la aplicación de parches de Oracle Database y Oracle Grid Infrastructure

Otorgue políticas de Identity and Management (IAM) para acceder a subredes, tarjetas de interfaz de red virtual (vNICs) y direcciones IP privadas (ips privados) a los usuarios o grupos que gestionan la base de datos y Oracle Grid Infrastructure. Por ejemplo, supongamos que el grupo admin-group gestiona el compartimento ABC. En ese caso, debe configurar las siguientes políticas:

Permitir que el grupo admin-group utilice subredes en el compartimento ABC
Permitir que el grupo admin-group utilice vNICs en el compartimento ABC
Permitir que el grupo admin-group utilice private-ips en el compartimento ABC

Regla necesaria específicamente para la red de copia de seguridad

La siguiente regla de seguridad es importante para la red de copia de seguridad porque permite que el sistema de base de datos se comunique con Object Storage a través del gateway de servicio (y, opcionalmente, con los repositorios de Oracle YUM si la red del cliente no tiene acceso a ellos). Es redundante con la regla de salida general de este tema (y de la lista de seguridad por defecto). Es opcional, pero se recomienda si se cambia la regla de salida general (o la lista de seguridad por defecto) involuntariamente.

Reglas necesarias para la red del cliente y la red de copia de seguridad
Este tema tiene varias reglas generales que permiten la conectividad esencial para los hosts de la VCN.
Reglas necesarias específicamente para la red del cliente
Las siguientes reglas de seguridad son importantes para la red de cliente.
Regla necesaria específicamente para la red de copia de seguridad
La siguiente regla de seguridad es importante para la red de copia de seguridad porque permite que el sistema de base de datos se comunique con Object Storage a través del gateway de servicio (y, opcionalmente, con los repositorios de Oracle YUM si la red de cliente no tiene acceso a ellos).
Reglas necesarias para el servicio Events
La instancia informática debe tener una dirección IP pública o un gateway de servicio para poder enviar métricas de instancia informática al servicio Events.
Reglas necesarias para el servicio Monitoring
La instancia informática debe tener una dirección IP pública o un gateway de servicio para poder enviar métricas de instancia informática al servicio Monitoring.

Tema principal: Configuración de red para Oracle Exadata Database Service en instancias de infraestructura de Exascale

Reglas necesarias para la red del cliente y la red de copia de seguridad

Este tema contiene varias reglas generales que permiten la conectividad esencial de los hosts de la VCN.

Si utiliza listas de seguridad para implantar sus reglas de seguridad, tenga en cuenta que las reglas siguientes están incluidas por defecto en la lista de seguridad por defecto. Actualice o reemplace la lista para satisfacer sus necesidades de seguridad específicas. Las dos reglas de ICMP (reglas generales de entrada 2 y 3) son necesarias para el funcionamiento correcto del tráfico de red en el entorno de Oracle Cloud Infrastructure. Ajuste la regla general de entrada 1 (la regla SSH) y la regla general de salida 1 para permitir el tráfico solo hacia y desde los hosts que requieren comunicarse con los recursos de su VCN.

Regla de entrada general 1: permite el tráfico SSH desde cualquier lugar.
Regla de entrada general 2: permite mensajes de fragmentación de detección de la MTU de ruta
Regla de entrada general 3: permite mensajes de error de conectividad dentro de la VCN
Esta regla permite a los hosts de la VCN recibir mensajes de error de conectividad entre sí.
Regla de salida general 1: permite todo el tráfico de salida

Temas relacionados

lista de seguridad por defecto

Tema principal: Reglas de seguridad para Oracle Exadata Database Service en infraestructura de Exascale

Regla de entrada general 1: permite el tráfico SSH desde cualquier lugar

Tema principal: Reglas necesarias para la red del cliente y la red de copia de seguridad

Regla de entrada general 2: permite mensajes de fragmentación de detección de la MTU de ruta

Tema principal: Reglas necesarias para la red del cliente y la red de copia de seguridad

Regla de entrada general 3: permite mensajes de error de conectividad dentro de la VCN

Esta regla permite a los hosts de la VCN recibir mensajes de error de conectividad entre sí.

Sin estado: No (todas las reglas deben tener un estado)
Tipo de origen: CIDR
Source CIDR: IPv4: your VCN's IPv4 CIDR, IPv6: your VCN's IPv6 CIDR
IP Protocol: ICMP
Tipo: todos
Código: Todos

Tema principal: Reglas necesarias para la red del cliente y la red de copia de seguridad

Regla de salida general 1: permite todo el tráfico de salida

Tema principal: Reglas necesarias para la red del cliente y la red de copia de seguridad

Reglas necesarias específicamente para la red del cliente

Las siguientes reglas de seguridad son importantes para la red de cliente.

Nota

Para sistemas X8M, Oracle recomienda que todos los puertos de la subred del cliente estén abiertos para el tráfico de entrada y salida. Se trata de un requisito para agregar servidores de base de datos adicionales al sistema.
Las reglas de entrada de cliente 1 y 2 solo cubren las conexiones iniciadas desde la subred de cliente. Si tiene un cliente que reside fuera de la VCN, Oracle recomienda configurar dos reglas similares adicionales que, por el contrario, tengan el CIDR de origen configurado en la dirección IP pública del cliente.
Las reglas de entrada de cliente 3 y 4 y las reglas de salida de cliente 1 y 2 permiten el tráfico TCP e ICMP dentro de la red de cliente y permiten que los nodos se comuniquen entre sí. Si la conectividad TCP falla en los nodos, el recurso de sistema de base de datos o de cluster de VM de Exadata no se podrá aprovisionar.

Regla de entrada del cliente 1: permite el tráfico de ONS y FAN desde la subred del cliente
Se recomienda la primera regla, que permite a los servicios de notificación de Oracle (ONS) informar sobre los eventos de notificación rápida de aplicación (FAN).
Regla de entrada del cliente 2: permite el tráfico SQL*NET desde la subred del cliente
Esta regla es para el tráfico SQL*NET y es necesaria en los siguientes casos:
Regla de salida del cliente 1: permite todo el tráfico TCP dentro de la subred del cliente
Esta regla es para el tráfico SQL*NET como se indica.
Regla de salida del cliente 2: permite todo el tráfico de salida (permite las conexiones a los repositorios de Oracle YUM)
La regla de salida del cliente 3 es importante porque permite las conexiones a los repositorios de Oracle YUM.

Tema principal: Reglas de seguridad para Oracle Exadata Database Service en infraestructura de Exascale

Regla de entrada del cliente 1: permite el tráfico de ONS y FAN desde la subred del cliente

Se recomienda la primera regla, que permite a los servicios de notificación de Oracle (ONS) informar sobre los eventos de notificación rápida de aplicación (FAN).

Sin estado: No (todas las reglas deben tener un estado)
Tipo de origen: CIDR
Source CIDR: IPv4: client subnet's IPv4 CIDR, IPv6: client subnet's IPv6 CIDR
Protocolo IP: TCP
Rango de puertos de origen: Todo
Rango de puertos de destino: 6200
Descripción: descripción opcional de la regla.

Tema principal: Reglas necesarias específicamente para la red del cliente

Regla de entrada del cliente 2: permite el tráfico SQL*NET desde la subred del cliente

Esta regla es para el tráfico SQL*NET y es necesaria en los siguientes casos:

Si necesita activar las conexiones de cliente a la base de datos
Si planea utilizar Oracle Data Guard.

Sin estado: No (todas las reglas deben tener un estado)
Tipo de origen: CIDR
Source CIDR: IPv4: client subnet's IPv4 CIDR, IPv6: client subnet's IPv6 CIDR
Protocolo IP: TCP
Rango de puertos de origen: Todo
Rango de puertos de destino: 1521
Descripción: descripción opcional de la regla.

Tema principal: Reglas necesarias específicamente para la red del cliente

Regla de salida del cliente 1: permite todo el tráfico TCP dentro de la subred del cliente

Esta regla es para el tráfico SQL*NET, como se ha indicado.

Sin estado: No (todas las reglas deben tener un estado)
Tipo de destino: CIDR
CIDR de destino: 0.0.0.0/0 (IPv4), ::/0 (IPv6)
Protocolo IP: TCP
Rango de puertos de origen: Todo
Rango de puertos de destino: 22
Descripción: descripción opcional de la regla.

Tema principal: Reglas necesarias específicamente para la red del cliente

Regla de salida de cliente 2: permite todo el tráfico de salida (permite las conexiones a los repositorios de Oracle YUM)

La regla de salida del cliente 3 es importante porque permite las conexiones a los repositorios de Oracle YUM.

Es redundante con la regla de salida general 1: Permitir todo el tráfico de salida (y en la lista de seguridad por defecto). Es opcional, pero se recomienda si se cambia la regla de salida general (o la lista de seguridad por defecto) involuntariamente.

Sin estado: No (todas las reglas deben tener un estado)
Tipo de destino: CIDR
CIDR de destino: 0.0.0.0/0 (IPv4), ::/0 (IPv6)
Protocolo IP: Todos
Descripción: descripción opcional de la regla.

Temas relacionados

lista de seguridad por defecto

Tema principal: Reglas necesarias específicamente para la red del cliente

Regla necesaria específicamente para la red de copia de seguridad

Es redundante con la Regla de salida general 1: permite todo el tráfico de salida en (y en ). Es opcional, pero se recomienda si se cambia la regla de salida general (o la lista de seguridad por defecto) involuntariamente.

Temas relacionados

Tema principal: Reglas de seguridad para Oracle Exadata Database Service en infraestructura de Exascale

Reglas necesarias para el servicio Events

La instancia informática debe tener una dirección IP pública o un gateway de servicio para poder enviar métricas de instancia informática al servicio Events.

Las reglas de salida por defecto son suficientes para permitir que la instancia informática envíe métricas de instancia informática al servicio Events.

Si la instancia no tiene una dirección IP pública, configure un gateway de servicio en la red virtual en la nube (VCN). El gateway de servicio permite que la instancia envíe métricas de instancia informática al servicio Events sin que el tráfico pase por internet. A continuación se incluyen unas notas especiales para configurar el gateway de servicio a fin de acceder al servicio Events:

Al crear el gateway de servicio, active la etiqueta de servicio denominada Todos los servicios de <region> en Oracle Services Network. Incluye el servicio Events.
Al configurar el enrutamiento para la subred que contiene la instancia, configure una regla de ruta con el Tipo de destino definido en Gateway de servicio y el Servicio de destino definido en Todos los servicios de <region> en Oracle Services Network.

Para obtener instrucciones detalladas, consulte Acceso a servicios de Oracle: gateway de servicio.

Tema principal: Reglas de seguridad para Oracle Exadata Database Service en infraestructura de Exascale

Reglas necesarias para el servicio Monitoring

La instancia informática debe tener una dirección IP pública o un gateway de servicio para poder enviar métricas de instancia informática al servicio Monitoring.

Las reglas de salida por defecto son suficientes para permitir que la instancia informática envíe métricas de instancia informática al servicio Monitoring.

Si la instancia no tiene una dirección IP pública, configure un gateway de servicio en la red virtual en la nube (VCN). El gateway de servicio permite que la instancia envíe métricas de instancia informática al servicio Monitoring sin que el tráfico pase por internet. A continuación se muestran notas especiales para configurar el gateway de servicio para acceder al servicio Monitoring:

Al crear el gateway de servicio, active la etiqueta de servicio denominada Todos los servicios de <region> en Oracle Services Network. Incluye el servicio Monitoring.
Al configurar el enrutamiento para la subred que contiene la instancia, configure una regla de ruta con el Tipo de destino definido en Gateway de servicio y el Servicio de destino definido en Todos los servicios de <region> en Oracle Services Network.

Para obtener instrucciones detalladas, consulte Acceso a servicios de Oracle: gateway de servicio.

Tema principal: Reglas de seguridad para Oracle Exadata Database Service en infraestructura de Exascale

Formas de implantar las reglas de seguridad

Descubra cómo implantar reglas de seguridad en la VCN mediante el servicio de red.

El servicio Networking ofrece dos formas de implantar reglas de seguridad en la VCN:

Para obtener una comparación de los dos métodos, consulte Comparación de listas de seguridad y grupos de seguridad de red.

Si utiliza grupos de seguridad de red
Si utiliza listas de seguridad
Si decide utilizar listas de seguridad, este es el proceso recomendado:

Tema principal: Configuración de red para Oracle Exadata Database Service en instancias de infraestructura de Exascale

Si utiliza grupos de seguridad de red

Tema principal: Formas de implantar las reglas de seguridad

Si utiliza listas de seguridad

Si decide utilizar listas de seguridad, este es el proceso recomendado:

Configure la subred del cliente para que utilice las reglas de seguridad necesarias:
1. Cree una lista de seguridad personalizada para la subred del cliente y agregue las reglas que se muestran en Reglas necesarias específicamente para la red del cliente.
2. Asocie las siguientes dos listas de seguridad a la subred del cliente:
  - Lista de seguridad por defecto de la VCN con todas sus reglas por defecto. Se incluye automáticamente con la VCN. Contiene por defecto las reglas que se indican en Reglas necesarias para la red del cliente y la red de copia de seguridad.
  - La nueva lista de seguridad personalizada que ha creado para la subred del cliente.
Configure la subred de copia de seguridad para que utilice las reglas de seguridad necesarias:
1. Cree una lista de seguridad personalizada para la subred de copia de seguridad y agregue las reglas que se enumeran en Regla necesaria específicamente para la red de copia de seguridad.
2. Asocie las siguientes dos listas de seguridad a la subred de copia de seguridad:
  - Lista de seguridad por defecto de la VCN con todas sus reglas por defecto. Se incluye automáticamente con la VCN. Contiene por defecto las reglas que se indican en Reglas necesarias para la red del cliente y la red de copia de seguridad.
  - La nueva lista de seguridad personalizada que ha creado para la subred de copia de seguridad.

Más adelante, cuando el administrador de la base de datos cree la instancia de Exadata Cloud Service, deberá seleccionar varios componentes de red. Cuando seleccione la subred del cliente y la subred de copia de seguridad que usted ya ha creado y configurado, las reglas de seguridad se aplicarán automáticamente para los nodos creados en esas subredes.

ADVERTENCIA:

no elimine la regla de salida por defecto de la lista de seguridad por defecto. Si lo hace, asegúrese de incluir en su lugar la siguiente regla de salida de sustitución en la lista de seguridad de la subred del cliente:

Sin estado: No (todas las reglas deben tener un estado)
Tipo de destino: CIDR
CIDR de destino: 0.0.0.0/0
Protocolo IP: Todos

Tema principal: Formas de implantar las reglas de seguridad

Requisitos de red para Oracle Database Autonomous Recovery Service

Oracle Database Autonomous Recovery Service requiere una subred del servicio de recuperación registrada dedicada a las operaciones de copia de seguridad y recuperación en la red virtual en la nube (VCN) de la base de datos.

Para utilizar Recovery Service para copias de seguridad, siga los pasos descritos en Configuración de Recovery Service.

Creación de un gateway de servicio en Object Storage
En la consola de OCI, cree un gateway de servicio en Object Storage. El gateway de servicios es necesario para las actualizaciones de automatización y los metadatos de configuración.

Temas relacionados

Configuración del Servicio de Recuperación

Tema principal: Configuración de red para Oracle Exadata Database Service en instancias de infraestructura de Exascale

Crear un gateway de servicio para el almacenamiento de objetos

En la consola de OCI, cree un gateway de servicio en Object Storage. El gateway de servicios es necesario para las actualizaciones de automatización y los metadatos de configuración.

Abra el menú de navegación. Haga clic en Red y, a continuación, en Red virtual en la nube.
Seleccione la VCN en la que se encuentran los servicios de base de datos de los que se va a realizar la copia de seguridad.
En la página Detalles de red virtual en la nube resultante, en Recursos, haga clic en Gateways de servicio.
Haga clic en Crear gateway de servicio y proporcione los siguientes detalles.
1. Nombre: nombre descriptivo para el gateway de servicio. No tiene que ser único. Evite introducir información confidencial.
2. Compartimento: compartimento en el que desea crear el gateway de servicio, si es diferente del compartimento en el que está trabajando actualmente.
3. Servicios: seleccione la etiqueta CIDR del servicio, All <region> Services in Oracle Services Network, en la lista desplegable.
4. Etiquetas: (opción avanzada) si tiene permisos para crear un recurso, también tiene permisos para aplicar etiquetas de formato a dicho recurso. Para aplicar una etiqueta definida, debe tener permisos para utilizar el espacio de nombres de la etiqueta. Para obtener más información sobre el etiquetado, consulte Etiquetas de recursos. Si no está seguro de si deben aplicar etiquetas, omita esta opción (puede aplicar las etiquetas posteriormente) o pregunte al administrador.
Haga clic en Crear gateway de servicio.

Espere a que se cree la puerta de enlace antes de continuar con el paso siguiente.
En Recursos, haga clic en Tablas de rutas.

Asociación de tabla de rutas: puede asociar una tabla de rutas de VCN específica a este gateway. Si asocia una tabla de rutas, posteriormente el gateway debe tener siempre una tabla de rutas asociada. Puede modificar las reglas de la tabla de rutas actual o sustituirlas por otra tabla de rutas.
Haga clic en el nombre de la tabla de rutas que está utilizando la subred para Recovery Service.
En la página Detalles de tabla de rutas resultante, haga clic en Agregar reglas de ruta en la sección Reglas de ruta.

Al configurar un gateway de servicio para una etiqueta CIDR de servicio determinada, también debe crear una regla de ruta que especifique dicha etiqueta como el destino y el destino como gateway de servicio. Haga esto para cada subred que necesite acceder al gateway.
En el cuadro de diálogo Agregar reglas de ruta resultante, introduzca los siguientes detalles:
1. Tipo de destino: gateway de servicio.
2. Servicio de destino: etiqueta CIDR del servicio que está activada para la puerta de enlace. All <region> Services in Oracle Services Network
3. Gateway de servicio de destino: seleccione el nombre que ha proporcionado en el paso 4.
4. Descripción: descripción opcional de la regla.
Haga clic en Agregar reglas de ruta.

Temas relacionados

Etiquetas de recurso

Tema principal: Requisitos de red para Oracle Database Autonomous Recovery Service

Interoperabilidad entre servicios entre ExaDB-D y ExaDB-XS: Data Guard, copia de seguridad y restauración

Ahora puede crear un grupo de Oracle Data Guard entre servicios de base de datos.

Con esta función, puede establecer la capacidad de copia de seguridad y restauración entre servicios para las siguientes configuraciones:

Base de datos primaria en ExaDB-D con una o más bases de datos en espera en ExaDB-XS o ExaDB-D.
Base de datos primaria en ExaDB-XS con una o más bases de datos en espera en ExaDB-D o ExaDB-XS.

Nota

En el momento de esta versión, Oracle Data Guard entre servicios entre Exadata Database Service on Dedicated Infrastructure y Exadata Database Service on Exascale Infrastructure solo se puede configurar con la versión de Oracle Database 23ai.

Esta capacidad le permite aprovechar el potencial de sus servicios de base de datos en su arrendamiento,

Nota

Para garantizar una disponibilidad máxima, Oracle recomienda ubicar sus clusters de VM peer en una infraestructura de Exadata distinta a la del cluster de VM primario.

Opciones de Configuración de Base de Datos en Espera

Al agregar una base de datos en espera, puede especificar los siguientes detalles:

Detalles de cluster de VM peer: si el destino es ExaDB-D, puede seleccionar la infraestructura de Exadata.
Selección de servicio de destino: seleccione ExaDB-D o ExaDB-XS. Por defecto, se selecciona el servicio que inicia el grupo de Data Guard. Si un servicio no está disponible en la región seleccionada, se desactiva con el mensaje: 'El servicio no está disponible en esta región'.
Tipo de Data Guard: el grupo se puede configurar con Data Guard o Active Data Guard, y cada base de datos en espera puede tener un tipo diferente.
Limitación de grupos de Data Guard: una base de datos primaria está limitada a un grupo de Data Guard.
Creación de base de datos en espera: solo se puede agregar una base de datos en espera a la vez. Sin embargo, las bases de datos en espera se pueden crear en cualquiera de las siguientes categorías sin restricciones en su número:
- Dentro del mismo servicio
- En todos los servicios
- Dentro del mismo dominio de disponibilidad (AD)
- En los distintos dominios de disponibilidad de la misma región
- En distintas regiones

Consideraciones clave para bases de datos principales y en espera entre servicios

Tanto la base de datos primaria como la base de datos en espera deben utilizar la misma solución de gestión de claves.
Data Guard se puede configurar en el modo de protección Rendimiento máximo o Disponibilidad máxima con el tipo de transporte Sync o Async, según las siguientes reglas:
- Para la primera base de datos en espera:
  - El valor predeterminado es el modo de rendimiento máximo con transporte asíncrono.
  - El modo de protección y el tipo de transporte no se pueden cambiar.
- Para la segunda y posteriores bases de datos en espera:
  - Hereda el modo de protección del primer modo en espera.
  - El valor predeterminado es Transporte asíncrono.
  - El modo de protección y el tipo de transporte no se pueden cambiar.

Visualización y edición de configuraciones de Data Guard

Vea todas las bases de datos que forman parte del grupo de Data Guard en la tabla de grupos de Data Guard, independientemente de si está en las páginas de la base de datos primaria o en espera.
Edite la configuración de Data Guard para actualizar:
- Tipo de Data Guard: puede ser diferente para cada base de datos en espera. Solo se puede cambiar desde una base de datos en espera.
- Contraseña de administrador de base de datos: se puede editar desde cualquier base de datos.
- Modo de protección: se puede cambiar entre el rendimiento máximo y la disponibilidad máxima desde la base de datos principal o cualquier base de datos en espera.
- Tipo de transporte: se puede cambiar entre Asíncrono y Sincronizar solo desde una base de datos en espera.

Nota

Si el modo de protección está definido en Max Availability, el sistema verifica que al menos una base de datos en espera utilice el transporte Sync. Si No se encuentra, se muestra el siguiente mensaje:

Para lograr una pérdida de datos cero, se necesita al menos una base de datos en espera con el transporte Sync. Se recomienda tener una base de datos en espera con transporte de sincronización en el mismo servicio que la base de datos primaria".

Switchover y Failover de Bases de Datos

Switchover (en cualquier base de datos en espera)
- El switchover se realiza sin aplicar una versión principal o una comprobación de actualización de versión (RU). Sin embargo, aparece una advertencia si la base de datos en espera tiene una configuración asimétrica, como recuentos de nodos, memoria o tipo de servicio diferentes.
Failover (en cualquier base de datos en espera)
- La conmutación por error se realiza sin aplicar una versión principal o una comprobación de actualización de versión (RU). Sin embargo, aparece una advertencia si la base de datos en espera tiene una configuración asimétrica, como recuentos de nodos, memoria o tipo de servicio diferentes.

Opciones de Copia de Seguridad y Restauración de Base de Datos

Nota

A partir del 06 de agosto de 2025, para los arrendamientos creados en las regiones FRA, PHX o NRT, Autonomous Recovery Service será el único destino de copia de seguridad cuando active la copia de seguridad automática en las bases de datos.

Copias de seguridad programadas y automáticas
- Puede programar copias de seguridad automáticas en la base de datos primaria, en la base de datos en espera o en ambas.
- Están soportadas tanto las copias de seguridad de Object Storage como las del servicio de recuperación.
- Si las copias de seguridad se configuran en bases de datos primaria y en espera, deben utilizar el mismo tipo de destino de copia de seguridad.
Restauración In Situ de la Misma Base de Datos en ExaDB-XS
Restaure y recupere una base de datos mediante una copia de seguridad realizada desde la misma base de datos en ExaDB-XS:
- Restaure la base de datos primaria mediante una copia de seguridad realizada en la base de datos primaria.
- Restaure la base de datos en espera mediante una copia de seguridad realizada en la base de datos en espera.
Restauración In Situ de una Base de Datos de Pares en ExaDB-XS
Restaure y recupere una base de datos peer (que no tiene copias de seguridad configuradas) mediante una copia de seguridad de la base de datos de origen con Recovery Service:
- Escenario 1: restaure la base de datos principal mediante la copia de seguridad en espera.
  - Base de datos principal: ExaDB-XS (no se han configurado copias de seguridad)
  - Base de datos en espera: ExaDB-XS (copias de seguridad configuradas en Recovery Service)
- Escenario 2: restaure la base de datos en espera mediante la copia de seguridad principal.
  - Base de datos principal: ExaDB-XS (copias de seguridad configuradas en Recovery Service)
  - Base de datos en espera: ExaDB-XS (no se han configurado copias de seguridad)
Restauración In Situ de una Base de Datos Peer en los Servicios
Restaure y recupere una base de datos en ExaDB-XS o ExaDB-D mediante una copia de seguridad de la base de datos de origen en el servicio opuesto (ExaDB-D o ExaDB-XS) con Recovery Service:
- Escenario 1: restauración de una base de datos peer en ExaDB-XS mediante una copia de seguridad de ExaDB-D
  - Caso de uso 1: restaure la base de datos principal mediante la copia de seguridad en espera.
  - Caso de uso 2: restaure la base de datos en espera mediante la copia de seguridad principal.
- Escenario 2: restauración de una base de datos peer en ExaDB-D mediante una copia de seguridad de ExaDB-XS
  - Caso de uso 1: restaure la base de datos principal mediante la copia de seguridad en espera.
  - Caso de uso 2: restaure la base de datos en espera mediante la copia de seguridad principal.

Restauración Externa (Creación de una Nueva Base de Datos)

En ExaDB-XSPuede crear una nueva base de datos en ExaDB-XS mediante una copia de seguridad desde el mismo servicio.
- Restaurar en:
  - El mismo dominio de disponibilidad (AD)
  - Un dominio de disponibilidad diferente dentro de la misma región
  - Una región diferente
- Soporta Object Storage o Recovery Service como destino de copia de seguridad.
En todos los servicios
- Escenario 1: creación de una nueva base de datos en ExaDB-D mediante una copia de seguridad de ExaDB-XS
  - Origen: ExaDB-XS (base de datos y copias de seguridad)
  - Destino: ExaDB-D (cualquier región o AD)
  - Destino de copia de seguridad: Object Storage o Recovery Service
- Escenario 2: creación de una nueva base de datos en ExaDB-XS mediante una copia de seguridad desde ExaDB-D
  - Origen: ExaDB-D (base de datos y copias de seguridad)
  - Destino: ExaDB-XS (cualquier región o AD)
  - Destino de copia de seguridad: Object Storage o Recovery Service

Tema principal: Preparación para Oracle Exadata Database Service en infraestructura de Exascale

Documentación de Oracle Cloud Infrastructure