Indipendentemente dall'architettura e dai componenti usati per implementarla, è necessario distribuire e configurare i componenti della soluzione. In un ambiente multi-tenant è importante considerare come distribuire le risorse di Azure, soprattutto quando si distribuiscono risorse dedicate per ogni tenant o quando si riconfigurano le risorse in base al numero di tenant nel sistema. In questa pagina vengono forniti agli architetti della soluzione indicazioni sulla distribuzione di soluzioni multi-tenant e vengono illustrati alcuni approcci da considerare quando si pianifica la strategia di distribuzione.
Considerazioni e requisiti principali
È importante avere una chiara idea dei requisiti, prima di pianificare la strategia di distribuzione. Le considerazioni specifiche includono quanto segue:
- Scala prevista: Si prevede di supportare un numero ridotto di tenant (ad esempio cinque o meno) o si creerà un numero elevato di tenant?
- Onboarding automatico o supportato: Quando un tenant è pronto per l'onboarding, sarà in grado di completare il processo stesso seguendo una procedura automatizzata? In alternativa, i nuovi tenant avviano una richiesta e li si esegue manualmente dopo aver ricevuto la richiesta? Sono necessari passaggi di approvazione manuale del team, ad esempio per evitare l'abuso del servizio?
- Tempo di provisioning: Quando un tenant è pronto per l'onboarding, come deve essere completato il processo di onboarding? Se non si ha una risposta chiara, valutare se questa operazione deve essere misurata in secondi, minuti, ore o giorni.
- Azure Marketplace: usare il Azure Marketplace per avviare la distribuzione? In caso affermativo, sono necessari requisiti per aggiungere nuovi tenant.
È anche consigliabile considerare i passaggi di onboarding e provisioning, l'automazione e la responsabilità della gestione delle risorse.
Passaggi di onboarding e provisioning
Prendere in considerazione tutto ciò che è necessario eseguire durante l'onboarding di un tenant e documentare questo elenco e flusso di lavoro, anche se viene eseguito manualmente. Il flusso di lavoro di onboarding include in genere quanto segue:
- Accettazione di contratti commerciali.
- Raccolta delle informazioni necessarie per configurare il sistema per il nuovo tenant.
- Passaggi di approvazione manuale, ad esempio, per prevenire frodi o abusi del servizio.
- Provisioning delle risorse in Azure.
- Creazione o configurazione di nomi di dominio.
- Eseguire attività di configurazione post-distribuzione, ad esempio la creazione del primo account utente per il tenant e trasmettere in modo sicuro le credenziali al tenant.
- Modifiche alla configurazione manuale, ad esempio modifiche ai record DNS.
Documentare chiaramente il flusso di lavoro necessario per eseguire l'onboarding di un nuovo tenant.
Considerare inoltre le risorse di Azure specifiche che è necessario effettuare il provisioning per un tenant. Anche se non si esegue il provisioning di risorse dedicate per ogni tenant, valutare se a volte è necessario distribuire le risorse quando viene eseguito l'onboarding di un nuovo tenant. Ciò può verificarsi quando un tenant richiede che i dati vengano archiviati in un'area specifica o quando si avvicinano i limiti di un timbro o componente nella soluzione e devono creare un'altra istanza per il successivo batch di tenant.
Valutare se il processo di onboarding è probabile che sia dirompente per altri tenant, soprattutto per coloro che condividono la stessa infrastruttura. Ad esempio, se è necessario modificare i database condivisi, questo processo potrebbe causare un impatto sulle prestazioni che altri tenant potrebbero notare? Valutare se è possibile evitare questi effetti o attenuarli eseguendo il processo di onboarding al di fuori delle normali ore operative.
Automazione
Le distribuzioni automatizzate sono sempre consigliabili per le soluzioni ospitate dal cloud. Quando si lavora con soluzioni multi-tenant, l'automazione della distribuzione diventa ancora più importante per i motivi seguenti:
- Scala: I processi di distribuzione manuale diventano sempre più complessi e richiedono molto tempo, poiché il popolamento del tenant aumenta. Un approccio di distribuzione automatizzato è più semplice da ridimensionare man mano che il numero di tenant aumenta.
- Ripetibile: In un ambiente multi-tenant usare un processo coerente per le distribuzioni in tutti i tenant. I processi manuali introducono la possibilità di errori o di passaggi eseguiti per alcuni tenant e non per altri. Questi processi manuali lasciano l'ambiente in uno stato incoerente, che rende più difficile per il team gestire la soluzione.
- Impatto delle interruzioni: Le distribuzioni manuali sono significativamente più rischiose e soggette a interruzioni rispetto alle distribuzioni automatizzate. In un ambiente multi-tenant, l'impatto di un'interruzione a livello di sistema (a causa di un errore di distribuzione) può essere elevato, poiché ogni tenant potrebbe essere interessato.
Quando si distribuisce in un ambiente multi-tenant, è necessario usare pipeline di distribuzione e usare le tecnologie di infrastruttura come codice (IaC), ad esempio Bicep, modelli JSON ARM, Terraform o Azure SDK.
Se si prevede di offrire la soluzione tramite la Azure Marketplace, è necessario fornire un processo di onboarding completamente automatizzato per i nuovi tenant. Questo processo è descritto nella documentazione delle API di evasione SaaS.
Capacità massima delle risorse
Quando si distribuiscono a livello di codice le risorse tenant nelle risorse condivise, considerare il limite di capacità per ogni risorsa. Quando si avvicina tale limite, potrebbe essere necessario creare un'altra istanza della risorsa per supportare un'ulteriore scalabilità. Prendere in considerazione i limiti di ogni risorsa distribuita e le condizioni che verranno attivate per distribuire un'altra istanza.
Si supponga, ad esempio, che la soluzione includa un server logico Azure SQL e che la soluzione esegue il provisioning di un database dedicato in tale server per ogni tenant. Un singolo server logico ha limiti, che includono un numero massimo di database supportati da un server logico. Quando si avvicinano questi limiti, potrebbe essere necessario effettuare il provisioning di nuovi server in modo che sia possibile continuare a eseguire l'onboarding dei tenant. Valutare se automatizzare questo processo o monitorare manualmente la crescita.
Responsabilità della gestione delle risorse
In alcune soluzioni multi-tenant si distribuiscono risorse di Azure dedicate per ogni tenant, ad esempio un database per ogni tenant. In alternativa, è possibile decidere su un numero impostato di tenant da ospitare in una singola istanza di una risorsa, quindi il numero di tenant che si dispone determina il set di risorse distribuite in Azure. In altre soluzioni si distribuisce un singolo set di risorse condivise e si riconfigurano le risorse quando si esegue l'onboarding di nuovi tenant.
Ognuno di questi modelli richiede la distribuzione e la gestione delle risorse in modi diversi e è necessario considerare come distribuire e gestire il ciclo di vita delle risorse di cui si esegue il provisioning. Due approcci comuni sono i seguenti:
- Per considerare i tenant come configurazione delle risorse distribuite e usare le pipeline di distribuzione per distribuire e configurare tali risorse.
- Per considerare i tenant come dati e disporre di un provisioning del piano di controllo e configurare l'infrastruttura per i tenant.
Di seguito sono riportate ulteriori discussioni su questi approcci.
Test
Pianificare un test approfondito della soluzione durante e dopo ogni distribuzione. È possibile usare test automatizzati per verificare il comportamento funzionale e non funzionale della soluzione. Assicurarsi di testare il modello di isolamento del tenant e considerare l'uso di strumenti come Azure Chaos Studio per introdurre intenzionalmente errori che simulano interruzioni reali e verificare che le funzioni della soluzione anche quando un componente non è disponibile o non funziona correttamente.
Approcci e modelli da prendere in considerazione
Diversi modelli di progettazione del Centro architettura di Azure e della community più ampia sono di rilevanza per la distribuzione e la configurazione di soluzioni multi-tenant.
Modello degli stamp di distribuzione
Il modello Deployment Stamps prevede la distribuzione di un'infrastruttura dedicata per un tenant o un gruppo di tenant. Un singolo stamp può contenere più tenant oppure può essere dedicato a un singolo tenant. È possibile scegliere di distribuire un singolo timbro oppure è possibile coordinare una distribuzione tra più francobolli. Se si distribuiscono francobolli dedicati per ogni tenant, è anche possibile valutare la distribuzione di interi francobolli a livello di codice.
Anelli di distribuzione
Gli anelli di distribuzione consentono di implementare gli aggiornamenti a gruppi diversi di infrastruttura in momenti diversi. Questo approccio viene comunemente usato con il modello Stamp di distribuzione e i gruppi di stamp possono essere assegnati a anelli distinti in base alle preferenze del tenant, ai tipi di carico di lavoro e ad altre considerazioni. Per altre informazioni, vedere Anelli di distribuzione.
Flag di funzionalità
I flag di funzionalità consentono di esporre progressivamente nuove funzionalità o versioni della soluzione a tenant diversi, mantenendo una singola codebase. È consigliabile usare Configurazione app di Azure per gestire i flag di funzionalità. Per altre informazioni, vedere Flag di funzionalità.
A volte è necessario abilitare in modo selettivo funzionalità specifiche per determinati clienti. Ad esempio, potrebbe essere disponibile un piano tariffario diverso che consenta l'accesso a determinate funzionalità. I flag di funzionalità non sono in genere la scelta giusta per questi scenari. Prendere invece in considerazione la creazione di un processo per tenere traccia e applicare i diritti di licenza che ogni cliente ha.
Antipattern da evitare
Quando si distribuiscono e si configurano soluzioni multi-tenant, è importante evitare situazioni che impediscono la scalabilità. tra cui:
- Distribuzione manuale e test. Come descritto in precedenza, i processi di distribuzione manuale aggiungono rischi e rallentano la possibilità di distribuire. È consigliabile usare le pipeline per le distribuzioni automatizzate, la creazione a livello di codice delle risorse dal codice della soluzione o una combinazione di entrambe.
- Personalizzazioni specializzate per i tenant. Evitare di distribuire funzionalità o una configurazione che si applica solo a un singolo tenant. Questo approccio aggiunge complessità alle distribuzioni e ai processi di test. Usare invece gli stessi tipi di risorse e codebase per ogni tenant e usare strategie come flag di funzionalità per le modifiche temporanee o per le funzionalità implementate progressivamente oppure usare piani tariffari diversi con diritti di licenza per abilitare in modo selettivo le funzionalità per i tenant che le richiedono. Usare un processo di distribuzione coerente e automatizzato, anche per i tenant con risorse isolate o dedicate.
Elenchi di tenant come configurazione o dati
È possibile considerare i due approcci seguenti quando si distribuiscono risorse in una soluzione multi-tenant:
- Usare una pipeline di distribuzione automatizzata per distribuire ogni risorsa. Man mano che vengono aggiunti nuovi tenant, riconfigurare la pipeline per effettuare il provisioning delle risorse per ogni tenant.
- Usare una pipeline di distribuzione automatizzata per distribuire risorse condivise che non dipendono dal numero di tenant. Per le risorse distribuite per ogni tenant, crearle all'interno dell'applicazione.
Quando si considerano i due approcci, è necessario distinguere tra la gestione dell'elenco di tenant come configurazione o come dati. Questa distinzione è importante anche quando si considera come creare un piano di controllo per il sistema.
Elenco di tenant come configurazione
Quando si considera l'elenco di tenant come configurazione, si distribuiscono tutte le risorse da una pipeline di distribuzione centralizzata. Quando si esegue l'onboarding di nuovi tenant, si riconfigura la pipeline o i relativi parametri. In genere, la riconfigurazione avviene tramite modifiche manuali, come illustrato nel diagramma seguente.
Il processo di onboarding di un nuovo tenant potrebbe essere simile al seguente:
- Aggiornare l'elenco dei tenant. Ciò si verifica in genere manualmente configurando la pipeline stessa o modificando un file di parametri incluso nella configurazione della pipeline.
- Attivare la pipeline da eseguire.
- La pipeline ridistribuisce il set completo di risorse di Azure, incluse le nuove risorse specifiche del tenant.
Questo approccio tende a funzionare correttamente per un numero ridotto di tenant e per le architetture in cui vengono condivise tutte le risorse. Si tratta di un approccio semplice perché tutte le risorse di Azure possono essere distribuite e configurate usando un singolo processo.
Tuttavia, quando si avvicina un numero maggiore di tenant, ad esempio da 5 a 10, diventa complesso riconfigurare la pipeline man mano che si aggiungono tenant. Il tempo necessario per eseguire la pipeline di distribuzione spesso aumenta in modo significativo. Questo approccio non supporta facilmente la creazione di tenant self-service e il lead time prima dell'onboarding di un tenant può essere più lungo perché è necessario attivare l'esecuzione della pipeline.
Elenco di tenant come dati
Quando si considera l'elenco di tenant come dati, si distribuiscono comunque i componenti condivisi usando una pipeline. Tuttavia, per le risorse e le impostazioni di configurazione che devono essere distribuite per ogni tenant, è necessario distribuire o configurare le risorse in modo imperativo. Ad esempio, il piano di controllo può usare gli SDK di Azure per creare una risorsa specifica o per avviare la distribuzione di un modello con parametri.
Il processo di onboarding di un nuovo tenant potrebbe essere simile al seguente e si verificherebbe in modo asincrono:
- Richiedere l'onboarding di un tenant, ad esempio avviando una richiesta API al piano di controllo del sistema.
- Un componente del flusso di lavoro riceve la richiesta di creazione e orchestra i passaggi rimanenti.
- Il flusso di lavoro avvia la distribuzione di risorse specifiche del tenant in Azure. A tale scopo, è possibile usare un modello di programmazione imperativo, ad esempio usando gli SDK di Azure o attivando in modo imperativo la distribuzione di un modello Bicep o Terraform.
- Al termine della distribuzione, il flusso di lavoro salva i dettagli del nuovo tenant nel catalogo tenant centrale. I dati archiviati per ogni tenant possono includere l'ID tenant e gli ID risorsa per tutte le risorse specifiche del tenant create dal flusso di lavoro.
In questo modo, è possibile effettuare il provisioning delle risorse per i nuovi tenant senza ridistribuire l'intera soluzione. È probabile che il tempo necessario per il provisioning di nuove risorse per ogni tenant sia più breve, perché è necessario distribuire solo tali risorse.
Tuttavia, questo approccio spesso richiede molto più tempo per la compilazione e il lavoro da dedicare deve essere giustificato dal numero di tenant o dagli intervalli di tempo di provisioning che è necessario soddisfare.
Per altre informazioni su questo approccio, vedere Considerazioni per i piani di controllo multi-tenant.
Nota
Il completamento delle operazioni di distribuzione e configurazione di Azure richiede spesso tempo. Assicurarsi di usare un processo appropriato per avviare e monitorare queste operazioni a esecuzione prolungata. Ad esempio, è possibile prendere in considerazione il modello asincrono Request-Reply. Usare tecnologie progettate per supportare operazioni a esecuzione prolungata, ad esempio App per la logica di Azure e Durable Functions.
Esempio
Contoso esegue una soluzione multi-tenant per i clienti. Attualmente, hanno sei tenant e prevedono un aumento di 300 tenant nei prossimi 18 mesi. Contoso segue l'app Multi-tenant con database dedicati per ogni approccio al tenant . Sono stati distribuiti un singolo set di risorse servizio app e un server logico Azure SQL condivisi tra tutti i tenant e distribuiscono un database Azure SQL dedicato per ogni tenant, come illustrato nel diagramma seguente.
Contoso usa Bicep per distribuire le risorse di Azure.
Opzione 1: usare le pipeline di distribuzione per tutti gli elementi
Contoso potrebbe prendere in considerazione la distribuzione di tutte le risorse usando una pipeline di distribuzione. La pipeline distribuisce un file Bicep che include tutte le risorse di Azure, inclusi i database Azure SQL per ogni tenant. Un file di parametri definisce l'elenco dei tenant e il file Bicep usa un ciclo di risorse per distribuire un database per ognuno dei tenant elencati, come illustrato nel diagramma seguente.
Se Contoso segue questo modello, è necessario aggiornare il file dei parametri come parte dell'onboarding di un nuovo tenant. È quindi necessario eseguire di nuovo la pipeline. Inoltre, è necessario tenere traccia manualmente del fatto che si trovino vicino a limiti, ad esempio se aumentano a una frequenza imprevistamente elevata e si avvicinano al numero massimo di database supportati in un singolo server logico Azure SQL.
Opzione 2: usare una combinazione di pipeline di distribuzione e creazione di risorse imperative
In alternativa, Contoso potrebbe considerare la possibilità di separare la responsabilità per le distribuzioni di Azure.
Contoso usa un file Bicep che definisce le risorse condivise da distribuire. Le risorse condivise supportano tutti i tenant e includono un database mappa tenant, come illustrato nel diagramma seguente.
Il team contoso crea quindi un piano di controllo che include un'API di onboarding del tenant. Quando il team di vendita ha completato la vendita a un nuovo cliente, Microsoft Dynamics attiva l'API per avviare il processo di onboarding. Contoso offre anche un'interfaccia Web self-service che i clienti possono usare e che attivano anche l'API.
L'API avvia in modo asincrono un flusso di lavoro che esegue l'onboarding dei nuovi tenant. Il flusso di lavoro avvia la distribuzione di un nuovo database Azure SQL, che può essere eseguito da uno degli approcci seguenti:
- Usare Azure SDK per avviare la distribuzione di un secondo file Bicep che definisce il database Azure SQL.
- Usare Azure SDK per creare in modo imperativo un database Azure SQL usando la libreria di gestione.
Dopo la distribuzione del database, il flusso di lavoro aggiunge il tenant al database dell'elenco di tenant, come illustrato nel diagramma seguente.
Gli aggiornamenti continui dello schema del database vengono avviati dal livello applicazione.
Autori di contributi
Questo articolo viene gestito da Microsoft. Originariamente è stato scritto dai collaboratori seguenti.
Autore principale:
- John Downs | Principal Customer Engineer, FastTrack per Azure
Altri collaboratori:
- Bohdan Cherchyk | Senior Customer Engineer, FastTrack per Azure
- Arsen Vladimirintune | Principal Customer Engineer, FastTrack per Azure
Per visualizzare i profili LinkedIn non pubblici, accedere a LinkedIn.