Wzorce i strategie migracji dzierżawy usługi Power BI

Organizacje napotykają różne scenariusze migracji dzierżaw w Power BI, sterowane fuzjami i przejęciami, zbyciem firmy, wymaganiami dotyczącymi rezydencji danych lub regionalnymi potrzebami w zakresie zgodności. Migracje dzierżawców to złożone przedsięwzięcia, które wymagają starannego planowania, kompleksowych strategii tworzenia kopii zapasowych i systematycznej realizacji. Ten artykuł zawiera wskazówki dotyczące migracji dzierżaw Power BI na skalę korporacyjną, w tym ramy decyzyjne ułatwiające ustalenie, czy migracja jest konieczna, oraz szczegółowe metody wdrożenia dla różnych wzorców migracji.

Ważna

Migracje dzierżawy niosą ze sobą znaczne ryzyko i wymagają dużego nakładu pracy ręcznej. Microsoft nie zapewnia bezpośredniej obsługi migracji zawartości między dzierżawami lub w ramach tej samej dzierżawy podczas relokacji regionalnych. Przed przystąpieniem do jakiejkolwiek migracji należy dokładnie ocenić alternatywy, takie jak pojemności obejmujące wiele regionów geograficznych, które mogą sprawdzić się w wielu scenariuszach bez złożoności i ryzyka, jakie wiążą się z migracją całej dzierżawy.

Scenariusze migracji dzierżawcy

Power BI migracja dzierżawy obejmuje trzy scenariusze. Ustal, które z nich dotyczy Twojej sytuacji, zanim zaplanujesz migrację.

Scenario Description Typowy wyzwalacz
Migracja równoległa (między dzierżawcami) Dwa oddzielne tenanty Microsoft 365 funkcjonują równolegle. Artefakty są przenoszone z tenanta źródłowego do tenanta docelowego pojedynczo. Fuzje i przejęcia, które łączą dwie organizacje w jedną dzierżawę.
Podział dzierżawy Pojedyncza dzierżawa usługi Power BI zostaje podzielona na dwie niezależne dzierżawy. Artefakty, obszary robocze i użytkownicy należący do wydzielanej jednostki biznesowej są selektywnie wydzielani. Zbycie i spin-offy.
Ponowne mapowanie dzierżawy (relokacja dzierżawy) Dzierżawa Power BI zostanie usunięta i ponownie utworzona w nowym regionie macierzysty w ramach tej samej dzierżawy Microsoft 365. Identyfikator dzierżawy Microsoft 365, domena i tożsamości użytkowników są zachowane. Aby uzyskać więcej informacji, zobacz Move Power BI między regionami geograficznymi. Wymagania dotyczące rezydencji danych, które wymuszają ustawienie regionu macierzystego dzierżawy na określony kraj/region.

Migracje równoległe i podziały dzierżawy to operacje między dzierżawami. Przemapowanie dzierżawy to przeniesienie do innego regionu w obrębie tej samej dzierżawy Microsoft 365.

Note

Informacje na temat kwestii i ograniczeń związanych z ponownym mapowaniem dzierżawy (relokacją regionalną) w usłudze pomoc techniczna firmy Microsoft można znaleźć tutaj: Przenieś dzierżawę Power BI do innego regionu. Pomoc techniczna firmy Microsoft jest ograniczona do usunięcia poprzedniego dzierżawcy i ponownego przypisania nowego dzierżawcy do określonego regionu; pomoc w zakresie migracji nie jest świadczona. Musisz mieć plan odtworzenia zarówno danych, jak i metadanych, niezależnie od tego, czy będzie on oparty na tworzeniu kopii zapasowych i przywracaniu za pomocą skryptów, ręcznych działaniach, czy procesie ponownego utworzenia i ponownego załadowania. Ta procedura niesie ze sobą znaczne ryzyko, w tym potencjalną utratę danych lub artefaktów, jeśli kopie zapasowe są niekompletne lub pominięto artefakty. Przestój podczas ponownego mapowania dzierżawcy może wynosić od trzech do 24 godzin, przy czym przywracanie artefaktów może wymagać dłuższego przestoju.

Ocena alternatyw przed migracją

