Gateway de dados local: guia de instalação e configuração

O gateway de dados local é a ponte entre o serviço do Power BI (nuvem) e suas fontes de dados locais. Sem ele, quaisquer dados que estejam atrás do firewall corporativo --- bancos de dados SQL Server, instâncias PostgreSQL, sistemas Oracle, compartilhamentos de arquivos, fontes ODBC --- não poderão ser atualizados no Serviço Power BI. O gateway também é necessário para conexões em tempo real/DirectQuery da nuvem para bancos de dados locais.

Apesar do seu papel crítico, o gateway é muitas vezes tratado como algo secundário. As organizações o instalam no laptop de um desenvolvedor, ignoram a configuração de alta disponibilidade e se perguntam por que as atualizações programadas falham todo fim de semana. Este guia abrange todo o ciclo de vida: decisões de arquitetura, instalação, clustering, configuração de fonte de dados, monitoramento, ajuste de desempenho e solução de problemas dos erros mais comuns.

---

Principais conclusões

• O gateway de dados local vem em dois modos: pessoal (usuário único, sem compartilhamento) e padrão/empresarial (compartilhado em toda a organização, suporta clustering)
• Os gateways corporativos devem sempre ser instalados em um servidor dedicado (nunca em uma estação de trabalho de desenvolvedor) com energia, rede e tempo de atividade confiáveis
• Clustering de gateway com dois ou mais nós fornece alta disponibilidade --- se um nó ficar inativo, o outro continuará processando solicitações de atualização
• Toda a comunicação é de saída do gateway para o Barramento de Serviço do Azure --- nenhuma porta de firewall de entrada precisa ser aberta
• As credenciais da fonte de dados são criptografadas localmente na máquina gateway usando a chave de recuperação --- perder essa chave significa reconfigurar todas as fontes de dados
• Os logs do gateway são o recurso de solução de problemas mais útil, localizado na pasta GatewayComponents nos dados do aplicativo local do usuário
• O desempenho pode ser melhorado habilitando o pool de conexões para fontes relacionais, definindo valores de tempo limite apropriados e garantindo que a máquina gateway tenha RAM e CPU adequadas

---

Arquitetura de gateway

Como funciona o gateway

O gateway estabelece uma ligação de saída ao Azure Service Bus utilizando a porta TCP 443 (HTTPS). Nenhuma porta de entrada precisa ser aberta em seu firewall. O fluxo de comunicação é:

1. Um usuário abre um relatório do Power BI no serviço ou uma atualização agendada aciona
2. O serviço Power BI envia uma solicitação de consulta ao Barramento de Serviço do Azure
3. O gateway (pesquisa do Barramento de Serviço do Azure) coleta a solicitação
4. O gateway executa a consulta na fonte de dados local
5. O gateway criptografa os resultados e os envia de volta por meio do Azure Service Bus
6. O serviço Power BI recebe os resultados e renderiza o relatório ou conclui a atualização

Esta arquitetura significa que o gateway nunca recebe conexões de entrada da Internet. Ele inicia todas as comunicações de saída, o que simplifica significativamente a configuração do firewall.

Gateway pessoal versus gateway padrão (empresarial)

Para qualquer implantação de produção, use o gateway padrão (empresarial). O gateway pessoal é adequado apenas para usuários individuais que criam protótipos com suas próprias fontes de dados.

---

Instalação

Pré-requisitos

Antes de instalar o gateway, certifique-se de que a máquina de destino atenda a estes requisitos:

Crítico: Não instale o gateway no mesmo servidor que seu banco de dados. O gateway compete por CPU e RAM durante as operações de atualização, e colocá-lo no banco de dados pode degradar o desempenho do gateway e do banco de dados.

Etapas de instalação

1. Baixe o instalador de gateway mais recente na página oficial de download da Microsoft
2. Execute o instalador e selecione "Gateway de dados local (recomendado)" para o modo empresarial
3. Aceite os termos da licença e escolha o diretório de instalação
4. Entre com sua conta organizacional (a conta deve estar no mesmo locatário do Azure AD que seu serviço do Power BI)
5. Selecione "Registrar um novo gateway neste computador"
6. Nomeie o gateway (use um nome descritivo: por exemplo, "PROD-GW-NY-01" para gateway de produção, Nova York, nó 1)
7. Defina a chave de recuperação --- armazene-a com segurança em um gerenciador de senhas ou cofre de chaves. Você precisará dele para adicionar nós de cluster ou recuperar o gateway
8. Conclua a instalação

O serviço de gateway é iniciado automaticamente e executado na conta "NT SERVICE\PBIEgwService" por padrão.

Alterando a conta de serviço

Por padrão, o gateway é executado como uma conta de serviço local. Para acessar recursos de rede (compartilhamentos de arquivos, bancos de dados associados a domínios com autenticação do Windows), pode ser necessário alterar a conta de serviço para uma conta de domínio:

1. Abra os Serviços do Windows (services.msc)
2. Encontre "Serviço de gateway de dados local"
3. Clique com o botão direito, selecione Propriedades e, em seguida, a guia Logon
4. Selecione "Esta conta" e insira as credenciais do domínio
5. Reinicie o serviço

Conceda à conta de serviço o seguinte:

• Política local "Logon como serviço"
• Acesso de leitura às fontes de dados que precisa consultar
• Acesso de rede a servidores de fonte de dados

---

Clustering de gateway para alta disponibilidade

Um único gateway é um ponto único de falha. Se a máquina falhar, todas as atualizações agendadas e conexões DirectQuery falharão. O clustering de gateway resolve isso distribuindo solicitações entre vários nós.

Criando um Cluster

1. Instale o gateway em uma segunda máquina seguindo as mesmas etapas de instalação
2. Durante a etapa "Registrar um novo gateway", selecione "Adicionar a um cluster de gateway existente"
3. Selecione o nome do gateway existente no menu suspenso
4. Insira a chave de recuperação (a mesma chave usada para o primeiro nó)
5. Conclua a instalação

O cluster agora tem dois nós. As solicitações são distribuídas entre nós íntegros.

Configuração de balanceamento de carga

Por padrão, os clusters de gateway distribuem solicitações aleatoriamente. Você pode configurar o balanceamento de carga:

Round-robin: Distribui solicitações uniformemente em todos os nós. Melhor para clusters com hardware idêntico.

Roteamento ponderado: direciona mais solicitações para nós mais poderosos. Configure no portal de administração do Power BI nas configurações do gateway.

Somente failover: todas as solicitações vão para o nó primário. Os nós secundários só serão ativados se o primário estiver indisponível. Melhor para implantações econômicas com um servidor em espera.

Topologia de cluster recomendada

Para implantações de produção, ECOSIRE recomenda um mínimo de dois nós de gateway:

Escalone as janelas de manutenção para que ambos os nós nunca fiquem inativos simultaneamente. As atualizações do Windows, os patches do .NET e as atualizações de versão do gateway devem ser aplicadas a um nó por vez.

---

Configuração da fonte de dados

Adicionando uma fonte de dados

Depois de instalar o gateway, configure as fontes de dados no serviço Power BI:

1. Vá para Configurações (ícone de engrenagem) e Gerenciar Gateways
2. Selecione seu cluster de gateway
3. Clique em "Adicionar fonte de dados"
4. Escolha o tipo de fonte de dados (SQL Server, PostgreSQL, Oracle, ODBC, etc.)
5. Insira os detalhes da conexão (nome do servidor, nome do banco de dados)
6. Selecione o método de autenticação (Windows, Basic, OAuth2)
7. Insira as credenciais
8. Teste a conexão

Tipos de fontes de dados compatíveis

O gateway padrão oferece suporte a mais de 80 tipos de fontes de dados. O mais comum para Power BI:

Criptografia de credenciais

