Pool per le flotte di Azure Cosmos DB (anteprima)

Importante

Questa funzionalità è attualmente in anteprima e viene fornita senza un contratto di servizio. Al momento, le anteprime non sono consigliate per i carichi di lavoro di produzione. Alcune funzionalità di questa anteprima non sono supportate o potrebbero avere vincoli di funzionalità. Per altre informazioni, vedere Condizioni per l'utilizzo supplementari di anteprime di Microsoft Azure.

Quando si utilizzano le flotte di Azure Cosmos DB, è possibile semplificare la gestione del throughput con i pool. I pool consentono di creare un pool condiviso di unità richiesta di velocità effettiva al secondo (UR/sec) a livello di fleetspace da cui più risorse possono usare UR/sec in base alle esigenze. Poiché i pool sono una funzionalità di flotta, le risorse tra sottoscrizioni e gruppi di risorse diversi all'interno dello stesso spazio flotta possono condividere UR/s da un pool comune.

I pool sono progettati per i clienti che creano applicazioni multi-tenant in cui i requisiti di isolamento spesso determinano che i dati di ogni tenant vengono archiviati in un account di database, un database o un contenitore separato. Invece di sovradimensionare la velocità effettiva per soddisfare le esigenze di throughput massimo, i pool permettono di configurare ciascun cliente in base al loro carico di lavoro tipico. Quando gli inquilini richiedono una maggiore capacità a causa di picchi, possono attingere dal pool condiviso. Questo approccio consente di ridimensionare le risorse dei singoli tenant mantenendo al contempo prestazioni e efficienza dei costi in tutta la flotta.

Importante

Il pooling è destinato a applicazioni e scenari multi-tenant in cui è presente un numero elevato di tenant con modelli di traffico diversi. In uno scenario di pooling, non tutti i tenant sono attivi contemporaneamente. Se si esegue un carico di lavoro con un numero ridotto di tenant o uno in cui la maggior parte dei tenant è 100% inattiva o 100% attiva, il pooling potrebbe non offrire ulteriori vantaggi.

Concetti

• RU/s dedicati: questo tasso di throughput sono i RU/s di cui è stato fatto il provisioning a livello di database o container dedicati a tale risorsa. Queste unità richiesta sono garantite e garantiscono che ogni risorsa abbia un livello minimo di prestazioni garantite.

  • Sono sempre disponibili RU/sec dedicati per le risorse all’interno degli account di database, impostati a livello di database condiviso o di contenitore condiviso. Queste allocazioni di throughput dedicate rappresentano le RU/s già configurate a livello del tuo database condiviso o contenitore.

  • Il punto di ingresso per ur/sec dedicate è 100 - 1.000 UR/sec di scalabilità automatica.

  • Per la scalabilità automatica, le UR/s dedicate si riferiscono alla velocità effettiva massima di scalabilità automatica, sempre garantita e disponibile.

• Pool RU/s: È possibile impostare gli RU/s in pool. Le UR/sec in pool sono le UR/sec totali disponibili all'interno di uno spazio flotta che qualsiasi risorsa nei relativi account di database può usare quando vengono superate le UR/sec dedicate.

Le risorse che superano l'allocazione di RU/sec dedicate vengono limitate senza la funzione di pooling. Con il pooling, possono superare i limiti dedicati utilizzando più RU/sec dal pool condiviso, garantendo una migliore efficienza dei costi e prestazioni per i carichi di lavoro multitenant.

Le RU dedicate vengono consumate prima di attingere dal pool.

Scenario di esempio

Si supponga di essere un fornitore di software indipendente (ISV) con 1.000 tenant, ognuno con:

• Un account di database per tenant per isolare la sicurezza tra le risorse.

• Un contenitore per account

• Scalabilità automatica con provisioning compreso tra 100 e 1000 RU/s per contenitore

Tuttavia, l'attività del tenant è imprevedibile:

• La maggior parte dei tenant utilizza un basso numero di RU/s per la maggior parte del tempo.

• La domanda massima per tenant attivo può raggiungere 5000 UR/sec

Senza pooling

• È necessario eseguire il provisioning eccessivo di ogni contenitore con 5000 RU/sec per gestire i carichi di picco

• Questa soluzione comporta uno spreco di RU/s e costi non necessari quando i clienti non sono attivi.

Con il pooling (condivisione delle risorse)

• I contenitori usano principalmente UR/sec dedicate (ad esempio, 100-1.000 UR/sec)

• La flotta ha un pool di velocità effettiva separato (ad esempio, 100.000 - 500.000 UR/sec) a livello di flotta

• Gli affittuari possono attingere temporaneamente dalla riserva invece di essere limitati quando superano le Unità di Richiesta (UR) dedicate.

• L'overprovisioning viene impedito, mentre si assicura ai tenant di ottenere la larghezza di banda necessaria durante i picchi di domanda

Funzionamento dell'efficienza aggregata

Le UR/sec del pool sono configurate per la scalabilità automatica per impostazione predefinita. Quando si configura un pool all'interno di un fleetspace, si definiscono una velocità minima e una velocità massima tra cui il pool può essere ridimensionato. Il valore massimo può essere al massimo 10 volte il valore minimo. Ad esempio, se si imposta la velocità effettiva minima su 100.000 UR/sec, è possibile impostare il valore massimo su qualsiasi valore fino a 1.000.000 UR/sec.

Ogni ora, viene addebitato per il massimo numero di UR/sec a cui il pool si è ridimensionato entro l'ora, per ogni regione in cui è disponibile il pool. Se il pool è inattivo, vengono fatturate le RU/s minime per ogni regione.

Regole di configurazione

Il pooling di throughput richiede che tutti gli account di database in uno fleetspace abbiano la stessa configurazione regionale. Ciò significa che gli account con aree diverse o impostazioni diverse di scrittura in una o più aree (utilizzo generico o livello di servizio business critical) non possono condividere lo stesso pool di velocità effettiva. Le UR/s del pool non vengono condivise anche tra aree.

Ecco alcuni esempi di configurazioni consentite e non consentite:

• Diverse configurazioni a livello di area
  • Consentito: due account, entrambi configurati come scrittura in una singola area in due aree di Azure distinte.
  • Consentito: due account, entrambi configurati come scrittura in più aree in due aree di Azure distinte.
  • Non consentito: un account, con scrittura a singola area, ma distribuito in due aree di Azure distinte. Un altro account, con scrittura a singola area, in una singola area di Azure diversa.
  • Non consentito: due account, con distribuzione globale configurata per due diversi set di aree.
• Vari livelli di servizio
  • Consentito: due account, entrambi con scrittura in più aree (business critical) configurate in due aree di Azure separate.
  • Non consentito: due account, uno con scrittura in più aree e l'altro con scrittura a singola area.

Annotazioni

Gli account devono avere la stessa configurazione sottostante di scritture in più aree (business critical) o scritture a singola area (utilizzo generico) per partecipare allo stesso pool.

Monitoraggio dell'utilizzo

Nell'anteprima è possibile monitorare le UR/s a cui il pool è stato ridimensionato tramite la FleetspaceAutoscaledThroughput metrica disponibile a livello di flotta.

È anche possibile monitorare il consumo di RU/sec in pool a livello di account nel portale di Azure tramite Monitoraggio di Azure seguendo questa procedura:

1. Passare alla pagina Metriche dell'account Azure Cosmos DB nel portale di Azure.

2. Filtrare in base al database e al contenitore di interesse.

3. Selezionare la metrica Totale richieste . Quindi, suddividere per tipo di capacità per verificare se le richieste utilizzavano il pool o solo la capacità di throughput dedicata delle risorse. È anche possibile determinare quante unità di richiesta sono state utilizzate dal pool di velocità effettiva rispetto alle UR/s dedicate fornite per ciascuna risorsa usando la metrica Totale unità di richiesta.

Limitazioni

Con la funzionalità di pooling, le UR/sec totali disponibili per il consumo per ogni partizione fisica sono ancora soggette a limiti di partizione fisica standard. Ogni partizione fisica ha limiti sulla quantità di UR/sec aggiuntiva che può trarre dal pool.

Nell'anteprima:

• Una partizione fisica usa fino a 3.000 UR/sec aggiuntive dal pool oltre alla velocità effettiva dedicata.

• Il consumo totale di UR/sec dedicati + pool delle partizioni fisiche non può superare 8.000 UR/sec totali, anche se sono disponibili più UR/sec per l'utilizzo dal pool.

• Il massimo totale di unità di richiesta al secondo (RU/s) che una partizione fisica può consumare durante il pooling è $\min(3000+currentThroughput, 8000)$.

Suggerimento

È possibile usare la metrica PhysicalPartitionThroughput in Monitoraggio di Azure per determinare il numero di UR/sec dedicate allocate a ogni partizione fisica.

Contenuti correlati

• Panoramica della flotta
• Analisi della flotta