Definir requisitos de carga de trabajo
Tome decisiones sobre sus requisitos para la comunicación, la conectividad y la resiliencia de las cargas de trabajo.
Requisitos de comunicación
Identifique los requisitos de comunicación de carga de trabajo para gateways de comunicación y conectividad de Internet, conectividad entre VCN y acceso a Oracle Services Network.
Gateways de comunicación de OCI
Debe decidir los gateways de comunicación adecuados para sus necesidades.
En la siguiente tabla, se muestran las funciones y los gateways recomendados que se deben utilizar para cada función.
| Función | Gateway recomendado | Comentarios |
|---|---|---|
| El tráfico entrante y saliente de OCI se puede iniciar desde OCI o desde Internet | Gateway de internet | Necesita una subred pública y un recurso con IP pública |
| Los recursos de OCI acceden a Internet de forma segura | Gateway de NAT | Solo se permite el tráfico iniciado desde la subred a través del gateway de NAT |
| Acceso a Oracle Cloud Infrastructure Object Storage u otros servicios de Oracle Service Network | Gateway de servicio | Algunos ejemplos de servicios son el servicio de gestión del sistema operativo, Oracle Linux o Yum Service. Consulte la sección Explorar para obtener una lista completa de los servicios admitidos en Oracle Services Network |
| Conexión entre OCI y las ubicaciones locales y entre las | Gateway de enrutamiento dinámico (DRG) | Un enrutador virtual conecta VCN y ubicaciones locales a través de un punto de conexión central y también se conecta entre regiones y distintos arrendamientos |
Conectividad entre VCN
Decida cómo establecer una comunicación entre las VCN de OCI. Puede conectar dos CNV dentro del mismo arrendamiento o de distintos arrendamientos.
Puede ver tres ejemplos de conectividad entre VCN mediante un gateway de intercambio de tráfico local o un gateway de enrutamiento dinámico.
Gateway de intercambio de tráfico local (LPG)
En la siguiente imagen se muestra una región con dos VCN mediante el método de gateway de intercambio de tráfico local:
Ambas CN deben estar en la misma región y puede tener un máximo de diez LPG por VCN.
Gateway de enrutamiento dinámico (DRG)
Oracle recomienda utilizar gateways de direccionamiento dinámico. Puede conectar las redes virtuales dentro de la misma región o entre regiones. Un DRG puede conectar hasta 300 VCN.
En la siguiente imagen se muestra una región con dos VCN conectadas por un DRG en la misma región:
En la siguiente imagen se muestra una región con dos VCN que utilizan el DRG con dos VCN conectadas entre regiones separadas:
Acceso a Oracle Services Network
Oracle Services Network (OSN) es una red conceptual que forma parte de Oracle Cloud Infrastructure y solo pueden utilizarla los servicios de Oracle.
La siguiente arquitectura muestra el acceso a Oracle Services Network:
Estos servicios tienen direcciones IP públicas que se pueden acceder a través de Internet. Sin embargo, puede acceder a Oracle Services Network sin el tráfico que pasa por Internet mediante un gateway de servicios desde una VCN.
Al agregar una ruta a OSN, debe decidir si la red debe utilizar todos los servicios o simplemente acceder a Oracle Cloud Infrastructure Object Storage.
El almacenamiento de objetos se suele utilizar con fines de copia de seguridad, como para las copias de seguridad de Oracle Database.
Requisitos híbridos y multinube
Decida si necesita una arquitectura híbrida en la nube o multinube. Evalúe los requisitos de ancho de banda para la conexión para una buena experiencia de usuario.
Puede conectar Oracle Cloud a las redes locales mediante FastConnect o una VPN de sitio a sitio.
El siguiente diagrama muestra una arquitectura de ejemplo de conexión de un entorno local a OCI mediante VPN de sitio a sitio o FastConnect:
En el siguiente diagrama se muestra un ejemplo de arquitectura de una base de datos en OCI y el equilibrador de carga de aplicaciones en Microsoft Azure:
La latencia es importante para una buena experiencia de usuario con mejores tiempos de respuesta. Oracle y Micorsoft Azure tienen puntos de integración en diferentes ubicaciones de todo el mundo. Esto facilita la integración y también reduce la latencia, lo que hace posible tener una solución que se extienda entre las nubes mediante FastConnect y ExpressRoute.
Puede utilizar FastConnect como conexión primaria y VPN de sitio a sitio como conexión de copia de seguridad. También puede conectarse a otras nubes mediante VPN de sitio a sitio y FastConnect según sus necesidades.
Conexión a redes locales
Puede conectarse a redes locales mediante una de las siguientes opciones:
- FastConnect utiliza una conexión dedicada para el ancho de banda y la latencia fijos. Oracle recomienda utilizar conexiones redundantes para la resiliencia.
- La VPN de sitio a sitio utiliza Internet como operador y también puede utilizar FastConnect. El ancho de banda y la latencia pueden variar, por lo que Oracle recomienda utilizar túneles redundantes.
Conexión a redes locales mediante FastConnect
En la siguiente imagen se muestra una arquitectura con una región local y OCI mediante FastConnect, donde el tráfico no pasa por la red pública de Internet:
Utilice VPN de sitio a sitio como conexión de copia de seguridad para FastConnect, por lo que la conexión principal es FastConnect y la copia de seguridad es VPN. Las velocidades de conexión disponibles son 1 Gbps, 10 Gbps o 100 Gbps.
- Configure un circuito virtual con intercambio de tráfico público si solo necesita acceder a Oracle Services Network.
- Utilice una VPN de sitio a sitio que utilice IPSec para el cifrado de tráfico, además del intercambio de tráfico público de FastConnect.
- Utilice el intercambio de tráfico privado cuando necesite una conexión privada a los recursos de OCI (VCN).
Nota:
Oracle recomienda utilizar el doble del equipo para la redundancia.Conexión a redes locales mediante VPN de sitio a sitio
VPN de sitio a sitio conecta DC local a OCI. La VPN de sitio a sitio utiliza Internet como operador y cifra el tráfico mediante el protocolo IPSec.
En la siguiente imagen se muestra una arquitectura con dispositivos locales de cliente redundantes y una conexión OCI mediante una VPN de sitio a sitio:
VPN de sitio a sitio conecta centros de datos locales a OCI. El rendimiento puede variar según el tráfico de Internet. Al igual que con FastConnect, debe configurar una VPN de sitio a sitio con túneles redundantes y, de ser posible, también con dispositivos CPE redundantes. Oracle proporciona dos puntos finales de VPN para cada conexión VPN de sitio a sitio.
En función de las necesidades de su empresa, puede utilizarla como alternativa a FastConnect si tiene un ancho de banda constante. La VPN de sitio a sitio está integrada en herramientas de Oracle Cloud para facilitar la configuración y está disponible sin costo adicional. Sin embargo, la VPN de sitio a sitio no se puede ampliar al mismo ancho de banda que FastConnect (actualmente, 250 Mbps/tunnel). Puede utilizarla como base de datos en espera para FastConnect.
Utilice VPN de sitio a sitio como alternativa gratuita si no necesita las conexiones de alto rendimiento de Megaport o Equinix que se analizan en las siguientes secciones.
Conéctese a Amazon Web Services
Las conexiones a otras nubes públicas de Oracle Cloud Infrastructure son rápidas y fáciles de establecer mediante nuestros partners de FastConnect.
En el siguiente diagrama se muestra una conexión entre OCI y AWS con nuestro partner de conexión Megaport:
Conéctese a Microsoft Azure
Microsoft y Oracle tienen una asociación con la preintegración de Azure con OCI en varias regiones.
En el siguiente diagrama se muestra la preintegración de Azure con OCI mediante ExpressRoute y FastConnect:
Puede activar el acceso entre las nubes activándolo desde ambos sitios o la consola mediante FastConnect y ExpressRoute sin proveedor de servicios de red intermedio. Solo necesita configurar un circuito virtual 1x, ya que tiene redundancia incorporada mediante un estándar diferente al de FastConnect. No hay costo de tráfico entre Azure si utiliza un SKU local y selecciona la velocidad de conexión mínima de 1 Gbps. Las interconexiones se crean donde Azure y OCI se ubican unos a otros para permitir una baja latencia entre las nubes.
Nota:
No todas las regiones tienen esta capacidad. Utilice un proveedor de servicios de red en otras regiones.Si desea conectarse a Microsoft Azure, consulte Acceso a Microsoft Azure.
Requisitos de resiliencia
Decida si desea tener resiliencia frente a interrupciones regionales y considere un despliegue en varias regiones.
Despliegue en varias regiones
Utilice una configuración entre regiones estándar para un despliegue en varias regiones donde empareje una región con otra para la copia cruzada. Configure los mismos recursos en la región en espera y configure el intercambio de tráfico remoto entre DRG.
Los datos entre las regiones utilizan el eje central de red de Oracle en lugar de Internet. Debe configurar la replicación de los datos y el contenido necesario para ejecutar el despliegue en la región en espera.
Descripción de la ilustración multi-region-deployment-full-arch.png
equilibrio de carga
Utilice un equilibrador de carga para distribuir el tráfico a varios servidores backend.
Equilibrador de carga
Un equilibrador de carga estándar para servidores web orientados al público puede terminar el tráfico SSL o transferirlo al backend. Puede aplicar directamente la protección del firewall de aplicaciones web (WAF) a un equilibrador de carga y utilizar unidades flexibles entre el ancho de banda mínimo y el máximo en función del tráfico.
Puede configurar un equilibrador de carga público o privado en la capa 4/7, capa TCP/HTTP.
equilibrador de carga de red
Proporciona un equilibrio de carga de transferencia no proxy con alto rendimiento y latencia ultrabaja. Los equilibradores de carga de red son gratuitos. Se optimizan para conexiones de larga ejecución en días o meses con conexiones al mismo servidor backend, lo que es óptimo para la base de datos. Puede escalar y reducir automáticamente en función del tráfico del cliente y no requiere configuraciones de ancho de banda ni terminación SSL.
Los equilibradores de carga de red garantizan que los servicios permanezcan disponibles al dirigir el tráfico solo a servidores en buen estado basados en datos de capa 3/capa 4 (protocolo IP).