Migracja dzierżawy wiąże się z dużym ryzykiem i wymaga dużego wysiłku. Przed kontynuowaniem zapoznaj się z opcjami alternatywnymi. Poniższe strategie mogą pomóc Ci uniknąć migracji dzierżawcy lub relokacji.

Wdrażanie obejmujące wiele regionów geograficznych

Wdrożenie wielogeograficzne umożliwia wdrażanie zasobów pojemnościowych Power BI i Fabric w wybranym przez siebie regionie bez zmiany regionu macierzystego dzierżawy. Dane w tych pojemnościach pozostają blisko użytkowników końcowych i można mieć wiele pojemności w różnych regionach w ramach tej samej dzierżawy.

Migracja artefaktów na pojemność w innym regionie jest prostsza niż migracja samego dzierżawcy. Aby przenieść obszar roboczy do innego regionu, przypisz ponownie obszar roboczy z jednej pojemności do innej. Ponowne przypisywanie jest bezproblemowe dla elementów Power BI.

Ważna

Fabric elementy nie przetrwają ponownego przypisania obszaru roboczego między pojemnościami w różnych regionach. Usuń elementy Fabric przed ponownym przypisaniem obszaru roboczego, a następnie odtwórz je, lub użyj integracji z Git, aby utworzyć kopię zapasową elementów Fabric i je przywrócić.

Rozważ wdrożenie obejmujące wiele regionów geograficznych, aby spełnić następujące wymagania:

  • Opóźnienie danych. Umieść dane i moc obliczeniową bliżej użytkowników końcowych, wdrażając zasoby w ich regionie.
  • Miejsce przechowywania danych. Dane i zasoby obliczeniowe są powiązane z regionem pojemności , a nie regionem dzierżawy. Wdrożenie wielogeograficzne utrzymuje dane w obrębie granic rezydencji danych dla większości obciążeń roboczych.

Rozważ ponowne mapowanie dzierżawy wyłącznie wtedy, gdy wymagania dotyczące rezydencji danych są na tyle rygorystyczne, że nawet metadane dzierżawy (definicje obszarów roboczych, metadane modelu semantycznego, metadane wizualizacji, ustawienia, zasady) oraz informacje o użytkownikach Microsoft 365 muszą pozostawać w granicach wymagań dotyczących rezydencji danych.

Korzystaj z własnego konta magazynu dla usługi Dataflow Gen1

Dataflow Gen1 zapisuje dane wyjściowe na koncie usługi Azure Data Lake Storage (ADLS) Gen2, które domyślnie znajduje się w regionie macierzystym dzierżawy Power BI. Jeśli lokalizacja magazynu usługi Dataflow Gen1 jest jedynym problemem rezydencji, skonfiguruj własne konto usługi ADLS Gen2 w żądanym regionie zamiast przenosić dzierżawę.

Niestandardowy Azure Relay na potrzeby niezgodności regionu bramy

Jeśli zasób pojemności jest wdrożony w regionie innym niż region macierzysty dzierżawy, domyślny punkt końcowy lokalnej bramy danych (on-premises) kieruje ruch z powrotem do regionu macierzystego. Aby zachować ruch bramy w regionie pojemności, skonfiguruj niestandardowy przekaźnik Azure. Sama niezgodność regionu bramy nie powinna powodować migracji dzierżawy.

Przeglądanie przypadku biznesowego

Jeśli migracja dzierżawcy wynika z potrzeb biznesowych (na przykład konsolidacji rozliczeń), rozważ wysiłek i ryzyko w zestawieniu z oczekiwanymi korzyściami. Mała dzierżawa może być stosunkowo łatwa do migracji; duża dzierżawa ze znaczną ilością zawartości w usłudze Fabric może uzasadniać ponowne przeanalizowanie potrzeby biznesowej przed podjęciem dalszych działań.

Co jest obsługiwane na potrzeby migracji

Większość elementów Power BI obsługuje eksport definicji za pośrednictwem interfejsu API administratora usługi Power BI lub Workspace Scanner API i można je obsługiwać za pomocą skryptów. Większość elementów Fabric nie obsługuje eksportowania definicji i musi zostać ręcznie utworzona ponownie.

Poniższa tabela zawiera podsumowanie ścieżki migracji dla każdego typu artefaktu.

