Casos de uso de puntos finales privados

Este es el caso de uso más común para Data Flow y puntos finales privados.

La integración de Data Flow con orígenes de datos locales a través de puntos finales privados garantiza un procesamiento de datos seguro y eficiente en entornos híbridos.

Mediante el uso de opciones de conectividad de red privada como VPN de sitio a sitio o FastConnect, puede conectar sin problemas aplicaciones de Data Flow a repositorios de datos alojados en la infraestructura local. Esto proporciona una comunicación sólida y de baja latencia, al tiempo que mantiene estrictos límites de seguridad. Utilícelo para casos de uso que requieran acceso y procesamiento de datos seguros en entornos locales y en la nube.

Un elemento clave de esta configuración es la resolución de DNS, que ahora tiene lugar dentro del gateway de acceso privado. La configuración proporciona un nombre DNS (nombre de dominio completo o FQDN) para los puntos finales privados, no la dirección IP privada en sí. Si ha configurado la configuración de red para DNS, los hosts pueden acceder al punto final privado mediante el uso de FQDN. Data Flow soporta grupos de seguridad de red (NSG) con sus recursos. Puede solicitar que el servicio Data Flow configure el punto final privado en un NSG dentro de su VCN. Los NSG le permiten escribir reglas de seguridad para controlar el acceso al punto final privado sin conocer la dirección IP privada asignada al punto final privado.

Cuando se ha establecido la conectividad entre la VCN del cliente de OCI y la red local, para que la aplicación Data Flow funcione correctamente, es necesario asociar las IP privadas de la red local a un solucionador de dominio privado en la VCN del cliente de OCI.

Para ilustrar esta parte, estamos utilizando dos redes conectadas mediante OCI Network Visualizer. La subred privada hdi-dataflow-VCN está conectada a una asociación de gateway de enrutamiento dinámico de disdemo-DRG.

A partir de este punto, la parte relevante es decidir cómo se produce la resolución de DNS. En este ejemplo, hemos creado dos solucionadores de DNS:

• Una conectada a la vista estándar hdi-dataflow-vcn (industrial.com)
• Otra en una vista privada de cliente con la resolución para el dominio oraclevcn.com, que indica que se trata de una subred privada en una VCN de OCI.

En "Detalles del solucionador privado" de la VCN seleccionada, seleccione Gestionar vistas privadas. Existen dos opciones:

• En nuestro caso, la vista privada protegida crea la vista privada hdi-dataflow-vcn (orden 1).
• Con Gestionar vistas privadas de nuevo, cree la vista privada de cliente (orden 2).

Navegando a la primera vista privada hdi-dataflow-vcn, en Private Zones, creamos la zona industrial.com con el tipo Primary Zone.

Del mismo modo, vaya a la vista privada-cliente y verifique que ya se ha creado una zona privada en la subred privada de la VCN a la que se hace referencia.

En la zona industrial.com de la vista privada, seleccione Gestionar registros para crear un nuevo registro para la IP de un MySQLServer externo que se ejecuta en la red local del cliente. Por ejemplo:

Nombre: MySQL_Customer_OnPremises(.industrial.com)

Tipo: A -Dirección IPv4

TTL en segundos: 3600

RDATA/respuestas

Dirección: 10.xx.xx.xx (la dirección IP del recurso local).

Del mismo modo, haga lo mismo para el acceso privado dentro de otra VCN privada de OCI que se haya intercambiado con la VCN actual, como la de la imagen anterior, a través del gateway de intercambio de tráfico local (LPG). Por lo tanto, en la zona interna privatesubnet.dfarchitecture.oraclevcn.com, agregue un registro a la IP de otra instancia de MySQL que se ejecute en la subred privada de la VCN conectada. Por ejemplo:

Dominio: mysql-private.privatesubnet.dfarchitecture.oraclevcn.com

Tipo: A -Dirección IPv4

TTL en segundos: 3600

RDATA/respuestas

Dirección: 12.xx.xx.xx (la dirección IP del recurso en la VCN conectada).

De nuevo, la resolución de DNS es el factor clave que se debe abordar al utilizar puntos finales privados de Data Flow. Resuélvalos utilizando los tipos de registro adecuados para la red descendente. Para estos tipos y configuraciones, siga la documentación de Gestión de zonas de DNS.

Data Flow soporta la integración de punto final privado para un acceso de datos entre regiones perfecto mediante el intercambio de tráfico remoto de VCN a través de un gateway de direccionamiento dinámico (DRG) actualizado.

Esta configuración permite a las aplicaciones de Data Flow de una región conectarse de forma segura a orígenes de datos alojados en la VCN de otra región, como se muestra en la siguiente imagen:

Puede garantizar transferencias de datos de alto rendimiento y baja latencia al tiempo que mantiene una sólida estrategia de seguridad mediante el uso de las capacidades avanzadas del DRG actualizado, incluido el enrutamiento transitivo y la conectividad centralizada.

Además, con las capacidades de red multinube de OCI, puedes ampliar esta configuración para conectarte, por ejemplo, con Microsoft Azure. Mediante el uso de OCI-Azure Interconnect o un marco de conectividad multinube similar, puede activar Data Flow para procesar datos almacenados en recursos de Azure como Azure Blob Storage o Azure SQL Database, como se muestra en la siguiente imagen:

Esta arquitectura admite conectividad centralizada, enrutamiento transitivo y transferencia de datos de baja latencia entre OCI y Azure, al tiempo que mantiene estrictos estándares de seguridad y cumplimiento.

Para el punto final privado de Data Flow, importa cómo se resuelvan los nombres de DNS antes del DRG, mediante solucionadores privados, como se muestra en Conexión a recursos locales. Una ventaja tangible es que las instancias para la conectividad privada en el servicio, la VCN puede acceder a una carga de trabajo especificada por el consumidor sin recorrer Internet. Además, el punto final privado de Data Flow puede ampliar la conectividad privada de las instancias de la VCN de servicio a la red local del consumidor y a otras redes a las que se puede acceder a través de la VCN del consumidor. Desde el punto de vista de la facilidad de uso, puede seguir interactuando solo con la consola de servicio (o API) y no necesita otra interfaz para permitir el acceso privado. A pesar de la flexibilidad de funcionamiento mediante el punto final privado de Data Flow, existen algunas limitaciones:

• El límite por defecto para un punto final privado de Data Flow no es superior a cinco por arrendamiento por región.
• Si se necesita conectividad a Internet para que una aplicación de Spark se ejecute con puntos finales privados activados, la zona de DNS correspondiente (por ejemplo, las API/google.zone de Google) se debe mencionar en la sección de parámetros (zonas) para los puntos finales privados de la aplicación. Por lo tanto, si la zona está en la lista de permitidos, el tráfico se enruta a la VCN del cliente para su resolución. La red del cliente es responsable de la conectividad a Internet una vez que el paquete llega a la VCN del gateway de consumidor. El tráfico de red se borra para todas las demás zonas no mencionadas en el parámetro (zonas DNS).

Data Flow se puede conectar a RAC (cluster de aplicación real) o a la máquina de Exadata como aplicación cliente mediante SCAN (nombre de acceso de cliente único).

El SCAN es un nombre virtual similar al utilizado para las direcciones IP virtuales. Sin embargo, a diferencia de una IP virtual, el nombre virtual SCAN está asociado a todo el cluster en lugar de a un nodo individual y a varias direcciones IP, no solo a una dirección.

Cuando la función de proxy SCAN está activada, se establece un punto de entrada de conexión inversa (RCE) para manejar redirecciones basadas en IP. Como se muestra en la siguiente imagen, se crea una VNIC de punto final privado (tarjeta de interfaz de red virtual de punto final privado) en la VCN del cliente. La VNIC de punto final privado de RCE es única para cada configuración de punto final privado de Data Flow. Una consideración importante sobre la conexión TLS a un cluster de base de datos es que los listeners de SCAN de base de datos redirigen el tráfico de red a un FQDN, no directamente a la dirección IP. Solo los redireccionamientos de FQDN desde un listener de SCAN activan TLS. Por lo tanto, configure el cluster de base de datos para redirigir a un FQDN si TLS es un requisito.

Los pasos de configuración que se realizan en segundo plano para crear la función de proxy SCAN:

• El usuario configura el proxy SCAN en la configuración del punto final privado de Data Flow
• Data Flow actualiza RCE para incluir la configuración de SCAN (nombre y puerto DNS del listener de SCAN), que proporciona una nueva IP (IP de proxy de SCAN) en el enlace de VCN de servicio al mismo puerto de SCAN
• A continuación, Data Flow utiliza la IP de proxy de SCAN para crear una asignación de DNS dentro de la red de servicio, utilizando el nombre de DNS del listener de SCAN original y la IP de proxy de SCAN

