Ofte stillede spørgsmål om datagateway for virtuelt netværk (virtuelt netværk)

Vi understøtter GCC L4 (Texas og Virginia) og L5 (DoD East). Denne funktion understøttes i øjeblikket ikke i GCC L2.

Kunder bør ikke fjerne RP-tildelingen på abonnementsniveau før mindst tre timer efter sletning af en gateway, fordi vi stadig skal rydde op i ressourcer.

Når du bruger OAuth2-legitimationsoplysninger i Dataflow Gen1, understøtter gatewayen ikke automatisk opdatering af tokens, når adgangstokens udløber. Tokens udløber typisk 1 time efter opdateringens start, men kan udløbe på mindre end 1 time, afhængigt af datakilden og lejerpolitikkerne. Dataflow gen2, semantiske modeller, datapipelines kan opdatere tokens midt i stream og bør ikke påvirkes på grund af dette.

Vi understøtter luftskellet skyer i det østlige USA/det vestlige USA og det østlige USA/det vestlige USA.

Brug Private links til at sikre denne forbindelse. Flere oplysninger: Dokumentation til Private Links i Power BI

Den virtuelle netværksdatagateway er fysisk i det samme område som dit virtuelle Azure-netværk. Metadataene (navn, detaljer, datakilder, krypterede legitimationsoplysninger osv.) for alle dine virtuelle netværksdatagateways gemmes dog i lejerens standardområde. Du kan administrere alle virtuelle netværksdatagateways, når du vælger din lejers hjemmeområde i Power Platform Administration.

Ja. Du kan bruge en virtuel netværksdatagateway, og dine politikker for betinget adgang gælder stadig.

En komplet liste over understøttede datatjenester:

• Power BI er tilgængelig i Understøttede Azure-datatjenester
• Til Power Platform-dataflow er tilgængelige i understøttede datakilder

Virtuelle netværksdatagateways er kun premium-funktioner og er kun tilgængelige i Fabric-kapaciteter (alle SKU'er) og Power BI Premium-kapaciteter (A4 SKU eller nyere eller en hvilken som helst P SKU).

Ja

Gennemse dokumentationen til det virtuelle Azure-netværk for at få begrænsninger (f.eks. områderelaterede) på VNets, slutpunkter og tilknyttede Azure-ressourcer.

Gennemse den tilsvarende produktdokumentation til Azure-datatjenesten for at kontrollere, om private slutpunkter understøttes, og hvordan du aktiverer dem.

Hvis du får vist fejl, f.eks Authorization failed for Public API route . eller DM_GWPipeline_Client_OAuthTokenLoginFailedError når du forsøger at oprette en virtuel netværksdatagatewayforbindelse med OAuth-godkendelse mod en Azure-ressource, hvor en firewall blokerer offentlig internetadgang og er konfigureret med private slutpunkter, betyder det, at du eksplicit skal oprette et tjenesteslutpunkt til privat godkendelse ved at kalde Microsoft Entra ID-tjenesten. Du kan løse denne situation ved at gå til det virtuelle netværksundernet, der bruges til datagatewayen for det virtuelle netværk, og aktivere tjenesteslutpunktet Microsoft.AzureActiveDirectory som vist nedenfor.

Ja, der er ingen afhængighed af Power BI-startområdet for denne funktion. Hvis denne funktion er aktiveret i det område, hvor det virtuelle netværk findes, kan du oprette en ny virtuel netværksdatagateway.

Nej. Den virtuelle netværksdatagateway er fysisk i det samme område som dit virtuelle Azure-netværk. I øjeblikket kan du heller ikke vælge, hvor metadataene (navn, oplysninger, datakilder, krypterede legitimationsoplysninger osv.) for alle dine virtuelle netværksdatagateways gemmes. Disse data gemmes i din lejers standardområde.

Nej. Den virtuelle netværksdatagateway skal oprettes i den samme lejer som Power BI-lejeren.

Nej, virtuelle netværksgateways er i øjeblikket kun tilgængelige i din lejers hjemmeområde.

Få områder, der skal kontrolleres:

• Sørg for, at din datakilde kører.
• Sørg for, at der er adgang til datakilden fra det virtuelle netværk – specifikt fra det undernet, der delegeres, mens du opretter den virtuelle netværksdatagateway. Du kan f.eks. udrulle en VM i undernettet og kontrollere, om du kan oprette forbindelse til datakilden.
• Følgende Azure Network Security Groups (NSGs) kan være påkrævet, afhængigt af dit scenarie:
  • Tillad udgående trafik til Microsoft Entra ID-slutpunktet, mens du bruger godkendelse af OAuth eller Tjenesteprincipal til at oprette forbindelse til en datakilde.
  • Tillad udgående trafik til nøglecenter (nøglecenter), mens du bruger HTTPS til at oprette forbindelse til en datakilde.

Forbindelsen mellem den nye virtuelle netværkstjeneste og dit virtuelle netværk er via HTTPS og TLS 1.2.

I forbindelse med SQL serveruafhængig med automatisk pause mislykkes den første anmodning muligvis, hvis SQL er i midlertidigt afbrudt tilstand, men det næste lykkes.

Når den virtuelle netværksgateway bruges første gang, tager det ca. 2 minutter at få konfigurationen. På samme måde kan du opleve en forsinkelse på ca. et minut, næste gang du bruger den, hvis den virtuelle netværksdatagateway ikke bruges i 30 minutter.

Ja, det understøttes i nationale cloudmiljøer.

Nej. VNET-datagatewayen leverer fuldt administreret beregning. Du kan vælge at skalere antallet af noder i hver klynge.

Ja

Kontrollér, om der er andre gateways, der bruger det samme virtuelle netværk og undernet. Hvis du vil kunne slette, vil det tage op til 48 til 72 timer, efter at den sidste gateway, der bruger dette virtuelle netværk og undernet, blev fjernet.

Ud over de fem reserverede IP'er er vores anbefaling at have ca. 5-7 flere IP'er, så du kan føje flere virtuelle netværksgateways til det samme virtuelle netværk og undernet.

Sørg for, at du eksplicit har en rolle med tilladelsen Microsoft.Network/virtualNetworks/subnets/join/action på det virtuelle netværk, f.eks. rollen Azure Network Contributor. Denne tilladelse er påkrævet for at oprette en virtuel netværksdatagateway.

Hvordan sammenlignes sikkerhed med datagatewayen i det lokale miljø? Ja, alle data, der går gennem en virtuel netværksdatagateway, forbliver på Azure-backbone. Vi bruger en intern Microsoft-tunnel, der ikke når det offentlige internet mellem det virtuelle netværk og Power BI-tjeneste. På den anden side åbner datagatewayen i det lokale miljø en forbindelse for at bruge Azure Relay til at oprette forbindelse til Power BI-tjeneste.

I betragtning af de forskellige ressourcer: abonnement, Microsoft.PowerPlatform-ressourceudbyder, virtuelt netværk, undernet og Power BI-tjenestens hjemmelejer. Hvis du bruger et tjenesteslutpunkt, skal det virtuelle netværk og undernettet være i samme område som de data, du opretter forbindelse til. Hvis du bruger et privat slutpunkt, kan de være i forskellige områder. Konfigurationen af datagatewayen findes i power BI-hjemmelejerområdet.

En virtuel netværksgateway kan generelt få adgang til kilder, der kan nås i det samme virtuelle netværk. Hvis der er et andet virtuelt netværk, der er isoleret fra det første, er en anden virtuel netværksgateway nødvendig.

• Du kan ikke delegere et undernet, der kaldes gatewaysubnet til Power Platform Administration. Denne begrænsning skyldes, at det er et reserveret ord til funktionen Azure Gateway-undernet.
• Du kan ikke ændre området, abonnementet eller ressourcegruppen for det virtuelle netværk, som den virtuelle netværksdatagateway blev oprettet på. Dette scenarie understøttes ikke i øjeblikket.
• Hvis en OAuth-opdatering, der tager længere tid end én time, annulleres med fejlen "Ugyldige forbindelseslegitimationsoplysninger" eller timeout, er problemet sandsynligvis, at legitimationsoplysningerne er udløbet.

Brugerne er begrænset til 1.000 datakilder på hver VNET-gateway. Hvis du når grænsen for det maksimale antal datakilder, skal du kontrollere, at antallet af datakilder for hver VNET-gateway ikke er over grænsen på 1000. Du kan løse eventuelle relaterede problemer ved manuelt at fjerne datakilderne fra Administration eller alternativt bruge følgende PowerShell-script til at masseslette alle datakilder ved hjælp af en angivet VNET-gateway, der overskrider denne grænse. Du skal erstatte teksten "GatewayClusterID" med det specifikke VNET-gateway-id, for at dette script kan fungere.

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