Order Artifact Ścieżka migracji
1 Gateways Brak ścieżki migracji. Musi zostać ponownie skonfigurowane w dzierżawie docelowej przez administratora Power BI.
2 Przestrzenie robocze Brak ścieżki migracji. Musi zostać odtworzone w dzierżawie docelowej. Tworzenie zbiorcze jest możliwe przy użyciu interfejsu API administratora Power BI.
3 Elementy tkaniny Elementy obsługujące integrację z usługą Git można zarchiwizować przez zatwierdzenie zmian w repozytorium Git, odłączenie ich od źródłowego obszaru roboczego i ponowne połączenie z nowym obszarem roboczym w dzierżawie docelowej. Tworzona jest tylko kopia zapasowa definicji; dane nie są uwzględniane. Elementy, które nie obsługują integracji z usługą Git, muszą zostać ponownie odtworzone ręcznie. W przypadku Lakehouse zachowywane są tylko metadane; tabele Delta i schematy nie są przenoszone.
4 Dataflows Pobierz definicję JSON i zaimportuj ją ponownie do dzierżawy docelowej. Skrypty są możliwe przy użyciu interfejsu API administratora.
5 Semantyczne modele/zestawy danych Użyj funkcji tworzenia kopii zapasowej i przywracania na koncie magazynu ADLS Gen2 lub pobierz definicję i zaimportuj ją ponownie. Skrypty są możliwe przy użyciu interfejsu API administratora.
6 Raporty Właściciele lub administratorzy pobierają plik .pbix i publikują go ponownie do dzierżawy docelowej. Możesz też wyeksportować definicję JSON. Skrypty są możliwe przy użyciu interfejsu API administratora.
7 Dashboards Brak ścieżki migracji. Należy ręcznie utworzyć ponownie.
8 aplikacje Power BI Brak ścieżki migracji. Należy ręcznie utworzyć ponownie.
9 Raporty stronicowane Właściciele lub administratorzy pobierają plik RDL i publikują go do dzierżawy docelowej.

Ważna

Zawsze odtwarzaj artefakty w tej kolejności. Artefakty zależne są uzależnione od artefaktów źródłowych, a niezachowanie kolejności może prowadzić do nieprawidłowych odwołań w czasie wykonywania. Wykonanie synchronizacji usługi Git spowoduje wyczyszczenie wszystkich elementów w obszarze roboczym, które nie istnieją w repozytorium.

Metodologia migracji

Rozważ następujące przykładowe działania. Większość kroków ma zastosowanie do wszystkich trzech scenariuszy. Kroki dotyczące konkretnego scenariusza są wskazane w ich nagłówkach.

Krok 1: Odkrywanie i ocena inwentaryzacji

Przeprowadź pełną inwentaryzację artefaktów i zależności oraz określ, co można, czego nie można i czego nie należy migrować.

Działania

  • Uruchom odkrywanie w całej dzierżawie za pomocą kombinacji:
    • administracyjne interfejsy API usługi Power BI
    • Administracyjne interfejsy API platformy Fabric
    • Dzienniki aktywności (obszary robocze, raporty, zestawy danych, odświeżenia)
    • Dokumentacja ręczna elementów, które nie są uwidacznione przez interfejsy API
  • Przechwytywanie:
    • Obszary robocze (typ, pojemność, region)
    • Raporty, modele semantyczne (szczególnie duży format magazynu), przepływy danych
    • Elementy usługi Fabric (Lakehouse, Warehouse, Eventhouse, notesy)
    • Bramy, źródła danych, poświadczenia
    • Role zabezpieczeń na poziomie wiersza, uprawnienia obszaru roboczego, linki do udostępniania
  • Klasyfikuj każdy obszar roboczy według złożoności migracji (niski, średni, wysoki) na podstawie artefaktów, które zawiera i zależności.

Outputs

  • Główny arkusz kalkulacyjny inwentaryzacyjny.
  • Klasyfikacja złożoności migracji dla każdego obszaru roboczego.

Krok 2. Odnajdywanie użytkowników i zabezpieczeń

Przechwytuj tożsamość użytkownika, licencje i uprawnienia oraz mapuj je pomiędzy dzierżawami, jeśli jest to wymagane.

