Criteri di limitazione dell'infrastruttura

La limitazione si verifica quando la capacità di un tenant utilizza più risorse di capacità rispetto a quelle acquistate. Una limitazione eccessiva può comportare una riduzione dell'esperienza dell'utente finale. Un tenant di Microsoft Fabric può creare più capacità e assegnare aree di lavoro a una capacità specifica per la fatturazione e il dimensionamento.

La limitazione viene applicata a livello di capacità, vale a dire che, mentre una capacità o un set di aree di lavoro, potrebbe riscontrare una riduzione delle prestazioni a causa dell'overload, altre capacità potrebbero continuare a funzionare normalmente. Nei casi in cui le funzionalità come gli artefatti OneLake vengono prodotte in una capacità e utilizzate da un'altra, lo stato di limitazione della capacità di utilizzo determina se le chiamate all'artefatto vengono limitate.

Bilanciare le prestazioni e l'affidabilità

Fabric è progettato per offrire prestazioni veloci ai propri clienti consentendo alle operazioni di accedere a più risorse di unità di capacità (CU) rispetto a quelle allocate alla capacità. Le attività che potrebbero richiedere alcuni minuti per il completamento in altre piattaforme possono essere completate in pochi secondi in Fabric. Per evitare di penalizzare gli utenti durante l'aumento del carico operativo, Fabric uniforma o media l'utilizzo cu di un'operazione in un minimo di cinque minuti e anche più a lungo per l'utilizzo elevato della cu, ma richieste di runtime brevi. Questo comportamento garantisce prestazioni costantemente veloci senza riscontrare limitazioni.

Per le operazioni in background con runtime lunghi e che utilizzano carichi di cu pesanti, Fabric consente di uniformare l'utilizzo del CU in un periodo di 24 ore. L'smoothing elimina la necessità di data scientist e amministratori di database di dedicare tempo alla creazione di pianificazioni dei processi per distribuire il carico cu nel corso del giorno per impedire il blocco degli account. Con il smoothing cu di 24 ore, i processi pianificati possono essere eseguiti contemporaneamente senza causare picchi in qualsiasi momento durante il giorno e si possono godere di prestazioni costantemente veloci senza sprecare tempo nella gestione delle pianificazioni dei processi.

Le operazioni in anteprima non sono limitate

Quando una capacità entra in uno stato limitato, influisce solo sulle operazioni richieste dopo l'avvio della limitazione della capacità. Tutte le operazioni, incluse quelle a esecuzione prolungata inviate prima dell'inizio della limitazione, possono essere eseguite fino al completamento. Questo comportamento garantisce che le operazioni vengano completate, anche durante i picchi di utilizzo della cu.

Trigger di limitazione e fasi di limitazione

Dopo il smoothing, alcuni account potrebbero ancora riscontrare picchi di utilizzo della cu durante i periodi di creazione di report di picco. Per gestire questi picchi, gli amministratori possono configurare avvisi di posta elettronica per ricevere una notifica quando una capacità consuma il 100% delle risorse cu di cui è stato effettuato il provisioning. Questo modello indica che la capacità può trarre vantaggio dal bilanciamento del carico e l'amministratore deve prendere in considerazione l'aumento delle dimensioni dello SKU. È importante notare che per gli SKU F, è possibile aumentarli e ridurli manualmente in qualsiasi momento nelle impostazioni di amministrazione. Tuttavia, anche quando una capacità funziona al massimo del potenziale cu, Fabric non applica la limitazione. Questo comportamento garantisce che gli utenti abbiano prestazioni costantemente veloci senza subire interruzioni.

La prima fase della limitazione inizia quando una capacità ha utilizzato tutte le risorse CU disponibili per i prossimi 10 minuti. Ad esempio, se sono state acquistate 10 unità di capacità e quindi sono state utilizzate 50 unità al minuto, si creerà un trasporto di 40 unità al minuto. Dopo due e mezzo minuti, avresti accumulato un trasporto di 100 unità, preso in prestito dalle finestre future. A questo punto, quando tutta la capacità è già esaurita per i prossimi 10 minuti, Fabric avvia il primo livello di limitazione e tutte le nuove operazioni interattive vengono ritardate di 20 secondi all'invio. Se il trasferimento raggiunge un'ora intera, le richieste interattive vengono rifiutate, ma le operazioni in background pianificate continuano a essere eseguite. Se la capacità accumula un totale di 24 ore di trasporto, l'intera capacità viene bloccata fino a quando il trasporto non viene pagato.

Consumo smussato futuro

Nota

Microsoft tenta di migliorare la flessibilità dei clienti nell'uso del servizio, bilanciando al contempo la necessità di gestire l'utilizzo della capacità dei clienti. Per questo motivo, Microsoft potrebbe modificare o aggiornare i criteri di limitazione dell'infrastruttura.

Utilizzo	Limiti dei criteri	Impatto sull'esperienza dei criteri della piattaforma
Utilizzo <= 10 minuti	Protezione dell'eccedenza	I processi possono usare 10 minuti di utilizzo della capacità futura senza limitazioni.
Utilizzo di 10 minuti < <= 60 minuti	Ritardo interattivo	I processi interattivi richiesti dall'utente sono ritardati di 20 secondi all'invio.
Utilizzo di 60 minuti < <= 24 ore	Rifiuto interattivo	I processi interattivi richiesti dall'utente vengono rifiutati.
Utilizzo > 24 ore	Rifiuto in background	Tutte le richieste vengono rifiutate.

Riduzione dell'utilizzo della capacità di trasporto

Ogni volta che una capacità ha capacità inattiva, il sistema paga i livelli di trasporto.

Se si hanno 100 minuti di cu e un portforward di 200 minuti cu, e non si dispone di alcuna operazione in esecuzione, ci vogliono due minuti per pagare il carico di trasporto. In questo esempio il sistema non viene limitato, perché ci sono due minuti di trasporto. I ritardi di limitazione non inizieranno fino a quando non si accumulano 10 minuti di trasporto.

Se è necessario pagare il trasporto più velocemente, è possibile aumentare temporaneamente le dimensioni dello SKU per generare una capacità di inattività maggiore applicata al trasporto.

Il comportamento della limitazione è specifico di Fabric

Sebbene la maggior parte dei prodotti Fabric segua le regole di limitazione indicate in precedenza, esistono alcune eccezioni.

Ad esempio, i flussi di eventi di Fabric hanno molte operazioni che possono essere eseguite per anni dopo l'avvio. La limitazione delle nuove operazioni del flusso di eventi non avrebbe senso, quindi la quantità di risorse CU allocate per mantenere aperto il flusso viene ridotta fino a quando la capacità non è di nuovo in buona posizione.

Un'altra eccezione è l'intelligenza in tempo reale, che non sarebbe in tempo reale se le operazioni siano state ritardate di 20 secondi. Di conseguenza, l'intelligence in tempo reale ignora la prima fase di limitazione con ritardi di 20 secondi a 10 minuti di trasporto e attende fino alla fase di rifiuto a 60 minuti di trasporto per iniziare la limitazione. Questo comportamento garantisce che gli utenti possano continuare a godere di prestazioni in tempo reale anche durante periodi di elevata domanda.

Analogamente, quasi tutte le operazioni nella categoria Warehouse vengono segnalate come background per sfruttare il smoothing di 24 ore dell'attività per consentire i modelli di utilizzo più flessibili. La classificazione di tutti i data warehousing come background impedisce picchi di utilizzo cu di attivare troppo rapidamente la limitazione delle richieste. Alcune richieste potrebbero attivare una stringa di operazioni limitate in modo diverso. Ciò può rendere un'operazione in background soggetta alla limitazione come operazione interattiva.

Classificazioni interattive e in background per la limitazione e il smoothing

Microsoft Fabric divide le operazioni in due tipi, interattive e in background. È possibile trovare descrizioni di queste e le distinzioni tra di esse nelle operazioni di Fabric.

Alcuni amministratori potrebbero notare che le operazioni vengono talvolta classificate come interattive e uniformate come sfondo o viceversa. Questa distinzione si verifica perché i sistemi di limitazione di Fabric devono applicare regole di limitazione prima che una richiesta inizi l'esecuzione. Lo smoothing si verifica dopo l'avvio dell'esecuzione del processo e il consumo di CU può essere misurato.

I sistemi di limitazione tentano di classificare accuratamente le operazioni all'invio, ma talvolta la classificazione di un'operazione potrebbe cambiare dopo l'applicazione della limitazione. Quando l'operazione inizia a essere eseguita, diventano disponibili informazioni più dettagliate sulla richiesta. In scenari ambigui, i sistemi di limitazione tentano di eseguire errori sul lato della classificazione delle operazioni in background, che è nell'interesse migliore dell'utente.

Tenere traccia delle eccedenze e delle operazioni rifiutate

È possibile verificare se la capacità è in overload esaminando il grafico Utilizzo nell'app Metriche della capacità di Microsoft Fabric. Un picco che supera la riga indica un overload. Per analizzare ulteriormente l'overload, eseguire il drill-through nella pagina timepoint. È quindi possibile esaminare sia le operazioni interattive che quelle in background e verificare quali sono state responsabili dell'overload della capacità. È anche possibile determinare quando si sono verificati gli eventi di overload.

Poiché l'utilizzo superiore al 100% non implica automaticamente la limitazione, è necessario usare il grafico Limitazione durante la valutazione delle eccedenze. Da qui è possibile aprire una tabella che mostra i minuti per il burndown, un grafico con aggiunta, burndown e percentuale cumulativa e altro ancora.

Per visualizzare una cronologia visiva di qualsiasi sovrautilizzo della capacità, tra cui trasporto, cumulativo e burndown dei dati di utilizzo, passare alla scheda Eccedenze. È possibile modificare la scala visiva delle eccedenze per visualizzare 10 minuti, 60 minuti e 24 ore. Carryforward tiene conto solo delle operazioni fatturabili.

Il drill-down dell'app Microsoft Fabric Capacity Metrics consente agli amministratori di visualizzare le operazioni rifiutate durante un evento di limitazione. Sono disponibili informazioni limitate su queste operazioni perché non sono mai state autorizzate ad iniziare. L'amministratore può visualizzare il prodotto, l'utente, l'ID operazione e l'ora di invio della richiesta. Quando una richiesta viene rifiutata, gli utenti finali ricevono un messaggio di errore che chiede di riprovare più tardi.

Azioni che è possibile eseguire per il ripristino da situazioni di overload

Strategie che è possibile usare per il ripristino da una situazione di limitazione:

• attendere che lo stato dell'overload sia finito prima di inviare nuove richieste.
• aggiornare lo SKU di una capacità F.
• sospendere/riprendere una capacità F.
• ridimensionare automaticamente una capacità P.
• spostare la priorità più bassa o l'eccedenza delle aree di lavoro dalla capacità.

Contenuto correlato

• Installare l'app Microsoft Fabric Capacity Metrics per monitorare le capacità dell'infrastruttura.