Planlegging av Power BI-implementering: Datagatewayer

Merk

Denne artikkelen er en del av planleggingsserien for power BI-implementering av artikler. Denne serien fokuserer hovedsakelig på Power BI-opplevelsen i Microsoft Fabric. Hvis du vil ha en innføring i serien, kan du se Planlegging av Power BI-implementering.

Denne artikkelen hjelper deg med å planlegge og implementere lokale datagatewayer og virtuelle nettverksdatagatewayer for Microsoft Fabric. Det er primært rettet mot:

• Fabric-administratorer: Administratorene som er ansvarlige for å overvåke Fabric i organisasjonen. Stoffadministratorer må kanskje samarbeide med Power Platform-administratorer, databaseadministratorer, informasjonssikkerhetsteam, nettverksteam og andre relevante team.
• Gateway-administratorer: Personene som er ansvarlige for å implementere, administrere og overvåke gatewayer og deres datakildetilkoblinger.
• Gateway-bidragsytere: De desentraliserte teamene og enkeltpersoner som er ansvarlige for å legge til og administrere gateway-datakildetilkoblinger.
• Center of Excellence (COE), IT- og BI-team: Teamene som er ansvarlige for å støtte brukere som trenger tilgang til, kobler til og oppdaterer data.
• Innholdseiere og opprettere: Teamene og enkeltpersoner som bruker gatewayer til å koble til datakildene sine og oppdatere Fabric-dataelementer.

Hvis du vil ha tilgang til kildedata for Semantiske Power BI-modeller, dataflyter og andre Fabric-dataelementer, trenger du kanskje en datagateway. En datagateway overfører sikkert data mellom private nettverk eller lokale datakilder og skytjenester, inkludert Fabric.

Merk

Denne artikkelen gir en oversikt over gatewayer. Den fokuserer på viktige hensyn og handlinger for planlegging og implementering av gatewayer for å støtte stoffinnholdet.

Hvis du vil ha mer informasjon om hvordan gatewayer fungerer, kan du se:

• Hva er en lokal datagateway?
• Lokal gatewayarkitektur
• Gatewayarkitektur for virtuelt nettverk (VNet)
• Planlegge, skalere og vedlikeholde en forretningskritisk gatewayløsning

Planlegge viktige beslutninger

Gatewayer er ofte integrert i vellykkede Power BI- og Fabric-implementeringer. Et COE- eller sentralt data- og BI-team planlegger vanligvis og administrerer gatewayer sentralt, selv om noen organisasjoner bruker desentraliserte team til å administrere gatewayer. For å redusere muligheten for fremtidige avbrudds- og styringsrisikoer, er det viktig å nøye planlegge hvordan og når du bruker gatewayer.

Du planlegger vanligvis gateway-implementering i to forskjellige faser.

• Leieroppsett: Når du forbereder deg på å implementere eller overføre til Fabric, bør du vurdere om noen datakilder trenger en gateway. Gatewayplanleggingsaktiviteter er også relevante for planlegging på leiernivå for sikkerhet, arbeidsområder og overvåking og overvåking.
• Planlegging av BI-løsninger: Når du planlegger en ny BI-løsning, bør du vurdere om løsningen krever en gateway mens du samler inn tekniske krav til den nye løsningen. Du trenger kanskje også en gateway når du legger til en ny datakilde i en eksisterende løsning.

Planlegging av en gateway-implementering begynner med å ta viktige beslutninger, og starter med om du trenger en gateway eller ikke.

Tips

Først må du opprette en oversikt over datakildene. Du bør evaluere følgende viktige beslutninger for hver datakilde. Pass på å dokumentere resultatene og lagre dem på en sentral plassering som er lett tilgjengelig, for eksempel en kommunikasjonshub eller den sentraliserte portalen.

Identifisere om du trenger en gateway

Generelt sett trenger du en gateway for datakilden når:

• Datakilden er plassert lokalt.
• Datakilden er plassert i et privat nettverk.
• Du krever en vert for koblingsprogramvare.
• Du krever sikkerhetsisolering for bestemte koblinger eller funksjoner.

I slike situasjoner trenger du en gateway til:

• Oppdater data i Stoff-portalen. Dette scenarioet gjelder når en innholdsoppretter konfigurerer dataoppdatering i Power Bi-tjeneste for en datakilde som krever en gateway.
• Opprett innhold i Stoff-portalen. Dette scenarioet gjelder når en innholdsforfatter oppretter eller endrer dataelementer (for eksempel en semantisk modell eller dataflyt) i Power Bi-tjeneste som krever en gateway.
• Støtter DirectQuery-tilkoblinger. Dette scenarioet gjelder når en innholdsoppretter publiserer en semantisk modell som inkluderer directquery-tabeller (eller dobbel) lagringsmodus, og datakilden for disse tabellene krever en gateway. Dette bruksscenariet dekker også muligheten til å fremtvinge datatillatelser per bruker som er definert i datakilden. En SQL Server-database kan for eksempel fremtvinge sikkerhet på radnivå (RLS), og Power BI kan administrere enkel pålogging (SSO)-tilkobling. Hvis du vil ha mer informasjon, kan du se Fremtvinge datasikkerhet basert på forbrukeridentitet.
• Live koble til SQL Server Analysis Services. Dette scenarioet gjelder når en innholdsoppretter publiserer en rapport som bruker en live-tilkobling til en SQL Server Analysis Services (SSAS)-database.

Avsnittene nedenfor beskriver når du trenger en gateway.

Lokale datakilder

Du trenger en gateway for å koble til lokale datakilder fra Fabric-portalen. Gatewayen fungerer som en bro, evaluerer spørringsuttrykk på gatewaymaskinen og overfører sikkert lokale data til skyen.

Dette scenarioet er relevant når du kobler til:

• Datakilder som befinner seg på lokale maskiner.
• Filer som er lagret i en lokal katalog.
• Skybaserte og lokale datakilder som kombineres i én enkelt spørring.
• En skybasert virtuell maskin (VM) – kjent som infrastruktur som en tjeneste, eller IaaS.

Private nettverksdatakilder

Du trenger en gateway for å koble til datakilder som er plassert i et privat nettverk, for eksempel et Azure Virtual Network (Azure VNet). Et virtuelt nettverk, eller VNet, er et logisk isolert segment av et nettverk som isolerer trafikk fra det offentlige Internett. Et VNet gir forbedret nettverkssikkerhet.

Dette scenarioet er relevant når datakilden:

• Ligger i et datasenter i et privat nettverk, for eksempel organisasjonsnettverket (eller er bak en brannmur).
• Er en skybasert VM i et VNet (kjent som infrastruktur som en tjeneste, eller IaaS).
• Er en skybasert databasetjeneste i en VNet (kjent som plattform som en tjeneste, eller PaaS).

Merk

Det er en vanlig misforståelse at du ikke trenger en gateway for datakilder i skyen. Når en skydatakilde befinner seg i et privat organisasjonsnettverk, kreves en gateway.

Vertskoblingsprogramvare

Noen ganger trenger du kanskje en gateway for å være vert for støtteelementer som kreves for å koble til datakilden. Denne programvaren kan inneholde egendefinerte datakoblinger, drivere eller biblioteker som du installerer på gateway-maskinen. Den Power Bi-tjeneste har ikke tilgang til denne programvaren, så den kan ikke oppdatere datakilder som bruker den uten å stole på gatewayen , selv når du kobler til en skydatakilde.

Dette scenarioet er relevant når du kobler til en datakilde med koblinger som:

• Driveren. En offisiell kobling kan kreve installasjon av nødvendige drivere. Når du for eksempel kobler til en Oracle-database, trenger du kanskje Oracle Data Access Client-programvaren.
• Egendefinert kobling. Noen datakilder kan kreve egendefinerte koblinger eller tredjepartskoblinger. Du trenger for eksempel kanskje en egendefinert kobling for å koble til et eldre eller rettighetsbeskyttet system.
• Klientbibliotek. Noen datakilder kan kreve et støttebibliotek for å tillate klientverktøy å koble til det. Når du for eksempel kobler til en Analysis Services-database, må et klientbibliotek være installert.
• ODBC- eller OLE DB-kobling. En offisiell kobling kan kreve en ODBC-driver eller OLE DB-leverandør. Når du for eksempel kobler til SAP HANA, trenger du en ODBC-driver.