W przypadku ponownego mapowania dzierżawy identyfikatory obiektów użytkownika są zachowywane. W przypadku migracji równoległej lub podziału dzierżawy użytkownicy mają różne identyfikatory obiektów w dzierżawie docelowej. Przypisz każdą tożsamość źródłowej dzierżawy do odpowiadającej jej tożsamości docelowej dzierżawy. Ponowne przypisywanie licencji Power BI (Free, Pro, PPU). Odzwierciedlić grupy zabezpieczeń w nowym dzierżawcy Microsoft 365.

Działania

Identyfikowanie i rejestrowanie:

  • Przypisania licencji Power BI (pobrane z Microsoft Graph)
  • Identyfikatory obiektów użytkownika w dzierżawie źródłowej
  • Identyfikatory obiektów użytkownika w docelowej dzierżawie (tylko obok siebie lub w widoku podzielonym)
  • Uprawnienia użytkownika i poziomy dostępu obszaru roboczego
  • Bieżące ustawienia na poziomie dzierżawy (zarejestrowane ręcznie za pośrednictwem portalu administracyjnego)
  • Bieżące konfiguracje nadzoru (etykiety poufności, zasady promowania)

Możesz pobrać uprawnienia obszaru roboczego i artefaktów za pomocą interfejsów API administratora Power BI oraz interfejsu Workspace Scanner API.

Krok 3. Komunikacja uczestników projektu i zarządzanie zmianami

Przekaż plan migracji na wczesnym etapie, aby zmniejszyć odporność i obciążenie obsługi.

Kluczowe grupy uczestników projektu

  • Główni sponsorzy
  • Właściciele obszarów roboczych i autorzy raportów
  • Użytkownicy końcowi
  • Zespoły IT, zabezpieczeń i tożsamości

Działania

  • Opracowanie planu komunikacji obejmującego:
    • Omówienie i uzasadnienie migracji.
    • Co jest migrowane, a co nie (na przykład osobiste obszary robocze, nieaktywne obszary robocze).
    • Co się zmienia (adresy URL, dostęp, chronometraż odświeżania). Linki w aplikacjach Power Apps i w usłudze SharePoint, które odwołują się do adresów URL usługi Power BI, również są objęte tym problemem.
    • Co się nie zmienia (semantyka danych, wizualizacje, logika biznesowa).
  • Przekazywanie dat klucza:
    • Blokowanie okien (zazwyczaj około jednego tygodnia bez zmian w dzierżawie źródłowej podczas ostatniej kopii zapasowej).
    • Przewidywany czas przestoju (w scenariuszach ponownego mapowania dzierżawy).
    • Okresy weryfikacji umożliwiające interesariuszom weryfikację swoich raportów w docelowej dzierżawie.
    • Punkty kontrolne migracji i daty likwidowania dzierżawy źródłowej (scenariusze równoległe).

Outputs

  • Prezentacja briefingowa dla interesariuszy.
  • Użytkownik końcowy — często zadawane pytania.

Krok 4. Przesyłanie żądania ponownego mapowania dzierżawy (tylko ponowne mapowanie dzierżawy)

Gdy data migracji zostanie zablokowana, prześlij zgłoszenie do pomocy technicznej i konkretnie wybierz opcję przemapowania dzierżawy. Inżynier pomocy technicznej Microsoft przyjmuje żądanie.

Działania

  • Prześlij zgłoszenie do działu wsparcia.
  • Ukończ listę kontrolną gotowości udostępnioną przez Microsoft.
  • Zaakceptuj datę i miejsce migracji, w tym przedział czasu tworzenia kopii zapasowej.
  • Usuń istniejącą pojemność przed ponownym mapowaniem dzierżawy.

Oczekiwane wyniki

  • Typowe ponowne mapowanie trwa około trzech godzin, ale opóźnienia do 24 godzin są możliwe, jeśli wystąpią komplikacje.
  • Po zakończeniu remapowania nowy dzierżawca ma ten sam identyfikator dzierżawcy i znajduje się w żądanym regionie.

Krok 5. Gotowość dzierżawy docelowej

Nowo utworzony lub ponownie zamapowany dzierżawca nie jest od razu gotowy do przyjmowania zawartości. Najpierw skonfiguruj ją.

