Grootte van on-premises gegevensgateway

Dit artikel is bedoeld voor Power BI-beheerders die de on-premises gegevensgateway moeten installeren en beheren.

De gateway is vereist wanneer Power BI toegang moet hebben tot gegevens die niet rechtstreeks via internet toegankelijk zijn. Het kan worden geïnstalleerd op een on-premises server of iaaS (Infrastructure as a Service).

Gatewayworkloads

De on-premises gegevensgateway ondersteunt twee workloads. Het is belangrijk dat u deze workloads eerst begrijpt voordat we de grootte en aanbevelingen van de gateway bespreken.

Werkbelasting gegevens in cache

Met de gegevensworkload met cache worden brongegevens opgehaald en getransformeerd voor het laden in semantische Power BI-modellen (voorheen gegevenssets genoemd). Dit doet u in drie stappen:

  1. Verbinding maken ion: de gateway maakt verbinding met brongegevens.
  2. Gegevens ophalen en transformeren: gegevens worden opgehaald en zo nodig getransformeerd. Waar mogelijk pusht de Power Query mashup-engine transformatiestappen naar de gegevensbron. Dit wordt ook wel query folding genoemd. Als dit niet mogelijk is, moeten transformaties door de gateway worden uitgevoerd. In dit geval verbruikt de gateway meer CPU- en geheugenresources.
  3. Overdracht: gegevens worden overgebracht naar de Power BI-service: een betrouwbare en snelle internetverbinding is belangrijk, met name voor grote gegevensvolumes.

Diagram van cachegegevens met de on-premises gegevensgateway die verbinding maakt met on-premises bronnen.

Live Verbinding maken ion- en DirectQuery-workloads

De workload Live Verbinding maken ion en DirectQuery werkt voornamelijk in de passthrough-modus. De Power BI-service verzendt query's en de gateway reageert met queryresultaten. Over het algemeen zijn queryresultaten klein in grootte.

Voor deze workload zijn CPU-resources vereist voor het routeren van query's en queryresultaten. Meestal is er veel minder vraag naar CPU dan vereist is voor de cachegegevensworkload, met name wanneer het nodig is om gegevens te transformeren voor caching.

Betrouwbare, snelle en consistente connectiviteit is belangrijk om ervoor te zorgen dat rapportgebruikers responsieve ervaringen hebben.

Diagram van Live Verbinding maken ion en DirectQuery met de on-premises gegevensgateway die verbinding maakt met on-premises bronnen.

Overwegingen bij het aanpassen van de grootte

Het bepalen van de juiste grootte voor uw gatewaycomputer kan afhankelijk zijn van de volgende variabelen:

  • Voor gegevensworkloads in de cache:
    • Het aantal gelijktijdige semantische modelvernieuwing
    • De typen gegevensbronnen (relationele database, analytische database, gegevensfeeds of bestanden)
    • Het gegevensvolume dat moet worden opgehaald uit gegevensbronnen
    • Transformaties die nodig zijn om te worden uitgevoerd door de Mashup-engine van Power Query
    • Het volume aan gegevens dat moet worden overgedragen naar de Power BI-service
  • Voor Live Verbinding maken ion- en DirectQuery-workloads:
    • Het aantal gelijktijdige rapportgebruikers
    • Het aantal visuals op rapportpagina's (elke visual verzendt ten minste één query)
    • De frequentie van updates in de cache van power BI-dashboardquery's
    • Het aantal realtime rapporten met de functie Pagina automatisch vernieuwen
    • Of semantische modellen beveiliging op rijniveau afdwingen (RLS)

Over het algemeen vereisen live-Verbinding maken ion- en DirectQuery-workloads voldoende CPU, terwijl cachegegevensworkloads meer CPU en geheugen vereisen. Beide workloads zijn afhankelijk van een goede verbinding met de Power BI-service en de gegevensbronnen.

Notitie

Power BI-capaciteiten leggen limieten op voor modelvernieuwing parallellisme en live Verbinding maken ion- en DirectQuery-doorvoer. Er is geen zin om de grootte van uw gateways te wijzigen om meer te leveren dan wat de Power BI-service ondersteunt. Limieten verschillen per Premium-SKU (en een vergelijkbare grootte A SKU). Zie Microsoft Fabric-capaciteitslicenties en wat is Power BI Premium? (Capaciteitsknooppunten).

Belangrijk

Soms verwijst dit artikel naar Power BI Premium of de capaciteitsabonnementen (P-SKU's). Houd er rekening mee dat Microsoft momenteel aankoopopties consolideert en de Power BI Premium-SKU's per capaciteit buiten gebruik stelt. Nieuwe en bestaande klanten moeten overwegen om in plaats daarvan F-SKU's (Fabric-capaciteitsabonnementen) aan te schaffen.

Zie Belangrijke update voor Power BI Premium-licenties en veelgestelde vragen over Power BI Premium voor meer informatie.

Aanbevelingen

Aanbevelingen voor gatewaygrootte zijn afhankelijk van veel variabelen. In deze sectie bieden we u algemene aanbevelingen waarmee u rekening kunt houden.

Initiële grootte

Het kan lastig zijn om de juiste grootte nauwkeurig te schatten. We raden u aan om te beginnen met een machine met ten minste 8 CPU-kernen, 8 GB RAM-geheugen en meerdere Gigabit-netwerkadapters. Vervolgens kunt u een typische gatewayworkload meten door CPU- en geheugensysteemtellers te registreren. Zie De prestaties van de on-premises gegevensgateway bewaken en optimaliseren voor meer informatie.

Connectiviteit

Plan de best mogelijke connectiviteit tussen de Power BI-service en uw gateway en uw gateway en de gegevensbronnen.

  • Streven naar betrouwbaarheid, snelle snelheden en lage, consistente latenties.
  • Elimineren of verminderen machinehops tussen de gateway en uw gegevensbronnen.
  • Verwijder netwerkbeperking die wordt opgelegd door de firewallproxylaag. Zie Power BI-URL's toevoegen aan uw acceptatielijst voor meer informatie over Power BI-eindpunten.
  • Stel Azure ExpressRoute in om persoonlijke, beheerde verbindingen met Power BI tot stand te brengen.
  • Controleer voor gegevensbronnen in Virtuele Azure-machines of de VM's zijn gekoppeld aan de Power BI-service.
  • Voor Live Verbinding maken ion-workloads naar SQL Server Analysis Services (SSAS) met dynamische beveiliging op rijniveau, zorgt u voor een goede verbinding tussen de gatewaycomputer en de on-premises Active Directory.

Clustering

Voor grootschalige implementaties kunt u een gateway maken met meerdere clusterleden. Clusters voorkomen single points of failure en kunnen verkeer verdelen over gateways. U kunt:

  • Installeer een of meer gateways in een cluster.
  • Isoleer workloads naar zelfstandige gateways of clusters van gatewayservers.

Zie On-premises gegevensgateway clusters met hoge beschikbaarheid en taakverdeling beheren voor meer informatie.

Semantisch modelontwerp en -instellingen

Semantisch modelontwerp en hun instellingen kunnen van invloed zijn op gatewayworkloads. Als u de workload van de gateway wilt verminderen, kunt u rekening houden met de volgende acties.

Voor semantische importmodellen:

  • Minder frequente gegevensvernieuwing instellen.
  • Stel incrementeel vernieuwen in om de hoeveelheid gegevens die moet worden overgedragen te minimaliseren.
  • Zorg er indien mogelijk voor dat query folding plaatsvindt.
  • Met name voor grote gegevensvolumes of behoefte aan resultaten met lage latentie, converteert u het ontwerp naar een DirectQuery- of samengesteld model.

Voor semantische DirectQuery-modellen:

  • Optimaliseer gegevensbronnen, model- en rapportontwerpen. Zie richtlijnen voor DirectQuery-modellen in Power BI Desktop voor meer informatie.
  • Maak aggregaties om resultaten op een hoger niveau in de cache op te cachen om het aantal DirectQuery-aanvragen te verminderen.
  • Beperk intervallen voor het automatisch vernieuwen van pagina's in rapportontwerpen en capaciteitsinstellingen.
  • Met name wanneer dynamische beveiliging op rijniveau wordt afgedwongen, beperkt u de updatefrequentie van de dashboardcache.
  • Met name voor kleinere gegevensvolumes of voor niet-vluchtige gegevens converteert u het ontwerp naar een import- of samengesteld model.

Voor semantische live-Verbinding maken ionmodellen:

  • Met name wanneer dynamische beveiliging op rijniveau wordt afgedwongen, beperkt u de updatefrequentie van de dashboardcache.

Raadpleeg de volgende bronnen voor meer informatie over dit artikel: