Multi-tenancy e Archiviazione BLOB di Azure

Archiviazione BLOB di Azure archivia dati non strutturati, ad esempio documenti, immagini e video. Questo articolo descrive le strategie di partizionamento, i modelli di isolamento e le funzionalità di gestione rete virtuale di Azure per le soluzioni multi-tenant. Fornisce indicazioni che consentono di distribuire il carico delle richieste, isolare i dati dei tenant e gestire l'accesso, la conservazione, la crittografia e l'utilizzo.

Strategie di partizionamento

gestione rete virtuale di Azure partiziona automaticamente i dati usando una chiave di partizione costituita dal nome dell'account di archiviazione, dal nome del contenitore e dal nome del BLOB. Azure bilancia il carico degli intervalli di chiavi di partizione nel servizio. Non controlli la partizione fisica per un BLOB. Collocare ciascun tenant in un contenitore separato o in un prefisso del nome BLOB non fornisce velocità effettiva dedicata né isolamento delle prestazioni.

In un account di archiviazione condivisa, un carico di lavoro che concentra le richieste su un intervallo ristretto di nomi BLOB può creare una partizione ad accesso frequente, anche quando l'account ha capacità inutilizzata. Le partizioni ad accesso frequente possono aumentare la latenza e causare risposte HTTP 500 (Timeout operazione) o HTTP 503 (Server occupato).

Per i client che caricano blocchi inferiori a 256 KiB, la denominazione dei BLOB può influire sulle prestazioni di caricamento. Ad esempio, un'applicazione che scrive tutti i dati di un giorno in un BLOB denominato usando il modello yyyy-mm-dd indirizza ogni scrittura per quel giorno alla stessa chiave di partizione, che può creare una partizione ad accesso frequente. Per i carichi di lavoro con frequenza elevata delle richieste, suddividere i dati in più BLOB e aggiungere un prefisso hash breve o un valore di secondi o minuti, vicino all'inizio di ogni nome BLOB. Evitare modelli di denominazione sequenziali o solo in append. I caricamenti che usano blocchi di dimensioni maggiori non sono influenzati dalla denominazione delle partizioni. Per altre informazioni, vedere Ottimizzare le partizioni BLOB e obiettivi di scalabilità e prestazioni per gestione rete virtuale di Azure.

Un tenant con volumi elevati può creare una partizione ad accesso frequente o consumare una quota sproporzionata della capacità di un account di archiviazione. Monitorare i modelli di limitazione e richiesta del tenant, usare i tentativi di backoff esponenziale e prendere in considerazione un account di archiviazione dedicato per i tenant che necessitano di scalabilità indipendente o un isolamento delle prestazioni più elevato. Il partizionamento e l'isolamento del tenant sono problematiche separate. Per le opzioni di isolamento, vedere Modelli di isolamento.

Modelli di isolamento

Il partizionamento controlla come gestione rete virtuale di Azure distribuisce il carico delle richieste, ma non stabilisce un confine di isolamento del tenant. Quando si usa gestione rete virtuale di Azure in un sistema multi-tenant, determinare il livello di isolamento da applicare. gestione rete virtuale di Azure supporta contenitori condivisi, contenitori per ogni tenant e account di archiviazione per ogni tenant. La tabella seguente riepiloga le differenze tra i principali modelli di isolamento tenancy per gestione rete virtuale di Azure.

Consideration Contenitori BLOB condivisi Contenitori BLOB per ogni tenant Account di archiviazione per ogni tenant
Isolamento dei dati Medio basso. Usare i percorsi per identificare i dati di ogni tenant o gli spazi dei nomi gerarchici. Medium. Usare gli URL della firma di accesso condiviso con ambito contenitore per supportare l'isolamento della sicurezza. High
Isolamento delle prestazioni Low Basso. La maggior parte delle quote e dei limiti si applica all'intero account di archiviazione. High
Complessità della distribuzione Low Medium High
Complessità operativa Low Medium High
Scenario di esempio Ogni tenant ha solo alcuni blob. Gli URL di firma di accesso condiviso con ambito tenant vengono emessi. Ogni tenant ha un proprio timbro di distribuzione.

Note

Prendere in considerazione quote e limiti di archiviazione quando si seleziona un modello di isolamento. Questi limiti includono i limiti dei servizi di Azure, gli obiettivi di scalabilità generali e gli obiettivi di scalabilità per il provider di risorse di archiviazione.

Contenitori BLOB condivisi

Quando si usa l'archiviazione BLOB, è possibile usare un contenitore BLOB condiviso che include percorsi BLOB per separare i dati per ogni tenant.

ID del locatario Percorso di esempio BLOB
tenant-a https://contoso.blob.core.windows.net/sharedcontainer/tenant-a/blob1.mp4
tenant-b https://contoso.blob.core.windows.net/sharedcontainer/tenant-b/blob2.mp4

I prefissi dei nomi BLOB identificano i dati di ogni tenant, ma la denominazione da sola non impone l'isolamento dell'accesso. gestione rete virtuale di Azure offre una funzionalità per elencare, o enumerare, i BLOB che iniziano con un prefisso specificato. Assicurarsi che la configurazione dell'applicazione e dell'autorizzazione impedisca ai tenant di accedere ai BLOB di altri tenant. Progettare i nomi dei BLOB all'interno di ogni prefisso del tenant per evitare di concentrare volumi di richieste elevati in un intervallo ristretto di chiavi di partizione. Per altre informazioni, vedere Strategie di partizionamento.

La funzionalità dello spazio dei nomi gerarchico in Archiviazione offre una struttura di directory o cartelle più avanzata, incluso il controllo di accesso specifico della directory. Questa funzionalità supporta scenari multi-tenant in cui sono presenti contenitori BLOB condivisi, ma si vuole concedere l'accesso ai dati di un singolo tenant.

In alcune soluzioni multi-tenant potrebbe essere necessario archiviare un singolo BLOB o un set di BLOB per ogni tenant, ad esempio le icone del tenant per personalizzare un'interfaccia utente. Un singolo contenitore BLOB condiviso può funzionare per questi scenari. È possibile usare l'identificatore del tenant come nome del BLOB e leggere il BLOB specifico anziché enumerare un percorso BLOB.

Quando si usano contenitori condivisi, valutare se è necessario tenere traccia dei dati e dell'utilizzo dell'archiviazione per ogni tenant. Per altre informazioni, vedere Monitoraggio.

Contenitori BLOB per ogni tenant

È possibile creare singoli contenitori BLOB per ogni tenant all'interno di un singolo account di archiviazione. Non esiste alcun limite al numero di contenitori BLOB che è possibile creare all'interno di un account di archiviazione.

I contenitori separati forniscono un confine per il controllo degli accessi e la gestione, ma non forniscono l'isolamento delle prestazioni. Tutti i contenitori BLOB nell'account condividono gli obiettivi di capacità e prestazioni dell'account di archiviazione.

Quando si crea un contenitore per ogni tenant, è possibile usare il controllo di accesso di gestione rete virtuale di Azure, inclusa la firma di accesso condiviso (SAS), per gestire l'accesso ai dati di ogni tenant. Usare l'inventario BLOB per misurare la capacità usata da ogni contenitore.

Account di archiviazione per ogni tenant

Il livello di isolamento più elevato usa un account di archiviazione dedicato per ogni tenant. Questo modello garantisce l'isolamento completo delle chiavi di archiviazione, che è possibile ruotare in modo indipendente. Consente anche di ridimensionare la soluzione oltre i limiti e le quote per ogni account di archiviazione. Si consideri questo modello per i tenant con volumi di richieste costantemente elevati o che richiedono obiettivi di prestazioni indipendenti. È tuttavia necessario considerare anche il numero massimo di account di archiviazione consentiti all'interno di una singola sottoscrizione di Azure.

Funzionalità di gestione rete virtuale di Azure che supportano la multi-tenancy

Le funzionalità di gestione rete virtuale di Azure seguenti consentono di implementare e gestire il modello di isolamento scelto.

Firme di accesso condiviso

Quando si usa gestione rete virtuale di Azure da un'applicazione client, valutare se instradare le richieste client tramite un altro componente controllato, ad esempio una rete per la distribuzione di contenuti (CDN) o un'API. In alternativa, è possibile consentire ai client di connettersi direttamente all'account di archiviazione. L'invio di richieste tramite un altro componente può offrire vantaggi come la memorizzazione nella cache dei dati nella rete perimetrale.

L'accesso client diretto alle gestione rete virtuale di Azure per scaricare o caricare i dati può migliorare le prestazioni, soprattutto per i BLOB di grandi dimensioni. Riduce anche il carico sulle applicazioni e sui server back-end e riduce il numero di hop di rete.

Una firma di accesso condiviso (SAS) consente di fornire alle applicazioni client l'accesso limitato ai BLOB.

È possibile utilizzare un SAS per limitare l'ambito delle operazioni che un client può eseguire e gli oggetti su cui queste operazioni vengono svolte. Ad esempio, se si ha un account storage condiviso per tutti i tenant e si tengono i dati del tenant A in un contenitore BLOB denominato tenanta, è possibile creare una SAS (Shared Access Signature) che consenta solo agli utenti del tenant A di accedere a tale contenitore. Per ulteriori informazioni sugli approcci che isolano i dati dei locatari in un account di archiviazione, vedere Modelli di isolamento.

