FAQ do gateway de dados no local

Não, os serviços geralmente podem se conectar a fontes de dados na nuvem sem um gateway. No entanto, você pode precisar de um gateway de dados se suas fontes de dados estiverem protegidas por um firewall, exigirem uma VPN ou estiverem em redes virtuais.

Ao usar credenciais OAuth2 no Dataflows Gen1, o gateway não suporta a atualização automática de tokens quando os tokens de acesso expiram. Os tokens normalmente expiram 1 hora após o início da atualização, mas podem expirar em menos de 1 hora, dependendo da fonte de dados e das políticas do locatário. Fluxos de dados Gen2, modelos semânticos, pipelines de dados são capazes de atualizar tokens mid-stream e não devem ser afetados devido a isso.

Analise a seção de requisitos no artigo de instalação.

Não, o gateway se conecta à fonte de dados usando as informações de conexão fornecidas. Nesse sentido, considere o gateway como um aplicativo cliente. O gateway só precisa se conectar ao servidor especificado.

Atualmente, a Microsoft oferece suporte ativo apenas às últimas seis versões do gateway de dados local. Lançamos uma nova atualização para gateways de dados todos os meses.

Não há restrições de licenciamento para instalar e registrar um gateway.

Verifique se a sua ligação de rede tem um bom débito. Cada ambiente é diferente e a taxa de transferência depende da quantidade de dados enviados. Para garantir um nível mínimo de taxa de transferência entre sua fonte de dados local e os datacenters do Azure, use o Azure ExpressRoute. Para ajudar a medir sua taxa de transferência, você pode usar o aplicativo Azure Speed Test.

As credenciais inseridas para uma fonte de dados são criptografadas e armazenadas no serviço de nuvem do gateway. As credenciais são descriptografadas no gateway local. Para obter mais informações sobre criptografia de credenciais no Power BI, vá para o whitepaper de segurança do Power BI.

No computador local, no aplicativo Serviços, o serviço é chamado de "Serviço de gateway de dados local". No Gestor de Tarefas, no separador Serviços, o nome do serviço é "PBIEgwService". Por padrão, o serviço do Windows usa "NT SERVICE\PBIEgwService" como o SID de serviço (SSID).

Não, o serviço do Windows precisa de uma conta válida do Windows.

Não, o gateway usa conexões de saída para o Azure Relay.

Vá para Habilitar conexões de saída do Azure.

Se você bloquear o tráfego IP de saída, talvez seja necessário desbloquear a lista de IP do Datacenter do Azure. O gateway se comunica com o Azure Relay usando um endereço IP e um nome de domínio totalmente qualificado. A lista de IP do Datacenter do Azure é atualizada semanalmente. Para obter mais informações, vá para Habilitar conexões de saída do Azure.

Para evitar a latência da rede, instale o gateway o mais próximo possível da fonte de dados. Se você puder instalar o gateway na fonte de dados real, esse local mais próximo minimizará a latência.

Além disso, considere a proximidade com os datacenters do Azure. Por exemplo, se o seu serviço usa o datacenter Oeste dos EUA e você tem o SQL Server hospedado em uma máquina virtual do Azure, você também pode querer sua VM do Azure na região Oeste dos EUA. Essa configuração minimiza a latência e evita cobranças de saída na VM do Azure.

Os resultados são enviados através do Azure Relay. Para obter mais informações, vá para Arquitetura de gateway de dados local.

O gateway requer conectividade com a fonte de dados. Portanto, se a fonte de dados não estiver acessível em sua rede de perímetro, o gateway pode não ter acesso.

Por exemplo, suponha que seu computador SQL Server não esteja na rede de perímetro. Além disso, suponha que você não pode se conectar a esse computador a partir da rede de perímetro. Se você colocar o gateway em sua rede de perímetro, o gateway não poderá acessar o computador do SQL Server.

Sim.

Essa prioridade depende do Windows ou dos drivers de fonte de dados relevantes. Esse comportamento é configurável no Windows e em vários drivers, mas não está sob o controle do gateway.

Não, o acesso ao Microsoft Entra ID entre locatários não é suportado. Um modelo semântico do Power BI em um locatário não pode se conectar a fontes de dados de um locatário diferente usando uma conta de ID do Microsoft Entra. Essa limitação se aplica independentemente de a fonte de dados usar um gateway de dados local ou não. Para superar essa limitação, use um tipo de autenticação diferente de OAuth.

Sim, para obter mais informações, vá para Forçar comunicação HTTPS com o Azure Relay. Ativar esse recurso tem pouco efeito sobre o desempenho.

Não, são produtos diferentes. Para obter mais informações sobre o Data Management Gateway, que agora é chamado de Self-hosted Integration Runtime, vá para Criar e configurar um tempo de execução de integração auto-hospedado.

Sim, você deve usar o PowerShell para adicionar outros proprietários ao mesmo gateway. Esses usuários podem criar o gateway no portal do Azure. No entanto, eles devem se conectar ao portal e ao gateway usando o mesmo locatário.

N.º Um gateway ainda é necessário ao se conectar a fontes de dados locais.

Para obter mais informações: Mantenha os dados na região onde estão armazenados

Para ajudar a evitar um único ponto de falha, você pode configurar gateways de dados locais como clusters para alta disponibilidade. Por padrão, os serviços de nuvem, como Power Apps e Power BI, usam o gateway primário e voltam para o gateway secundário se o primário não estiver disponível.

Ao instalar o gateway, você fornece uma chave de recuperação. Você pode usar a chave para restaurar ou migrar um gateway.

A chave fornece uma maneira de adicionar um novo gateway a um cluster ou migrar, recuperar ou assumir um gateway.

Resolução de Problemas

Para obter mais informações, vá para Solucionar problemas do gateway de dados local.

Vá para Ferramentas de solução de problemas.

Você pode habilitar o rastreamento de consultas ativando o registro em log adicional. Os logs incluem as consultas enviadas. Lembre-se de desativar o rastreamento de consultas quando terminar a solução de problemas. Ter o rastreamento de consultas habilitado faz com que os logs sejam maiores.

Você também pode examinar as ferramentas da fonte de dados para rastrear consultas. Por exemplo, se o SQL Server e o SQL Server Analysis Services forem fontes de dados, você poderá usar os Eventos Estendidos do SQL Server ou o SQL Server Profiler para rastrear consultas.

Os usuários estão limitados a 1.000 fontes de dados em cada cluster de gateway pessoal ou empresarial.

Se você atingir o limite máximo de fontes de dados, verifique se o número de fontes de dados nesse cluster de gateway não está acima do limite. Para resolver quaisquer problemas relacionados, você pode manualmente remover as fontes de dados do centro de administração ou, alternativamente:

• Use o seguinte script do PowerShell para localizar seu gateway pessoal que excede o limite e exclua em massa todas as fontes de dados que o utilizam.

## https://zcusa.951200.xyz/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
  }
}

• Use o seguinte script do PowerShell para excluir em massa todas as fontes de dados usando um gateway corporativo específico:

## https://zcusa.951200.xyz/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
$datasources = Get-DataGatewayClusterDatasource -GatewayClusterId <GatewayClusterId>;
foreach ($datasource in $datasources)
{
  $datasource
  "datasource id={2}, datasourceType={3}, datasource connection details={4}" -f $datasource.Id, $datasource.DatasourceType, $datasource.ConnectionDetails
 
  ## conditional logic to determine if name matches set
  ## Remove-DataGatewayClusterDatasource -GatewayClusterId $gw.Id -GatewayClusterDatasourceId $datasource.Id
}

Como posso evitar atingir este limite? Se você for um ISV ou qualquer outro proprietário de aplicativo incorporado do Power BI com muitos clientes, use de perfis de entidade de serviço para aplicativos de multilocação no Power BI incorporado. Se você não for um ISV, poderá atingir esse limite porque está criando uma nova fonte de dados para cada arquivo CSV ou Excel. Para resolver isso, convém usar a "caixa de upload de arquivo" no Power BI Desktop para selecionar vários arquivos do Excel, o que cria várias conexões de fonte de dados. Nesse cenário, para garantir que apenas uma única fonte de dados seja selecionada, recomendamos que você selecione a pasta que contém esses arquivos do Excel.

Sim, quando você gerencia um gateway, você pode ir para a guia do administrador para adicionar mais administradores. Você também pode ter grupos de segurança como administradores.

Não, o administrador do gateway gerencia o gateway de dentro do serviço.

Se o processo de migração falhar no novo servidor, o gateway de dados local ainda existirá no servidor antigo. Você ainda pode executar esse gateway, a menos que o servidor esteja offline ou o software do gateway tenha sido desinstalado. No entanto, para restaurar o gateway no servidor antigo, você pode ser solicitado a usar sua chave de recuperação do gateway.

Como a migração inclui apenas duas tarefas, a instalação do gateway e a restauração e configuração no novo servidor, a migração geralmente pode ser concluída em 10 a 15 minutos.

Sim. No entanto, há uma boa chance de falhas durante esse período, e migrações como essas devem ser feitas em uma janela de tempo de inatividade. Para obter mais informações: Minimizar o tempo de inatividade da migração

Próximos passos

• Resolução de problemas do gateway de dados no local