As credenciais da fonte de dados são criptografadas usando a chave de recuperação e armazenadas localmente na máquina gateway. Eles nunca são enviados para a nuvem em texto simples. Ao adicionar um nó de cluster, as credenciais são sincronizadas usando a chave de recuperação compartilhada.

Importante: se você perder a chave de recuperação e todos os nós do gateway falharem, você deverá:

1. Instale um novo gateway com uma nova chave de recuperação
2. Reconfigure todas as fontes de dados e credenciais
3. Remapeie todos os conjuntos de dados no serviço Power BI para o novo gateway

Armazene a chave de recuperação no Azure Key Vault ou no gerenciador de senhas da sua organização.

Pool de conexões

Para bancos de dados relacionais (SQL Server, PostgreSQL, Oracle), habilite o pool de conexões para reutilizar conexões de banco de dados em operações de atualização:

No arquivo de configuração do gateway (Microsoft.PowerBI.EnterpriseGateway.exe.config):

<setting name="PoolConnections" serializeAs="String">
    <value>True</value>
</setting>
<setting name="MinPoolSize" serializeAs="String">
    <value>2</value>
</setting>
<setting name="MaxPoolSize" serializeAs="String">
    <value>20</value>
</setting>

O pool de conexões reduz a sobrecarga de estabelecimento de novas conexões de banco de dados para cada consulta, especialmente durante cargas de trabalho do DirectQuery com muitos usuários simultâneos.

---

Configuração de atualização agendada

Configurando atualização agendada

Depois de publicar um conjunto de dados no serviço Power BI:

1. Vá para as configurações do conjunto de dados
2. Em "Conexão de gateway", selecione seu gateway e a fonte de dados configurada
3. Em "Atualização agendada", ative o botão de alternância
4. Defina a frequência de atualização (diária, semanal ou horários específicos)
5. Configure o fuso horário
6. Opcionalmente, configure notificações de falha

Atualizar limites de frequência

Atualizar o Windows e escalonar

Não agende todas as atualizações do conjunto de dados ao mesmo tempo. O gateway possui CPU e memória finitas, e atualizações simultâneas competem por recursos.

Prática recomendada: crie um cronograma de atualização que escalone os conjuntos de dados na janela disponível:

Os conjuntos de dados críticos são atualizados primeiro, garantindo que sejam concluídos mesmo que atualizações posteriores encontrem problemas.

Atualização incremental e o gateway

A atualização incremental reduz significativamente o volume de dados processados ​​através do gateway. Em vez de atualizar todo o conjunto de dados, apenas as linhas novas e alteradas são obtidas. Isto é especialmente importante para grandes conjuntos de dados onde a atualização completa levaria horas e consumiria recursos excessivos do gateway.

Configure a atualização incremental no Power BI Desktop (consulte a abordagem do parâmetro RangeStart/RangeEnd) e publique no Serviço. O gateway trata as consultas parametrizadas automaticamente.

---

Configuração de firewall e proxy

Conexões de saída necessárias

O gateway requer acesso HTTPS de saída (TCP 443) para:

Se o seu firewall exigir listas de permissões de IP explícitas em vez de domínios curinga, use o arquivo JSON de intervalos de IP do Azure da Microsoft (atualizado semanalmente) para encontrar os intervalos de IP do Barramento de Serviço do Azure em sua região.

Configuração do servidor proxy

Se o gateway precisar rotear através de um proxy corporativo:

1. Edite Microsoft.PowerBI.EnterpriseGateway.exe.config
2. Adicione a configuração do proxy na seção <system.net>:

<system.net>
  <defaultProxy useDefaultCredentials="true">
    <proxy proxyaddress="http://proxy.company.com:8080"
           bypassonlocal="true" />
  </defaultProxy>
</system.net>

3. Reinicie o serviço de gateway

Se o proxy exigir credenciais específicas (não a autenticação de passagem do Windows), talvez seja necessário usar um arquivo PAC do proxy ou configurar o proxy para permitir a conta de serviço do gateway sem autenticação adicional.

Configuração TLS