Usare il modello Valet Key per rilasciare token SAS vincolati e con ambito dal tier applicazione. Ad esempio, se l'applicazione multi-tenant consente agli utenti di caricare video, l'API o il livello applicazione può autenticare il client usando il sistema di autenticazione dell'applicazione. È quindi possibile fornire una firma di accesso condiviso (SAS) che consente al client di caricare un file video in un percorso blob specifico all'interno di un contenitore designato. Il client carica quindi il file direttamente nell'account di archiviazione, riducendo la larghezza di banda e il carico sull'API. Se il client tenta di leggere i dati dal contenitore BLOB o scrivere dati in un altro contenitore nell'account di archiviazione, Archiviazione blocca la richiesta. SAS (firma di accesso condiviso) scade dopo un periodo di tempo configurabile.

I criteri di accesso memorizzati consentono di definire un singolo criterio da usare quando si rilasciano più token di firma di accesso condiviso del servizio. I criteri di accesso archiviati non si applicano ai token SAS di delega utente o ai token SAS dell'account.

Firma di accesso condiviso con delega utente

Una firma di accesso condiviso del servizio o una firma di accesso condiviso dell'account di archiviazione viene firmata con una delle chiavi dell'account di archiviazione, quindi qualsiasi componente che ne crea una deve accedere a tali chiavi. Una SAS di delega utente è protetta con credenziali Microsoft Entra. Il livello applicazione richiede una chiave di delega utente usando la propria identità gestita, quindi firma i token con ambito limitato al tempo per ogni tenant. Non si distribuiscono o si archiviano le chiavi dell'account. Microsoft consiglia di usare una firma di accesso condiviso della delega utente anziché una firma di accesso condiviso con chiave dell'account quando la progettazione lo supporta. Usare durate di token brevi e pianificare come revocare l'accesso se un token viene compromesso.

In una soluzione multi-tenant, combina una firma di accesso condiviso di delega utente con il pattern Valet Key per rilasciare token con ambito tenant supportati dal provider di identità. È possibile associare ogni token a un utente delegato specifico. Per correlare i log dell'applicazione con i log di Storage, impostare un ID richiesta client (x-ms-client-request-id) nelle richieste di Storage e registrarlo insieme all'ID tenant. Per altre informazioni, vedere Concedere l'accesso limitato alle risorse Archiviazione di Azure usando firme di accesso condiviso.

Controllo degli accessi in base all'identità

gestione rete virtuale di Azure fornisce anche il controllo degli accessi in base all'identità tramite Microsoft Entra ID. Questa funzionalità consente il controllo degli accessi in base agli attributi, che consente l'accesso con granularità fine ai percorsi BLOB o ai BLOB contrassegnati con un ID tenant specifico.

Controllo della concorrenza

gestione rete virtuale di Azure non fornisce transazioni tra più BLOB. Se più istanze dell'applicazione possono aggiornare lo stesso BLOB, implementare una strategia di controllo della concorrenza. Usare ETag e richieste condizionali per la concorrenza ottimistica o acquisire un lease BLOB per la concorrenza pessimistica.

Un lease attivo garantisce al titolare del lease l'accesso esclusivo in scrittura al blob con lease. Non impedisce letture non coordinate né rende atomiche le operazioni su più BLOB. In una soluzione multi-tenant prendere in considerazione il controllo della concorrenza quando più worker possono elaborare o aggiornare il BLOB dello stesso tenant. Per altre informazioni, vedere Gestire la concorrenza in gestione rete virtuale di Azure.

Gestione del ciclo di vita

Quando si usa l'archiviazione BLOB in una soluzione multi-tenant, i tenant potrebbero richiedere criteri diversi per la conservazione dei dati. Quando si memorizzano grandi volumi di dati, è anche possibile spostare automaticamente i dati specifici del tenant nei livelli di archiviazione ad accesso meno frequente o archivio per ottimizzare i costi.

Usare i criteri di gestione del ciclo di vita per impostare il ciclo di vita del blob per tutti i tenant o per un gruppo di tenant. È possibile applicare una politica di gestione del ciclo di vita ai contenitori del Blob o a un sottoinsieme di Blob all'interno di un contenitore. Tuttavia, i criteri di gestione del ciclo di vita hanno limiti al numero di regole che è possibile specificare. Pianificare e testare attentamente la configurazione in un ambiente multi-tenant. Valutare la possibilità di distribuire più account di archiviazione se il numero di regole supera i limiti.

Archiviazione non modificabile

Quando si configura l'archiviazione BLOB non modificabile nei contenitori di archiviazione usando criteri di conservazione basati sul tempo, l'archiviazione impedisce l'eliminazione o la modifica dei dati prima di un'ora specificata. Questa imposizione si verifica a livello di account di archiviazione e si applica a tutti gli utenti, inclusi gli amministratori dell'organizzazione.

Usare l'archiviazione non modificabile se i tenant devono mantenere i dati o i record a causa di requisiti legali o di conformità. Valutare il modo in cui questa funzionalità si adatta al ciclo di vita del tenant. Ad esempio, se un tenant viene disattivato e richiede l'eliminazione dei dati, potrebbe non essere possibile soddisfare la richiesta. Se si utilizza l'archiviazione non modificabile per i dati dell'inquilino, prendere in considerazione come risolvere questo problema nelle condizioni di servizio.

Copia sul lato server

In un sistema multi-tenant potrebbe essere necessario spostare i dati da un account di archiviazione a un altro. Ad esempio, se si sposta un tenant tra ambiti di distribuzione o si ribilancia un set frammentato di account di archiviazione, è necessario copiare o trasferire i dati di un tenant specifico. Quando si dispone di grandi volumi di dati, usare le API di copia sul lato server per ridurre il tempo di migrazione.

Lo strumento AzCopy è un'applicazione che è possibile eseguire dal computer o da una macchina virtuale per gestire il processo di copia. AzCopy è compatibile con la funzionalità di copia sul lato server e fornisce un'interfaccia della riga di comando scriptabile che è possibile eseguire dalle soluzioni. È anche possibile usare AzCopy per caricare e scaricare grandi volumi di dati.

Se è necessario usare le API di copia lato server direttamente dal codice, è consigliabile usare le opzioni seguenti:

Replica di oggetti

Replica oggetti replica automaticamente e in modo asincrono i BLOB in blocchi tra un account di archiviazione di origine e di destinazione. La replica di oggetti non supporta gli account con spazio dei nomi gerarchico abilitato o BLOB di origine crittografati con chiavi fornite dal cliente. I contenitori di destinazione rifiutano le scritture mentre le regole di replica sono attive, quindi la replica degli oggetti da sola non fornisce scritture attive-attive.

In una soluzione multi-tenant è possibile usare questa funzionalità quando la replica attiva-passiva è sufficiente. Gli scenari di esempio possono essere la distribuzione di copie dei dati del tenant tra gli stamp di distribuzione o la distribuzione di asset di sola lettura quando si implementa il modello Geode.

Encryption

gestione rete virtuale di Azure crittografa i dati a riposo. In una soluzione multi-tenant, prendere in considerazione l'uso di ambiti di cifratura con chiavi gestite dal cliente. È possibile assegnare chiavi di crittografia diverse a tenant diversi, anche quando i dati si trovano nello stesso account di archiviazione. In alternativa, è possibile fornire una chiave di crittografia per singole richieste di gestione rete virtuale di Azure. Si tratta di opzioni di gestione delle chiavi separate. Pianificare la rotazione e la revoca delle chiavi insieme al ciclo di vita del tenant.

Monitoring

In una soluzione multi-tenant valutare se è necessario misurare il consumo per ogni tenant. Definire le metriche specifiche da tenere traccia, ad esempio la capacità di archiviazione usata da ogni tenant o il numero di operazioni eseguite per i dati di ogni tenant. È anche possibile usare l'allocazione dei costi per tenere traccia del costo dell'utilizzo di ogni tenant e abilitare il chargeback tra più sottoscrizioni.

gestione rete virtuale di Azure offre funzionalità di monitoraggio predefinite. Le metriche di capacità predefinite segnalano l'utilizzo dell'account di archiviazione, non dei singoli contenitori. Pianificare come misurare l'utilizzo per ogni tenant quando i tenant condividono un account.

Monitorare la latenza delle richieste e le risposte HTTP 500 e 503 per rilevare possibili partizioni attive o carichi di lavoro che si avvicinano agli obiettivi di scalabilità. Correlare questi dati di telemetria con gli identificatori del tenant in modo che sia possibile identificare i tenant i cui modelli di accesso influiscono sulla capacità condivisa.

È anche possibile registrare tutte le richieste all'archiviazione, quindi aggregare e analizzare tali log. Questo approccio offre flessibilità quando si aggregano e raggruppano i dati per ogni tenant. Tuttavia, nelle soluzioni che creano volumi elevati di richieste all'archiviazione, valutare se il vantaggio ottenuto da questo approccio giustifica il costo per acquisire ed elaborare tali log.

L'inventario di Archiviazione di Azure offre un altro approccio per misurare le dimensioni totali di un contenitore BLOB.

Contributors

Microsoft gestisce questo articolo. I seguenti collaboratori hanno scritto questo articolo.

Autore principale:

  • John Downs | Principal Software Engineer, Azure Patterns & Practices

Altri contributori:

Per visualizzare i profili LinkedIn non pubblici, accedere a LinkedIn.

  • Ultimo aggiornamento: