Azure offre molte opzioni per organizzare le risorse. In una soluzione multi-tenant esistono compromessi specifici da considerare quando si pianifica la strategia dell'organizzazione delle risorse. In questo articolo vengono esaminati due elementi principali dell'organizzazione delle risorse di Azure: isolamento del tenant e scalabilità orizzontale tra più risorse. Viene anche descritto come usare i limiti e le quote delle risorse di Azure e come ridimensionare la soluzione oltre questi limiti.
Considerazioni e requisiti principali
Requisiti di isolamento del tenant
Quando si distribuisce una soluzione multi-tenant in Azure, è necessario decidere se dedicare risorse a ogni tenant o condividere risorse tra più tenant. Nelle sezioni relative agli approcci multi-tenancy e alle linee guida specifiche del servizio di questa serie vengono descritte le opzioni e i compromessi per molte categorie di risorse. In generale, sono disponibili diverse opzioni per l'isolamento del tenant. Esaminare i modelli tenancy da considerare per una soluzione multi-tenant per altre indicazioni su come decidere il modello di isolamento.
Ridimensiona
La maggior parte delle risorse di Azure, nonché gruppi di risorse e sottoscrizioni, impone limiti che possono influire sulla capacità di ridimensionare. Potrebbe essere necessario prendere in considerazione la scalabilità orizzontale o la compressione dei contenitori per soddisfare il numero pianificato di tenant o il carico di sistema pianificato.
Se si sa con certezza che non si crescerà a un numero elevato di tenant o a un carico elevato, non sovraccaricare il piano di scalabilità orizzontale. Tuttavia, se si prevede di aumentare la soluzione, prendere in considerazione attentamente il piano di scalabilità orizzontale. Assicurarsi di progettare la scalabilità seguendo le indicazioni riportate in questo articolo.
Se si dispone di un processo di distribuzione automatizzato e si deve ridimensionare tra le risorse, determinare come distribuire e assegnare tenant tra più istanze di risorse. Ad esempio, come si rileva che si sta avvicinando al numero di tenant che è possibile assegnare a una risorsa specifica? Si prevede di distribuire nuove risorse just-in-time per le esigenze? In alternativa, si distribuirà un pool di risorse in anticipo in modo che siano pronti per l'uso quando sono necessari?
Suggerimento
Nelle prime fasi di progettazione e sviluppo, è possibile non scegliere di implementare un processo di scalabilità orizzontale automatizzato. È comunque consigliabile prendere in considerazione e documentare chiaramente i processi necessari per la scalabilità man mano che si cresce.
È anche importante evitare di fare ipotesi nel codice e nella configurazione, che possono limitare la scalabilità. Ad esempio, potrebbe essere necessario aumentare il numero di istanze in più account di archiviazione. Assicurarsi che il livello applicazione non presupporrà che si connetta solo a un singolo account di archiviazione per tutti i tenant.
Approcci e modelli da prendere in considerazione
Isolamento dei tenant
Le risorse di Azure vengono distribuite e gestite tramite una gerarchia. La maggior parte delle risorse viene distribuita in gruppi di risorse, contenuti nelle sottoscrizioni. I gruppi di gestione raggruppano logicamente le sottoscrizioni. Tutti questi livelli gerarchici sono associati a un tenant di Microsoft Entra.
Quando si determina come distribuire le risorse per ogni tenant, è possibile isolare a livelli diversi nella gerarchia. Ogni opzione è valida per determinati tipi di soluzioni multi-tenant e offre vantaggi e compromessi. È anche comune combinare approcci, usando modelli di isolamento diversi per diversi componenti di una soluzione.
Isolamento all'interno di una risorsa condivisa
È possibile scegliere di condividere una risorsa di Azure tra più tenant ed eseguire tutti i carichi di lavoro in una singola istanza. Esaminare le linee guida specifiche del servizio per i servizi di Azure usati per comprendere eventuali considerazioni o opzioni specifiche che potrebbero essere importanti.
Quando si eseguono singole istanze di una risorsa, è necessario prendere in considerazione eventuali limiti del servizio, limiti di sottoscrizione o quote che potrebbero essere raggiunti durante la scalabilità. Ad esempio, esiste un numero massimo di nodi supportati da un cluster del servizio Azure Kubernetes (servizio Azure Kubernetes) ed è previsto un limite superiore per il numero di transazioni al secondo supportate da un account di archiviazione. Prendere in considerazione la scalabilità in più risorse condivise man mano che si avvicinano a questi limiti.
È anche necessario assicurarsi che il codice dell'applicazione sia completamente consapevole della multi-tenancy e che limiti l'accesso ai dati per un tenant specifico.
Come illustrazione dell'approccio alle risorse condivise, si supponga che Contoso stia creando un'applicazione SaaS multi-tenant che include un'applicazione Web, un database e un account di archiviazione. Potrebbero decidere di distribuire risorse condivise e di usare queste risorse per gestire tutti i clienti. Nel diagramma seguente un singolo set di risorse viene condiviso da tutti i clienti.
Separare le risorse in un gruppo di risorse
È anche possibile distribuire risorse dedicate per ogni tenant. È possibile distribuire un'intera copia della soluzione per un singolo tenant. In alternativa, è possibile condividere alcuni componenti tra tenant e distribuire altri componenti dedicati a un tenant specifico.
È consigliabile usare i gruppi di risorse per gestire le risorse con lo stesso ciclo di vita. In alcuni sistemi multi-tenant è opportuno distribuire risorse per più tenant in un singolo gruppo di risorse o in un set di gruppi di risorse.
È importante considerare come distribuire e gestire queste risorse, ad esempio se la distribuzione di risorse specifiche del tenant viene avviata dalla pipeline di distribuzione o dall'applicazione. È anche necessario determinare come identificare chiaramente le risorse specifiche correlate a tenant specifici. Prendere in considerazione l'uso di una strategia chiara per la convenzione di denominazione, i tag delle risorse o un database del catalogo tenant.
È consigliabile usare gruppi di risorse separati per le risorse condivise tra più tenant e le risorse distribuite per singoli tenant. Tuttavia, per alcune risorse, Azure limita il numero di risorse di un singolo tipo che può essere distribuito in un gruppo di risorse. Questo limite significa che potrebbe essere necessario ridimensionare più gruppi di risorse man mano che si aumenta.
Si supponga che Contoso abbia tre clienti: Adventure Works, Fabrikam e Tailwind. Possono scegliere di condividere l'applicazione Web e l'account di archiviazione tra i tre clienti e quindi distribuire singoli database per ogni tenant. Nel diagramma seguente a ogni cliente viene assegnato un gruppo di risorse che contiene risorse condivise e un gruppo di risorse che contiene un database.
Separare i gruppi di risorse in una sottoscrizione
Quando si distribuisce un set di risorse per ogni tenant, è consigliabile usare gruppi di risorse specifici del tenant dedicati. Ad esempio, quando si segue il modello Stamp di distribuzione, ogni stamp deve essere distribuito nel proprio gruppo di risorse. È possibile valutare la possibilità di distribuire più gruppi di risorse specifici del tenant in una sottoscrizione di Azure condivisa, che consente di configurare facilmente criteri e regole di controllo di accesso.
È possibile scegliere di creare un set di gruppi di risorse per ogni tenant e anche gruppi di risorse condivise per le risorse condivise.
Quando si distribuiscono gruppi di risorse specifici del tenant in sottoscrizioni condivise, tenere presente il numero massimo di gruppi di risorse in ogni sottoscrizione e altri limiti a livello di sottoscrizione applicabili alle risorse distribuite. Quando si avvicinano questi limiti, potrebbe essere necessario ridimensionare più sottoscrizioni.
In questo esempio, Contoso potrebbe scegliere di distribuire un timbro per ognuno dei clienti e inserire i francobolli in gruppi di risorse dedicati all'interno di una singola sottoscrizione. Nel diagramma seguente viene creata una sottoscrizione, che contiene tre gruppi di risorse, per ogni cliente.
Sottoscrizioni separate
Distribuendo sottoscrizioni specifiche del tenant, è possibile isolare completamente le risorse specifiche del tenant. Inoltre, poiché la maggior parte delle quote e dei limiti si applica all'interno di una sottoscrizione, l'uso di una sottoscrizione separata per ogni tenant garantisce che ogni tenant abbia l'uso completo di tutte le quote applicabili. Per alcuni tipi di account di fatturazione di Azure, è possibile creare sottoscrizioni a livello di codice. È anche possibile usare le prenotazioni di Azure e il piano di risparmio di Azure per il calcolo tra sottoscrizioni.
Tenere presente il numero di sottoscrizioni che è possibile creare. Il numero massimo di sottoscrizioni può variare, a seconda della relazione commerciale con Microsoft o di un partner Microsoft, ad esempio se si ha un contratto Enterprise.
Tuttavia, può essere più difficile richiedere aumenti di quota, quando si lavora in un numero elevato di sottoscrizioni. L'API Quota fornisce un'interfaccia programmatica per alcuni tipi di risorse. Tuttavia, per molti tipi di risorse, è necessario richiedere aumenti di quota avviando un caso di supporto. Può anche essere difficile lavorare con contratti di supporto tecnico di Azure e casi di supporto, quando si lavora con molte sottoscrizioni.
Valutare la possibilità di raggruppare le sottoscrizioni specifiche del tenant in una gerarchia di gruppi di gestione per semplificare la gestione delle regole e dei criteri di controllo di accesso.
Si supponga, ad esempio, che Contoso abbia deciso di creare sottoscrizioni di Azure separate per ognuno dei tre clienti, come illustrato nel diagramma seguente. Ogni sottoscrizione contiene un gruppo di risorse, con il set completo di risorse per il cliente.
Ogni sottoscrizione contiene un gruppo di risorse, con il set completo di risorse per il cliente.
Usano un gruppo di gestione per semplificare la gestione delle sottoscrizioni. Includendo Produzione nel nome del gruppo di gestione, possono distinguere chiaramente i tenant di produzione da tenant non di produzione o di test. I tenant non di produzione avranno regole e criteri di controllo di accesso di Azure diversi applicati.
Tutte le sottoscrizioni sono associate a un singolo tenant di Microsoft Entra. L'uso di un singolo tenant di Microsoft Entra significa che le identità del team contoso, inclusi gli utenti e le entità servizio, possono essere usate nell'intero ambiente di Azure.
Separare le sottoscrizioni in tenant di Microsoft Entra separati
È anche possibile creare manualmente singoli tenant di Microsoft Entra per ognuno dei tenant o distribuire le risorse nelle sottoscrizioni all'interno dei tenant di Microsoft Entra dei clienti. Tuttavia, l'uso di più tenant di Microsoft Entra rende più difficile l'autenticazione, la gestione delle assegnazioni di ruolo, l'applicazione di criteri globali e l'esecuzione di molte altre operazioni di gestione.
Avviso
È consigliabile creare più tenant di Microsoft Entra per la maggior parte delle soluzioni multi-tenant. Lavorare tra i tenant di Microsoft Entra introduce complessità aggiuntive e riduce la capacità di ridimensionare e gestire le risorse. In genere, questo approccio viene usato solo dai provider di servizi gestiti (MSP), che gestiscono gli ambienti Di Azure per conto dei clienti.
Un singolo tenant di Microsoft Entra può essere usato da più sottoscrizioni separate e risorse di Azure. Prima di eseguire uno sforzo per distribuire più tenant di Microsoft Entra, valutare se esistono altri approcci che potrebbero raggiungere gli scopi.
In situazioni in cui è necessario gestire le risorse di Azure nelle sottoscrizioni associate a più tenant di Microsoft Entra, prendere in considerazione l'uso di Azure Lighthouse per gestire le risorse nei tenant di Microsoft Entra.
Ad esempio, Contoso potrebbe creare tenant Microsoft Entra separati e sottoscrizioni di Azure separate per ognuno dei clienti, come illustrato nel diagramma seguente.
Un tenant di Microsoft Entra è configurato per ogni tenant di Contoso, che contiene una sottoscrizione e le risorse necessarie. Azure Lighthouse è connesso a ogni tenant di Microsoft Entra.
Imballaggio bin
Indipendentemente dal modello di isolamento delle risorse, è importante considerare quando e come la soluzione verrà ridimensionata in più risorse. Potrebbe essere necessario ridimensionare le risorse, man mano che aumenta il carico nel sistema o man mano che aumenta il numero di tenant. Prendere in considerazione la creazione di contenitori per distribuire un numero ottimale di risorse per i requisiti.
Suggerimento
In molte soluzioni è più semplice ridimensionare l'intero set di risorse insieme, anziché ridimensionare singolarmente le risorse. Prendere in considerazione il modello Deployment Stamps .Consider following the Deployment Stamps pattern.
Limiti delle risorse
Le risorse di Azure hanno limiti e quote che devono essere considerate nella pianificazione della soluzione. Ad esempio, le risorse potrebbero supportare un numero massimo di richieste simultanee o impostazioni di configurazione specifiche del tenant.
Il modo in cui si configura e si usa ogni risorsa influisce anche sulla scalabilità di tale risorsa. Ad esempio, data una determinata quantità di risorse di calcolo, l'applicazione può rispondere correttamente a un numero definito di transazioni al secondo. Oltre questo punto, potrebbe essere necessario aumentare il numero di istanze. I test delle prestazioni consentono di identificare il punto in cui le risorse non soddisfano più i requisiti.
Nota
Il principio di ridimensionamento a più risorse si applica anche quando si lavora con servizi che supportano più istanze.
Ad esempio, app Azure Servizio supporta l'aumento del numero di istanze del piano, ma esistono limiti per quanto tempo è possibile ridimensionare un singolo piano. In un'app multi-tenant su larga scala, è possibile superare questi limiti e distribuire risorse aggiuntive servizio app in base alla crescita.
Quando si condividono alcune delle risorse tra tenant, è necessario innanzitutto determinare il numero di tenant supportati dalla risorsa, quando è configurato in base ai requisiti. Distribuire quindi il numero totale di risorse necessarie per gestire il numero totale di tenant.
Si supponga, ad esempio, di distribuire un gateway app Azure lication come parte di una soluzione SaaS multi-tenant. Esaminare la progettazione dell'applicazione, testare le prestazioni del gateway applicazione in condizioni di carico ed esaminarne la configurazione. Si determina quindi che una singola risorsa del gateway applicazione può essere condivisa tra 100 clienti. In base al piano di crescita dell'organizzazione, si prevede di eseguire l'onboarding di 150 clienti nel primo anno, quindi è necessario pianificare la distribuzione di più gateway applicazione per il servizio del carico previsto.
Nel diagramma precedente sono presenti due gateway applicazione. Il primo gateway è dedicato ai clienti da 1 a 100 e il secondo è dedicato ai clienti da 101 a 200.
Limiti relativi a gruppi di risorse e sottoscrizioni
Sia che si lavori con risorse condivise o dedicate, è importante tenere conto dei limiti. Azure limita il numero di risorse che possono essere distribuite in un gruppo di risorse e in una sottoscrizione di Azure. Quando si avvicinano questi limiti, è necessario pianificare la scalabilità tra più gruppi di risorse o sottoscrizioni.
Si supponga, ad esempio, di distribuire un gateway applicazione dedicato, per ognuno dei clienti, in un gruppo di risorse condiviso. Per alcune risorse, supporto tecnico di Azure che distribuiscono fino a 800 risorse dello stesso tipo in un singolo gruppo di risorse. Pertanto, quando si raggiunge questo limite, è necessario distribuire tutti i nuovi gateway applicazione in un altro gruppo di risorse. Nel diagramma seguente sono presenti due gruppi di risorse. Ogni gruppo di risorse contiene 800 gateway applicazione.
Tenant bin pack tra gruppi di risorse e sottoscrizioni
È anche possibile applicare il concetto di compressione bin tra risorse, gruppi di risorse e sottoscrizioni. Ad esempio, quando si dispone di un numero ridotto di tenant, è possibile distribuire una singola risorsa e condividerla tra tutti i tenant. Il diagramma seguente mostra la compressione del contenitore in una singola risorsa.
Man mano che si aumenta, è possibile raggiungere il limite di capacità per una singola risorsa e aumentare il numero di istanze a più risorse (R). Il diagramma seguente illustra la creazione di contenitori in più risorse.
Nel corso del tempo, è possibile raggiungere il limite del numero di risorse in un singolo gruppo di risorse e quindi distribuire più risorse (R) in più gruppi di risorse (G). Il diagramma seguente mostra la compressione dei contenitori tra più risorse, in più gruppi di risorse.
Man mano che si aumenta ancora di più, è possibile distribuire in più sottoscrizioni (S), ognuna contenente più gruppi di risorse (G) con più risorse (R). Il diagramma seguente illustra la creazione di contenitori tra più risorse, in più gruppi di risorse e sottoscrizioni.
Pianificando la strategia di scalabilità orizzontale, è possibile passare a un numero estremamente elevato di tenant e sostenere un elevato livello di carico.
Tag
I tag delle risorse consentono di aggiungere metadati personalizzati alle risorse di Azure, che possono essere utili per la gestione e il monitoraggio dei costi. Per altre informazioni, vedere Allocare i costi usando i tag delle risorse.
Antipattern da evitare
- Non pianificare la scalabilità. Assicurarsi di avere una chiara comprensione dei limiti delle risorse che verranno distribuite e quali limiti potrebbero diventare importanti, man mano che aumenta il carico o il numero di tenant. Pianificare la distribuzione di risorse aggiuntive durante la scalabilità e il test del piano.
- Non prevede di bin pack. Anche se non è necessario aumentare immediatamente, pianificare la scalabilità delle risorse di Azure tra più risorse, gruppi di risorse e sottoscrizioni nel tempo. Evitare di fare ipotesi nel codice dell'applicazione, ad esempio una singola risorsa quando potrebbe essere necessario ridimensionarsi a più risorse in futuro.
- Ridimensionamento di molte singole risorse. Se si dispone di una topologia di risorse complessa, può diventare difficile ridimensionare singoli componenti, uno alla volta. Spesso è più semplice ridimensionare la soluzione come unità, seguendo il modello Stamp di distribuzione.
- Distribuzione di risorse isolate per ogni tenant, quando non necessario. In molte soluzioni è più conveniente ed efficiente distribuire risorse condivise per più tenant.
- Uso di tenant Microsoft Entra separati. In generale, è sconsigliabile effettuare il provisioning di più tenant di Microsoft Entra. La gestione delle risorse nei tenant di Microsoft Entra è complessa. È più semplice ridimensionare le sottoscrizioni collegate a un singolo tenant di Microsoft Entra.
- Overarchitecting quando non è necessario ridimensionare. In alcune soluzioni si sa con certezza che non si crescerà mai oltre un certo livello di scalabilità. In questi scenari non è necessario creare logica di ridimensionamento complessa. Tuttavia, se l'organizzazione prevede di crescere, sarà necessario prepararsi a ridimensionare, potenzialmente a breve.
Collaboratori
Questo articolo viene gestito da Microsoft. Originariamente è stato scritto dai seguenti contributori.
Autore principale:
- John Downs | Principal Customer Engineer, FastTrack per Azure
Altri contributori:
- Jason Beck | Senior Customer Engineer, FastTrack per Azure
- Bohdan Cherchyk | Senior Customer Engineer, FastTrack per Azure
- Laura Nicolas | Senior Customer Engineer, FastTrack per Azure
- Arsen Vladimirintune | Principal Customer Engineer, FastTrack per Azure
- Joshua Waddell | Senior Customer Engineer, FastTrack per Azure
Per visualizzare i profili LinkedIn non pubblici, accedere a LinkedIn.
Passaggi successivi
Esaminare gli approcci di gestione dei costi e allocazione .