Compartir vía


Red virtual administrada de Azure Data Factory

SE APLICA A: Azure Data Factory Azure Synapse Analytics

Sugerencia

Pruebe Data Factory en Microsoft Fabric, una solución de análisis todo en uno para empresas. Microsoft Fabric abarca todo, desde el movimiento de datos hasta la ciencia de datos, el análisis en tiempo real, la inteligencia empresarial y los informes. Obtenga información sobre cómo iniciar una nueva evaluación gratuita.

En este artículo se explican las redes virtuales administradas y los puntos de conexión privados administrados en Azure Data Factory.

Red virtual administrada

Al crear una instancia de Azure Integration Runtime en la red virtual administrada de Azure Data Factory, el entorno de ejecución de integración se aprovisiona con la red virtual administrada. Usa puntos de conexión privados para conectarse de forma segura a almacenes de datos admitidos.

La creación de un entorno de ejecución de integración dentro de una red virtual administrada garantiza que el proceso de integración de datos esté aislado y protegido.

Ventajas del uso de una red virtual administrada:

  • Con una red virtual administrada puede dejar que Data Factory se ocupe de la pesada tarea de administrar la red virtual. No es necesario crear una subred para un entorno de ejecución de integración que podría usar muchas direcciones IP privadas de la red virtual y requeriría una planeación previa de la infraestructura de la red.
  • No se necesita un conocimiento profundo de las redes de Azure para realizar integraciones de datos de forma segura. En su lugar, empezar a utilizar ETL seguro es mucho más sencillo para los ingenieros de datos.
  • Una red virtual administrada, junto con los puntos de conexión privados administrados, sirve de protección contra la filtración de datos.

Actualmente, la red virtual administrada solo se admite en la misma región que Data Factory.

Nota:

Un entorno de ejecución de integración global existente no se puede cambiar a un entorno de ejecución de integración en una red virtual administrada de Data Factory y viceversa.

Diagrama que muestra la arquitectura de red virtual administrada de Data Factory.

Hay dos maneras de habilitar la red virtual administrada en la factoría de datos:

  1. Habilite la red virtual administrada durante la creación de la factoría de datos.

Captura de pantalla de la habilitación de la red virtual durante la creación de la factoría de datos.

  1. Habilite la red virtual administrada en el tiempo de ejecución de integración.

Captura de pantalla de la habilitación de la red virtual administrada en el tiempo de ejecución de integración

Puntos de conexión privados administrados

Los puntos de conexión privados administrados son puntos de conexión que se crean en la red virtual administrada de Data Factory y establecen un vínculo privado a recursos de Azure. Data Factory administra estos puntos de conexión privados en su nombre.

Data Factory admite vínculos privados. Puede usar Azure Private Link para acceder a los servicios de plataforma como servicio (PaaS) de Azure, como Azure Storage, Azure Cosmos DB y Azure Synapse Analytics.

Cuando se usa un vínculo privado, el tráfico entre los almacenes de datos y la red virtual administrada atraviesa completamente la red troncal de Microsoft. Private Link protege frente a los riesgos de la filtración de datos. El vínculo privado a un recurso se establece mediante la creación de un punto de conexión privado.

Un punto de conexión privado usa una dirección IP privada en la red virtual administrada para incorporar el servicio de manera eficaz a la red virtual. Los puntos de conexión privados se asignan a un recurso específico de Azure, no a todo el servicio. Los clientes pueden limitar la conectividad a un recurso específico aprobado por su organización. Para obtener más información, consulte Vínculos privados y puntos de conexión privados.

Nota:

El proveedor de recursos Microsoft.Network debe estar registrado en su suscripción.

  1. Asegúrese de habilitar la red virtual administrada en la factoría de datos.
  2. Creación de un nuevo punto de conexión privado administrado en Administrar Hub.

Captura de pantalla que muestra los nuevos puntos de conexión privados administrados.

  1. Una conexión de punto de conexión privado se crea con estado Pendiente cuando se crea un punto de conexión privado administrado en Data Factory. Se inicia un flujo de trabajo de aprobación. El propietario del recurso de vínculo privado es responsable de aprobar o rechazar la conexión.

Captura de pantalla que muestra la opción Administrar aprobaciones en Azure Portal.

  1. Si el propietario aprueba la conexión, se establece el vínculo privado. De lo contrario, no se establece. En cualquier caso, el punto de conexión privado administrado se actualiza con el estado de la conexión.

Captura de pantalla que muestra la aprobación del punto de conexión privado administrado.

Solo un punto de conexión privado administrado en un estado aprobado puede enviar tráfico a un recurso de vínculo privado específico.

Nota

No se admite un DNS personalizado en la red virtual administrada.

Creación interactiva

Entre las funcionalidades de la creación interactiva se incluyen probar la conexión, examinar la lista de carpetas y la lista de tablas, obtener esquemas y obtener una vista previa de los datos. Puede habilitar la creación interactiva al crear o editar una instancia del entorno de ejecución de integración de Azure que se encuentre en una red virtual administrada por Azure Data Factory. El servicio de back-end asignará previamente el proceso para las funcionalidades de creación interactiva. De lo contrario, el proceso se asignará cada vez que se realice cualquier operación interactiva, lo que tardará más tiempo. El período de vida (TTL) para la creación interactiva es de 60 minutos de manera predeterminada, lo que significa que se deshabilitará automáticamente después de 60 minutos de la última operación de creación interactiva. Puede cambiar el valor de TTL según sus necesidades reales.

Captura de pantalla que muestra la creación interactiva.

Período de vida

Actividad de copia

De manera predeterminada, cada actividad de copia pone en marcha un nuevo proceso en función de la configuración de la actividad de copia. Con la red virtual administrada habilitada, el tiempo de inicio de los procesos de acceso esporádico tarda unos minutos y el movimiento de datos no se puede iniciar hasta que se complete. Si las canalizaciones contienen varias actividades de copia secuencial o tiene muchas actividades de copia en el bucle foreach y no se pueden ejecutar todas en paralelo, puede habilitar un valor del período de vida (TTL) en la configuración de Azure Integration Runtime. Al especificar un valor del período de vida y números DIU necesarios para la actividad de copia se mantienen activos los procesos correspondientes durante un período de tiempo determinado después de que se complete su ejecución. Si una nueva actividad de copia comienza durante el tiempo de TTL, volverá a usar los procesos existentes y el tiempo de inicio de actividad se reducirá drásticamente. Una vez completada la segunda actividad de copia, los procesos permanecerán activos de nuevo durante el tiempo de TTL. Tiene la flexibilidad de seleccionar entre los tamaños de proceso predefinidos, que van de pequeño a mediano a grande. Como alternativa, también tiene la opción de personalizar el tamaño de proceso en función de los requisitos específicos y las necesidades en tiempo real.

Nota

Volver a configurar el número DIU no afectará a la ejecución de la actividad de copia actual.

Nota:

La medida de la unidad de integración de datos (DIU) de 2 DIU no se admite para la actividad de copia en una red virtual administrada.

La DIU que seleccione en TTL se usará para ejecutar todas las actividades de copia, el tamaño de la DIU no se escalará automáticamente según las necesidades reales. Por lo tanto, tiene que elegir suficientes DIU.

Advertencia

La selección de pocas DIU para ejecutar muchas actividades hará que muchas actividades estén pendientes en la cola, lo que afectará gravemente al rendimiento general.

Canalización y actividad externa

De forma similar a la copia, tiene la capacidad de adaptar el tamaño de proceso y la duración de TTL según sus requisitos específicos. Sin embargo, a diferencia de la copia, tenga en cuenta que la canalización y el TTL externo no se pueden deshabilitar.

Nota:

El período de vida (TTL) solo se aplica a la red virtual administrada.

Captura de pantalla que muestra la configuración TTL.

Puede usar la tabla siguiente como referencia para determinar el número óptimo de nodos para ejecutar canalizaciones y actividades externas.

Tipo de actividad Capacity
Actividad de canalización Aproximadamente 50 por nodo
La actividad de script y la actividad de búsqueda con SQL alwaysEncrypted tienden a consumir más recursos en comparación con otras actividades de canalización, con el número sugerido que está alrededor de 10 por nodo.
Actividad externa Aproximadamente 800 por nodo

Comparación de diferentes TTL

En la tabla siguiente se enumeran las diferencias entre los distintos tipos de TTL:

Característica Creación interactiva Copia de la escala de proceso Escala de proceso externo y canalización
Cuándo surtir efecto Inmediatamente después de la habilitación Primera ejecución de la actividad Primera ejecución de la actividad
Se puede deshabilitar Y Y N
El proceso reservado es configurable N Y Y

Nota:

No se puede habilitar TTL en el entorno de ejecución de integración de Azure predeterminado de resolución automática. Puede crear un entorno de ejecución de integración de Azure para él.

Nota:

Cuando se activa el TTL de escala del proceso Copy/Pipeline/External, la facturación viene determinada por los recursos de proceso reservados. Como resultado, la salida de la actividad no incluye billingReference, ya que esto es exclusivamente relevante en escenarios que no son TTL.

Creación de una red virtual administrada mediante Azure PowerShell

$subscriptionId = ""
$resourceGroupName = ""
$factoryName = ""
$managedPrivateEndpointName = ""
$integrationRuntimeName = ""
$apiVersion = "2018-06-01"
$privateLinkResourceId = ""

