Planlegge, skalere og vedlikeholde en forretningskritisk gatewayløsning

Denne artikkelen er ment for alle som planlegger å distribuere en lokal datagateway i et forretningskritisk scenario. En lokal datagateway er forretningskritisk hvis den er avgjørende for normal drift av virksomheten og håndterer forretningskritiske data.

Hvis forretningskritiske gatewayer ikke administreres riktig, kan det hende du opplever mislykkede spørringer eller treg ytelse. Når du planlegger, skalerer og vedlikeholder den forretningskritiske gatewayløsningen på riktig måte, kan sannsynligheten for et problem med forretningspåvirkning minimeres.

Terminologi

Følgende viktige termer brukes i denne artikkelen:

• Gateway: Det lokale datagatewayprogrammet som er installert på en datamaskin.
• Gateway-server: En Windows-datamaskin (virtuell maskin eller fysisk datamaskin/server) som har det lokale datagatewayprogrammet installert.
• Gateway-klynge: Et sett med gatewayer som fungerer sammen (og kan være belastningsbalansert).
• Gateway-medlem: En gateway som er en del av en gateway-klynge.

Bildet nedenfor viser relasjonen mellom begrepene som er definert ovenfor.

Anbefalinger for forretningskritiske gatewayer

For forretningskritiske gatewayer må gatewayene distribueres og administreres riktig for å sikre høy tilgjengelighet, god ytelse og vedlikeholdbar skalerbarhet. Distribusjon av gatewayer på feil måte kan føre til dårlig ytelse, mislykkede spørringer og problemer med å diagnostisere potensielle problemer. Det kan også hindre muligheten til å skalere gatewayene opp og ut etter hvert som bruken vokser.

Følg anbefalingene i de neste inndelingene for å sikre optimal skalerbarhet, ytelse og gjennomstrømming.

Kjenn alle gjenopprettingsnøklene for gatewayen

Kontroller at alle gateway-gjenopprettingsnøkler er kjent og oppbevart på et trygt sted. Uten en gjenopprettingsnøkkel kan ikke gatewayer gjenopprettes eller nedgraderes. Denne begrensningen er etter utforming. Hvis du mister gjenopprettingsnøklene, er det eneste alternativet å opprette nye gatewayer og gjenopprette datakildene. Du kan heller ikke legge til nye gatewayer i klyngen uten gjenopprettingsnøkkelen, noe som vil begrense fremtidig skalerbarhet.

Lagre gjenopprettingsnøklene på et sikkert sted på samme måte som du lagrer administrativ legitimasjon, for eksempel en passordsikker, som bare kan åpnes av autoriserte administratorer.

Hvis du for øyeblikket ikke kjenner alle gjenopprettingsnøklene for gatewayen, er dette en betydelig forretningsrisiko. Opprett umiddelbart nye gateway-klynger og begynn å overføre arbeidsbelastninger til gateway-klyngene.

Arbeidsbelastninger for utvikling og forretningskritiske arbeidsbelastninger

Skill utviklingsarbeidsbelastninger fra forretningskritiske ved å konfigurere én eller flere gateway-klynger for utvikling og én eller flere produksjonsgatewayklynger som beskrevet nedenfor.

Bruk en gateway-klynge for utvikling til å teste ut nye semantiske modeller, rapporter, spørringer og så videre. Når en ny arbeidsbelastning er bekreftet, overfører du den til en forretningskritisk gatewayklynge. Denne prosessen hindrer nye, utestede eller eksperimentelle arbeidsbelastninger fra å ha ytelsespåvirkninger på produksjonsarbeidsbelastninger.

Bruk også klyngen(e) for utviklingsgateway til å teste nye gateway-oppdateringer før du bruker oppdateringer på de forretningskritiske gatewayklyngene. Nye gatewayoppdateringer bør distribueres i minst 24 timer i klyngen(e) for utviklingsgatewayen før de brukes på forretningskritiske gatewayklynger.

Bruke flere gateway-klynger

Hvis du oppretter en gateway-klynge for et stort antall brukere i organisasjonen, må du opprette flere gateway-klynger basert på forretningsenheter eller mindre for å begrense potensiell ytelsespåvirkning til et lite delsett av brukere.

Vi anbefaler ikke at én enkelt forretningskritisk gatewayklynge brukes for et helt selskap (med mindre firmaet er lite). I et enkelt gateway-klyngescenario kan én bruker tenkes å sende en spørring som forårsaker en betydelig ytelsespåvirkning for all trafikk på tvers av gatewayen. Hvis gatewayen brukes i hele firmaet, kan ytelsespåvirkningen påvirke hele firmaet. Når en gateway-klynge brukes på tvers av et helt firma, kan det også være vanskeligere for deg å identifisere hvilken spørring som kan forårsake et ytelsesproblem når du bruker funksjonen for overvåking av gateway-ytelse.

