Pool di flotta di Azure Cosmos DB

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

• UR/s dedicate: questo throughput sono le UR/sec di cui è stato fatto il provisioning a livello di database o contenitori dedicati a tale risorsa. Queste unità richiesta sono garantite e garantiscono che ogni risorsa abbia un livello minimo di prestazioni garantite.

  • Sono sempre disponibili UR/sec dedicate 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 UR/s: è possibile impostare le UR/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 UR/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 UR/s 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 UR/s per contenitore

Tuttavia, l'attività del tenant è imprevedibile:

• La maggior parte dei tenant utilizza un basso numero di UR/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 UR/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

• 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 spazio di flotta.

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

• Il provisioning eccessivo viene impedito assicurando al contempo ai tenant di ottenere la velocità effettiva necessaria quando i picchi di domanda

Funzionamento della velocità effettiva in pool

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 UR/s minime per ogni regione.

Regole di configurazione

Il pooling della velocità effettiva 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 a singola area (utilizzo generico) in due aree distinte di Azure.
  • Consentito: due account, entrambi configurati come scrittura in più aree (business critical) in due aree distinte di Azure.
  • Non consentito: un account, con scrittura a singola area (utilizzo generico) ma distribuito in due aree di Azure distinte. Un altro account, con scrittura a singola area (utilizzo generico), 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 (business critical) e l'altro con scrittura a singola area (utilizzo generico).

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

È possibile monitorare le UR/s a cui il pool è stato ridimensionato tramite la metrica FleetspaceAutoscaledThroughput 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 velocità effettiva 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 predefinite

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.

Per impostazione predefinita:

• Una partizione fisica usa fino a 5.000 UR/sec aggiuntive dal pool oltre alla velocità effettiva dedicata. Se l'applicazione richiede un valore diverso, inviare un ticket di supporto.

• Il consumo totale di una partizione fisica in UR/sec dedicati e di pool non può superare il totale di 10.000 UR/sec, anche se dal pool sono disponibili ulteriori UR/sec.

• In sintesi, il numero massimo di UR/sec di una partizione fisica può essere utilizzato durante l'uso del pooling = $\min(5000+currentThroughput, 10000)$.

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