$vnetResourceId = "subscriptions/${subscriptionId}/resourceGroups/${resourceGroupName}/providers/Microsoft.DataFactory/factories/${factoryName}/managedVirtualNetworks/default"
$privateEndpointResourceId = "subscriptions/${subscriptionId}/resourceGroups/${resourceGroupName}/providers/Microsoft.DataFactory/factories/${factoryName}/managedVirtualNetworks/default/managedprivateendpoints/${managedPrivateEndpointName}"
$integrationRuntimeResourceId = "subscriptions/${subscriptionId}/resourceGroups/${resourceGroupName}/providers/Microsoft.DataFactory/factories/${factoryName}/integrationRuntimes/${integrationRuntimeName}"

# Create managed Virtual Network resource
New-AzResource -ApiVersion "${apiVersion}" -ResourceId "${vnetResourceId}" -Properties @{}

# Create managed private endpoint resource
New-AzResource -ApiVersion "${apiVersion}" -ResourceId "${privateEndpointResourceId}" -Properties @{
        privateLinkResourceId = "${privateLinkResourceId}"
        groupId = "blob"
    }

# Create integration runtime resource enabled with virtual network
New-AzResource -ApiVersion "${apiVersion}" -ResourceId "${integrationRuntimeResourceId}" -Properties @{
        type = "Managed"
        typeProperties = @{
            computeProperties = @{
                location = "AutoResolve"
                dataFlowProperties = @{
                    computeType = "General"
                    coreCount = 8
                    timeToLive = 0
                }
            }
        }
        managedVirtualNetwork = @{
            type = "ManagedVirtualNetworkReference"
            referenceName = "default"
        }
    }

Nota:

Puede obtener groupId de otros orígenes de datos de un recurso de vínculo privado.

Nota:

ReferenceName solo debe establecerse como "valor predeterminado" si crea a través del comando de PowerShell.

Conexión saliente

Servicios y orígenes de datos admitidos

Los siguientes servicios tienen compatibilidad nativa con los puntos de conexión privados. Se pueden conectar a través de un vínculo privado desde una red virtual administrada de Data Factory:

  • Azure Databricks
  • Azure Functions (Plan Premium)
  • Azure Key Vault
  • Azure Machine Learning
  • Azure Private Link
  • Microsoft Purview

Para obtener compatibilidad con orígenes de datos, puede consultar la introducción al conector. Puede acceder a todos los orígenes de datos admitidos por Data Factory a través de una red pública.

Orígenes de datos locales

Para obtener información sobre cómo acceder a orígenes de datos locales desde una red virtual administrada mediante un punto de conexión privado, consulte Acceso a SQL Server local desde una red virtual administrada de Data Factory mediante un punto de conexión privado.

Comunicaciones salientes a través del punto de conexión público desde una red virtual administrada de Data Factory

Se abren todos los puertos para las comunicaciones salientes.

Limitaciones y problemas conocidos

Creación de un servicio vinculado para Key Vault

Cuando se crea un servicio vinculado para Key Vault, no existe ninguna referencia al entorno de ejecución de integración. Por este motivo, no se puede generar un punto de conexión privado cuando se crea un servicio vinculado para Key Vault. Sin embargo, cuando se crea un servicio vinculado para almacenes de datos que hacen referencia a Key Vault y este servicio vinculado hace referencia a un entorno de ejecución de integración con la red virtual administrada habilitada, puede crear un punto de conexión privado para Key Vault durante la creación.

  • Prueba de conexión: esta operación de un servicio vinculado de Key Vault solo valida el formato de la dirección URL, pero no realiza ninguna operación de red.
  • Uso del punto de conexión privado: esta columna siempre se muestra en blanco, incluso si crea un punto de conexión privado para Key Vault.

Creación de un servicio vinculado de Azure HDInsight

La columna Uso del punto de conexión privado siempre se muestra en blanco, incluso si crea un punto de conexión privado para HDInsight usando un servicio de vínculo privado y un equilibrador de carga con reenvío de puertos.

Captura de pantalla que muestra un punto de conexión privado de Key Vault.

Nombre de dominio completo ( FQDN ) de Azure HDInsight

Si ha creado un servicio de vínculo privado personalizado, el FQDN deberá terminar con azurehdinsight.net sin un privatelink inicial en el nombre de dominio al crear un punto de conexión privado. Si usara privatelink en el nombre de dominio, asegúrese de que sea válido y puede resolverlo.

Restricciones de acceso en una red virtual administrada con puntos de conexión privados

No puede acceder a cada recurso de PaaS cuando ambos lados están expuestos a Private Link y al punto de conexión privado. Este problema es una limitación conocida de Private Link y de los puntos de conexión privados.

Por ejemplo, tiene un punto de conexión privado administrado para la cuenta de almacenamiento A. También puede acceder a la cuenta de almacenamiento B a través de la red pública en la misma red virtual administrada. Pero cuando la cuenta de almacenamiento B tiene una conexión de punto de conexión privado desde otra red virtual administrada o red virtual del cliente, no puede acceder a la cuenta de almacenamiento B de la red virtual administrada a través de la red pública.

Vea los siguientes tutoriales: