Power BI:n vuokralaisten siirtomallit ja -strategiat

Organisaatiot kohtaavat erilaisia vuokralaisten siirto-skenaarioita Power BI:ssä, joita ohjaavat fuusiot ja yritysostot, yritysten myynnit, tietojen hallintavaatimukset tai alueelliset vaatimustenmukaisuusvaatimukset. Vuokralaisten siirrot ovat monimutkaisia tehtäviä, jotka vaativat huolellista suunnittelua, kattavia varausstrategioita ja järjestelmällistä toteutusta. Tämä artikkeli tarjoaa ohjeita yritystason Power BI -vuokralaisten migraatioihin, mukaan lukien päätöskehykset, joiden avulla voidaan määrittää, onko migraatio tarpeellista, sekä yksityiskohtaiset toteutusmenetelmät eri migraatiomalleille.

Important

Vuokralaisten muuttoihin liittyy merkittäviä riskejä ja se vaatii laajaa manuaalista työtä. Microsoft ei tarjoa suoraa tukea sisällön siirtämiseen vuokralaisten välillä tai saman vuokralaisen sisällä alueellisissa siirroissa. Ennen siirtymistä arvioi huolellisesti vaihtoehtoja, kuten monimaantieteellisiä kapasiteetteja, jotka voivat käsitellä monia skenaarioita ilman täyden vuokralaisen muuton monimutkaisuutta ja riskiä.

Vuokralaisten siirtoskenaariot

Power BI:n vuokralaisten siirto kattaa kolme skenaariota. Tunnista, mikä niistä sopii tilanteeseesi ennen kuin suunnittelet muuttoa.

Esimerkkitilanne Description Tyypillinen laukaisin
Vierekkäinen (vuokralaisten välinen siirtymä) Kaksi erillistä Microsoft 365 -vuokralaista toimii rinnakkain. Artefaktit siirretään lähdevuokralaiselta kohdevuokralaiselle yksilöllisesti. Fuusiot ja yritysostot, jotka yhdistävät kaksi organisaatiota yhdeksi vuokralaiseksi.
Vuokralaisten jakautuminen Yksi Power BI-vuokralainen on jaettu kahteen itsenäiseen vuokralaiseen. Lähtevän liiketoimintayksikön artefaktit, työtilat ja käyttäjät erotellaan valikoivasti. Luopumiset ja spin-offit.
Vuokralaisten uudelleenkartoitus (vuokralaisen siirto) Power BI:n vuokralainen poistetaan ja luodaan uudelleen uudelle kotialueelle samassa Microsoft 365 -vuokralaisessa. Microsoft 365:n vuokralaisen ID, toimialue ja käyttäjätunnukset säilyvät. Lisätietoja löytyy osoitteesta Move Power BI between maantieteelliset alueet. Tietojen asuinpaikkavaatimukset, jotka pakottavat vuokralaisen kotialueen tiettyyn maahan/alueeseen.

Rinnakkaiset siirtymät ja vuokralaisten jakaminen ovat vuokralaisten välisiä toimintoja. Vuokralaisen uudelleenkartoitus on alueen siirto saman Microsoft 365 vuokralaisen sisällä.

Note

Vuokralaisen uudelleenkartoitukseen (alueellinen siirto) Microsoft-tuki:n kanssa koskevat huomioita ja rajoituksia katso Siirrä Power BI vuokralainen toiselle alueelle. Microsoft-tuki -apu rajoittuu edellisen vuokralaisen poistamiseen ja uuden vuokralaisen uudelleenkartoittamiseen määritellylle alueelle; migraatioapua ei tarjota. Sinulla täytyy olla nesteytyssuunnitelma sekä datalle että metatiedalle, olipa kyse sitten skriptatusta varmuuskopioinnista ja palautuksesta, manuaalisista toiminnoista tai uudelleenluonti- ja latausprosessista. Tämä menettely sisältää huomattavan riskin, mukaan lukien mahdollinen datan tai artefaktien menetys, jos varmuuskopiot ovat puutteellisia tai artefakteja jätetään pois. Käyttökatkot vuokralaisten uudelleenkartoituksessa voivat vaihdella kolmesta 24 tuntiin, ja esineiden palautus vaatii enemmän käyttökatkoa.

Arvioi vaihtoehtoja ennen siirtymistä

Vuokralaisten muutto vaatii huomattavaa riskiä ja vaivaa. Tutki vaihtoehtoisia vaihtoehtoja ennen kuin etenet. Seuraavat strategiat voivat auttaa sinua välttämään vuokralaisten muuton tai muuton.

Moni-geo-käyttöönotto

multi-geo deployment mahdollistaa Power BI ja Fabric kapasiteetin käyttöönoton haluamallasi alueella samalla kun vuokralaisen kotialue pysyy muuttumattomana. Näiden kapasiteettien sisällä oleva data pysyy lähellä loppukäyttäjiäsi, ja voit pitää useita kapasiteetteja eri alueilla saman vuokralaisen alla.

Artefaktien siirtäminen toiseen alueeseen on helpompaa kuin vuokralaisen siirtäminen. Siirtääksesi työtilan toiselle alueelle, määritä työtila uudelleen yhdestä kapasiteetista toiseen. Power BI-esineiden uudelleensijoittaminen on saumaton.

Important

Fabric-esineet eivät kestä työtilan uudelleenjakoa eri alueiden kapasiteetin välillä. Poista Fabric-elementit ennen työtilan uudelleenmäärittelyä ja luo ne uudelleen sen jälkeen, tai käytä Git-integraatiota varmuuskopioidaksesi ja palauttaaksesi Fabric-kohteet.

Harkitse moni-geo-käyttöönottoa seuraavissa vaatimuksissa:

  • Dataviive. Sijoita data ja lasketaan lähemmäs loppukäyttäjiä ottamalla kapasiteettia käyttöön heidän alueellaan.
  • Data-residenssi. Tietosi ja laskentasi ovat sidottu kapasiteettialueeseesi, eivät vuokralaisalueeseen. Moni-geo-käyttöönotto pitää datan asuinalueiden sisällä useimmissa työkuormissa.

Vuokralaisen uudelleenkartoitusta harkitaan vain, kun datan asuinvaatimukset ovat niin tiukkoja, että jopa vuokralaisten metatiedot (työtilan määritelmät, semanttinen mallin metatiedot, visuaaliset metatiedot, asetukset, käytännöt) ja Microsoft 365:n käyttäjätiedot on pysyttävä datan asuinrajojen sisällä.

Ota oma tallennustili mukaan Dataflow Gen1:lle

Dataflow Gen1 kirjoittaa tuloksensa Azure Data Lake Storage (ADLS) Gen2-tilille, joka oletuksena sijaitsee Power BI vuokralaisen kotialueella. Jos Dataflow Gen1 -tallennuspaikka on ainoa asuinpaikkasi, konfiguroi oma ADLS Gen2 -tili haluamallesi alueelle sen sijaan, että siirtäisit vuokralaista.

Custom Azure relay for gateway region mismatch

Jos kapasiteettisi on otettu käyttöön eri alueella kuin vuokralaisen kotialue, oletus paikan päällä oleva dataportin päätepiste ohjaa liikenteen takaisin kotialueelle. Jotta gateway-liikenne pysyy kapasiteettialueellasi, konfiguroi custom Azure relay. Pelkkä porttialueen ristiriita ei pitäisi laukaista vuokralaisten siirtoa.

Tarkastele liiketoimintaperustetta

Jos vuokralaisten muutto johtuu yrityksen tarpeesta (esimerkiksi laskutuksen yhdistäminen), punnitse vaivaa ja riskiä suhteessa lopputulokseen. Pieni vuokralainen voi olla helppo muuttaa; suuri vuokralainen, jolla on merkittävä Fabric-sisältö, saattaa vaatia yrityksen tarpeen uudelleenarviointia ennen etenemistä.

Mitä tuetaan maahanmuuttoon

Useimmat Power BI tuotteet tukevat määritelmän vientiä Power BI Admin API tai Workspace Scanner API kautta ja ne voidaan skriptata. Useimmat Fabric-esineet eivät tue määrittelyn vientiä, vaan ne täytyy luoda uudelleen manuaalisesti.

Seuraava taulukko tiivistää kunkin artefaktityypin migraatiopolun.

Järjestys Artefakti Siirtopolku
1 Yhdyskäytävät Ei muuttoreittiä. Se täytyy konfiguroida uudelleen kohdevuokralaisessa Power BI:n ylläpitäjän toimesta.
2 Workspaces Ei muuttoreittiä. Se täytyy luoda uudelleen kohdevuokralaisessa. Massaluominen on mahdollista Power BI Admin API:n avulla.
3 Fabric-kohteet Git-integraatiota tukevat kohteet voidaan varmuuskopioida sitoutumalla Gittiin, irrottamalla linkit lähdetyötilasta ja yhdistämällä uudelleen uuteen työtilaan kohdevuokralaisessa. Vain määritelmä on varmuuskopioitu; Tietoja ei ole mukana. Kohteet, jotka eivät tue Git-integraatiota, täytyy luoda uudelleen manuaalisesti. Lakehousessa säilytetään vain metatiedot; Delta-taulukot ja skeemat eivät siirry toisiinsa.
4 Tietovuot Lataa määritelmä JSON ja tuo uudelleen kohdevuokralaiseen. Skriptaus on mahdollista ylläpitäjän API:n avulla.
5 Semanttiset mallit / aineistot Käytä varmuuskopiointia ja palauta ADLS Gen2 -tallennustilille tai lataa määritelmä ja tuo uudelleen. Skriptaus on mahdollista ylläpitäjän API:n avulla.
6 Raportit Omistajat tai ylläpitäjät lataavat .pbix-tiedoston ja julkaisevat sen kohdevuokralaiselle. Vaihtoehtoisesti viedä JSON-määritelmä. Skriptaus on mahdollista ylläpitäjän API:n avulla.
7 Koontinäytöt Ei muuttoreittiä. Se täytyy luoda uudelleen käsin.
8 Power BI -sovellukset Ei muuttoreittiä. Se täytyy luoda uudelleen käsin.
9 sivuerotellut raportit Omistajat tai ylläpitäjät lataavat RDL-tiedoston ja julkaisevat sen kohdevuokralaiselle.

Important

Luo aina artefakteja tässä järjestyksessä. Alavirran artefaktit riippuvat ylävirran artefakteista, ja tilauksen ohittaminen voi johtaa rikkoutuneisiin viittauksiin suorituksen aikana. Git-synkronoinnin suorittaminen pyyhkii kaikki työtilan kohteet, joita ei ole reposita.

Migraatiomenetelmä

Harkitse seuraavia viitetehtäviä. Useimmat vaiheet koskevat kaikkia kolmea skenaariota. Skenaarioon liittyvät vaiheet mainitaan otsikoissaan.

Vaihe 1: Löytö ja varaston arviointi

Rakenna täydellinen inventaario artefakteista ja riippuvuuksista ja tunnista, mitä voit, et voi tai et saa siirtää.

Aktiviteetit

  • Suorita vuokralaislaajuinen tiedonhankinta käyttämällä yhdistelmää:
    • Power BI Admin API:t
    • Fabric Admin API:t
    • Toimintalokit (työtilat, raportit, aineistot, päivitykset)
    • Manuaalinen dokumentaatio kohteille, joita API:t eivät ole paljastaneet
  • Vangitseminen:
    • Työtilat (tyyppi, kapasiteetti, alue)
    • Raportit, semanttiset mallit (erityisesti suuri tallennusmuoto), datavirrat
    • Fabric-esineet (Lakehouse, Warehouse, Eventhouse, muistikirjat)
    • Yhdyskäytävät, tietolähteet, tunnistetiedot
    • Rivitason tietoturvaroolit (RLS), työtilan käyttöoikeudet, jakolinkit
  • Luokittele jokainen työtila migraation monimutkaisuuden mukaan (matala, keskitaso, korkea) sen sisältämien artefaktien ja riippuvuuksien perusteella.

Tuotokset

  • Ensisijainen varastotaulukko.
  • Migraation monimutkaisuusluokitus jokaiselle työtilalle.

Vaihe 2: Käyttäjän ja tietoturvan löytäminen

Tallenna käyttäjäidentiteetti, lisensointi ja käyttöoikeudet sekä kartoita ne vuokralaisten välillä tarvittaessa.

Vuokralaisen uudelleenkartoituksessa käyttäjäobjektin ID:t säilyvät. Vierekkäisessä siirrossa tai vuokralaisen jakamisessa käyttäjillä on eri objekti-ID:t kohdevuokralaisessa. Yhdistä jokainen lähde-tenant-identiteetti sen kohde-tenant-identiteettiin. Määritä Power BI-lisenssien siirron uudelleen (Free, Pro, PPU). Peilaa tietoturvaryhmät uudessa Microsoft 365 -vuokralaisessa.

Aktiviteetit

Tunnista ja kirjaa:

  • Power BI lisenssien siirto (lähde: Microsoft Graph)
  • Käyttäjäobjektin ID:t lähdevuokralaisessa
  • Käyttäjäobjektin ID:t kohdevuokralaisessa (vain rinnakkain tai jaettuina)
  • Käyttäjäoikeudet ja työtilan käyttöoikeudet
  • Nykyiset vuokralaistason asetukset (kaappaus manuaalisesti ylläpitoportaalin kautta)
  • Nykyiset hallintoasetukset (herkkyystunnisteet, suosituskäytännöt)

Voit poimia työtilan ja artefaktien oikeuksia käyttämällä Power BI Admin API:ia ja Workspace Scanner API.

Vaihe 3: Sidosryhmäviestintä ja muutosjohtaminen

Viestitä siirtosuunnitelma ajoissa vastuksen ja tukikuorman vähentämiseksi.

Keskeiset sidosryhmät

  • Toiminnanjohtajat
  • Työtilan omistajat ja raporttien tekijät
  • Loppukäyttäjät
  • IT-, tietoturva- ja identiteettitiimit

Aktiviteetit

  • Laadi viestintäsuunnitelma, joka kattaa:
    • Muuttoliikkeen yleiskatsaus ja perustelut.
    • Mitä siirretään ja mitä ei siirretä (esimerkiksi henkilökohtaiset työtilat, lepotilat).
    • Mitä muuttuu (URL-osoitteet, pääsy, päivitysajoitus). Alavirran Power Apps- ja SharePoint-linkit, jotka viittaavat Power BI:n URL-osoitteisiin, vaikuttavat myös.
    • Mikä ei muutu (datan semantiikka, visuaalit, liiketoimintalogiikka).
  • Viesti keskeiset päivämäärät:
    • Jäädytä ikkunat (tyypillisesti noin viikon ajan, jolloin lähdevuokralaisessa ei ole muutoksia viimeisen varmuuskopion aikana).
    • Odotettu käyttökatko (vuokralaisten uudelleenkartoitustilanteissa).
    • Validointijaksot sidosryhmille varmistaa omat raporttinsa kohdevuokralaisessa.
    • Lähdevuokralaisen leikkausvaiheet ja poistopäivät (rinnakkaiset skenaariot).

Tuotokset

  • Sidosryhmien tiedotuspöytä.
  • Loppukäyttäjän UKK.

Vaihe 4: Lähetä vuokralaisen uudelleenkartoituspyyntö (vain vuokralaisen uudelleenkartoitus)

Kun siirtopäivä on lukittu, lähetä tukipyyntö ja valitse nimenomaan vuokralaisen uudelleenkartoitusvaihtoehto. Microsoftin tukiinsinööri ottaa pyynnön vastaan.

Aktiviteetit

  • Lähetä tukipyyntö.
  • Täytä Microsoft:n tarjoama valmiustarkistuslista.
  • Sovitaan siirtopäivästä ja -ajasta, mukaan lukien varaaika.
  • Poista olemassa oleva kapasiteetti ennen kuin vuokralaisen uudelleenkartoitus tapahtuu.

Odotetut tulokset

  • Tyypillinen uudelleenkartoitus kestää noin kolme tuntia, mutta jopa 24 tunnin viiveet voivat olla mahdollisia, jos komplikaatioita ilmenee.
  • Kun uudelleenkartoitus on valmis, uudella vuokralaisella on sama vuokralaistunnus ja hän sijaitsee pyydetyllä alueella.

Vaihe 5: Kohdista vuokralaisten valmius

Vasta luotu tai uudelleen kartoitettu vuokralainen ei ole heti valmis vastaanottamaan sisältöä. Säädä se ensin.

