Preguntas más frecuentes sobre la puerta de enlace de datos local

No, los servicios generalmente pueden conectarse a orígenes de datos en la nube sin una puerta de enlace. Sin embargo, es posible que necesite una puerta de enlace de datos si sus orígenes de datos están detrás de un firewall, requieren una VPN o están en redes virtuales.

Al usar las credenciales de OAuth2, la puerta de enlace actualmente no admite la actualización automática de tokens cuando expiran los tokens de acceso (una hora después del inicio de la actualización). Esta limitación para las actualizaciones de larga duración existe para las puertas de enlace de VNET y para las puertas de enlace de datos locales.

Revise la sección de requisitos en el artículo de instalación.

No, la puerta de enlace se conectará con el origen de datos con la información de conexión que se proporcionó. En este sentido, piense en la puerta de enlace como en una aplicación de cliente. La puerta de enlace solo necesita conectarse al servidor especificado.

Actualmente, Microsoft solo admite activamente las últimas seis versiones de la puerta de enlace de datos local. Lanzamos una nueva actualización de las puertas de enlace de datos locales cada mes.

No existen restricciones de licencia para instalar y registrar una puerta de enlace. Pero cualquier servicio en la nube podría tener restricciones de licencia sobre cómo se usan las puertas de enlace dentro de ese servicio. Para Power BI se requiere una licencia Premium. Todas las licencias de Fabric admiten la puerta de enlace. Otros servicios pueden tener también restricciones de licencia propias.

Compruebe que la conexión de red tiene buen rendimiento. Cada entorno es diferente y el rendimiento depende de la cantidad de datos que se envían. Para garantizar un nivel mínimo de rendimiento entre sus origen de datos locales y los centros de datos de Azure, use Azure ExpressRoute. Para ayudar a medir su rendimiento, puede utilizar la aplicación Azure Speed Test.

Las credenciales que especifique para un origen de datos se cifran y almacenan en el servicio en la nube de la puerta de enlace. Las credenciales se descifran en la puerta de enlace local. Para más información sobre el cifrado de credenciales en Power BI, vaya a Notas del producto sobre la seguridad de Power BI.

En su equipo local, en la aplicación Servicios, el servicio se llama "servicio de puerta de enlace de datos local". En el Administrador de tareas, en la pestaña Servicios, el nombre del servicio es "PBIEgwService". De manera predeterminada, el servicio de Windows usa "NT SERVICE\PBIEgwService" como SID del servicio (SSID).

No, el servicio de Windows debe tener una cuenta de Windows válida.

No, la puerta de enlace usa conexiones salientes a Azure Relay.

Vaya a Habilitación de conexiones salientes de Azure.

Si bloquea el tráfico IP saliente, puede que deba desbloquear la lista de direcciones IP del centro de datos de Azure. La puerta de enlace se comunica con Azure Relay utilizando una dirección IP y un nombre de dominio completo. La lista de direcciones IP del Centro de datos de Azure se actualiza semanalmente. Para más información, vaya a Habilitación de conexiones salientes de Azure.

Para evitar la latencia de la red, instale la puerta de enlace lo más cerca posible del origen de datos. Si puede instalar la puerta de enlace en el origen de datos real, esta ubicación más cercana minimiza la latencia.

Además, considere la proximidad a los centros de datos de Azure. Por ejemplo, si su servicio usa el centro de datos del oeste de los EE. UU. y tiene SQL Server alojado en una máquina virtual de Azure, es posible que también desee tener su máquina virtual de Azure en la región del oeste de los EE. UU. Esta configuración minimiza la latencia y evita los cargos de salida en la VM de Azure.

Los resultados se envían a través de Azure Relay. Para más información, vaya a Arquitectura de puerta de enlace de datos local.

La puerta de enlace requiere una conexión con el origen de datos. Entonces, si no se puede acceder al origen de datos en su red perimetral, es posible que la puerta de enlace no tenga acceso.

Por ejemplo, suponga que su equipo con SQL Server no está en su red perimetral. Además, suponga que no puede conectarse a ese equipo desde la red perimetral. Si coloca la puerta de enlace en su red perimetral, la puerta de enlace no puede alcanzar el equipo con SQL Server.

Sí.

Esta prioridad depende de Windows o de los controladores de origen de datos pertinentes. Este comportamiento se puede configurar tanto en Windows como en varios controladores, pero no está bajo el control de la puerta de enlace.

No, no se admite el acceso de Microsoft Entra ID entre inquilinos. Un modelo semántico de Power BI en un inquilino no se puede conectar a orígenes de datos de otro inquilino mediante una cuenta de Microsoft Entra ID. Esta limitación se aplica tanto si origen de datos utiliza una puerta de enlace de datos local como si no. Para superar esta limitación, utilice un tipo de autenticación que no sea OAuth.

Sí, para más información, vaya a Forzar la comunicación HTTPS con Azure Relay. La activación de esta característica tiene poco efecto en el rendimiento.

No, son productos diferentes. Para más información sobre la puerta de enlace de Administración de datos, que ahora se llama Entorno de ejecución de integración autohospedado, vaya a Creación y configuración de un entorno de ejecución de integración autohospedado.