Działania

  • Skonfiguruj ustawienia dzierżawy Power BI:
    • Kontrolki tworzenia obszaru roboczego
    • Udostępnianie i zasady dostępu zewnętrznego
    • Zarządzanie wizualizacjami niestandardowymi
    • Etykiety poufności i ochrona informacji
    • Dziennik audytu i włączanie monitorowania
  • Zakup Fabric pojemności równej lub wyższej jednostki SKU niż źródło.
  • Konfigurowanie i weryfikowanie bram, klastrów bram i łączności danych.
  • W przypadku scenariuszy równoległych lub podziału dzierżawy:
    • Utwórz użytkownika w dzierżawie docelowej dla każdego użytkownika w dzierżawie źródłowej i zapisz mapowanie użytkowników.
    • Utwórz ponownie grupy użytkowników z dzierżawy źródłowej.
    • Przypisz licencje Power BI w docelowej dzierżawie.
  • Dostosuj ład: etykiety poufności, integracja z Microsoft Purview i zasady promowania.

Krok 6. Pilot migracji

Uruchom migrację testową w reprezentatywnym przykładowym obszarze roboczym przed migracją produkcyjną.

W przypadku migracji równoległych dzierżawca źródłowy pozostaje dostępny jako rozwiązanie awaryjne na potrzeby ponownych prób. W przypadku ponownego mapowania dzierżawy zawartości, których kopia zapasowa nie została poprawnie utworzona przed ponownym mapowaniem, nie można odzyskać. Udany pilotaż to podstawowy sposób na ograniczenie ryzyka związanego ze ścieżką remapowania.

Kryteria wyboru obszaru roboczego pilotażowego

  • Zawiera mieszankę artefaktów: raporty, modele semantyczne, przepływy danych i elementy usługi Fabric.
  • Używa realistycznych źródeł danych i harmonogramów odświeżania.
  • Ma uprawnienia na poziomie obszaru roboczego, a najlepiej także RLS.
  • Jest aktywnie używany, ale nie ma krytycznego znaczenia dla działania.

Krok 7. Wykonanie migracji

Wykonaj migrację. Obsługiwane elementy są najpierw tworzone za pomocą skryptów; nieobsługiwane elementy są odtwarzane ręcznie.

W przypadku dużych dzierżawców napisz skrypty, które wykorzystują administracyjny interfejs API Power BI do zbiorczego eksportu i ponownego tworzenia artefaktów.

Odtwórz artefakty w kolejności określonej w Co jest obsługiwane w przypadku migracji. Pominięcie kolejności narusza zależności.

Krok 8. Walidacja i testowanie

Sprawdź, czy zawartość została pomyślnie zmigrowana i działa prawidłowo.

Wyeksportowane definicje modelu semantycznego nie zawierają danych bazowych. Każdy zaimportowany model semantyczny wymaga co najmniej jednego ręcznego odświeżenia w dzierżawie docelowej.

Wskazówka

Rozważ tymczasowe skalowanie do jednostki SKU o większej pojemności podczas walidacji. Duża liczba współbieżnych odświeżeń może w przeciwnym razie usycić pojemność docelową.

Działania

  • Weryfikowanie danych: liczba wierszy, agregacje kluczy, powodzenie odświeżania.
  • Weryfikacja zabezpieczeń: reguły RLS, dostęp do obszaru roboczego, zakresy udostępniania.
  • Weryfikowanie wydajności: czasy ładowania raportu, czas odpowiedzi zapytań, dyspozycyjność pojemności.

Krok 9: Przełączenie użytkowników i ich adaptacja

Przenieś użytkowników do docelowego tenanta i zaktualizuj aplikacje zależne.

Działania

  • Udziel użytkownikom dostępu do obszarów roboczych i artefaktów w dzierżawie docelowej.
  • Zaktualizuj osadzone adresy URL raportów, linki SharePoint, połączenia Power Apps i przepływy Power Automate odwołujące się do zawartości Power BI.
  • Wyłącz możliwość edycji w dzierżawie źródłowej (faza tylko do odczytu) przed ostatecznym wycofaniem z eksploatacji.
  • Uruchom krótkie sesje włączania obejmujące to, co się zmieniło i gdzie znaleźć zawartość.

Treści powiązane

  • Ostatnia aktualizacja o