O gateway requer TLS 1.2. Se o seu ambiente ainda tiver o TLS 1.0 ou 1.1 habilitado, o gateway usará o TLS 1.2 por padrão. No entanto, se o servidor de origem de dados suportar apenas TLS 1.0, a conexão falhará.

Verifique se o TLS 1.2 está habilitado no registro do Windows:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Client
  Enabled = 1 (DWORD)
  DisabledByDefault = 0 (DWORD)

---

Monitoramento e registro

Registros de gateway

O gateway grava logs detalhados em:

C:\Users\<ServiceAccount>\AppData\Local\Microsoft\On-premises data gateway\

Arquivos de registro principais:

Habilitando registro adicional

Para solução de problemas, habilite o registro detalhado:

1. Abra o aplicativo de configuração do gateway
2. Vá para Diagnóstico
3. Ative "Registro adicional"
4. Reproduza o problema
5. Exporte os logs usando o botão "Exportar logs" (cria um ZIP de todos os arquivos de log)
6. Desative o registro adicional após a solução de problemas (isso gera grandes volumes de registro)

Contadores de desempenho

O gateway expõe os contadores de desempenho do Windows na categoria "gateway de dados local":

Configure o Monitor de Desempenho do Windows ou uma ferramenta de monitoramento (Prometheus, Datadog, Azure Monitor) para rastrear esses contadores e alertar sobre limites.

Monitoramento do Portal de Administração do Power BI

No portal de administração do Power BI:

1. Vá para Admin Portal e, em seguida, Gateway Management
2. Visualize todos os gateways, seu status (online/offline) e versão
3. Veja estatísticas de uso de fontes de dados
4. Monitore as taxas de sucesso/falha de atualização

Configure notificações por e-mail para eventos offline do gateway e falhas de atualização.

---

Ajuste de desempenho

Dimensionamento correto de hardware

O desempenho do gateway é principalmente limitado por:

1. CPU — para análise de consulta, compactação de dados e criptografia
2. RAM — para armazenar resultados de consultas intermediárias
3. Rede — para transferência de dados para o Azure Service Bus

Diretrizes de tamanho:

Configurações do mecanismo de mashup

O gateway usa o mecanismo Power Query (Mashup) para transformação de dados. Configure no aplicativo gateway:

Máximo de consultas simultâneas: O padrão é o número de núcleos de CPU vezes 2. Aumento para cargas de trabalho vinculadas a E/S (aguardando fontes de dados lentas). Diminuição para cargas de trabalho vinculadas à CPU (transformações pesadas).

Limite de memória por consulta: O padrão é sem limite. Defina um limite (por exemplo, 2 GB) para evitar que uma única consulta descontrolada consuma toda a RAM disponível.

Otimização de rede

Localize o gateway próximo à fonte de dados. A latência da rede entre o gateway e a fonte de dados é multiplicada pelo número de consultas por atualização. Um gateway no mesmo data center que o banco de dados minimiza a latência.

Não localize o gateway com base na proximidade do Azure. A conexão do Barramento de Serviço do Azure é uma única conexão TCP persistente. A latência para o Azure afeta a configuração inicial da ligação, mas não a produção de consultas.

Use uma conexão com fio. Nunca execute um gateway de produção em Wi-Fi. A conectividade intermitente causa falhas de atualização.

Otimização de consulta na origem

A maneira mais rápida de melhorar o desempenho do gateway é otimizar as consultas que ele executa:

• Use consultas SQL personalizadas em vez de importar tabelas inteiras (reduza o volume de dados)
• Criar índices de banco de dados em colunas usadas em cláusulas WHERE e JOINs
• Use visualizações com pré-junções e pré-agregações para modelos de dados complexos
• Habilite a dobragem de consultas no Power Query para enviar transformações para o banco de dados
• Implementar atualização incremental para reduzir o volume de dados por ciclo de atualização

---

Solução de erros comuns

"O gateway não está acessível"

Causa: O serviço de gateway está parado, a máquina está inoperante ou a conectividade de rede com o Azure está bloqueada.

Resolução:

1. Verifique se o serviço gateway do Windows está em execução (services.msc)
2. Verifique se o HTTPS de saída para *.servicebus.windows.net é permitido
3. Verifique as configurações de proxy se estiver atrás de um proxy corporativo
4. Verifique se a máquina gateway tem conectividade com a Internet
5. Verifique se a versão do gateway está desatualizada (as atualizações automáticas podem falhar silenciosamente)

"Não foi possível conectar-se à fonte de dados"

Causa: Credenciais incorretas, conectividade de rede com a fonte de dados ou problemas de driver.

Resolução:

1. Teste a conexão no aplicativo de configuração do gateway (Diagnóstico e, em seguida, Testar Conexão)
2. Verifique se o servidor da fonte de dados pode ser acessado pela máquina gateway (ping, telnet para porta)
3. Verifique se as credenciais estão corretas e se a conta não está bloqueada/expirada
4. Para Oracle e SAP, verifique se as bibliotecas de cliente necessárias estão instaladas na máquina gateway
5. Verifique se o firewall da fonte de dados permite conexões do IP do gateway

"A atualização do gateway de dados local está demorando muito"

Causa: Conjunto de dados grande, consultas lentas, recursos de gateway insuficientes ou gargalo de rede.

Resolução:

1. Habilite a atualização incremental para reduzir o volume de dados
2. Otimize consultas SQL (adicione índices, reduza colunas, filtre linhas)
3. Verifique o uso de CPU e RAM da máquina gateway durante a atualização
4. Escalone as programações de atualização para reduzir a carga simultânea
5. Considere adicionar um segundo nó de gateway para distribuição de carga

"As credenciais da fonte de dados são inválidas"

Causa: Senha alterada, conta bloqueada ou delegação Kerberos configurada incorretamente.

Resolução:

1. Insira novamente as credenciais no serviço Power BI (configurações do conjunto de dados e, em seguida, conexão do gateway)
2. Se estiver usando a autenticação do Windows com Kerberos, verifique:

• A conta de serviço de gateway tem privilégios de delegação no Active Directory
• Os SPNs estão configurados corretamente para a fonte de dados
• O KDC (controlador de domínio) é acessível a partir do gateway

"A versão do gateway está desatualizada"

Causa: A atualização automática falhou ou foi desativada.

Resolução:

1. Baixe o instalador de gateway mais recente da Microsoft
2. Execute o instalador na máquina gateway existente (ele é atualizado no local)
3. Para clusters, atualize um nó por vez com um intervalo entre as atualizações
4. Verifique a versão do gateway no portal de administração do Power BI após a atualização

---

Melhores práticas de segurança

Princípio do Menor Privilégio

• A conta de serviço de gateway deve ter acesso somente leitura às fontes de dados
• Não use contas de administrador de domínio ou de administrador de banco de dados
• Crie contas de serviço dedicadas por tipo de fonte de dados se sua política de segurança exigir
• Alterne as senhas das contas de serviço regularmente e atualize a configuração da fonte de dados do gateway

Gerenciamento de chave de recuperação

A chave de recuperação criptografa todas as credenciais armazenadas localmente. Trate-a com o mesmo cuidado que uma chave mestra de banco de dados:

• Armazene no Azure Key Vault ou em um gerenciador de senhas corporativo
• Documente quem tem acesso à chave de recuperação
• Incluir a rotação de chaves de recuperação na sua política de gerenciamento de chaves
• Teste a recuperação restaurando um gateway do backup com a chave de recuperação

Segmentação de rede

Coloque o gateway em um segmento de rede que possa alcançar:

• Servidores de fontes de dados (SQL Server, PostgreSQL, Oracle, etc.)
• Barramento de Serviço do Azure (HTTPS de saída)
• Azure AD (HTTPS de saída)

Bloqueie todo o outro tráfego de entrada e saída. O gateway não precisa de conexões de entrada de nenhuma origem.

Trilha de auditoria