Sí, debe usar PowerShell para agregar otros propietarios a la misma puerta de enlace. Estos usuarios pueden crear la puerta de enlace en Azure Portal. Sin embargo, deben conectarse al portal y a la puerta de enlace utilizando el mismo inquilino.

No. Sigue siendo necesaria una puerta de enlace al conectarse a fuentes de datos locales.

Más información: Mantener los datos en la región donde se almacenan

Para ayudar a evitar un único punto de error, puede configurar puertas de enlace de datos locales como clústeres para alta disponibilidad. De forma predeterminada, los servicios en la nube como Power Apps y Power BI usan la puerta de enlace principal y recurren a la puerta de enlace secundaria si la primaria no está disponible.

Al instalar la puerta de enlace, proporcione la clave de recuperación. Puede usar la clave de recuperación para restaurar o migrar una puerta de enlace.

La clave proporciona una forma de agregar una nueva puerta de enlace a un clúster o de migrar, recuperar o tomar el control de una puerta de enlace.

Solucionar problemas

Para más información, vaya a Solucionar problemas de la puerta de enlace de datos local.

Vaya a Herramientas para la solución de problemas.

Puede habilitar el seguimiento de consultas activando registro adicional. Los registros incluyen las consultas que se envían. Recuerde desactivar el seguimiento de consultas cuando haya terminado la resolución de problemas. Tener habilitado el seguimiento de consultas hace que los registros sean mayores.

También puede consultar las herramientas del origen de datos para el seguimiento de las consultas. Por ejemplo, si SQL Server y SQL Server Analysis Services son orígenes de datos, puede usar Eventos extendidos de SQL Server o SQL Server Profiler para rastrear consultas.

Los usuarios están limitados a 1 000 orígenes de datos por usuario.

Si ha alcanzado el número máximo de orígenes de datos, compruebe que el número de orígenes de datos por usuario no ha superado el límite. Para resolver cualquier problema relacionado, puede quitar manualmente los orígenes de datos del centro de administración o, como alternativa, usar el siguiente script de PowerShell de puerta de enlace para buscar y eliminar de forma masiva los orígenes de datos que superen el límite.

## https://learn.microsoft.com/powershell/module/datagateway/?view=datagateway-ps
## PowerShell version of '7.0.0' to run
## required module "DataGateway" Install-Module -Name DataGateway and sign in the same user who exceeded the 1000 limit
Connect-DataGatewayServiceAccount

## get the gateway information per the sign in person
$gatewayClusters = Get-DataGatewayCluster | where-Object {$_.Type -EQ 'Personal'}; 
foreach ($gw in $gatewayClusters)
{
  $datasources = Get-DataGatewayClusterDatasource -GatewayClusterId $gw.Id;
  foreach ($datasource in $datasources)
  {
    $datasource
    "gateway cluster id={0}, Personal Gateway={1}, datasource id={2}, datasourceType={3}, datasource connection details={4}" -f $gw.Id, $datasource.OnPremGatewayRequired, $datasource.Id, $datasource.DatasourceType, $datasource.ConnectionDetails 
   
    ## conditional logic to determine if name matches set
    ## Remove-DataGatewayClusterDatasource -GatewayClusterId $gw.Id -GatewayClusterDatasourceId $datasource.Id
  }
}

¿Cómo puedo evitar alcanzar este límite? Si es un ISV o cualquier otro propietario de aplicaciones de Power BI Embedded con muchos clientes, use perfiles de entidad de servicio para aplicaciones multiinquilino en Power BI Embedded. Si no es un ISV, puede llegar a este límite porque está creando un nuevo origen de datos para cada archivo CSV o Excel. Para solucionar este problema, es posible que quiera usar el cuadro "Cargar archivo" en Power BI Desktop para seleccionar varios archivos de Excel, lo que crea varias conexiones de origen de datos. En este escenario, para asegurarse de que solo se selecciona un único origen de datos, se recomienda seleccionar la carpeta que contiene esos archivos de Excel en su lugar.

Sí, al administrar una puerta de enlace, puede ir a la pestaña del administrador para agregar más administradores. También puede tener grupos de seguridad como administradores.

No, el administrador de la puerta de enlace la administra desde el servicio.

Si el proceso de migración falla en el nuevo servidor, la puerta de enlace de datos local todavía existe en el servidor anterior y aún puede ejecutar esa puerta de enlace a menos que el servidor esté desconectado o el software de la puerta de enlace se haya desinstalado. Sin embargo, para restaurar la puerta de enlace en el servidor anterior, es posible que se le pida usar la clave de recuperación de su puerta de enlace.

Dado que la migración incluye solo dos tareas, la instalación de la puerta de enlace y la restauración y configuración en el nuevo servidor, la migración generalmente se puede completar en diez a quince minutos.

Sí. Sin embargo, existe una buena probabilidad de que se produzcan errores durante este tiempo y las migraciones como estas deben realizarse en un período de tiempo de inactividad. Más información: Minimice el tiempo de inactividad de la migración

• Si se cancela una actualización de OAuth que tarda más de una hora con el error "Credenciales de conexión no válidas" o se agota el tiempo de espera, es probable que la credencial haya caducado.

Pasos siguientes

• Solución de problemas con la puerta de enlace de datos local