Bruk gatewayens funksjoner for høy tilgjengelighet og belastningsfordeling

Bruk alltid gatewayens funksjoner for høy tilgjengelighet og belastningsfordeling for alle forretningskritiske gatewayklynger.

• Høy tilgjengelighet: Eliminerer å ha ett enkelt feilpunkt.
• Belastningsfordeling: Distribuerer automatisk arbeidsbelastningen på tvers av alle gateway-servere i klyngen.

Konfigurer minst to gatewayer per gateway-klynge i tilfelle en gateway blir frakoblet av en eller annen grunn. Dette oppsettet sikrer at én enkelt gateway-feil ikke fører til at hele gatewayklyngen mislykkes. I tillegg kan CPU, minne, samtidighetsgrenser aktiveres på gatewayene for bedre å distribuere belastningen på tvers av gateway-klyngen.

Planlegge og vedlikeholde skalerbarhet for gatewayklynge

Når du konfigurerer en gateway-klynge ved hjelp av våre anbefalte retningslinjer for maskinvare og programvare, sikrer du at klyngen kjører med god ytelse. Gatewayer som ikke skaleres riktig, kan føre til dårlig ytelse. Det er mange faktorer du må vurdere å ha god ytelse på gateway-klyngen.

Fastslå maskinvarespesifikasjoner for gatewayserver

Gateway-serverspesifikasjoner (CPU, minne, disk og så videre) er en viktig faktor, som i de fleste tilfeller brukes Power Query-transformasjonene på dataene på gateway-serveren. Som sådan må en gateway-server ha nok ressurser, minne og prosessorkraft til å håndtere alle datatransformasjonene.

Når du må velge en serverstørrelse, finnes det to måledata som er viktigst: Minne og CPU. Du trenger både rikelig minne og CPU-kraft for å behandle trinnene for power query-datatransformasjon på gatewayen. Det er viktig at gatewayserveren er kraftig nok til å behandle den høyeste arbeidsbelastningen du har. Hvis gatewayserveren ikke kan håndtere arbeidsbelastningen, vil direktespørringen eller dataoppdateringen mislykkes. Det er også viktig å forstå hvor mange spørringer som utføres samtidig.

Disse forskjellige spørringsalternativene har en annen effekt på gatewayserveren.

Spørringstype	Grensefaktor
Importer	Minne
DirectQuery	CPU
Direkte Koble til	CPU

Under en import må hele datasettet spørres og behandles, noe som er en tung minneoppgave. Denne importen tar ofte lengre tid også. DirectQueries og Live Koble til ions er vanligvis CPU tunge. I de fleste tilfeller utføres direkte spørringer mange ganger for å behandle bare en liten del av dataene. Siden bare en liten del av dataene behandles, er ikke disse direkte spørringene vanligvis en tung oppgave i minnet. Fordi spørringene utføres mange ganger ved behov, kan dette imidlertid være CPU-intensivt.

Vurder å optimalisere gatewayserveren for minne eller CPU, avhengig av arbeidsbelastningen.

Når du skal skalere en gateway-klynge

Skalering er et viktig aspekt ved en forretningskritisk gatewayklynge. Etter hvert som bruken med gateway-klyngen vokser, må gateway-klyngen skaleres opp og/eller skaleres ut for å sikre god ytelse. Vi anbefaler at du begynner å skalere ut en gateway-klynge hvis du tidligere har skalert opp gatewayene i klyngen.

Skalering og distribusjon av trafikkbelastning på tvers av individuelle noder i en klynge er en kompleks prosess som varierer avhengig av hvert enkelt scenario. Selv om det ikke finnes noen definitiv modell for å sikre at all gatewaytrafikk blir forutsigbart vedlikeholdt, indikerer grensene nedenfor et skaleringsbehov. Generelt anbefaler vi at du skalerer ut (legger til noder i klyngen) fortrinnsvis for å skalere opp (øke CPU, RAM eller diskplass på individuelle noder). Skalering ut har en tendens til å være mer effektiv generelt i evnen til systemet som helhet for å håndtere ekstra trafikk. Oppskalering har også en positiv innvirkning på total båndbredde som klyngen kan behandle, mens oppskalering vanligvis ikke gjør det. Når én eller flere gatewaynoder viser indikasjoner på å nå terskler som er beskrevet nedenfor, bør skalering av klyngen vurderes på det sterkeste.

• CPU: CPU er over 80% for lengre perioder, men sporadiske korte (under 5 minutter) pigger som maks ut CPUer er ikke unormale.

• RAM: Tilgjengelig minne dips under 20% regelmessig.

• Disk: Frigjør diskplass under 5 GB ofte. Denne dip kan også indikere et behov for å konfigurere hurtigbufring eller utskriftskø kataloger mer strategisk.

• Samtidighet: Kjører mer enn 40 spørringer samtidig på én enkelt node.

Siden oppdateringer og spørringer distribuert på tvers av gatewaynoder kan ha svært forskjellige profiler, anbefaler vi også ekstra gransking på langvarige eller minneintensive jobber. Spørringsoptimalisering i slike tilfeller kan ha stor innvirkning på ytelse og skalerbarhet, ikke bare for individuelle rapporter og oppdateringer, men på systemet som helhet. Vi anbefaler at du isolerer aktuelle oppdateringer til en enkelt dedikert gateway-klynge for å evaluere ytelsesegenskaper og utføre optimalisering ved hjelp av diagnostikk for spørringsplan, foldingsindikatorer og alle andre publiserte ytelsesanbefalinger. Denne isolasjonen minimerer mengden data som hentes og mengden etter behandling som kreves. Denne isolasjonen kan også brukes som en langsiktig strategi for å sequester langvarige ETL-jobber til en dedikert gateway-klynge for å redusere strid med andre typiske oppdateringer på tvers av organisasjonen.

Skalere en gateway-klynge

Oppskalering er når du øker spesifikasjonene (CPU, minne, disk og så videre) for gateway-serverne.

Oppskalering kan være nødvendig hvis maksimal CPU eller minne nås når gatewayen utfører én eller flere spørringer. En spørring kan bare kjøres på én gateway-server, og derfor må gatewayserveren ha nok ressurser tilgjengelig til å behandle hele spørringen sammen med de resulterende dataene.

Skalere ut en gateway-klynge

Skalering er nødvendig hvis gatewayserveren allerede har høye spesifikasjoner (gatewayserveren har med andre ord allerede blitt skalert opp), eller du har nådd grensene for hva en enkelt gateway-server kan administrere på grunn av antall samtidige spørringer som kjøres. Bred belastningsøkning på tvers av hele gatewaymedlemssettet er en god indikasjon på at skalering av en klynge ved å legge til noder er riktig handlingsforløp. Når du skal skalere en gateway-klynge , angis bestemte terskler som angir når det er på tide å skalere. Hvis du vil ha mer informasjon om skalering, kan du gå til Bruk gatewayens funksjoner for høy tilgjengelighet og belastningsfordeling.

Skalering ved å opprette nye gateway-klynger

Hvis ressursbruken til gateway-klyngen er høy eller et svært stort antall brukere er avhengige av en gateway-klynge, kan du opprette en ny gateway-klynge. Et delsett av arbeidsbelastningen kan deretter overføres til den nye gateway-klyngen. Når et stort antall brukere er avhengige av én enkelt gateway-klynge, øker sannsynligheten for at en bruker kan sende en spørring som forårsaker en betydelig ytelseseffekt på tvers av hele gatewayklyngen, betydelig.

Et eksepsjonelt stort antall brukere som er avhengige av én enkelt gateway-klynge, er en indikator på at en ny gateway-klynge bør opprettes.

Overvåking og feilsøking av gatewayytelse

Det er viktig å overvåke den generelle ytelsen til forretningskritiske gatewayer ved hjelp av funksjonen for overvåking av gateway-ytelse . Du kan også bruke denne funksjonen til å feilsøke ytelsesproblemer, identifisere flaskehalser og identifisere spørringer som påvirker den generelle gatewayytelsen. Denne funksjonen er også et viktig verktøy for å hjelpe deg med å finne ut når du skal skalere en gateway-klynge.

Hvis du identifiserer en spørring som har stor innvirkning på gatewayen, noe som resulterer i dårlig generell ytelse, kan du kanskje skrive om spørringen for å være mer effektiv og minimere ytelseseffekten.

Hvis Microsoft identifiserer dårlig ytelse forårsaket av en gateway eller en gateway-relatert komponent, for eksempel en Power BI Premium-kapasitet som er overbelastet, må den overbelastede komponenten løses ved å skalere eller redusere belastningen. Microsoft undersøker ikke dårlig ytelse når en gateway eller en gateway-relatert komponent er overbelastet.