Perguntas frequentes de gateway de dados no local

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

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

Revise 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 um aplicativo de cliente. O gateway só precisa se conectar ao servidor especificado.

Atualmente, a Microsoft dá suporte ativo apenas às últimas seis versões do gateway de dados local. Lançamos uma nova atualização mensal para gateways de dados locais.

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

Verifique se a conexão de rede tem boa taxa de transferência. 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 a fonte de dados local e os datacenters do Azure, use Azure ExpressRoute. Para ajudar a medir sua produtividade, você pode usar o Aplicativo de Teste de Velocidade do Azure.

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 a criptografia de credencial no Power BI, acesse 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 Gerenciador de Tarefas, na guia Serviços, o nome do serviço é "PBIEgwService". Por padrão, o serviço Windows usa "NT SERVICE\PBIEgwService" como o SSID (SID de Serviço).

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

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

Confira Habilitar conexões de saída do Azure.

Se você bloquear o tráfego de IP de saída, talvez seja necessário desbloquear a lista de IP do Datacenter do Azure. O gateway se comunica com a Retransmissão do Azure 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, confira 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, essa localização mais próxima 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 do Oeste dos EUA e você tem o SQL Server hospedado em uma máquina virtual do Azure, talvez você também queira sua VM do Azure na região Oeste dos EUA. Essa configuração minimizará a latência e evitará encargos de saída na VM do Azure.

Os resultados são enviados por meio da Retransmissão do Azure. Para obter mais informações, confira Arquitetura do gateway de dados local.

O gateway exige a conectividade com a fonte de dados. Portanto, se a fonte de dados não estiver acessível na sua rede de perímetro, talvez o gateway não tenha acesso.

Por exemplo, suponha que o seu computador do SQL Server não esteja na sua rede de perímetro. Suponha também que você não possa se conectar a esse computador na rede de perímetro. Se você colocar o gateway na 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 da 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, não há suporte para o acesso ao Microsoft Entra ID entre locatários. 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 do Microsoft Entra ID. 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 que não seja OAuth.

Sim, para obter mais informações, confira Forçar a comunicação HTTPS com a Retransmissão do Azure. A ativação desse recurso tem pouco efeito no desempenho.

Não, eles são produtos diferentes. Para obter mais informações sobre o Gateway de Gerenciamento de Dados, agora chamado de IR auto-hospedado, confira Criar e configurar um IR auto-hospedado.

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

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

Mais informações: Manter dados na região onde eles estão armazenados

Para ajudar a evitar um ponto único de falha, você pode configurar gateways de dados locais como clusters para alta disponibilidade. Por padrão, serviços de nuvem como o Power Apps e o Power BI usam o gateway primário e voltarão 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 de migrar, recuperar ou assumir o controle de um gateway.

Solução de problemas

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

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

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

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

Os usuários sã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 remover manualmente as fontes de dados do centro de administração ou, como alternativa:

• Use o script do PowerShell a seguir para encontrar seu gateway pessoal que exceda o limite e exclua em massa todas as fontes de dados que o usam.

## 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
  }
}

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

## 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
$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 evitar que esse limite seja alcançado? Se você for um ISV ou qualquer outro proprietário de aplicativo inserido do Power BI com muitos clientes, use perfis de entidade de serviço para aplicativos de vários locatários no Power BI inserido. Se você não for um ISV, poderá atingir esse limite porque estará criando uma nova fonte de dados para cada arquivo CSV ou Excel. Para resolver isso, talvez você queira usar a "caixa carregar 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, é possível acessar a guia do administrador para adicionar outros administradores. Também é possível ter grupos de segurança como administradores.

Não, o administrador do gateway gerencia o gateway pelo 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, talvez você precise usar a 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 haver falhas durante esse período, e migrações como essas devem ser feitas em uma janela de tempo de inatividade. Mais informações: Minimizar o tempo de inatividade da migração

Próximas etapas

• Solucionar problemas do gateway de dados local