Habilite a auditoria de segurança do Windows na máquina gateway para rastrear:

• Eventos de logon da conta de serviço
• Alterações na configuração do gateway
• Padrões de acesso à fonte de dados

Encaminhe esses eventos para o seu SIEM (Splunk, Sentinel, Datadog) para monitoramento centralizado.

---

Cenários de migração e atualização

Migrando para uma nova máquina gateway

1. Instale o gateway na nova máquina
2. Durante o registro, selecione "Migrar, restaurar ou assumir o controle de um gateway existente"
3. Insira a chave de recuperação do gateway original
4. A nova máquina herda todas as configurações e credenciais da fonte de dados
5. Verifique se todas as fontes de dados aparecem como conectadas no portal de administração do Power BI
6. Atualize quaisquer regras de firewall baseadas em IP para incluir o IP da nova máquina
7. Desative a máquina de gateway antiga

Atualizando Versões do Gateway

A Microsoft lança atualizações de gateway mensalmente. Melhores práticas:

• Assine as notas de versão do gateway para aviso prévio de alterações
• Teste primeiro novas versões em um cluster de gateway que não seja de produção
• Para clusters de produção, atualize um nó por vez com um intervalo de 24 horas
• Verifique as taxas de sucesso de atualização após cada atualização de nó
• Manter pelo menos um nó na versão anterior até que a nova versão seja validada

O gateway suporta compatibilidade de versão N-1 em clusters --- os nós não precisam executar exatamente a mesma versão.

---

Perguntas frequentes

Posso instalar o gateway em uma máquina virtual?

Sim. O gateway é executado em máquinas físicas e virtuais, incluindo VMs do Azure, AWS EC2 e Hyper-V ou VMware local. Para VMs do Azure, considere usar o gateway de dados VNet (em versão prévia para capacidades Premium), que elimina totalmente a necessidade de um gateway autogerenciado. Para VMs locais, certifique-se de que a VM tenha recursos de CPU e RAM dedicados (não compartilhados) e que o hipervisor não sobrecarregue recursos de forma agressiva.

Quantas fontes de dados um único gateway pode suportar?

Não há limite rígido para o número de fontes de dados por gateway. Na prática, os gateways normalmente suportam de 50 a 100 fontes de dados sem problemas. O fator limitante é a carga de consulta simultânea durante as janelas de atualização, e não o número de fontes de dados configuradas. Se os tempos de atualização forem degradantes, adicione nós de cluster em vez de criar instalações de gateway adicionais.

O gateway suporta Linux?

Não. O gateway de dados local requer Windows (Server 2016 ou posterior). Se suas origens de dados forem executadas no Linux, instale o gateway em uma máquina Windows que tenha acesso de rede aos servidores de origem de dados Linux. O gateway se conecta à fonte de dados pela rede – ele não precisa ser executado no mesmo sistema operacional que a fonte de dados.

O que acontece se ambos os nós de gateway em um cluster ficarem off-line simultaneamente?

Todas as atualizações agendadas falham e todas as conexões do DirectQuery retornam erros. O serviço do Power BI detecta o status offline e envia notificações aos administradores do gateway (se configurado). Os relatórios que usam dados armazenados em cache (modo de importação) continuam exibindo os últimos dados atualizados com êxito. Quando pelo menos um nó fica online novamente, as solicitações de atualização pendentes são processadas automaticamente. Para evitar esse cenário, escalone as janelas de manutenção e coloque os nós do cluster em infraestrutura física separada.

O gateway pode lidar com dados de streaming em tempo real?

O gateway foi projetado para padrões de resposta a consultas, não para streaming. Para dados em tempo real, considere conjuntos de dados de streaming do Power BI (que ignoram totalmente o gateway), Azure Stream Analytics ou Azure Event Hubs com painéis em tempo real do Power BI. O gateway oferece suporte ao DirectQuery para acesso quase em tempo real a bancos de dados locais, mas cada interação de relatório aciona uma nova consulta em vez de receber um fluxo contínuo de dados.