Nota
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare ad accedere o modificare le directory.
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare a modificare le directory.
Quando si compila la soluzione multi-tenant in Azure, è necessario prendere in considerazione molti elementi. Usare questo elenco di controllo come punto di partenza per progettare e creare la soluzione multi-tenant. Questo elenco di controllo è una risorsa complementare alla serie di articoli Architect soluzioni multi-tenant su Azure. L'elenco di controllo è strutturato in base alle considerazioni aziendali e tecniche e ai cinque pilastri di Azure Well-Architected Framework.
Suggerimento
Dopo aver esaminato questo elenco di controllo, seguire la revisione del percorso SaaS per valutare il prodotto Software as a Service (SaaS) analizzando la comprensione dell'architettura multi-tenant e il relativo allineamento con le procedure consigliate per le operazioni SaaS.
Considerazioni aziendali
Comprendere il tipo di soluzione che si sta creando, ad esempio business-to-business (B2B), business-to-consumer (B2C) o il software aziendale e il modo in cui i tenant sono diversi dagli utenti.
Definire i tenant. Comprendere quanti clienti supporti inizialmente e determinare i tuoi piani di crescita.
Definire il modello di determinazione prezzi e assicurarsi che sia allineato al consumo delle risorse di Azure dei tenant.
Comprendere se è necessario separare i tenant in livelli diversi. I livelli possono avere prezzi, funzionalità, promesse di prestazioni e posizioni geografiche diverse.
In base ai requisiti dei clienti, decidere i modelli di locazione appropriati per diverse parti della tua soluzione.
Quando si è pronti, vendere la soluzione multi-tenant B2B usando il marketplace commerciale Microsoft.
Considerazioni sull'affidabilità
Esaminare l'elenco di controlloWell-Architected Framework Reliability, applicabile a tutti i carichi di lavoro.
Comprendere l'antipattern Noisy Neighbor. Impedire ai singoli tenant di influire sulla disponibilità del sistema per altri tenant.
Progettare la soluzione multi-tenant per il livello di crescita previsto. Ma non sovraccaricare la crescita irrealistica.
Definire gli obiettivi SLOs a livello di servizio e, facoltativamente, i contratti SLA a livello di servizio per la soluzione. Gli SLO e gli SLA devono essere basati sui requisiti dei tuoi inquilini.
Testare la scalabilità della soluzione. Assicurarsi che funzioni correttamente con tutti i livelli di carico e che venga ridimensionato correttamente man mano che aumenta il numero di tenant.
Applicare i principi di progettazione chaos per testare l'affidabilità della soluzione.
Considerazioni sulla sicurezza
Applicare i principi zero trust e privilegi minimi in tutti i livelli della soluzione.
Assicurarsi di poter eseguire correttamente la mappatura delle richieste degli utenti ai locatari. Prendere in considerazione l'inclusione del contesto del tenant come parte del sistema di identità o tramite un altro metodo, ad esempio l'autorizzazione del tenant a livello di applicazione.
Progettare per l'isolamento del tenant. Testare continuamente il modello di isolamento.
Assicurarsi che il codice dell'applicazione impedisca l'accesso tra tenant o la perdita di dati.
Eseguire test di penetrazione continui e revisioni del codice di sicurezza.
Comprendere i requisiti di conformità dei tuoi clienti, inclusa la residenza dei dati e qualsiasi standard normativo o di conformità che sono tenuti a rispettare.
Gestire correttamente i nomi di dominio ed evitare vulnerabilità come gli attacchi di acquisizione del nome di dominio e del sottodominio.
Seguire le indicazioni specifiche del servizio per la multi-tenancy.
Considerazioni sull'ottimizzazione dei costi
Rivedere la checklist di Ottimizzazione dei costi del FrameworkWell-Architected, applicabile a tutti i carichi di lavoro.
Assicurarsi di poter misurare in modo adeguato il consumo per tenant e correlarlo ai costi dell'infrastruttura.
Evitare antipattern. Gli antipattern includono la mancata registrazione dei costi, il rilevamento dei costi con precisione non necessaria, l'uso della misurazione in tempo reale e l'uso degli strumenti di monitoraggio per la fatturazione.
Considerazioni sull'eccellenza operativa
Usare l'automazione per gestire il ciclo di vita del tenant, come l'integrazione, la distribuzione, il provisioning e la configurazione.
Comprendere le differenze tra i piani di controllo e i piani dati nella soluzione multi-tenant.
Trovare il giusto equilibrio per la distribuzione degli aggiornamenti del servizio. Prendere in considerazione sia i requisiti dei tenant che i requisiti operativi.
Monitorare l'integrità del sistema complessivo e di ogni tenant.
Configurare e testare gli avvisi per ricevere una notifica quando si verificano problemi specifici dei tenant o superano i limiti di consumo.
Organizzare le risorse di Azure per l'isolamento e la scalabilità.
Evitare gli antipattern di distribuzione e configurazione. Gli antipattern includono l'esecuzione di versioni distinte della soluzione per ogni tenant, le configurazioni o logiche specifiche del tenant codificate in modo fisso, e affidarsi a distribuzioni manuali.
Considerazioni sull'efficienza delle prestazioni
Rivedere la checklist delWell-Architected Framework Performance Efficiency, che è applicabile a tutti i carichi di lavoro.
Se si usa l'infrastruttura condivisa, pianificare come attenuare le preoccupazioni dei vicini rumorosi . Assicurarsi che un singolo tenant non possa ridurre le prestazioni complessive del sistema per altri tenant.
Determinare come ridimensionare le risorse di calcolo, archiviazione, rete e altre risorse di Azure in base alle esigenze dei tenant.
Prendere in considerazione i limiti di scalabilità per ogni risorsa di Azure. Organizzare le risorse in modo appropriato per evitare antipattern dell'organizzazione delle risorse. Ad esempio, non progettare eccessivamente la soluzione per lavorare all'interno di requisiti di scalabilità non realistici.
Contributori
Microsoft gestisce questo articolo. I collaboratori seguenti hanno scritto questo articolo.
Autori principali:
- Arsen Vladimirskiy | Ingegnere Cliente Capo
- Bohdan Cherchyk | Senior Customer Engineer
Altro collaboratore:
- John Downs | Principal Software Engineer
Per visualizzare i profili LinkedIn non pubblici, accedere a LinkedIn.