Esta opción puede ser útil al realizar un trabajo de desarrollo o de prueba de concepto.

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.

Debe configurar los siguientes elementos:

• 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). Consulte también Opción 1: acceso de gateway de servicio al servicio de OCI para 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). Consulte también Opción 1: acceso de gateway de servicio al servicio de OCI para la subred de copia de seguridad.
• Reglas de seguridad para activar el tráfico deseado hacia y desde los nodos de cálculo de las máquinas virtuales de Exadata. Consulte Reglas de seguridad para Oracle Exadata Database Service on Dedicated Infrastructure.
• 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).

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.

Debe configurar los siguientes elementos:

• Subredes:
  • Subred privada de cliente.
  • 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 servicios para que lo utilicen las subredes del cliente y la copia de seguridad a fin de acceder a los servicios OCI, como Object Storage para copias, YUM para actualizaciones del sistema operativo, IAM (Identity Access Management) y OCI Vault (Integración de KMS). Consulte también Opción 2: acceso del gateway de servicios al servicio OCI para las subredes del cliente y de copia de seguridad.
  • 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 target = DRG.
    • Una regla para la etiqueta CIDR de servicio denominada All <region> Services in Oracle Services Network y target = the service gateway. 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 target = NAT gateway.
  • 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 del servicio denominada All <region> Services in Oracle Services Network y target = the service gateway. 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.

Las direcciones IP no se deben solapar, especialmente cuando los clusters de VM 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 de Exadata Cloud Infrastructure (y, por lo tanto, VCN) en más de una región, asegúrese de que el espacio de dirección IP de las VCN no se superponga. Esto es importante si desea configurar la recuperación ante desastres con Oracle Data Guard.

Para Exadata X8 y versiones inferiores, las dos subredes que cree para los clusters de VM de Exadata Cloud Infrastructure no se deben superponer con 192.168.128.0/20.

Para Exadata X8M, X9M y X11M, las direcciones IP 100.64.0.0/10 están reservadas para la interconexión y no se deben utilizar para las redes virtuales en la nube de cliente o de copia de seguridad, ni para los clientes de base de datos.

En la siguiente tabla se muestran los tamaños mínimos de subred necesarios, según la infraestructura de VM de Exadata para cada tamaño de cluster de VM. 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.

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

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.

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 Exadata Cloud 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 el recurso de cluster de VM en la nube o sistema de base de datos de la instancia de Exadata Cloud Infrastructure

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
• Y así sucesivamente

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.

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.

Requisitos necesarios para utilizar la DNS privada.

• 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

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 necesitan 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
  

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

• 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.

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 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.

• Regla de salida de copia de seguridad: permite el acceso a Object Storage
  

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.

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.

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.