Perguntas frequentes sobre o gateway de dados de rede virtual (rede virtual)

Damos suporte ao GCC L4 (Texas e Virgínia) e L5 (DoD East). No momento, não há suporte para esse recurso não com o GCC L2.

Os clientes não devem remover a atribuição de RP no nível da assinatura até pelo menos três horas após a exclusão de um gateway, pois ainda precisamos limpar os recursos.

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.

Damos suporte a nuvens em air gapping em EUA Nat East/West e US Sec East.

Use links privados para proteger essa conectividade. Mais Informações: Documentação de links privados do Power BI

O gateway de dados de rede virtual está fisicamente na mesma região que sua rede virtual do Azure. No entanto, os metadados (nome, detalhes, fontes de dados, credenciais criptografadas e assim por diante) de todos os gateways de dados de rede virtual são armazenados na região padrão do seu locatário. Você pode gerenciar todos os gateways de dados de rede virtual ao selecionar a região inicial de seu locatário no Centro de administração do Power Platform.

Sim. Você pode usar um gateway de dados de rede virtual e suas políticas de acesso condicional ainda se aplicam.

Uma lista completa de serviços de dados com suporte:

• Para o Power BI está disponível em Serviços de dados do Azure com suporte
• Os fluxos de dados do Power Platform estão disponíveis em Fontes de dados com suporte

Os gateways de dados de rede virtual são um recurso somente premium e estão disponíveis apenas nas capacidades Fabric (qualquer SKU) e Power BI Premium (SKU A4 ou superior ou qualquer SKU P).

Yes

Consulte a documentação da rede virtual do Azure para ver se há restrições (por exemplo, relacionadas à região) em VNets, pontos de extremidade e recursos associados do Azure.

Examine a documentação do produto de serviço de dados do Azure correspondente para verificar se há suporte para pontos de extremidade privados e como habilitá-los.

Se você estiver recebendo erros como Authorization failed for Public API route ou DM_GWPipeline_Client_OAuthTokenLoginFailedError ao tentar criar uma conexão de Gateway de Dados de rede virtual com autenticação OAuth para um recurso do Azure com um firewall bloqueando o acesso público à Internet e configurado com pontos de extremidade privados, isso significa que você precisa criar explicitamente um ponto de extremidade de serviço para autenticação privada chamando o serviço Microsoft Entra ID. Para resolver essa situação, acesse a sub-rede da rede virtual usada para o Gateway de Dados da rede virtual e habilite o ponto de extremidade de serviço Microsoft.AzureActiveDirectory, conforme mostrado abaixo.

Sim, não há dependência da região de origem do Power BI para esse recurso. Se esse recurso estiver habilitado na região em que a rede virtual existe, você poderá criar um gateway de dados de rede virtual.

Não. O gateway de dados de rede virtual está fisicamente na mesma região que sua rede virtual do Azure. Atualmente, você também não pode escolher onde os metadados (nome, detalhes, fontes de dados, credenciais criptografadas e assim por diante) de todos os seus gateways de dados de rede virtual são armazenados. Esses dados estão armazenados na região padrão do seu locatário.

Não. O gateway de dados de rede virtual deve ser criado no mesmo locatário que o locatário do Power BI.

Não, os gateways de rede virtual estão atualmente disponíveis apenas na região de origem do seu locatário.

Algumas áreas a serem verificadas:

• Verifique se a fonte de dados está em funcionamento.
• Certifique-se de que a fonte de dados possa ser acessada de dentro da rede virtual, especificamente da sub-rede delegada ao criar o gateway de dados de rede virtual. Por exemplo, você pode implantar uma VM na sub-rede e verificar se pode se conectar à fonte de dados.
• Os seguintes Grupos de Segurança de Rede (NSGs) do Azure podem ser necessários, dependendo do seu cenário:
  • Permita o tráfego de saída para o ponto de extremidade do Microsoft Entra ID usando OAuth ou autenticação da entidade de serviço para se conectar a uma fonte de dados.
  • Permita o tráfego de saída para AC (autoridade de certificação) ao usar HTTPS para se conectar a uma fonte de dados.

A conectividade entre o novo serviço de rede virtual e sua rede virtual é via HTTPS e TLS 1.2.

Para SQL sem servidor com pausa automática, a primeira solicitação poderá falhar se o SQL estiver em um estado de pausa, mas as próximas serão bem-sucedidas.

Quando usado pela primeira vez, o gateway de rede virtual leva cerca de 2 minutos para ser configurado. Da mesma forma, se o gateway de dados de rede virtual não for usado por 30 minutos, você poderá ter um atraso de cerca de um minuto na próxima vez que usá-lo.

Não, somente há suporte para nuvens comerciais na versão de visualização pública.

Não. O gateway de dados VNET fornece computação totalmente gerenciada. Você pode optar por dimensionar o número de nós em cada cluster.

Yes

Verifique se há outros gateways usando a mesma rede virtual e sub-rede. Para poder excluir, levaria de 48 a 72 horas depois que o último gateway usando essa rede virtual e sub-rede fosse removido.

Além dos cinco IPs reservados, nossa recomendação é ter aproximadamente de 5 a 7 IPs a mais para que você possa adicionar mais gateways de rede virtual à mesma rede virtual e sub-rede.

Certifique-se de que você esteja explicitamente em uma função com a permissão Microsoft.Network/virtualNetworks/subnets/join/action na rede virtual, como a função Colaborador de Rede do Azure. Essa permissão é necessária para criar um gateway de dados de rede virtual.

Como a segurança se compara à do gateway de dados local? Sim, todos os dados que passam por um gateway de dados de rede virtual permanecem no backbone do Azure. Usamos um túnel interno da Microsoft que não chega à Internet pública entre a rede virtual e o serviço do Power BI. Por outro lado, o gateway de dados local abre uma conexão para usar a Retransmissão do Azure para se conectar ao serviço do Power BI.

Considerando os vários recursos: assinatura, provedor de recursos Microsoft.PowerPlatform, rede virtual, sub-rede e locatário de origem do serviço do Power BI. Caso esteja usando um ponto de extremidade de serviço, a rede virtual e a sub-rede devem estar na mesma região que os dados aos quais você está se conectando. Se você estiver usando um ponto de extremidade privado, eles poderão estar em regiões diferentes. A configuração do gateway de dados reside na região do locatário de origem do Power BI.

Um gateway de rede virtual geralmente pode acessar fontes que podem ser acessadas dentro dessa mesma rede virtual. Se houver outra rede virtual que esteja isolada da primeira, será necessário outro gateway de rede virtual.

• O intervalo de IPs da sub-rede da rede virtual não pode se sobrepor a 10.0.1.x.
• Você não pode delegar uma sub-rede chamada gatewaysubnet ao Centro de administração do Power Platform. Essa restrição ocorre porque é uma palavra reservada para o recurso de Sub-rede do Gateway do Azure.
• Você não pode alterar a região, a assinatura ou o grupo de recursos da rede virtual na qual o gateway de dados da rede virtual foi criado. Não há suporte para este cenário no momento.
• Se uma atualização do OAuth que demorar mais que uma hora for cancelada com o erro "Credenciais de Conexão Inválidas" ou tempo limite atingido, o problema poderá ser que a credencial expirou.

Os usuários são limitados a 1.000 fontes de dados em cada gateway de VNET. Se você atingir o limite máximo de fontes de dados, verifique se o número de fontes de dados para cada gateway de VNET não está acima do limite de 1000. Para resolver quaisquer problemas relacionados, você pode remover manualmente as fontes de dados do centro de administração ou, como alternativa, usar o script do PowerShell a seguir para excluir em massa todas as fontes de dados usando um gateway de VNET especificado que exceda esse limite. Você precisaria substituir o texto "GatewayClusterID" pela ID de gateway da VNET específica para que esse script funcione.

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