Nota
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare ad accedere o modificare le directory.
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare a modificare le directory.
Questo articolo guida gli amministratori di Fabric e Power BI nel processo di spostamento delle aree di lavoro dalle SKU Power BI Premium per capacità (SKU P) alle SKU di capacità di Microsoft Fabric (SKU F). Illustra il percorso standard all'interno della stessa area geografica, il percorso tra aree geografiche con gestione speciale per i modelli semantici di grandi dimensioni e gli elementi di Fabric, nonché i passaggi di convalida e dismissione.
La migrazione avviene a livello di area di lavoro. Riassegna ogni area di lavoro da una capacità con SKU P a una con SKU F. Non c'è alcun capovolgimento a livello di tenant. Riassegnare le aree di lavoro una alla volta tramite il portale di amministrazione di Fabric o in blocco tramite il notebook di migrazione della capacità.
Prima di iniziare, decidere quale SKU F acquistare, quale area usare e quando eseguire la migrazione. Per queste indicazioni, vedere Power BI Guida alle decisioni sulla migrazione degli SKU P Premium. Per una panoramica del processo end-to-end, vedi Panoramica della migrazione da Power BI Premium a Microsoft Fabric.
Prerequisiti
Prima di iniziare, verificare i prerequisiti seguenti:
- Accesso ad Azure. Si hanno le autorizzazioni per la sottoscrizione di Azure per registrare il provider di risorse
Microsoft.Fabrice per creare e gestire le capacità di Fabric. Seguire il principio dei privilegi minimi: invece di assegnare il ruolo Proprietario o Collaboratore generale, usare un ruolo personalizzato che concede solo leMicrosoft.Fabricazioni necessarie , ad esempioMicrosoft.Fabric/register/actioneMicrosoft.Fabric/capacities/*. Per l'elenco completo delle azioni disponibili, vedere autorizzazioni Microsoft.Fabric. Per creare il ruolo personalizzato, vedere Creare o aggiornare Azure ruoli personalizzati usando il portale di Azure. - Ruolo di amministratore di Fabric. Si dispone del ruolo di amministratore di Fabric (in precedenza amministratore di Power BI) nel tenant.
- Diritti di amministrazione della capacità Sei un amministratore della capacità di origine dello SKU P, quindi puoi riassegnare le aree di lavoro da essa. Per ulteriori informazioni, vedere Gestire gli amministratori della capacità.
- Area di lavoro o diritti di amministratore di Fabric. Sei un amministratore dell'area di lavoro per ogni area di lavoro che intendi riassegnare oppure effettui la riassegnazione come amministratore del tenant.
- Quota. L'area di Azure di destinazione dispone di una quota sufficiente di unità di capacità Fabric (CU) per eseguire il provisioning dello SKU F scelto. In caso contrario, richiedere un aumento della quota in anticipo. Per altre informazioni, vedi quote di capacità di Microsoft Fabric.
- App Microsoft Fabric Capacity Metrics installata. Usalo per stabilire una baseline di riferimento per il consumo attuale dello SKU P e convalidare il consumo dello SKU F dopo la migrazione. Vedi l'app Capacity Metrics di Microsoft Fabric.
Passaggio 1: Inventariare le aree di lavoro e gli elementi
Per evitare sorprese durante la migrazione, l'individuazione degli asset è il passaggio più efficace. Inventariare ogni area di lavoro assegnata alle capacità dello SKU P e contrassegnare gli elementi che richiedono una gestione speciale.
Per ogni area di lavoro, registrare:
- Nome e ID dell'area di lavoro
- Proprietari e contatto aziendale principale
- Power BI elementi: report, modelli semantici (e relativo formato di archiviazione), flussi di dati, report impaginati, dashboard
- Elementi di Fabric: Lakehouses, Warehouses, Notebooks, pipeline di Data Factory, Eventstreams, database KQL, Dataflows Gen2
- Finestre di aggiornamento pianificate e tutte le pipeline eseguite in base a una pianificazione
- Dipendenze del gateway
Contrassegnare gli elementi seguenti perché richiedono una gestione speciale in uno spostamento tra aree:
- Modelli semantici di formato di archiviazione di grandi dimensioni. Questi modelli non sopravvivono a una riassegnazione tra aree così come è. Vedere Gestire modelli semantici di formato di archiviazione di grandi dimensioni nelle migrazioni tra aree.
- Qualsiasi elemento di Fabric. Fabric gli elementi non sopravvivono a una riassegnazione tra aree. Vedere Gestire gli elementi di Fabric nelle migrazioni tra regioni.
Tip
Anche se l'organizzazione dispone solo di una licenza Power BI Premium, gli utenti potrebbero aver creato elementi Fabric durante una versione di valutazione di Fabric. Eseguire il rilevamento in tutte le aree di lavoro, non solo in quelle che si prevede contengano elementi Fabric.
Per estrarre i metadati dell'area di lavoro e degli elementi, usare le API REST di amministrazione Power BI o le funzioni di amministrazione di Semantic Link Labs.
Passaggio 2: Creare la capacità dello SKU F in Azure
Acquistare lo SKU F prima di riassegnare le aree di lavoro. Mantenere attivo lo SKU P fino a quando la riassegnazione e la convalida hanno esito positivo.
- Accedi al portale di Azure.
- Verifica che il provider di risorse
Microsoft.Fabricsia registrato nella tua sottoscrizione. Nel riquadro della sottoscrizione selezionare Provider di risorse, trovareMicrosoft.Fabrice selezionare Registra se non è già registrato. - Crea una capacità di Microsoft Fabric seguendo Acquista un abbonamento a Microsoft Fabric. Scegliere l'area, le dimensioni dello SKU e il modello di fatturazione (pagamento in base al consumo o prenotazione) scelti nella guida decisionale.
- Aggiungere un amministratore della capacità alla nuova capacità nel portale di amministrazione Fabric prima di riassegnare le aree di lavoro.
Note
Le funzionalità Premium di Power BI sono disponibili solo nelle capacità F64 e superiori. Gli utenti gratuiti possono visualizzare il contenuto con il ruolo Visualizzatore solo in F64 e versioni superiori. Se esegui il downgrade a F32 o a un livello inferiore, prevedi licenze Pro per ogni utente che visualizza i report.
Passaggio 3: Pilotare un'area di lavoro a basso impatto
Eseguire prima la migrazione di un'area di lavoro non critica. Questo progetto pilota convalida i prerequisiti e presenta eventuali strani elementi prima di toccare contenuti critici per l'azienda.
- Scegliere un'area di lavoro di test o a basso impatto con almeno un report, un aggiornamento pianificato e una connessione gateway.
- Riassegnare l'area di lavoro seguendo il passaggio 4: Riassegnare le aree di lavoro.
- Convalidare l'area di lavoro pilota seguendo il passaggio 5: Convalidare la migrazione.
- Risolvere eventuali problemi prima di continuare con il resto.
Passaggio 4: Riassegnare le aree di lavoro
Riassegnare le aree di lavoro dallo SKU P di origine al nuovo SKU F. Scegliere il metodo più adatto alla scalabilità della migrazione. Per alcune aree di lavoro, usare il portale di amministrazione Fabric. Per numerose aree di lavoro o capacità di destinazione multiple, utilizzare il notebook per la migrazione della capacità.
Importante
Se si esegue la migrazione tra aree, eseguire il backup o acquisire definizioni per gli elementi che non possono sopravvivere a una riassegnazione tra aree prima di riassegnare l'area di lavoro. L'omissione di questo passaggio causa la perdita di dati. Per le procedure, vedere Gestire modelli semantici di formato di archiviazione di grandi dimensioni e Gestire gli elementi Fabric.
Usare questo metodo quando si dispone di un numero ridotto di aree di lavoro o quando si vuole un processo manuale e controllabile in modo dettagliato. Riassegnare in blocco le aree di lavoro tramite la pagina Impostazioni capacità nel portale di amministrazione di Fabric:
- Accedere al servizio Power BI come amministratore di Fabric o di Power BI.
- Apri portale di amministrazione>Impostazioni capacità, seleziona la scheda Capacità Fabric e seleziona la nuova capacità F SKU.
- In Aree di lavoro assegnate a questa capacità selezionare Assegna aree di lavoro>specifiche, scegliere le aree di lavoro da spostare dallo SKU P e selezionare Applica.
La riassegnazione di una singola area di lavoro viene in genere completata in secondi. Ripeti per ogni gruppo di aree di lavoro.
Per il set completo di opzioni di riassegnazione (inclusa la riassegnazione di un'area di lavoro singola dalle impostazioni dell'area di lavoro, le API utente e amministratore e i requisiti di autorizzazione per tipo di capacità), vedere Riassegnazione di un'area di lavoro a un'altra capacità.
Importante
Gli aggiornamenti attivi e le query possono essere interrotti al momento della riassegnazione. Pianificare riassegnazioni al di fuori delle finestre di aggiornamento e dopo il completamento dei processi a esecuzione prolungata. Dopo la riassegnazione, gli utenti potrebbero dover attendere fino a un'ora prima di poter creare elementi Fabric nelle aree di lavoro migrate sulla nuova capacità.
Passaggio 5: Convalidare la migrazione
Verifica ogni lotto di aree di lavoro prima di continuare. Non disattivare lo SKU P finché la convalida non viene completata con esito positivo in tutti i workspace.
Importante
Se si esegue la migrazione tra aree geografiche, ripristinare o ricreare gli elementi di cui è stato eseguito il backup prima della riassegnazione prima di convalidare. Per le procedure, vedere Gestire modelli semantici di formato di archiviazione di grandi dimensioni e Gestire gli elementi Fabric.
Per ogni area di lavoro migrata, confermare:
- L'area di lavoro mostra il nuovo nome della capacità F SKU nelle impostazioni dell'area di lavoro.
- I report mission-critical vengono caricati per gli utenti finali.
- Gli aggiornamenti pianificati hanno esito positivo sulla nuova capacità. Attivare un aggiornamento su richiesta se non è possibile attendere l'esecuzione pianificata successiva.
- Le connessioni gateway funzionano. La maggior parte delle configurazioni del gateway persiste tramite la riassegnazione, ma potrebbe essere necessario aggiornare alcune.
- Le pipeline di distribuzione, le app dello spazio di lavoro e i processi CI/CD continuano a pubblicare e aggiornare i contenuti come previsto.
- I conteggi degli elementi nella nuova capacità corrispondono all'inventario acquisito nel passaggio 1. Eseguire nuovamente lo script di individuazione e confrontare i risultati.
Monitora l'app Microsoft Fabric Capacity Metrics nelle prime 24-48 ore dopo la migrazione. Individuare periodi prolungati di utilizzo della CU pari o prossimi al 100%, che indicano che la SKU è sottodimensionata.
Passaggio 6: Dismettere lo SKU P
Dopo che tutte le aree di lavoro hanno superato la convalida, annulla la sottoscrizione P SKU. Non annullare finché la riassegnazione non viene completata e convalidata. Per il periodo di tolleranza successivo all'annullamento, l'accesso con limitazioni e le tempistiche della perdita di dati, vedi Comprendere le tempistiche di ritiro dello SKU P.
Per annullare:
- Accedere al interfaccia di amministrazione di Microsoft 365 come amministratore globale o fatturazione.
- Apri Fatturazione>I tuoi prodotti, trova la sottoscrizione Power BI Premium P SKU e segui le istruzioni per l'annullamento. Se viene chiesto di specificare un motivo, citare la migrazione a Microsoft Fabric.
- Verificare che nessuna area di lavoro rimanga assegnata alla capacità annullata.
Se si usa Server di report di Power BI, verificare le licenze del server di report prima dell'annullamento. Dopo la migrazione, la chiave del server di report è disponibile nella scheda capacità Fabric in Impostazioni capacità nel portale di amministrazione.
Migrazioni tra aree: gestione speciale
Se lo SKU F di destinazione deve trovarsi in un'area Azure diversa (ad esempio, per i vantaggi di residenza dei dati o di latenza significativa), due categorie di elementi richiedono una gestione aggiuntiva: modelli semantici di formato di archiviazione di grandi dimensioni e Fabric elementi. La riassegnazione nella stessa area geografica è l'opzione predefinita consigliata. Per i criteri decisionali, vedere Scegliere tra la migrazione tra la stessa area e la migrazione tra aree. Per l'elenco completo dei tipi di elementi mobili e non rimovibili, vedere Restrizioni sullo spostamento di aree di lavoro.
La migrazione tra aree usa gli stessi sei passaggi di una migrazione della stessa area. I passaggi di gestione descritti in questa sezione vengono eseguiti prima e dopoil passaggio 4: Riassegnare le aree di lavoro per le aree di lavoro interessate.
Gestire modelli semantici di formato di archiviazione di grandi dimensioni nelle migrazioni tra aree
I modelli semantici di formato di archiviazione di grandi dimensioni sono associati all'area dell'area di lavoro in cui sono stati creati. Non sopravvivono a una riassegnazione tra aree.
È possibile procedere in due modi:
- Eliminare e ridistribuire. Eseguire il backup della definizione del modello, ad esempio usando gli strumenti degli endpoint XMLA o la copia del controllo del codice sorgente, eliminare il modello nell'area di lavoro di origine, riassegnare l'area di lavoro allo SKU F nella nuova area e quindi ridistribuire il modello nell'area di lavoro come se fosse nuovo. Il modello ridistribuito ottiene un nuovo GUID, quindi i report che facevano riferimento al modello originale devono essere nuovamente associati al modello ridistribuito.
- Backup e ripristino Segui Backup e ripristino dei modelli semantici di Power BI Premium. Eseguire il backup nell'area di origine, riassegnare l'area di lavoro e quindi eseguire il ripristino nella nuova area geografica. Il modello ripristinato riceve un nuovo GUID, quindi i report che facevano riferimento al modello originale devono essere ricollegati al modello ripristinato.
Pianificare il tempo di inattività per ogni modello interessato uguale al tempo di ridistribuzione o ripristino più il tempo di aggiornamento.
Gestire gli elementi di Fabric nelle migrazioni tra aree geografiche
Gli elementi di Fabric, ad esempio Lakehouses, Warehouses, Notebooks, pipeline di Data Factory, Eventstreams, database KQL e Dataflows Gen2, non vengono mantenuti in caso di riassegnazione tra aree geografiche. È necessario rimuoverli prima della riassegnazione e ricrearli nella nuova area in un secondo momento.
Modello più comune:
- Acquisire le definizioni degli elementi in Git. Connetti l'area di lavoro di origine a Git tramite l'integrazione Git di Fabric ed esegui il commit. Git acquisisce le definizioni degli elementi, non i dati sottostanti.
- Eseguire il backup dei dati separatamente. Esportare o copiare i dati che è necessario conservare (ad esempio, file Lakehouse, tabelle warehouse) in una posizione esterna all'area di lavoro.
- Eliminare gli elementi Fabric. Rimuovere gli elementi Fabric dall'area di lavoro di origine.
- Riassegnare l'area di lavoro. Spostare l'area di lavoro nella nuova capacità sku F seguendo il passaggio 4: Riassegnare le aree di lavoro.
- Ricrea gli elementi nella nuova regione. Eseguire il ripristino da Git in una nuova area di lavoro separata nella nuova capacità per evitare la sovrascrittura di altri elementi da parte di Git. Dopo la verifica, spostare o ripubblicare gli elementi nell'area di lavoro di destinazione.
- Ricaricare i dati. Ricaricare i dati di origine negli elementi ricreati.
Caution
La sincronizzazione di un'area di lavoro con Git può rimuovere qualsiasi elemento nell'area di lavoro non presente nel repository Git. Ripristinare sempre gli elementi di Fabric in un'area di lavoro separata da quella di cui è stata eseguita la migrazione e verificare il numero di elementi prima di spostarli.
Migrazioni multi-geo
Se la distribuzione Premium corrente usa capacità P multi-geo, effettua il provisioning di uno SKU F corrispondente in ogni area geografica di destinazione. Riassegnare le aree di lavoro in ogni area allo SKU F nell'area corrispondente e applicare le stesse regole di gestione speciali per area. Dopo la migrazione, gestire governance, posizionamento del contenuto e dimensionamento della capacità per area.
Migrazioni tra tenant
La migrazione tra tenant, ad esempio dopo un'acquisizione, non è supportata come riassegnazione dell'area di lavoro. È necessario ricreare manualmente gateway, modelli semantici, aree di lavoro, report, app e dashboard nel tenant di destinazione. Per la maggior parte delle esigenze in più aree, il multigeo all'interno di un singolo tenant è più semplice. Vedere Power BI modelli e strategie di migrazione dei tenant.
Risolvere i problemi comuni
| Sintomo | Causa possibile | Cosa fare |
|---|---|---|
| Non è possibile riassegnare un'area di lavoro alla nuova capacità | Non sei un amministratore della capacità di destinazione oppure il provider di risorse Microsoft.Fabric non è registrato. |
Aggiungersi come amministratore della capacità nel portale di amministrazione di Fabric e registrare il provider di risorse nella sottoscrizione di Azure. |
| La riassegnazione di un'area di lavoro ha esito negativo con un errore di area | L'area di lavoro contiene elementi che non possono essere trasferiti tra regioni (modelli in formato di archiviazione di grandi dimensioni o elementi Fabric). | Segui Migrazioni tra aree geografiche: gestione speciale. |
| I report vengono caricati lentamente dopo la migrazione | Il nuovo SKU F è sottodimensionato per i carichi di lavoro correnti. | Usa l'app Microsoft Fabric Capacity Metrics per verificare l'utilizzo delle CU e aumentare la capacità su richiesta tramite il portale di Azure. |
| Gli utenti gratuiti non possono più visualizzare i report | Il nuovo SKU F è F32 o più piccolo, in cui l'accesso al visualizzatore gratuito non è abilitato. | Aumentare le prestazioni fino a F64 o superiore oppure assegnare licenze Pro o PPU ai visualizzatori. |
| Gli aggiornamenti pianificati hanno esito negativo dopo la migrazione | Un gateway non è più raggiungibile o le credenziali di aggiornamento devono essere riautore autorizzate dopo lo spostamento dell'area di lavoro. | Nell'area di lavoro aprire le impostazioni del modello semantico, riautorizzare l'origine dati e verificare l'associazione del gateway. |
| Gli utenti non possono creare Fabric elementi in un'area di lavoro migrata per un massimo di un'ora | Comportamento previsto. Il carico di lavoro Fabric richiede tempo per inizializzare la nuova capacità. | Attendere fino a un'ora e riprovare. |
Per gli errori di riassegnazione non elencati qui (ad esempio migrazione non supportata, tentativi esauriti o errore di migrazione del database, che possono verificarsi con configurazioni di collegamento privato o chiavi gestite dal cliente), vedere Risoluzione dei problemi di riassegnazione della capacità comuni.