En la imagen anterior se muestra un ejemplo de un sistema Oracle Database RAC dentro de una subred privada en la VCN del cliente. El flujo de la imagen indica la secuencia utilizada para identificar la conectividad:

1. Data Flow inicia una conexión al punto final de proxy SCAN dentro de la VCN de servicio mediante el nombre de DNS. Data Flow define una conexión RAC de cliente mediante el proxy SCAN seleccionando un puerto específico. El proxy RCE SCAN reenvía la solicitud al listener de VNIC de punto final privado subyacente en la red del cliente. A continuación, inspecciona la respuesta del listener de SCAN en busca de una IP de la instancia de cluster de base de datos subyacente, crea una IP NAT de clase E y sustituye la IP de la instancia de cluster por una IP de NAT en la respuesta del proxy de SCAN.
2. El gateway de acceso privado recibe la solicitud de redirección del listener de SCAN y traduce automáticamente la IP del listener local de la VCN del cliente en una dirección IP asignada. A continuación, devuelve esta información a los componentes de Data Flow y realiza una solicitud de conexión a uno de los listeners locales.

En la configuración de punto final privado de Data Flow, introduzca el nombre de DNS del host de exploración en la sección de detalles de SCAN y su número de puerto asociado. Por ejemplo:

Nombre de DNS: oracleDB-scan-sub0911000090.dfarchitecture.oraclevcn.com

Puerto: 16001

Al ejecutar una ejecución sin servidor de Spark, es fundamental tener en cuenta los patrones de tráfico de red y el aislamiento para garantizar el mejor rendimiento, seguridad y cumplimiento.

Los trabajos de Spark sin servidor se ejecutan en un entorno gestionado en el que el tráfico de red fluye entre la aplicación, los orígenes de datos y los servicios externos. Para minimizar la latencia y controlar el tráfico, asegúrese de que los orígenes de datos se encuentren en la misma región y en la misma red virtual en la nube (VCN), siempre que sea posible. A continuación se muestran algunas consideraciones e información más sobre la configuración de punto final privado de Data Flow:

• Después de asociar una ejecución de aplicación con un recurso de punto final privado de Data Flow, el tráfico de red a Internet se enruta a la subred de su VCN a través de la infraestructura de punto final privado, siempre que la zona de DNS se incluya en la lista durante la creación del punto final privado. Falla si la VCN no tiene un gateway de Internet asociado. Si la zona DNS no está en la lista de permitidos, el tráfico de red se borra. El tráfico de red a los servicios de OCI, por ejemplo, Object Storage en Oracle Services Network, aún se enruta a través de la VCN de Data Flow.
• Cuando se esté ejecutando la ejecución de Data Flow, la aplicación de Data Flow de Spark que se ejecuta desde cualquier nodo asignado al inquilino inicia una conexión de red al recurso privado con el nombre de DNS, por ejemplo, customer1.instance1.subnet.oraclevcn.com. Esto implica una consulta DNS de la IP de proxy DNS asignada a su recurso privado, creada durante la configuración de punto final de conexión privada/punto final de conexión inversa. En una conexión inversa, un servidor inicia la conexión a un cliente, lo que permite que Data Flow acceda al recurso de forma privada conectándose a un punto final especificado dentro de la red.
• Las zonas de DNS en las vistas privadas crean un proxy que devuelve una dirección IP de clase E (240.0.0.0-255.255.255.255) para la asignación de customer.instance.subnet.oraclevcn.com desde un rango de CIDR específico, por ejemplo, 255.33.36.2, como se muestra en el script de prueba en Prueba del punto final privado de Data Flow. En este ejemplo, los nodos de Data Flow que ejecutan los trabajos pueden establecer una conexión de red a 255.33.36.0/24 y se crea una regla de salida con estado con ese rango CIDR de destino. Esto significa que cuando una instancia de Data Flow inicia el tráfico a otro host y ese tráfico se permite mediante reglas de seguridad de salida, todo el tráfico que la instancia recibe posteriormente de ese host durante un período se considera tráfico de respuesta (entrada) y se permite. También se agrega una regla de tabla de rutas para enrutar el punto final privado de Data Flow de forma adecuada para el rango de CIDR de destino como 255.33.36.0/24 asignado a ese recurso.