Aktiviteetit

  • Määritä Power BI:n vuokralaisen asetukset:
    • Työtilan luontiohjaimet
    • Jakamis- ja ulkoisen pääsyn politiikat
    • Mukautetun visuaalisen hallinnan hallinta
    • Herkkyysmerkinnät ja tiedon suojaus
    • Auditointiloki ja monitoroinnin käyttöönotto
  • Osta Fabric-kapasiteetit, joiden SKU on yhtä suuri tai korkeampi kuin lähteellä.
  • Konfiguroi ja validoi yhdyskäytävät, yhdyskäytäväklusterit ja datayhteydet.
  • Vierekkäin tai vuokralaisen jakotilanteessa:
    • Luo käyttäjä kohdevuokralaiseen jokaiselle lähdetenantin käyttäjälle ja tallenna käyttäjämääritys.
    • Luo käyttäjäryhmät uudelleen lähdetenantista.
    • Määritä Power BI -lisenssit kohdevuokralaiselle.
  • Align governance: herkkyystunnisteet, Microsoft Purview -integraatio ja hyväksyntäkäytännöt.

Vaihe 6: Migraatiopilotti

Suorita testimigraatio edustavalla esimerkkityöpisteellä ennen tuotantomigraatiota.

Rinnakkaissiirtoihin lähdevuokralainen pysyy käytettävissä varavaihtoehtona kokeiluille. Vuokralaisen uudelleenkartoituksessa sisältö, jota ei varmuuskopioitu oikein ennen uudelleenkartoitusta, ei voi palauttaa. Onnistunut pilotti on pääasiallinen tapa vähentää uudelleenkartoituspolun riskiä.

Pilottityötilan valintakriteerit

  • Sisältää sekoituksen artefakteja: raportteja, semanttisia malleja, datavirtoja ja Fabric-esineitä.
  • Käyttää realistisia tietolähteitä ja päivittää aikatauluja.
  • Sillä on työtilatason käyttöoikeudet ja mieluiten RLS.
  • Sitä käytetään aktiivisesti, mutta ei ole tehtäväkriittinen.

Vaihe 7: Migraation toteutus

Suorita siirto. Tuetut kohteet skriptataan ensin; Tuettomat esineet luodaan uudelleen käsin.

Suurille vuokralaisille kirjoita skriptejä, jotka käärivät Power BI Admin API:n massavientiin ja uudelleenluomiseen artefakteja massana.

Luo artefaktit uudelleen siinä järjestyksessä, joka on määritelty kohdassa Mitä tuetaan migraatiota varten. Järjestyksen ohittaminen rikkoo riippuvuuksia.

Vaihe 8: Validointi ja testaus

Varmista, että sisältö on onnistuneesti siirretty ja käyttäytyy oikein.

Viedyt semanttisen mallin määritelmät eivät sisällä taustalla olevaa dataa. Jokainen tuotu semanttinen malli tarvitsee vähintään yhden manuaalisen päivityksen kohdevuokralaisessa.

Vinkki

Harkitse väliaikaista skaalautumista suuremman kapasiteetin SKU:hun validoinnin aikana. Suuri määrä samanaikaisia päivityksiä voi muuten täyttää tavoitekapasiteetin.

Aktiviteetit

  • Validoi data: rivimäärät, avainaggregaatit, päivitys onnistuu.
  • Turvallisuuden varmistaminen: RLS-säännöt, työtilan käyttöoikeus, laajuuksien jakaminen.
  • Suorituskyvyn tarkistaminen: raportoi latausajat, kyselyjen reagointi, kapasiteettikapasiteetti.

Vaihe 9: Käyttäjien siirtyminen ja käyttöönotto

Siirrä käyttäjät kohdevuokralaiselle ja päivitä alavirran sovellukset.

Aktiviteetit

  • Anna käyttäjille pääsy työtiloihin ja artefakteihin kohdevuokralaisessa.
  • Päivitä upotettujen raporttien URL-osoitteet, SharePoint-linkit, Power Apps-yhteydet ja Power Automate -virtaukset, jotka viittaavat Power BI-sisältöön.
  • Poista muokkaus käytöstä lähdevuokralaisessa (vain luku -vaihe) ennen lopullista poistamista.
  • Järjestä lyhyitä enablement-sessioita, joissa kerrotaan, mitä on muuttunut ja mistä sisältöä löytää.

Liittyvä sisältö

  • Last updated on