Viktig

Når innholdsopprettere bruker et klientverktøy, for eksempel Power BI Desktop og løsningene deres, er avhengige av drivere, koblinger eller leverandører, bør du installere de samme komponentene på gateway-maskinen som er installert på maskinene for innholdsopprettere. Manglende eller manglende komponenter mellom opprettermaskiner og datagatewayer er en vanlig årsak til feil ved dataoppdatering av publisert innhold. Hvis du vil ha mer informasjon, kan du se Brukerverktøy og enheter.

Sikkerhetsisolasjon

Du trenger en gateway for å bruke bestemte Power Query-koblinger eller -funksjoner, for eksempel Web Connector eller Web.BrowserContents-funksjonen. Disse koblingene og funksjonene krever en gateway av mange grunner, inkludert sikkerhetsisolasjon.

Tips

Vurder følgende alternativer når du kobler til datakilder for nettsider.

• Web.Contents-funksjonen: Hvis du kobler til nettinnhold som ikke trenger å åpnes via en nettleser, kan du vurdere å bruke web.contents-funksjonen . Denne funksjonen krever ikke en gateway fordi den ikke bruker en nettleserkontroll.
• Notatblokker: Hvis du har Fabric-kapasitet, bør du vurdere å bruke Fabric-notatblokker til å transformere data. Notatblokker krever ikke en gateway for nettsidedata, og de kan yte bedre når de henter nettsideinformasjon, sammenlignet med Power Query.

Dette scenarioet er relevant når du kobler til en datakilde ved hjelp av koblinger og drivere, for eksempel:

• En spørring som bruker webkoblingen.
• En spørring som bruker funksjonene Web.PageellerWeb.BrowserContents .
• En tilkobling som bruker Access Database Engine (ACE) -driveren.

Fastslå hvilken type gateway du trenger

Når du har identifisert at du trenger en gateway, bør du bestemme hvilken type gateway som skal installeres. Det finnes tre typer gatewayer.

• Lokal datagateway (standardmodus)
• Lokal datagateway (personlig modus), kjent som en personlig gateway
• Gateway-tjeneste for virtuelt nettverk (VNet)

Gatewaytypen du velger, avhenger av kravene og datakildene. Avsnittene nedenfor beskriver hver av de tre gatewaytypene.

Lokal datagateway (standardmodus)

En lokal datagateway (standardmodus) gjør det mulig for flere brukere å koble til datakilder som via én enkelt delt gateway. Vanligvis installerer og administrerer du standardmodusgatewayer sentralt på en maskin med alltid pålogging. Med en standard modusgateway kan du koble til data fra flere tjenester, for eksempel Fabric, Power BI og andre Power Platform-tjenester.

Diagrammet nedenfor viser en oversikt på høyt nivå over en standard modusgateway.

Viktig

Dette diagrammet viser ikke arkitekturen til en lokal datagateway.

Diagrammet viser følgende konsepter.

Vare	Beskrivelse
	Den lokale datagatewayen (standardmodus) overfører sikkert data fra lokal datakilde til skytjenester.
	En standard modusdatagateway kreves for skydatakilder i bestemte scenarier (beskrevet i forrige del).
	Standardmodusdatagatewayen er installert på en maskin som alltid er på. Administratorer administrerer vm og datagateway sentralt. Gatewayadministratorer installerer programvare som kreves for datakildetilkoblinger, om nødvendig.
	Flere brukere kan koble til datakildene for datagatewayen.
	Brukere kan bruke datagatewayen for elementer som er publisert til Fabric-arbeidsområder, for eksempel semantiske modeller, dataflyter, datasamlebånd eller paginerte rapporter.
	Brukere kan bruke datagatewayen for andre Power Platform-skytjenester, for eksempel Power Platform-dataflyter.

En standard modusgateway kreves i følgende spesifikke situasjoner.

• Ulike Microsoft-skytjenester (for eksempel Power Apps og Fabric) og Fabric-dataelementer (for eksempel dataflyter) må spørre lokale datakilder (eller datakilder i skyen som krever en gateway).
• Paginerte rapporter må spørre lokale datakilder (eller datakilder i skyen som krever en gateway).
• Semantiske modeller bruker DirectQuery-lagringsmodus som må kobles til lokale datakilder (eller skydatakilder som krever en gateway).
• Live-tilkoblinger for SSAS.
• Datakilder avhenger av egendefinerte datakoblinger, drivere eller biblioteker.
• Når du forventer at du må flytte eller overføre gatewayen.

Personlig gateway

En lokal gateway (personlig modus), vanligvis kjent som en personlig gateway, gjør det mulig for en bruker å koble til lokale datakilder som ligger på samme maskin. En bruker installerer og administrerer vanligvis en personlig gateway fra sin egen maskin. Brukere kan ikke koble til data fra andre Power Platform-tjenester med en personlig gateway. De kan heller ikke dele gatewayen eller tilkoblingene med andre brukere.

En personlig gateway er ment for begrenset personlig bruk av én enkelt person. Innholdsopprettere installerer og bruker vanligvis disse gatewayene til å utføre personlig BI. Disse gatewayene er begrenset til personlig BI fordi de ikke kan deles. I tillegg krever en personlig gateway at brukeren har maskinrettigheter og policygodkjenning for å laste ned og installere den personlige gateway-programvaren.

Tips

Ikke bruk en personlig gateway med team-, avdelings- eller enterprise BI-løsninger.

For de fleste scenarioer der du kobler til lokale data, bør du bruke en gateway i standardmodus (beskrevet i forrige del). Det er fordi du kan dele en standard modusgateway med flere brukere, den støtter DirectQuery-spørringer og live-tilkoblinger, og den har flere alternativer for å sentralisere gatewaystyring og -administrasjon.

Forsiktig!

Siden en personlig gateway vanligvis er installert på en brukermaskin, er det vanskeligere å administrere og styre. Hvis du trenger å bruke en personlig gateway, kan du vurdere å flytte den til en sentralt administrert vm som bruker en tjenestekonto. Denne fremgangsmåten sikrer at gatewaytilgjengelighet ikke er avhengig av en brukermaskin (som kan være slått av) og forbedrer gatewaystyring og -administrasjon.

Diagrammet nedenfor viser en oversikt på høyt nivå over en personlig gateway.

Viktig

Dette diagrammet viser ikke arkitekturen til en lokal datagateway.

Diagrammet viser følgende konsepter.

Vare	Beskrivelse
	En personlig gateway er vanligvis installert på en brukermaskin.
	Den personlige gatewayen overfører sikkert data fra lokale datakilder på brukermaskinen til skytjenester.
	Den personlige gatewayen administreres vanligvis av brukeren som installerte den.
	Én enkelt bruker bruker den personlige gatewayen for begrenset personlig bruk. En gateway for personlig modus kan ikke deles.
	En personlig gateway kan bare brukes for elementer som er publisert til et Power BI-arbeidsområde, for eksempel semantiske modeller eller Power BI-dataflyter.

For å gjenta, er en personlig gateway ment for begrenset, personlig bruk av én enkelt person. Det finnes imidlertid to spesifikke scenarioer som krever at du bruker en personlig gateway.

• Selvbetjente innholdsopprettere må oppdatere publisert innhold som er koblet til lokale datakilder på maskinen eller andre lokale datakilder.
• Semantiske modeller bruker Python - eller R-kode i Power Query.

Tips

Når det er mulig, unngå å bruke en personlig gateway. Vurder i stedet følgende alternativer.

• SharePoint: Hvis du trenger å koble til lokale filer, kan du vurdere å laste opp disse filene til SharePoint eller OneDrive for arbeid eller skole i stedet. Du kan koble til disse filene ved hjelp av SharePoint-mappekoblingen, som ikke krever en gateway.
• OneLake: Hvis du trenger å koble til lokale filer og du har Fabric-kapasitet, kan du også bruke OneLake-filutforsker til å laste opp og synkronisere filer med et lakehouse. Koble til til et Fabric lakehouse krever ikke en gateway.
• Notatblokker: Hvis du trenger å transformere data med Python eller R og du har Fabric-kapasitet, kan du vurdere å bruke Fabric-notatblokker til å transformere dataene og skrive dem til tabeller som er lagret i OneLake. Notatblokker krever ikke en gateway for å kjøre Python- eller R-kode. Du drar også nytte av den forbedrede ytelsen og tilleggsfunksjonene som er tilgjengelige i notatblokker.

VNet-gateway

En VNet-gateway gjør det mulig for flere brukere å koble til datakilder som er sikret med private nettverk, inkludert datakilder som bruker private endepunkter. Med en VNet-gateway kan du koble til data med flere tjenester, og du kan dele gatewayen eller tilkoblingene med flere brukere.

En VNet-gateway er en Microsoft-administrert tjeneste. Hvis organisasjonen bruker private nettverk, trenger du en VNet-gateway.

Viktig

Hvis du vurderer å bruke VNet Gateway-tjenesten, kan du diskutere det med IT-teamene som håndterer nettverk og sikkerhet. Disse teamene kan bidra til å sikre at alt er konfigurert, for eksempel private endepunkter (hvis aktuelt) og gateway-kommunikasjon.

En VNet-gateway støttes bare for Power BI Fabric- eller Premium-kapasiteter. VNet-gatewayen faktureres som en additive premium infrastrukturkostnad for denne kapasiteten.

Viktig

Til tider refererer denne artikkelen til Power BI Premium eller dets kapasitetsabonnementer (P SKU-er). Vær oppmerksom på at Microsoft for øyeblikket konsoliderer kjøpsalternativer og trekker tilbake Power BI Premium per kapasitet sKU-er. Nye og eksisterende kunder bør vurdere å kjøpe Fabric-kapasitetsabonnementer (F SKU-er) i stedet.

Hvis du vil ha mer informasjon, kan du se Viktige oppdateringer som kommer til Power BI Premium-lisensiering og vanlige spørsmål om Power BI Premium.

Diagrammet nedenfor viser en oversikt på høyt nivå over en VNet-gateway.

Viktig

Dette diagrammet viser ikke arkitekturen til en VNet-datagateway.

Diagrammet viser følgende konsepter.

Vare	Beskrivelse
	Du bruker en virtuell nettverksgateway (VNet) til å koble til datakilder på et privat nettverk, for eksempel de i en Azure VNet.
	VNet-datagatewayen er en Microsoft-administrert tjeneste. Du administrerer VNet-datagatewayen sentralt fra Azure-portalen og administrasjonsportalen for Power Platform.
	Flere brukere kan bruke en VNet-datagateway.
	Brukere kan bruke en VNet-datagateway for elementer som er publisert til et Stoff-arbeidsområde, for eksempel semantiske modeller.
	Brukere kan bruke en VNet-datagateway for andre Power Platform-tjenester, for eksempel Power Platform-dataflyter.

Advarsel!

VNet-gatewayer har noen begrensninger, og de støtter ikke alle datakilder eller scenarier. Valider at datakildene og scenarioene støttes, og se de vanlige spørsmålene før du fortsetter med VNet Gateway-implementering og løsningsplanlegging.

Bestemme antall gatewayer

Når du har fastslått at du trenger en gateway og hvilken type gatewayer, bør du bestemme hvor mange gatewayer du trenger.

Avhengig av behovene dine, kan det hende du krever flere gatewayer. Vurder følgende faktorer når du bestemmer hvor mange gatewayer som skal installeres og brukes.

Tilgjengelighet og ytelse

Det er viktig at gatewayer har høy tilgjengelighet for å unngå forstyrrelser forårsaket av oppdaterings- eller spørringsforsinkelser. Én måte å sikre at gatewayen er tilgjengelig på, er å installere flere gatewayer i en gateway-klynge med høy tilgjengelighet. En gateway-klynge er en samling gatewayer som du installerer på forskjellige virtuelle maskiner, og som er logisk knyttet sammen som én enkelt, funksjonell enhet (klyngen). Hver gateway-maskin kalles noen ganger en node.

Her er fordelene ved å bruke en gateway-klynge.

• Unngå ett enkelt feilpunkt:Failover unngår ett enkelt feilpunkt når den primære gatewaymaskinen blir utilgjengelig. Hvis den blir utilgjengelig, sendes spørringer til en annen node i klyngen. Hvis du bruker en klynge med flere maskiner, reduseres risikoen. Det øker også oppetiden, noe som hjelper deg med å oppfylle kravene til høy tilgjengelighet og nødgjenoppretting.
• Bedre ytelse:Belastningsfordeling forbedrer ytelsen når det er høy samtidig bruk. Belastningsfordeling distribuerer arbeidsbelastningen ved å sende spørringer til andre noder i klyngen. Det er nyttig når den primære gatewayen er opptatt, eller når én enkelt operasjon (for eksempel en lang dataoppdatering) bruker mange ressurser.
• Unngå nedetid: Når du installerer gateway-programvareoppdateringer, kan du utføre installasjonen på én node av klyngen om gangen. På den måten unngår den å ta hele klyngen frakoblet.

Viktig

Vi anbefaler på det sterkeste at du bruker gateway-klynger for forretningskritiske arbeidsbelastninger.

Hvis du vil ha mer informasjon og veiledning om hvordan du konfigurerer en gateway-klynge, kan du se Planlegge, skalere og vedlikeholde en forretningskritisk gatewayløsning..

Miljøer

Innholdsopprettere bruker vanligvis separate miljøer til å utvikle og administrere forretningskritiske løsninger, for eksempel utvikling, test og produksjon. Avhengig av antall miljøer du bruker og hvordan du bruker dem, vil du kanskje ha separate gateway-klynger for hvert miljø.

Skille gateway-klynger i ulike miljøer kan:

• Segreger og minimer forstyrrelser forårsaket av utviklings- og testaktiviteter.
• Forbedre tilgjengeligheten og ytelsen til produksjonsarbeidsbelastninger.
• Gi et trygt miljø for å installere og teste programvareoppdateringer for gatewayen.

Viktig

Vi anbefaler at du har separate gateway-klynger for produksjonsarbeidsbelastninger. Hvis du har én gateway-klynge på tvers av alle miljøer, kan dette representere ekstra risiko. Hvis du vil minimere kostnads- og administrasjonsarbeidet, er det vanlig å tildele færre ressurser (for eksempel minne og CPU) til en gateway-klynge for utvikling.

Områder

For å sikre god ytelse for dataoppdateringer er det viktig at du vurderer plasseringen av datakilder, gatewayer og hvor brukerne befinner seg. Hvis du vil redusere ventetiden, bør du installere gatewayer så nær datakildene som mulig. Derfor må du kanskje installere flere gateway-klynger for å støtte ulike områder eller leiere.

Forsiktig!

Kontroller at gatewayinstallasjonen er i samsvar med eventuelle krav til datalagring for organisasjonen.

Viktig

For å minimere ventetiden anbefaler vi at du installerer gatewayer på maskiner som er i samme område som datakildene. I tillegg, for VNet-gatewayer, bør gatewayene og datakildene være på samme delnett.

Sjekkliste – Når du planlegger en gateway-implementering, omfatter viktige beslutninger og handlinger:

• Opprett en oversikt over datakilder: Med en oversikt over datakildene kan du bekrefte og dokumentere hvilke datakilder som trenger en gateway.
• Bestem hvilke situasjoner som krever en gateway: Vurder hvordan innholdsopprettere og forbrukere fungerer. Kontroller at du er kjent med når en gateway kreves. Opprett dokumentasjon og opplæring for brukerfellesskapet.
• Bestem deg for hvilken type gateway du trenger: Kontroller at du validerer eventuelle antagelser og vurderer mulige begrensninger, slik at du er sikker på at den valgte gatewaytypen oppfyller kravene dine.
• Unngå personlige gatewayer: Vurder å bruke en gateway i standardmodus i stedet. Bestem om det finnes noen personlige gateway-datakilder som kan omdirigeres til å bruke en standard modusgateway (slik at den ikke er begrenset for bruk av én enkelt person).
• Bestem om du trenger en gateway-klynge: Bruk gatewayklynger for forretningskritiske løsninger. Gateway-klynger gir høy tilgjengelighet og belastningsfordeling. De bidrar også til å unngå et enkelt feilpunkt og forbedre ytelsen i perioder med høy samtidig bruk.
• Bestem deg for hvor mange gatewayer du trenger: Vurder separate gatewayklynger for ulike miljøer for å unngå forstyrrelser. Vurder andre faktorer, for eksempel bruk eller områder.

Installer gatewayer

På dette tidspunktet vet du hvilke typer gateway du trenger og hvor mange. Deretter må du planlegge for gatewayinstallasjonen. Vanligvis er gatewayer installert på virtuelle maskiner som du dedikerer til dette formålet (ofte kalt gateway-maskiner). Hver maskin i gateway-klyngen bør alltid være på for å sikre kontinuerlig støtte for brukeraktivitet og dataoppdateringsoperasjoner.

Merk

Siden en VNet-gateway er en administrert tjeneste, laster du ikke ned og installerer den. I stedet klargjør og konfigurerer du en VNet-gateway i Azure-portalen, og binder den deretter til en Fabric- eller Power BI Premium-kapasitet. Hvis du vil ha mer informasjon, kan du se Opprette virtuelle nettverksdatagatewayer.

Identifiser gatewayeiere og installasjonsprogram

Før du installerer gatewayen, må du identifisere hvem som skal installere og eie gatewayen.

Gateway-eiere

Vanligvis er gatewayeieren en teknisk person som installerer, eier og administrerer gatewayen. Gateway-eiere er ansvarlige for ulike aktiviteter.

• Planlegging: Ta viktige beslutninger som beskrevet tidligere, og definer de tekniske spesifikasjonene for en gateway-maskin, inkludert opprinnelige systemressurser. Eieren av gatewayen bør også sørge for at en støtteplan er på plass.
• Installasjon: Velg en passende maskin for å installere gateway-programvaren og utføre førstegangsinstallasjon og installasjon.
• Administrasjon: Endre gatewayinnstillinger eller innstillinger for optimalisering (for eksempel konfigurering av strømming i stedet for utskriftsdata) eller overvåkingsformål (for eksempel konfigurering av ytelseslogging). Gateway-eieren tar også avgjørelser om når du skal skalere opp (legge til flere ressurser i gateway-maskinene) eller skalere ut (installere flere gatewayer i klyngen).
• Testing: Valider gatewaybruken under førstegangsoppsettet, slik at tilstrekkelige ressurser er tilgjengelige for gateway-maskinene. Eieren av gatewayen bør også teste månedlige oppdateringer før du installerer dem.
• Oppdatering: Oppdater og installer gateway-programvaren og støtteelementer (for eksempel koblingsprogramvare) i tide.
• Overvåking:Overvåk gatewayens oppetid og tilstand, inkludert samlingen av gateway-loggfilene som tillater overvåking for problemer og uregelmessig aktivitet.
• Overføring: Lagre gjenopprettingsnøkler på et trygt sted som er tilgjengelig for et bredere team. Gatewayeieren bør også være personen som bruker disse nøklene til å overføre, gjenopprette eller flytte gatewayen om nødvendig.

Viktig

Sørg for at eieren av gatewayen er klar over, og er enig i, disse ansvarsoppgavene. Hvis eieren av gatewayen ikke er forberedt på å administrere gatewayen, kan det raskt bli en avhengighet som blokkerer innholdseiere og opprettere. I tillegg kan du identifisere om eieren av gatewayen forstår hvordan du installerer og administrerer en gateway, og om ikke, hvordan du lærer dem opp til å gjøre dette.

Tips

Noen organisasjoner tillater gateway-eierskap i forretningsenheter og avdelinger, mens andre reserverer gateway-eierskap for et sentralisert team (for eksempel IT). Én måte å håndtere det på er å danne et partnerskap der IT administrerer gatewayklyngenodene, og forretningsenheten administrerer datakildetilkoblingene.

Fordi eierskap av gatewayer er et viktig ansvar, bør du tydelig definere hvem som kan installere gatewayer i organisasjonen.

Gateway-installasjoner

Hvis du vil redusere administrasjonskostnader og redusere styringsrisiko, er det viktig å begrense antall aktive gatewayer i organisasjonen. Til dette formål anbefaler vi at du begrenser antall brukere som kan installere gatewayer.

Advarsel!

Gateway-eiere har full kontroll over gatewayene de administrerer. Dette betyr at eiere av skadelig gateway potensielt kan fange opp informasjon når den flyter gjennom en lokal datagateway. Derfor er det viktig at du begrenser muligheten til å installere gatewayer til klarerte personer.

For standardmodusgatewayer administrerer du gateway-installasjoner enten fra Fabric-portalen eller administrasjonssenteret for Power Platform. Du administrerer også hvem som kan opprette VNet-datagatewayer ved hjelp av innstillingen for gateway-installasjonsprogrammet.

• Stofftilkoblinger og gatewayer-side: Du kan administrere gateway-installasjoner fra tilkoblings- og gatewaysiden i Fabric-portalen.
• Administrasjonssenter for Power Platform: Du kan også administrere gateway-installasjoner fra administrasjonssenteret for Power Platform. Innstillinger du endrer her, påvirker gatewayer du bruker fra Fabric.

Du kan også administrere gateway-installasjoner programmatisk ved hjelp av PowerShell-cmdleter for lokal gateway-administrasjon. For personlige gatewayer og standardmodusgatewayer kan du bruke disse cmdletene til å angi gatewayens leierpolicy. Å angi leierpolicyen for gatewayen ved hjelp av PowerShell er den eneste måten å administrere hvem som kan installere personlige gatewayer i leieren.

Viktig

Vi anbefaler at du regulerer hvem som kan installere personlige gatewayer, noe som begrenser installasjon og bruk for gyldige, godkjente forretningssaker.

Klargjøre gatewayinstallasjon

Når du har identifisert hvem som skal installere og eie gatewayen, bør du forberede deg på gatewayinstallasjonen. Du bør:

• Identifiser hvor gatewayen skal installeres.
• Bestem deg for ressursene som gatewaymaskinen trenger.
• Bli enige om hvordan du gir gatewayen et navn når den er installert.

De følgende avsnittene beskriver disse viktige vurderingene for planlegging av en gateway-installasjon.

Identifiser hvor gatewayen skal installeres

Vanligvis installerer du en gateway på en maskin som alltid er på (også kalt gateway-maskinen). Du kan installere bare én gateway av hver type (personlig modus eller standardmodus) på en maskin.

Her er de viktigste faktorene for å finne ut hvor du skal installere en gateway.

• Plassering: Vanligvis bør gatewaymaskinen være plassert nær datakilden for å minimere ventetiden. Vanligvis må en standard gateway installeres i standard dataområde. Hvis premium-kapasitetsplasseringen er forskjellig fra standard dataområde for leieren, kan du imidlertid undersøke hvordan du bruker en Azure Relay som et alternativ for å oppfylle kravene til datalagring.
• Støtteelementer: Bestem hvilke koblinger, drivere eller biblioteker du må installere på gateway-maskinen.
• Domene: Bestem hva relasjonen til gatewaymaskinen er med måldomenet. VM-en må være en domenetilkoblet maskin med en klareringsrelasjon med måldomenet. Det kan ikke være en domenekontroller.

Tips

Hvis du vil unngå ressurskonflikt, må du ikke installere urelatert programvare på en gateway-maskin. Gateway-maskinen bør være fullstendig dedikert til å være vert for den lokale datagatewayen.

Bestem deg for gatewayens maskinressurser

Gatewaymaskinen bør ha tilstrekkelige ressurser til å håndtere den forventede spørringsarbeidsbelastningen.

Her er de viktigste faktorene for å bestemme gateway-maskinressurser.

• Bruk: Bestem hvor mange og hvilken type elementer som skal bruke gatewayen, og hvilken spørringskoncurrence (fra mange brukere) som skal være. Høyere bruk krever gateway-maskiner med flere ressurser.
• Koble til iontype: Bestem om semantiske modeller for Power BI importerer data, bruker DirectQuery eller en live-tilkobling. For semantiske importmodeller er det viktig å kontrollere antall dataoppdateringer for å beregne ressursbehov for gateway (for eksempel RAM). For DirectQuery eller live-tilkoblinger bør du vurdere antall rapportforbrukere for å estimere ressursbehov (for eksempel CPU).

Tips

Valider gateway-maskinressursene ved å utføre belastningstesting. Du kan utføre denne typen test ved å overvåke gatewayens maskintilstand når du utfører oppdateringer av datasett, og ved å simulere høy samtidig bruk av DirectQuery- eller live-tilkoblingsrapporter.

Bli enige om navnekonvensjoner

Hvordan du gir navn til gatewayen og datakildetilkoblingene er viktig. Navnet bør gjøre det enkelt for innholdsopprettere å vite hva de skal koble til. Hvis du vil sikre at gatewayer og datakildetilkoblinger har klare navn, bør du bruke en logisk navnekonvensjon.

Når du definerer navnekonvensjonene, bør du vurdere følgende punkter.

• Inkluder en variant av Gateway eller DataGW i navnet for å identifisere gatewayen for overvåkings-, loggings- og feilsøkingsformål.
• Inkluder det bestemte formålet med gatewayen når den støtter bestemte stoffelementer, operasjoner, områder eller forretningsområder.
• Bruk en variant av Utvikling, Test eller Prod i navnet når gatewayen støtter et bestemt miljø.
• Gi gatewayen et navn som samsvarer med navnet på klyngen den tilhører. Gi for eksempel hver gateway-maskin i klyngen et unikt navn, for eksempel Node1, Node2 og så videre.

Her er noen eksempler på logiske gatewaynavn.

• DataGW-Prod-Node1
• Gateway-DevTest-Node1
• Gateway-FinanceTeam-Prod-Node1

Installere og konfigurere gatewayer

Når du har tatt viktige beslutninger og forberedelser, installerer gatewayeieren gatewayene og utfører førstegangsoppsett.

Merk

Hvis du vil ha informasjon om hvordan du laster ned og installerer en gateway, kan du se:

• Laste ned og installere en standard modusgateway
• Laste ned og installere en gateway for personlig modus

Når du installerer og konfigurerer gatewayer, bør du vurdere følgende faktorer.

• Installasjonsplassering: Når du vil installere gatewayen på en annen plassering enn standard installasjonsbane, kan du endre installasjonsplasseringen.
• Gjenopprettingsnøkkel: Når du vil overføre, gjenopprette eller overta en eksisterende gateway, må du bruke gatewayens gjenopprettingsnøkkel. Sørg for at du beholder gjenopprettingsnøkkelen på et trygt og sikkert sted som er tilgjengelig for andre gatewayadministratorer.
• Datasenterområde: Når du vil at området skal være forskjellig fra den registrerte tjenestens leier, kan du endre datasenterområdet.
• Azure Relay: Når du vil bruke ditt eget relé i stedet for standard, kan du oppgi dine egne videresendingsdetaljer.
• Proxy-innstillinger: Når arbeidsmiljøet krever at gatewayen går gjennom en proxy-server for å koble til Fabric-portalen, må du konfigurere proxy-innstillinger.
• Gateway-tjenestekonto: Når du vil bruke en eksplisitt domenekonto, kan du endre gateway-tjenestekontoen fra standardkontoen, som er PBIEgwService.
• Kommunikasjonsinnstillinger: Når en brannmur blokkerer utgående tilkoblinger, kan sikkerhets- og nettverksteamene konfigurere brannmuren til å tillate utgående tilkoblinger fra gatewayen til det tilknyttede Azure-området.
• Leierregistrering: Når du vil begrense hvilke leiere som har tillatelse til å registrere det lokale datagatewayprogrammet for å forhindre datautfiltrering.
• Leierinnstillinger for integrering: Når du vil sikre at gatewayen fungerer med enkel pålogging (SSO) (for eksempel med Microsoft Entra ID-basert godkjenning) slik du ønsker.

Viktig

Vi anbefaler at du begrenser leierregistrering til bare leiere i organisasjonen. Dette trinnet bidrar til å forbedre gatewaysikkerheten fordi standardinnstillingen ikke har noen begrensning på leierregistrering.

Sjekkliste – Når du forbereder og installerer en gateway, omfatter viktige beslutninger og handlinger:

• Identifiser gateway-eieren og installasjonsprogram: Sørg for at eieren av gatewayen er klar over ansvaret. Begrens gatewayinstallasjon til de aktuelle personene.
• Utfør opplæring: Om nødvendig kan du lære opp gatewayeiere og installasjonsprogram til effektivt å installere, administrere og støtte gatewayen. Utfør kryssopplæring for en sikkerhetskopi når det er nødvendig.
• Opprett navnekonvensjoner: Opprett navnekonvensjoner for gatewayer som tilsvarer formål, miljø, klyngenode og brukstilfellene den støtter, eller operasjonene den utfører.
• Vurder ressursbehov: Bestem hva arbeidsbelastningen og bruken skal være for å bestemme innledende ressurser (for eksempel minne og CPU).
• Angi leierinnstillingene for integrering: Se gjennom og angi innstillingene for integreringsleietakeren for å sikre at gatewayen fungerer med enkel pålogging (SSO) slik du ønsker.
• Klargjør gateway-maskinen: Konfigurer en maskin som alltid er på, med tilstrekkelige ressurser til å støtte gateway-operasjoner.
• Installer gatewayen: Utfør førstegangsoppsett av gatewayen på gateway-maskinen.
• Installer støtteelementer: Installer egendefinerte datakoblinger eller avhengig programvare for å støtte scenarioet.

Administrer gatewayer

Når du har installert gatewayene, bør du deretter legge til datakildetilkoblinger. Når du legger til disse tilkoblingene, bør du også planlegge hvordan du skal administrere tilgang til gatewayen og tilkoblingene.

Legge til datakildetilkoblinger

Du må legge til de første datakildetilkoblingene før du kan bruke gatewayen. Du kan legge til tilkoblinger manuelt fra Power Bi-tjeneste eller administrasjonssenteret for Power Platform, eller programmatisk med REST-API-ene for Power BI.

Når du legger til tilkoblinger, bør du vurdere følgende punkter.

• Lagret legitimasjon: Vurder hvilken legitimasjon som skal brukes til å koble til datakilden. Når du legger til en tilkobling, må du oppgi legitimasjon for denne datakilden (med mindre den støtter anonym godkjenning). Det er en viktig beslutning, fordi alle spørringer til datakilden kjører ved hjelp av denne legitimasjonen, med mindre du bruker Microsoft Entra enkel pålogging (SSO) for datagatewayen.
• Navnekonvensjoner: Som gatewayer bør tilkoblinger også bruke logiske og konsekvente navnekonvensjoner. Kontroller at tilkoblingsnavn samsvarer med datakildenavnet. Eksempel: FinanceDB-Prod er et logisk navn som angir datakilden.
• Enkel pålogging: I innstillingene for Fabric-administratoren bør du aktivere alternativet Microsoft Entra enkel pålogging (SSO) for gateway når du vil bruke enkel pålogging (SSO) med DirectQuery (enten ved hjelp av Active Directory SSO eller Microsoft Entra SSO). Du bør bruke SSO når du vil fremtvinge datasikkerhet i datakildesystemet basert på rapportbrukeridentiteten.
• Personvernnivåer: For import av datakildetilkoblinger må du angi personvernnivået. Kontroller at du velger riktig personvernnivå for å isolere datakilden på riktig måte om nødvendig. Det er viktig å forstå at personvernnivåene som er angitt i Power BI Desktop, ikke overholdes av gatewayer.

Merk

Datakildenavnet kan endres etterpå, men server- og databasenavnene kan ikke endres etter at de er konfigurert. Hvis du vil unngå feil, må du kontrollere at datakildeinformasjonen samsvarer med det som skal brukes i Power BI Desktop.

Tips

Hvis du vil forbedre effektiviteten og nøyaktigheten, kan du vurdere å automatisere opprettingen av datakildetilkoblinger ved hjelp av REST-API-ene for Power BI. I dette tilfellet anbefaler vi at du inkluderer gjennomgangs- og godkjenningsprosesser i stedet for automatisk behandling av hver forespørsel som oppretter eller oppdaterer en tilkobling.

Klargjør gatewaytilgang

Når du har lagt til de første datakildetilkoblingene, bør du bestemme deg for hvordan du skal administrere tilgang til både gatewayen og tilkoblingene.

Innholdsopprettere trenger tilgang til en gateway-tilkobling for å kunne koble til en datakilde. Brukertilgang til gateway-tilkoblinger utføres for hver tilkobling, så vurder hvem som trenger tilgang til hver gateway-tilkobling, og hvordan du administrerer denne tilgangen. Du bør administrere tilgang ved hjelp av sikkerhetsroller for både gatewayer og tilkoblinger.

Gateway-roller

Gatewayroller lar deg kontrollere hvem som kan administrere gatewayen og datakildetilkoblingene. Disse rollene fungerer på samme måte som arbeidsområderoller, noe som tillater ulike tillatelser avhengig av rollen. Ved hjelp av roller kan du administrere gateway-tilgang mer effektivt.

Tips

Vi anbefaler at du bruker sikkerhetsgrupper til å administrere rollemedlemskap i stedet for individuelle kontoer. På den måten er det enklere å administrere brukere, spesielt på tvers av flere gatewayer. Du kan bruke de samme sikkerhetsgruppene til å administrere annen tilgangskontroll, for eksempel medlemskap i sikkerhetsrolle på radnivå og medlemskap i apppublikum .

Viktig

En bruker som bare trenger å bruke gatewayen til å koble til en datakilde, trenger ikke å tilhøre en gatewayrolle. I dette tilfellet har de bare brukertilkoblingsrollen .

Det finnes tre gatewayroller for administrasjon av en lokal standardgateway.

• Administrator: Medlemmer av denne rollen kan administrere og oppdatere gatewayen. En gatewayadministrator er vanligvis eieren av gatewayen, men det kan også være flere administratorer for en gateway. Gateway-administratorer bør være Fabric-administratorer eller medlemmer av COE- eller central BI-teamet. Ansvaret til en administrator er det samme som en gatewayeier.
• Koble til ionoppretter med deling: Medlemmer av denne rollen kan opprette gateway-tilkoblinger, teste gatewaystatusen og dele gatewayen med andre. Denne rollen kan ikke fjerne brukere fra gatewayen. Vurder å legge til noen i denne rollen når de er ansvarlige for et delsett av analytiske løsninger, som i et desentralisert team for en forretningsenhet. Ansvarsområder for noen med denne rollen inkluderer:
  • Konfigurere og teste nye tilkoblinger.
  • Administrere tilkoblinger de eier, for eksempel angi legitimasjon.
  • Dele gatewayen med andre brukere som trenger den.
  • Regelmessig gjennomgang av hvem som har tilgang til en gateway, validerer om de fortsatt trenger det, og fjerner dem når de ikke trenger det.
• Koble til ionoppretter: Medlemmer av denne rollen kan opprette tilkoblinger på gatewayen og teste statusen deres. Oppretteren av tilkoblingen bør være en innholdseier som på riktig måte kan konfigurere de riktige tilkoblingene til å bruke gatewayen. Ansvaret for en Koble til ionoppretterrolle er det samme som Koble til ionoppretteren med delingsrolle, med unntak av at de ikke kan dele tilgang til gatewayen.

Merk

VNet-gatewayer støtter bare rollen administratorgateway.

Tilkoblingsroller for datakilde

Datakildetilkoblingsroller lar deg kontrollere hvem som kan bruke, administrere og dele tilkoblinger. En bruker med en tilkoblingsrolle trenger ikke å tilhøre en gatewayrolle.

Det finnes tre tilkoblingsroller for datakilder.

• Eier: Medlemmer av denne rollen kan administrere tilkoblingen eller slette den når den ikke lenger er nødvendig. Eiere kan administrere tilkoblingsrollene, inkludert å legge til andre tilkoblingseiere. En eier er vanligvis også en tilkoblingsoppretter. Vurder å gjøre noen til en tilkoblingseier når de er forvalter eller administrator for datakilden, eller de har betydelig kunnskap om datakilden og innholdet. Ansvarsområder for en eier inkluderer:
  • Administrere tilkoblinger, for eksempel oppdatere legitimasjon, om nødvendig.
  • Sletter tilkoblingen når den ikke lenger er nødvendig.
  • Administrere tilkoblingsroller fra administrasjonssenteret for Power Platform.
• Bruker med deling: Medlemmer av denne rollen kan bruke og dele datakilden ved å legge til andre brukere. Vurder å legge til noen i denne rollen når de spiller en viktig rolle i brukerfelleskapet. Mestere kan være gode kandidater til denne rollen. Ansvarsområder for noen med denne rollen inkluderer:
  • Dele tilkoblingen med andre brukere som trenger den.
  • Regelmessig gjennomgang av hvem som har tilgang til en tilkobling, validerer om de fortsatt trenger det, og fjerner dem når de ikke trenger det.
• Bruker: Medlemmer av denne rollen kan bruke datakilden i Power BI-rapporter og Power BI-dataflyter. Brukere er bare ansvarlige for å spørre dataene fra arbeidsbelastningene og klientverktøyene.

Tips

Hvis du vil hindre at styringsrisikoen oversharing, bør du begrense hvem som kan dele gatewayer og tilkoblinger til bestemte personer som kan utføre denne oppgaven effektivt og ansvarlig.

Dokumentgateway og tilkoblinger

Når du har konfigurert gateway-klyngen, bør du dokumentere den. Du bør dokumentere gatewayene slik at de er enkle å finne for innholdsopprettere, og enkelt for gatewayadministratorer å vedlikeholde. Vurder å lagre gatewaydokumentasjon på et tilgjengelig sted, for eksempel den sentraliserte portalen for det aktuelle praksisfellesskapet.

Vurder å dokumentere følgende informasjon.

• Gatewaynavn og GUID
• Gateway-maskinnavn (og eventuelle respektive identifikatorer)
• Gateway-eier
• Siste oppdateringsdato for programvare (gatewayversjon)
• Formålet med gateway-klyngen (for eksempel miljø, område, forretningsområde)
• Hvilke datakildetilkoblinger som skal vedlikeholdes på denne gatewayen
• Om gatewayen bruker en brukeridentitet eller lagret legitimasjon
• Policy for tilgangsbehandling (hvordan du har tenkt å bruke gatewayroller og tilkoblingsroller)

Viktig

Kontroller at du dokumenterer gateway-gjenopprettingstastene for standardmodusgatewayer. Disse gjenopprettingsnøklene kreves hvis du trenger å gjenopprette eller lokalisere gatewayen på nytt. Oppbevar denne informasjonen på et trygt og sikkert sted som er tilgjengelig for flere klarerte personer i et sentralt team. Hvis du har et organisatorisk passordhvelv, er det et ideelt sted.

Oppdater gatewayer

Hvis du vil sikre at gatewayene forblir funksjonelle og fungerer bra, må du utføre flere oppgaver.

• Installer Windows-oppdateringer og utfør annet servervedlikehold.
• Oppdater gatewayprogramvaren. Gateway-programvaren oppdateres månedlig, og Microsoft støtter bare de seks siste versjonene av den lokale gatewayen.
• Oppdater egendefinerte datakoblinger, drivere og biblioteker når det er nødvendig.

Merk

Eieren av gatewayen må manuelt bruke gatewayoppdateringer for hver gateway. Derfor er det viktig å planlegge en prosess for å oppdatere gatewayene regelmessig.

Tips

Når du arbeider med Power Query Online-opplevelsen, bruker Power Query-motoren den nyeste versjonen av Power Query som er tilgjengelig. Når du imidlertid bruker en gateway til å bruke transformasjoner, bruker den versjonen som er installert på gatewaymaskinen. For å sikre en konsekvent brukeropplevelse er det viktig å holde gateway-maskinene oppdatert.

Resten av denne delen beskriver hvordan du oppdaterer gatewayprogramvaren.

Installere oppdateringer på utviklings- eller testgatewayer

Det er viktig å holde gatewayene oppdatert for å unngå uventede forstyrrelser, og også dra nytte av de nyeste forbedringene. Oppdateringer kan likevel få uventede konsekvenser for gatewayens ytelse og funksjon. Hvis du vil unngå å påvirke forretningskritiske løsninger, bør du først installere gateway-programvareoppdateringer til en utvikling eller testgateway (før de brukes på gatewayer som støtter produksjonsmiljøer).

Valider oppdateringer

Du kan teste gatewayer ved først å bruke oppdateringen på gatewayer som støtter utviklings- og testmiljøer.

Vurder følgende punkter når du validerer gatewayoppdateringer.

• Definer gjentakbare testbetingelser: Du bør definere en liste over gjentakende testbetingelser for å hjelpe deg med å sikre at du tester alle relevante gatewayoperasjoner og datakilder. Du kan for eksempel identifisere hvilke rapporter og semantiske modeller som anses som kritiske og krever validering. Det kan også hende du har noen samsvarskrav som kvalifiserer som gjentakbare testbetingelser.
• Bruk et sett med testrapporter: Behold et sett med rapporter som skal brukes til funksjonell testing hver gang gatewayen oppdateres. Disse rapportene hjelper deg med raskt å validere testbetingelsene som kan gjentas. Disse testrapportene viser ofte bare totaler og antall. Målet ditt er å sikre at du tester tilgang, gjengivelse og oppdatering for:
  • Hver ofte brukte datakilde.
  • Hver nøkkeltype for dataelement, som de mest kritiske semantiske modellene.
  • Ulike lagringsmoduser, for eksempel import og DirectQuery.
• Identifiser forretningskritiske rapporter: Ha tilgang til (eller kopier av) forretningskritiske rapporter som du kan teste for den nye oppdateringen. Disse rapportene kan hjelpe deg med å sikre at dataene kan oppdateres, og DirectQuery-rapporter fungerer som forventet.
• Automatiser testprosesser: Bruk REST-API-ene for Power BI til å teste dataoppdateringen for import av dataelementer og til å evaluere DAX-spørringer. Kontroller at du kan fange opp og logge oppdateringsfeil eller spørringsfeil.

Viktig

Vi anbefaler på det sterkeste at du tester gatewayoppdateringer på utviklings- og testklyngen før du bruker dem på produksjon. Testing av oppdateringer er viktig fordi det ikke er noen tilbakerullingsprosess. Som et alternativ, før du starter oppdateringen, kan du opprette et VM-bilde, som er en komplett kopi av filsystemstrukturen og dataene på maskinen.

Installer oppdateringer på produksjon

Når du har validert gatewayoppdateringen, bør du bruke oppdateringen på alle gatewayer som støtter produksjonsmiljøer. En gateway er utilgjengelig mens den oppdateres, så du bør være konsekvent i når og hvordan du oppdaterer gatewayene.

Vurder følgende punkter om oppdatering av gatewayer.

• I den sentraliserte portalen dokumenterer du gjeldende versjon av gatewayen.
• Bruk oppdateringer i perioder med historisk lav gatewaybruk.
• Bruk en konsekvent tidsplan når du tester og bruker oppdateringer. Hvis månedlige oppdateringer er for ofte, må du sørge for at gatewayene oppdateres minst kvartalsvis.
• Oppdater én gateway-klyngemaskin om gangen. Ved å rotere gjennom hver maskin kan du unngå nedetid.

Oppdater legitimasjon

For datakildetilkoblinger som krever lagret legitimasjon, må du kanskje rotere legitimasjonen regelmessig. Organisasjonen kan for eksempel ha en policy som krever ofte tilbakestilling av passord. Denne praksisen er også nyttig når et nøkkelteammedlem forlater organisasjonen. Hvis du vil forbedre effektiviteten, kan du bruke REST-API-ene for Power BI til å oppdatere legitimasjonen.

Sjekkliste – Når du administrerer datagatewayer, omfatter viktige beslutninger og handlinger:

• Opprett datakildetilkoblinger: Konfigurer datakildetilkoblingene for vanlige organisatoriske datakilder. Sørg for at tilkoblingene følger klare, konsekvente navnekonvensjoner.
• Dokumentgatewayer og datakilder: Opprett konsis dokumentasjon om gatewayer og tilkoblinger. Sørg for at denne dokumentasjonen er lett tilgjengelig fra den sentraliserte portalen for gatewayeiere og administratorer.
• Behandle tilkoblingsforespørsler: Opprett en prosess for å samle inn og behandle tilkoblingsforespørsler. Avgjør om det kreves en godkjenningsprosess for tilkoblingsforespørsler. Vurder å automatisere prosessen ved hjelp av REST-API-ene for Power BI.
• Klargjør gatewayroller: Bruk prinsippet om minst mulig tilgang til å tilordne enkeltpersoner til gateway-roller. Vurder å legge til datakildeforvaltere i Koble til ionoppretteren eller Koble til ionoppretteren med delingsrolle, slik at de kan bidra til tilkoblingsbehandling.
• Klargjør tilkoblingsroller: Tilordne innholdsopprettere (og forbrukere når det er aktuelt) til tilkoblingsroller, slik at de kan bruke gatewayen. Begrens brukere med deling til de brukerne som vil dele tilkoblingen på en ansvarlig måte, og hjelp til regelmessig gjennomgang og administrering av tilgang.
• Opprett kortfattet brukerdokumentasjon: Dokumenter nøkkelelementene som er viktige for innholdsopprettere, for å finne og bruke gatewayen og tilkoblingene. Plasser dokumentasjonen et sentralt og lett tilgjengelig for brukerfellesskapet, for eksempel en sentralisert portal eller et SharePoint-støtteområde.
• Dokumenter og lagre gjenopprettingsnøkler nøye: Lagre gjenopprettingsnøkler på et trygt og sikkert sted som er tilgjengelig for mer enn ett gruppemedlem. Sørg for at de enkelt kan bli funnet hvis du trenger å gjenopprette gatewayen.
• Opprett en prosess for å installere oppdateringer: Bestem hvor ofte du installerer gateway-programvareoppdateringer og prosessen som skal følges. Mål å oppdatere gatewayer innen én til tre måneder etter oppdateringsutgivelsen.
• Installer gatewayoppdateringer først ved utvikling og test: Sørg for at utvikling og testgatewayer oppdateres før produksjon og brukes til første testing.
• Test gateway-oppdateringer før de brukes på produksjonsgatewayer: Konfigurer en prosess for å teste månedlige gatewayoppdateringer ved hjelp av gjentakende testbetingelser og elementer.
• Installer gatewayoppdateringer raskt og regelmessig på produksjon: Kontroller at produksjonsgatewayer holdes oppdatert.
• Oppdater tilkoblingslegitimasjon: Oppdater lagret legitimasjon ved behov ved hjelp av tilkoblinger.

Overvåke, overvåke og optimalisere gatewayer

Gatewayer er en viktig del av fabric-dataintegrering. Hvis du vil unngå avbrudd og redusere risikoen, bør du overvåke og regelmessig overvåke gatewayene i leieren.

Overvåking av gatewayer bidrar til å:

• Redusere styringsrisiko.
• Forhindre problemer.
• Undersøk hendelser, for eksempel ytelsesproblemer eller feil ved dataoppdatering.

Tabellen nedenfor gir en oversikt over de vanlige problemene du kan støte på når du administrerer en datagatewayklynge, og hvordan du overvåker eller undersøker problemer.

Potensielt problem	Type problem	Slik overvåker eller undersøker du problemet
For mange gatewayer	Styring	• Administrasjonssenter for Power Platform • Gateway PowerShell-cmdleter • REST-API-er for Power BI
Overdeling av gateway	Styring	• Administrasjonssenter for Power Platform • Gateway PowerShell-cmdleter • REST-API-er for Power BI • Aktivitetslogg for Power BI
Gatewayen er frakoblet	Ytelse og tilgjengelighet	• Administrasjonssenter for Power Platform • Overvåking av gateway-maskin • Gatewaylogger
Gateway-feil	Ytelse og tilgjengelighet	• Gatewaylogger
Spørringsfeil	Ytelse og tilgjengelighet	• Gatewaylogger • Gatewaylogger (ekstra logging)
Trege oppdateringer eller spørringer	Ytelse og tilgjengelighet	• Overvåking av gateway-maskin • Hendelseslogg for Windows • Windows-ytelsestellere • Gatewaylogger • Gatewaylogger (ekstra logging) • Serverovervåkingsverktøy

Merk

Hvis du vil ha mer informasjon om overvåking og overvåking av gatewayer, kan du se:

• Overvåke og optimalisere lokal datagatewayytelse
• Planlegging av Power BI-implementering: Overvåking på datanivå
• Planlegging av Power BI-implementering: Overvåking på leiernivå

Tips

Hvis du bruker Fabric-kapasitet, kan verktøyene i Fabric gi deg de ideelle komponentene for å bygge og organisere en organisatorisk gateway-overvåkingsløsning. Du kan for eksempel:

• Bruk Data Factory til å kopiere gatewaylogger og lande dem i OneLake.
• Bruk notatblokker til å samle inn gatewayinformasjon programmatisk ved hjelp av REST-API-ene for Power BI og transformere gateway-loggfiler til tabeller.
• Bruk Power BI til å opprette en semantisk modell og rapport om gatewaytilstand.
• Bruk dataaktivator til å sende varsler til gatewayeiere og administratorer når det er avvik eller forstyrrelser.

Overvåke gatewayer

Du bør jevnlig se gjennom hvor mange gatewayer som er installert på leieren, og hvem som installerte dem. Du kan overvåke utbredelsen fra tilkoblings- og gatewaysiden i Stoff-portalen og administrasjonssenteret for Power Platform. Begge visningene gir en kortfattet, funksjonell oversikt over alle gatewayene du har tilgang til. Administratorer bør se gjennom denne informasjonen regelmessig.

Merk

Du kan også programmatisk hente en liste over gatewayer ved hjelp av PowerShell-cmdleter eller ved hjelp av REST-API-ene for Power BI. Du kan også identifisere installasjonshendelser for gateway ved hjelp av aktivitetsloggen.

Vurder å kombinere denne informasjonen med aggregert analyse om antallet og typen gateway-datakilder. Du kan presentere denne informasjonen i konsolidert, tenantomfattende styring eller overvåkings- og overvåkingsrapportering.

Når du overvåker utbredelsen av gatewayen, bør du rette oppmerksomheten mot følgende måledata.

• Økende antall gatewayer eller installasjonsprogram: Kontroller at du undersøker uventede nye gatewayer eller installasjonsprogram.
• Redundans i tilkoblinger på tvers av gatewayer: Prøv å konsolidere tilkoblinger for å unngå ekstra vedlikehold av gatewayene.
• Uventede installasjoner eller gatewayer: Kontroller at nye installasjoner eller gatewayer har gjennomgått en godkjenningsprosess før de installeres.
• Uventede gatewaymaskiner, tilkoblinger eller konfigurasjon: Kontroller at du identifiserer eventuelle uregelmessige gatewayegenskaper, for eksempel gatewayer som er installert på brukermaskiner eller tilkoblinger til lokale filer. Identifiser også innstillinger som skaper risiko, for eksempel ignorering av personvernnivå.

Samle inn og analysere gatewaylogger

Hver gateway-maskin produserer detaljerte logger som du kan bruke til å identifisere og løse problemer. Disse loggene er en samling detaljerte tekniske filer som er lagret på gateway-maskinen. Du kan også midlertidig aktivere flere logger fra den lokale gateway-appen for å samle inn mer detaljert informasjon om spørringer og tidsberegninger.

Hvis du vil unngå å innføre nettverksforsinkelser, anbefaler vi at du tillater at gatewayloggene skrives til den lokale gatewaymaskinen. Du kan imidlertid velge å endre banen der loggene er skrevet med konfigurasjonsfilene for gatewayen. Du kan også oppdatere hvor lenge loggene beholdes. Lag alltid en kopi av konfigurasjonsfilene før du redigerer dem.

Opprett en løsning for dataintegrering for å samle inn og konsolidere loggfilene fra hver gateway-maskin, slik at du kan analysere dataene. Ideelt sett bør denne prosessen automatiseres og utdata til en analytisk rapport for enkelt å vise alle gatewayer og identifisere avvik.

Tips

Vurder å bruke datavarsler til å varsle gatewayadministratorer og opprettere av datakildetilkobling om avvikende aktivitet for henholdsvis gatewayer og tilkoblinger. På den måten kan de utføre umiddelbare korrigerende handlinger.

Overvåk gateway-maskintilstand

Tilstanden til gatewayen er avhengig av tilstanden til serveren. For å unngå forstyrrelser bør du overvåke gateway-maskiner for å oppdage når en maskin ikke fungerer bra eller er frakoblet.

Tips

Kontroller at gatewaymaskinen er lagt til i alle virksomhetsovervåkingsverktøy som organisasjonen bruker til å overvåke servere.

Optimalisere og feilsøke gatewayer

Når det oppstår problemer med en gateway, må du undersøke og identifisere problemet. Feilsøking innebærer vanligvis å undersøke gatewayloggene som er beskrevet i forrige del, og teste ulike optimaliseringer for å se om de løser problemet.

Her er noen vanlige gatewayoptimaliseringer.

• Endre fra spoling til strømming: Gatewayer vil som standard spole data til gatewaymaskinen når de evaluerer en spørring. Det resulterer i midlertidig lagring av data før den overføres til skyen. Spoling kan være tregere enn alternativet for strømming, der data overføres direkte. Du kan endre denne innstillingen i konfigurasjonsfilene for gatewayen.
• Antivirusskanning:Hvis du utelater bestemte mapper fra antivirusskanning på gateway-maskinen, kan det forbedre ytelsen når du bruker antivirusprogramvare på filnivå.
• Planlegger å skalere opp eller skalere ut: Vurder når du skal skalere opp en gateway-klynge ved å legge til flere ressurser på gateway-maskinen, eller skaler ut klyngen ved å legge til en annen gateway på en annen maskin.

Viktig

VNet-gatewayer har én enkelt maskinvarekonfigurasjon, som ikke kan skaleres eller endres.

Merk

Hvis du vil ha mer informasjon om optimalisering og feilsøking av gatewayer, kan du se:

• Feilsøke den lokale gatewayen
• Feilsøke en VNet-nettverksgateway
• Planlegge, skalere og vedlikeholde en forretningskritisk gatewayløsning

Sjekkliste – Når du overvåker gatewayer, omfatter viktige beslutninger og handlinger:

• Overvåk gateway-maskiner: Sørg for at gatewayer installeres på maskiner som overvåkes av bedriftsovervåkingsløsninger. Ellers må du sørge for at du kan oppdage når disse maskinene ikke fungerer bra.
• Mål utbredelse av gateway: Overvåk utviklingen av hvor mange gatewayer som er installert i leieren over tid.
• Samle inn og analysere gatewaylogger: Opprett en løsning for automatisk å samle inn og kombinere loggfilene fra de forskjellige gateway-maskinene. Analyser disse filene for å trekke ut meningsfull informasjon. Vurder å sette opp to typer analytiske overvåkingsløsninger: én for varsler og handling, og en annen for utforskende analyse av grunnårsak når det oppstår problemer.
• Bekreft roller og ansvarsområder: Sørg for at roller og ansvar er definert for overvåking, optimalisering og feilsøking.

Relatert innhold

Hvis du vil ha mer informasjon, handlinger, beslutningskriterier og anbefalinger for å hjelpe deg med implementeringsbeslutninger for Power BI, kan du se planlegging av Power BI-implementering.