Vanliga frågor och svar om virtuellt nätverk (virtuellt nätverk) för datagateway

Vi stöder GCC L4 (Texas och Virginia) och L5 (DoD East). Den här funktionen stöds för närvarande inte i GCC L2.

Kunder bör inte ta bort RP-tilldelningen på prenumerationsnivå förrän minst tre timmar efter borttagningen av en gateway eftersom vi fortfarande behöver rensa resurser.

När du använder OAuth2-autentiseringsuppgifter i Dataflöden Gen1 stöder gatewayen inte uppdatering av token automatiskt när åtkomsttoken upphör att gälla. Token upphör vanligtvis att gälla 1 timme efter att uppdateringen startar, men kan upphöra att gälla på mindre än 1 timme, beroende på datakällan och klientprinciperna. Dataflöden gen2, semantiska modeller, datapipelines kan uppdatera token mitt i strömmen och bör inte påverkas på grund av detta.

Vi stöder luftgapade moln i USA, östra/västra och USA, östra/västra.

Använd privata länkar för att skydda den här anslutningen. Mer information: Dokumentation om Privata Länkar i Power BI

Den virtuella nätverksdatagatewayen finns fysiskt i samma region som ditt virtuella Azure-nätverk. Metadata (namn, information, datakällor, krypterade autentiseringsuppgifter och så vidare) för alla dina virtuella nätverksdatagatewayer lagras dock i klientorganisationens standardregion. Du kan hantera alla virtuella nätverksdatagatewayer när du väljer din klients hemregion i administrationscentret för Power Platform.

Ja. Du kan använda en datagateway för virtuella nätverk och dina principer för villkorlig åtkomst gäller fortfarande.

En fullständig lista över datatjänster som stöds:

• För Power BI är tillgängligt i Azure-datatjänster som stöds
• För Power Platform är dataflöden tillgängliga i datakällor som stöds

Datagatewayer för virtuella nätverk är en premiumfunktion och är endast tillgängliga i Infrastrukturresurser (alla SKU: er) och Power BI Premium-kapaciteter (A4 SKU eller högre eller någon P SKU).

Ja

I dokumentationen för virtuella Azure-nätverk finns begränsningar (till exempel regionrelaterade) för virtuella nätverk, slutpunkter och associerade Azure-resurser.

Granska motsvarande produktdokumentation för Azure-datatjänsten för att kontrollera om privata slutpunkter stöds och om hur du aktiverar dem.

Om du får fel som eller Authorization failed for Public API route när du försöker skapa en datagatewayanslutning för ett virtuellt nätverk med OAuth-autentisering mot en Azure-resurs med en brandvägg som DM_GWPipeline_Client_OAuthTokenLoginFailedError blockerar offentlig Internetåtkomst och konfigureras med privata slutpunkter, innebär det att du uttryckligen måste skapa en tjänstslutpunkt för privat autentisering genom att anropa Microsoft Entra ID-tjänsten. Lös den här situationen genom att gå till det virtuella nätverksundernätet som används för det virtuella nätverket Data Gateway och aktivera tjänstslutpunkten Microsoft.AzureActiveDirectory enligt beskrivningen nedan.

Ja, det finns inget beroende av Power BI-hemregionen för den här funktionen. Om den här funktionen är aktiverad i den region där det virtuella nätverket finns kan du skapa en ny virtuell nätverksdatagateway.

Nej. Den virtuella nätverksdatagatewayen finns fysiskt i samma region som ditt virtuella Azure-nätverk. För närvarande kan du inte heller välja var metadata (namn, information, datakällor, krypterade autentiseringsuppgifter och så vidare) för alla dina virtuella nätverksdatagatewayer lagras. Dessa data lagras i din klientorganisations standardregion.

Nej. Den virtuella nätverksdatagatewayen måste skapas i samma klientorganisation som Power BI-klientorganisationen.

Nej, virtuella nätverksgatewayer är för närvarande endast tillgängliga i klientorganisationens hemregion.

Några områden att kontrollera:

• Kontrollera att datakällan är igång.
• Kontrollera att datakällan kan nås inifrån det virtuella nätverket , särskilt från undernätet som delegeras när du skapar den virtuella nätverksdatagatewayen. Du kan till exempel distribuera en virtuell dator i undernätet och kontrollera om du kan ansluta till datakällan.
• Följande Azure Network Security Groups (NSG:er) kan krävas beroende på ditt scenario:
  • Tillåt utgående trafik till Microsoft Entra ID-slutpunkten när du använder OAuth- eller Tjänsthuvudnamnsautentisering för att ansluta till en datakälla.
  • Tillåt utgående trafik till CA (certifikatutfärdare) när du använder HTTPS för att ansluta till en datakälla.

Anslutningen mellan den nya virtuella nätverkstjänsten och det virtuella nätverket sker via HTTPS och TLS 1.2.

För SQL serverlös med automatisk pausning kan den första begäran misslyckas om SQL är i pausat tillstånd, men de kommande kommer att lyckas.

När den används för första gången tar det cirka 2 minuter för den virtuella nätverksgatewayen att konfigureras. Om den virtuella nätverksdatagatewayen inte används på 30 minuter kan det uppstå en fördröjning på ungefär en minut nästa gång du använder den.

Nej, endast kommersiella moln stöds för den offentliga förhandsversionen.

Nej. VNET-datagatewayen tillhandahåller fullständigt hanterad beräkning. Du kan välja att skala antalet noder i varje kluster.

Ja

Kontrollera om det finns andra gatewayer som använder samma virtuella nätverk och undernät. För att kunna ta bort skulle det ta upp till 48 till 72 timmar efter att den senaste gatewayen med det här virtuella nätverket och undernätet togs bort.

Utöver de fem reserverade IP-adresserna rekommenderar vi att du har cirka 5–7 ip-adresser till så att du kan lägga till fler virtuella nätverksgatewayer i samma virtuella nätverk och undernät.

Kontrollera att du uttryckligen är i en roll med behörigheten Microsoft.Network/virtualNetworks/subnets/join/action i det virtuella nätverket, till exempel rollen Azure Network-deltagare. Den här behörigheten krävs för att skapa en virtuell nätverksdatagateway.

Hur skiljer sig säkerheten från den lokala datagatewayen? Ja, alla data som går via en virtuell nätverksdatagateway finns kvar på Azure-stamnätet. Vi använder en intern Microsoft-tunnel som inte når det offentliga internet mellan det virtuella nätverket och Power BI-tjänst. Å andra sidan öppnar den lokala datagatewayen en anslutning för att använda Azure Relay för att ansluta till Power BI-tjänst.

Överväg de olika resurserna: prenumeration, Microsoft.PowerPlatform-resursprovider, virtuellt nätverk, undernät och Power BI-tjänstens hemklientorganisation. Om du använder en tjänstslutpunkt bör det virtuella nätverket och undernätet finnas i samma region som de data som du ansluter till. Om du använder en privat slutpunkt kan de finnas i olika regioner. Konfigurationen av datagatewayen finns i power BI-hemklientregionen.

En virtuell nätverksgateway kan i allmänhet nå källor som kan nås inom samma virtuella nätverk. Om det finns ett annat virtuellt nätverk som är isolerat från det första, krävs en annan virtuell nätverksgateway.

• Det virtuella nätverkets IP-intervall kan inte överlappa med 10.0.1.x.
• Du kan inte delegera ett undernät som heter gatewaysubnet till administrationscentret för Power Platform. Den här begränsningen beror på att det är ett reserverat ord för funktionen Azure Gateway-undernät.
• Du kan inte ändra region, prenumeration eller resursgrupp för det virtuella nätverk där den virtuella nätverksdatagatewayen skapades. Det här scenariot stöds inte för närvarande.
• Om en OAuth-uppdatering som tar längre tid än en timme avbryts med felet "Ogiltiga anslutningsuppgifter" eller timeout är problemet troligtvis att autentiseringsuppgifterna har upphört att gälla.

Användare är begränsade till 1 000 datakällor på varje VNET-gateway. Om du når gränsen för maximalt antal datakällor kontrollerar du att antalet datakällor för varje VNET-gateway inte överskrider gränsen på 1 000. För att lösa eventuella relaterade problem kan du manuellt ta bort datakällorna från administrationscentret eller använda följande PowerShell-skript för att massradera alla datakällor med hjälp av en angiven VNET-gateway som överskrider den gränsen. Du skulle behöva ersätta texten "GatewayClusterID" med det specifika VNET-gateway-ID:t för att det här skriptet ska fungera.

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