Más información sobre el diseño de red

Los componentes de infraestructura de red de OCI, como las redes virtuales en la nube, las subredes y los gateways, que se crean sin una planificación adecuada mediante los parámetros por defecto pueden generar problemas después del despliegue que pueden ser difíciles de resolver. Un diseño de red bien planificado ayuda a configurar una implementación exitosa y facilita el uso de su equipo y organización.

Realice su diseño de red temprano

Diseñar la red por completo antes del despliegue le permite detectar los problemas con antelación y eliminar las barreras para un despliegue correcto. Si bien es posible cambiar algunos elementos de diseño de red de OCI más adelante, puede requerir un esfuerzo significativo y puede interrumpir el flujo de negocio temporalmente.

Oracle recomienda lo siguiente para el diseño de red de OCI:

1. Planifica el tiempo adecuado y asigna recursos suficientes en tu plan de proyecto para diseñar correctamente tu red de OCI.
2. Incluya como mínimo el diseño, la topología, el tamaño de las redes virtuales en la nube y las subredes, el servicio de nombres de dominio (DNS) y cualquier conectividad de red externa a CSP locales u otros.
3. Considere la posibilidad de trabajar con su equipo de cuentas de Oracle para ver si Oracle puede proporcionar especialistas en redes de OCI para ayudarle.

A continuación, se muestra un ejemplo de un diagrama de diseño de red.

Descripción de la ilustración vcn-network-design-example.png

Sugerencia:

Busque arquitecturas de referencia relevantes para su despliegue específico para utilizarlas como punto de partida. Por ejemplo, Oracle tiene muchas arquitecturas de referencia para despliegues comunes de Oracle OCI, como Oracle E-Business Suite, Siebel y ExaCS en el Oracle Architecture Center.

Considere un diseño de VCN de hub y radios

La mejor práctica y recomendación de Oracle para la mayoría de los despliegues de OCI es utilizar un diseño de varias VCN en una topología de hub y radio utilizando el DRG para la conectividad.

A continuación, se muestran las ventajas de un diseño de hub y radios de varias VCN mediante el DRG:

• Aislar y segmentar diferentes entornos.
• Proporcione servicios comunes en la VCN del hub que todas las VCN radiales puedan compartir, como el servidor de log, el DNS o el uso compartido de archivos.
• Amplíe sus redes fácilmente, ya que el DRG le permite conectar hasta 300 VCN. Una vez que tenga un diseño de VCN con concentrador, será fácil agregar VCN adicionales.
• Coloque dispositivos de seguridad de red, como firewalls, en la VCN de hub para inspeccionar el tráfico destinado a las redes virtuales en la nube o procedente de ellas.

En el siguiente diagrama se muestra un ejemplo del uso de una arquitectura de red de hub y radio:

Descripción de la ilustración hub-and-spoke-topology.png

Oracle recomienda lo siguiente:

• Decida cómo y dónde desea segmentar diferentes entornos de red y considere poner cada uno en su propia VCN. A continuación, se muestran ejemplos comunes de clientes para utilizar redes virtuales en la nube independientes para entornos:
  • Entornos de producción y no producción
  • Clientes internos o externos
• Si tiene un despliegue de OCI muy simple o pequeño, como una prueba de concepto (POC), y no necesita ninguna de las ventajas que se tratan aquí, utilizar una única VCN es un buen enfoque. Incluso con una única VCN, siempre puede colocar un entorno en una VCN diferente en el futuro para aprovechar estas recomendaciones.

Uso de convenciones de nomenclatura de OCI estándar

Al aprovisionar los recursos de red necesarios en OCI, como redes virtuales en la nube, subredes, listas de seguridad y gateways de enrutamiento dinámico (DRG), se le pedirá que introduzca un nombre de recurso. El uso de una convención de nomenclatura estándar para sus recursos de OCI le ayuda a usted y a otros usuarios de OCI a comprender el objetivo y la ubicación de los recursos, y también indica cómo un recurso se diferencia de otros.

Algunos de estos nombres de recursos se pueden cambiar más adelante, pero otros no, como la etiqueta DNS. Otros, como el nombre de la VCN, se deben cambiar mediante la interfaz de línea de comandos (CLI).

Oracle recomienda lo siguiente:

1. Utilice un acrónimo descriptivo en algún lugar del nombre para describir el objetivo de un recurso. Por ejemplo:
   • vcn en algún lugar del nombre de la VCN (nombre de la VCN: vcn-prod-ashburn)
   • drg en algún lugar del nombre de DRG (nombre de DRG: drg-ashburn)
   • sl en algún lugar del nombre de la lista de seguridad (nombre de la lista de seguridad: web-sn-sl)
2. Asegúrese de que su convención de nomenclatura de recursos de red de OCI forma parte de su convención de nomenclatura de recursos de OCI general.
3. Considere el uso de etiquetas para agregar información de metadatos a los recursos.

Diseño de un DNS híbrido con DNS privado de OCI

El comportamiento por defecto de OCI se limita a realizar una resolución de DNS interna en la VCN utilizando oraclevcn.com como dominio por defecto. Esto puede provocar problemas de conectividad más adelante porque no puede resolver los nombres DNS de los recursos de otras redes virtuales en la nube o entornos locales.

El servicio DNS privado de OCI proporciona la capacidad de resolver sin problemas DNS entre OCI e infraestructura local:

• Cree y mantenga registros y dominios DNS personalizados en sus redes virtuales en la nube (como oci.customer.com).
• Integre la resolución de DNS en las redes virtuales en la nube, con DNS locales y otros entornos como CSP o DNS de partners de confianza.

Oracle recomienda lo siguiente:

• Incluya DNS como parte del diseño de red inicial e involucre a los administradores de DNS.
• Considere todos los entornos en los que desee una resolución de nombres DNS perfecta (desde o hacia entornos locales, redes virtuales en la nube de OCI, otros proveedores de servicios de comunicaciones, etc.) y utilice el DNS privado de OCI para activar una solución de DNS híbrido.
• Considere las advertencias antes y determine la dirección en la que desea continuar. Decida si desea utilizar el nombre de dominio oraclevcn.com por defecto o un nombre de dominio personalizado.

En el siguiente diagrama se muestra un ejemplo de arquitectura con nombres de dominio personalizados mediante un solucionador de DNS privado para la resolución de recursos internos locales con nombres de dominio personalizados:

Descripción de la ilustración architecture-deploy-private-dns.png

Sugerencia:

Al utilizar un nombre de dominio de OCI personalizado, la gestión de las zonas y los registros personalizados es manual. El valor por defecto oraclevcn.com es automático.

Decidir los tipos de subred antes del aprovisionamiento

Los CIDR de VCN se deben desglosar en una o más subredes para organizar los recursos. Las subredes pueden ser regionales o específicas del dominio de disponibilidad (AD), y también pueden ser públicas o privadas.

Las decisiones sobre subredes regionales frente a específicas de dominio de disponibilidad y subredes públicas frente a privadas no se pueden cambiar más adelante. Asegúrese de que sean correctos al aprovisionarlos inicialmente, para minimizar las interrupciones y la complejidad en una etapa posterior.

Oracle recomienda lo siguiente:

• Determine si necesita subredes públicas o privadas antes de crearlas. Considere posibles flujos de tráfico y dónde se origina o se destina el tráfico.
• Coloque los recursos que tengan un requisito específico para la conectividad de Internet entrante en subredes públicas y todos los demás recursos en subredes privadas.
• Aprovisione subredes regionales a menos que tenga un requisito específico que requiera el uso de subredes específicas de AD.

Sugerencia:

Para realizar cambios posteriormente, debe terminar las subredes y volver a aprovisionarlas. También debe terminar los recursos desplegados en las subredes y, a continuación, volver a aprovisionar los recursos en las nuevas subredes.

Diseñar y ajustar el tamaño de las subredes

Diseñe y asigne un tamaño a las subredes para que cumplan los requisitos actuales y futuros. El tamaño adecuado de VCN y subredes durante el diseño le ayudará a:

• Prepárese para el crecimiento y la expansión futuros
• Simplifique la asignación de IP mediante el uso de un espacio de direcciones IP contiguo y resumible

Oracle recomienda lo siguiente:

• Antes de crear una VCN, determine el número de bloques CIDR necesarios y el tamaño de cada bloque en función del número de recursos y subredes que planea desplegar en la VCN.
• Asegúrese de permitir cierta cantidad de crecimiento futuro dentro de las subredes y las redes virtuales en la nube.
• Preferiblemente inclínese hacia la creación de un CIDR más grande que demasiado pequeño.
• Puede agregar hasta cinco CIDR a una VCN, sin embargo, si agrega más adelante para adaptarse al crecimiento, es posible que los CIDR no contiguos dependan de la asignación de direcciones IP.
  • Por ejemplo, ha asignado 10.0.0.0/24 a una VCN para iniciar la prueba de una carga de trabajo. Después de realizar las pruebas correctamente, si desea ampliar la carga de trabajo a más máquinas virtuales, necesita más IP y subredes. Sin embargo, el siguiente bloque IP 10.0.1.0/24 se ha asignado en la herramienta de direcciones IP para otro fin. Como resultado, se le obliga a agregar un CIDR no contiguo a la VCN.
• Si es posible, utilice bloques CIDR que estén dentro del espacio de dirección IP privada RFC 1918 estándar.
• Evite utilizar el espacio de dirección IP 169.254.0.0/16. Muchos proveedores, incluido Oracle, utilizan el mismo espacio IP en su red y eso puede causar problemas.
• Seleccione bloques CIDR únicos que no se solapen con ninguna otra red (en OCI, sus centros de datos locales u otro CSP).
• Al diseñar las subredes, tenga en cuenta el flujo de tráfico y los requisitos de seguridad. Asocie todos los recursos de un nivel o rol específico a la misma subred.

Uso de listas de seguridad y tablas de rutas personalizadas para cada subred

Al aprovisionar subredes, se le pedirá que seleccione una tabla de rutas de VCN y una lista de seguridad para utilizarla con cada subred.

OCI proporciona una tabla de rutas por defecto y una lista de seguridad por defecto que, si se utiliza, se comparte con todas las subredes asociadas a ellas. El uso de las opciones por defecto es bueno para un despliegue sencillo o para empezar, pero no para un enfoque recomendado para un diseño de producción que incluya varias subredes. El uso de tablas de rutas de VCN y listas de seguridad específicas de cada subred le permite mantener el enrutamiento granular y el control de seguridad de las subredes individuales en lugar de hacer que compartan estos recursos.

Por ejemplo:

• Puede que desee que una subred privada tenga una ruta por defecto a un gateway de NAT y que una subred pública tenga una ruta por defecto a un gateway de Internet, lo que requeriría tener tablas de rutas de VCN independientes.
• Es posible que desee permitir un flujo de tráfico específico a una subred, pero no a otra, lo que requeriría tener listas de seguridad independientes

Oracle recomienda lo siguiente:

• Crear y asociar una tabla de rutas de VCN única para cada subred
• Crear y asociar una lista de seguridad única para cada subred

Sugerencia:

Cree y asocie estas tablas de rutas de VCN y listas de seguridad únicas al aprovisionar las subredes, ya que será más difícil cambiar de las predeterminadas más adelante.