Una soluzione multi-tenant ha più piani e ognuno ha le proprie responsabilità. Il piano dati consente agli utenti finali e ai client di interagire con il sistema. Il piano di controllo è il componente che gestisce le attività di livello superiore in tutti i tenant, ad esempio il controllo di accesso, il provisioning e la manutenzione del sistema per supportare le attività degli amministratori della piattaforma.
Questo articolo fornisce informazioni sulle responsabilità dei piani di controllo e su come progettare un piano di controllo che soddisfi le proprie esigenze.
Si consideri, ad esempio, un sistema di contabilità per la gestione dei record finanziari. Più tenant archiviano i propri record finanziari nel sistema. Quando gli utenti finali accedono al sistema per visualizzare e immettere i propri record finanziari, usano il piano dati. Il piano dati è probabilmente il componente principale dell'applicazione per la soluzione. I tenant probabilmente lo considerano come il modo per usare il sistema per lo scopo previsto. Al contrario, il piano di controllo è il componente che esegue l'onboarding di nuovi tenant, crea database per ogni tenant ed esegue altre operazioni di gestione e manutenzione. Se il sistema non dispone di un piano di controllo, gli amministratori dovranno eseguire molti processi manuali. In alternativa, le attività del piano dati e del piano di controllo verrebbero combinate, sovraplicando la soluzione.
Molti sistemi complessi includono piani di controllo. Ad esempio, il piano di controllo di Azure, Azure Resource Manager, è un set di API, strumenti e componenti back-end responsabili della distribuzione e della configurazione delle risorse di Azure. Il piano di controllo Kubernetes gestisce molte attività, ad esempio il posizionamento dei pod Kubernetes nei nodi di lavoro. Quasi tutte le soluzioni SaaS (Software as a Service) hanno un piano di controllo per gestire le attività tra tenant.
Quando si progettano soluzioni multi-tenant, è necessario prendere in considerazione i piani di controllo. Le sezioni seguenti forniscono i dettagli necessari per definire l'ambito e progettare un piano di controllo.
Responsabilità di un piano di controllo
Non esiste un singolo modello per un piano di controllo o le relative responsabilità. I requisiti e l'architettura della soluzione determinano le operazioni che devono essere eseguite dal piano di controllo. In alcune soluzioni multi-tenant, il piano di controllo ha un'ampia gamma di responsabilità ed è un sistema complesso a proprio diritto. In altre soluzioni multi-tenant, il piano di controllo ha solo responsabilità di base.
In generale, un piano di controllo potrebbe avere molte delle responsabilità principali seguenti:
- Gestione delle risorse: effettuare il provisioning e gestire le risorse di sistema necessarie al sistema per gestire il carico di lavoro, incluse le risorse specifiche del tenant. Il piano di controllo potrebbe richiamare e orchestrare una pipeline di distribuzione responsabile delle distribuzioni oppure potrebbe eseguire le operazioni di distribuzione stesse.
- Configurazione delle risorse: riconfigurare le risorse condivise in modo che siano consapevoli dei nuovi tenant. Ad esempio, il piano di controllo potrebbe configurare il routing di rete per assicurarsi che il traffico in ingresso sia mappato alle risorse del tenant corretto oppure potrebbe essere necessario ridimensionare la capacità delle risorse.
- Configurazione del tenant: archiviare e gestire la configurazione di ogni tenant.
- Gestione del ciclo di vita del tenant: gestire gli eventi del ciclo di vita del tenant, inclusi l'onboarding, lo spostamento e l'offboarding dei tenant.
- Telemetria: tenere traccia dell'uso delle funzionalità di ogni tenant e delle prestazioni del sistema.
- Rilevamento consumo: misurare il consumo di ogni tenant delle risorse del sistema. Le metriche di consumo potrebbero informare i sistemi di fatturazione o potrebbero essere usate per la governance delle risorse.
Se si usa il modello di tenancy multi-tenant completo e non si distribuiscono risorse specifiche del tenant, un piano di controllo di base potrebbe tenere traccia dei tenant e dei relativi metadati associati. Ad esempio, ogni volta che un nuovo tenant si iscrive al servizio, il piano di controllo potrebbe aggiornare i record appropriati in un database in modo che il resto del sistema sia in grado di soddisfare le richieste del nuovo tenant.
Si supponga invece che la soluzione usi un modello di distribuzione che richiede un'infrastruttura specifica del tenant, ad esempio il modello a tenant singolo automatizzato. In questo scenario, il piano di controllo potrebbe avere più responsabilità, ad esempio la distribuzione o la riconfigurazione dell'infrastruttura di Azure ogni volta che si esegue l'onboarding di un nuovo tenant. In questo tipo di soluzione, è probabile che il piano di controllo debba interagire con i piani di controllo per i servizi e le tecnologie usati, ad esempio Azure Resource Manager o il piano di controllo Kubernetes.
Anche i piani di controllo più avanzati possono assumere più responsabilità:
- Eseguire operazioni di manutenzione automatizzate: le operazioni di manutenzione comuni includono l'eliminazione o l'archiviazione di dati obsoleti, la creazione e la gestione degli indici di database e la rotazione di segreti e certificati crittografici.
- Posizionamento del tenant: allocare tenant a distribuzioni o timbri esistenti, che possono essere basati su un'ampia gamma di criteri, tra cui obiettivi di utilizzo stamp, requisiti del tenant e strategie di compressione bin.
- Ribilanciamento del tenant: ribilanciare i tenant esistenti tra i timbri di distribuzione man mano che cambiano l'utilizzo.
- Rilevamento delle attività dei clienti: eseguire l'integrazione con soluzioni di gestione dei clienti esterne, ad esempio Microsoft Dynamics 365, per tenere traccia dell'attività dei clienti.
Definire l'ambito di un piano di controllo
È necessario considerare attentamente quanto impegno spendere per la creazione di un piano di controllo per la soluzione. I piani di controllo da soli non forniscono valore immediato al cliente, quindi potrebbe non essere facile giustificare il lavoro di progettazione di spesa per la progettazione e la creazione di un piano di controllo di alta qualità. Tuttavia, man mano che il sistema cresce e aumenta, è sempre più necessario automatizzare la gestione e le operazioni per mantenere il passo con la crescita.
In determinate situazioni, potrebbe non essere necessario un piano di controllo completo. Questa situazione può verificarsi se il sistema avrà meno di 5-10 tenant. Al contrario, il team può assumere le responsabilità di un piano di controllo e può usare operazioni e processi manuali per eseguire l'onboarding e gestire i tenant. Tuttavia, è comunque necessario avere un processo e una posizione centrale per tenere traccia dei tenant e delle relative configurazioni.
Suggerimento
Se si decide di non creare un piano di controllo completo, è comunque consigliabile essere sistematici sulle procedure di gestione:
- Documentare accuratamente i processi.
- Laddove possibile, creare e riutilizzare script per le operazioni di gestione.
Se è necessario automatizzare i processi in futuro, la documentazione e gli script possono costituire la base del piano di controllo.
Man mano che si superano alcuni tenant, è probabile che si tragga vantaggio da avere un modo per tenere traccia di ogni tenant e applicare il monitoraggio in tutta la flotta di risorse e tenant. È anche possibile notare che il team impiega molto tempo e impegno nella gestione dei tenant. In alternativa, è possibile notare bug o problemi operativi a causa di incoerenze nei modi in cui i membri del team eseguono attività di gestione. Se si verificano queste situazioni, è opportuno prendere in considerazione la creazione di un piano di controllo più completo per assumere queste responsabilità.
Nota
Se si fornisce la gestione dei tenant self-service, è necessario un piano di controllo all'inizio del viaggio. È possibile scegliere di creare un piano di controllo di base e automatizzare solo alcune delle funzionalità più usate. È possibile aggiungere progressivamente altre funzionalità nel tempo.
Progettare un piano di controllo
Dopo aver determinato i requisiti e l'ambito del piano di controllo, è necessario progettarlo e progettarlo. Un piano di controllo è un componente importante. È necessario pianificarla attentamente, proprio come si pianificano gli altri elementi del sistema.
Piani di controllo ben architettati
Poiché un piano di controllo è un proprio sistema, è importante considerare tutti e cinque i pilastri di Azure Well-Architected Framework quando si progetta uno. Le sezioni seguenti evidenziano alcune aree specifiche su cui concentrarsi.
Affidabilità
I piani di controllo sono spesso componenti cruciali. È essenziale pianificare il livello di resilienza e affidabilità necessari al piano di controllo.
Considerare cosa accade se il piano di controllo non è disponibile. In casi estremi, un'interruzione del piano di controllo potrebbe causare l'indisponibilità dell'intera soluzione. Anche se il piano di controllo non è un singolo punto di guasto, un'interruzione potrebbe avere alcuni degli effetti seguenti:
- Il sistema non è in grado di eseguire l'onboarding di nuovi tenant, che potrebbero influire sulle vendite e sulla crescita aziendale.
- Il sistema non può gestire i tenant esistenti, con un numero maggiore di chiamate al team di supporto.
- Non è possibile misurare l'utilizzo dei tenant o fatturarli per il loro utilizzo, il che comporta ricavi persi.
- Non è possibile rispondere a un evento imprevisto di sicurezza disabilitando o riconfigurando un tenant.
- Il debito di manutenzione si accumula, con conseguenti danni a lungo termine al sistema. Ad esempio, se la soluzione richiede la pulizia notturna dei dati obsoleti, i dischi potrebbero riempirsi o ridurre le prestazioni.
Definire gli obiettivi a livello di servizio per il piano di controllo, inclusi gli obiettivi di disponibilità, l'obiettivo del tempo di ripristino (RTO) e l'obiettivo del punto di ripristino (RPO). Gli obiettivi impostati per il piano di controllo potrebbero essere diversi da quelli offerti ai clienti.
Seguire le linee guida di Azure Well-Architected Framework per la creazione di soluzioni affidabili in tutto il sistema, incluso il piano di controllo.
Sicurezza
I piani di controllo sono spesso sistemi con privilegi elevati. I problemi di sicurezza all'interno di un piano di controllo possono avere conseguenze irreversibili. A seconda della progettazione e della funzionalità, un piano di controllo potrebbe essere vulnerabile a molti tipi diversi di attacchi, tra cui i seguenti:
- Un piano di controllo potrebbe avere accesso a chiavi e segreti per tutti i tenant. Un utente malintenzionato che ha accesso al piano di controllo potrebbe essere in grado di accedere ai dati o alle risorse di qualsiasi tenant.
- Un piano di controllo può spesso distribuire nuove risorse in Azure. Gli utenti malintenzionati potrebbero essere in grado di sfruttare il piano di controllo per distribuire le proprie risorse nelle sottoscrizioni, con potenziali addebiti elevati.
- Se un utente malintenzionato porta il piano di controllo offline, può verificarsi un danno immediato e a lungo termine al sistema e all'azienda. Vedere Affidabilità per le conseguenze di un piano di controllo non disponibile.
Quando si progetta e si implementa un piano di controllo, è essenziale seguire le procedure consigliate per la sicurezza e creare un modello di minaccia completo per documentare e mitigare potenziali minacce e problemi di sicurezza nella soluzione. Per altre informazioni, vedere le linee guida di Azure Well-Architected Framework per la creazione di soluzioni sicure.
Eccellenza operativa
Poiché un piano di controllo è un componente critico, è consigliabile valutare attentamente come distribuirlo e usarlo nell'ambiente di produzione.
Analogamente ad altre parti della soluzione, è consigliabile distribuire istanze non di produzione del piano di controllo in modo che sia possibile testarne accuratamente le funzionalità. Se il piano di controllo esegue operazioni di distribuzione, valutare in che modo i piani di controllo non di produzione interagiscono con l'ambiente di Azure e la sottoscrizione di Azure in cui si distribuiscono risorse non di produzione. Pianificare anche come pulire rapidamente le risorse di test in modo che non accumulino accidentalmente addebiti.
È anche necessario pianificare come gestire l'accesso del team al piano di controllo. Seguire le procedure consigliate per concedere solo le autorizzazioni necessarie ai membri del team per svolgere i propri compiti. Oltre a contribuire a evitare incidenti di sicurezza, questo approccio consente di ridurre l'effetto di errori di configurazione accidentali.
Componenti
Non esiste un singolo modello per un piano di controllo e i componenti che si progettano e compilano dipendono dai requisiti. In genere, un piano di controllo è costituito da API e componenti di lavoro in background. In alcune soluzioni, un piano di controllo può includere anche un'interfaccia utente, che il team o persino i clienti potrebbero usare.
Isolare il piano di controllo dai carichi di lavoro del tenant
È consigliabile separare le risorse del piano di controllo da quelle usate per gestire i piani dati dei tenant. È ad esempio consigliabile usare server di database separati, server applicazioni e altri componenti. Spesso è consigliabile mantenere le risorse del piano di controllo in un gruppo di risorse di Azure separato da quelle che contengono risorse specifiche del tenant.
Isolando il piano di controllo dai carichi di lavoro dei tenant, si ottengono diversi vantaggi:
- È possibile configurare il ridimensionamento separatamente. Ad esempio, il piano di controllo potrebbe avere requisiti di risorse coerenti e le risorse dei tenant potrebbero essere ridimensionate in modo elastico in base alle proprie esigenze.
- C'è una testa di blocco tra il controllo e i piani dati, che consente di evitare problemi rumorosi vicini di distribuirsi tra i piani della soluzione.
- I piani di controllo sono in genere sistemi con privilegi elevati con livelli elevati di accesso. Separando il piano di controllo dai piani dati, si riduce la probabilità che una vulnerabilità di sicurezza possa consentire agli utenti malintenzionati di elevare le autorizzazioni nell'intero sistema.
- È possibile distribuire configurazioni di rete e firewall separate. I piani dati e i piani di controllo richiedono in genere tipi diversi di accesso alla rete.
Orchestrare sequenze di operazioni a esecuzione prolungata
Le operazioni eseguite da un piano di controllo sono spesso a esecuzione prolungata e comportano il coordinamento tra più sistemi. Le operazioni possono anche avere modalità di errore complesse. Quando si progetta il piano di controllo, è importante usare una tecnologia adatta per coordinare operazioni o flussi di lavoro a esecuzione prolungata.
Si supponga, ad esempio, che, quando si esegue l'onboarding di un nuovo tenant, il piano di controllo esegua le azioni seguenti in sequenza:
- Distribuire un nuovo database. Questa azione è un'operazione di distribuzione di Azure. Il completamento potrebbe richiedere alcuni minuti.
- Aggiornare il catalogo dei metadati del tenant. Questa azione potrebbe comportare l'esecuzione di un comando su un database SQL di Azure.
- Inviare un messaggio di posta elettronica di benvenuto al nuovo tenant. Questa azione richiama un'API di terze parti per inviare il messaggio di posta elettronica.
- Aggiornare il sistema di fatturazione per prepararsi alla fatturazione del nuovo tenant. Questa azione richiama un'API di terze parti. Si è notato che ha esito negativo intermittente.
- Aggiornare il sistema CRM (Customer Relationship Management) per tenere traccia del nuovo tenant. Questa azione richiama un'API di terze parti.
Se un passaggio della sequenza ha esito negativo, è necessario prendere in considerazione le operazioni da eseguire, ad esempio:
- Ripetere l'operazione non riuscita. Ad esempio, se il comando SQL di Azure nel passaggio 2 ha esito negativo con un errore temporaneo, è possibile riprovare.
- Continuare con il passaggio successivo. Ad esempio, è possibile decidere che sia accettabile se l'aggiornamento al sistema di fatturazione ha esito negativo, perché il team di vendita può aggiungere manualmente il cliente in un secondo momento.
- Abbandonare il flusso di lavoro e attivare un processo di ripristino manuale.
È anche necessario considerare l'esperienza utente per ogni scenario di errore.
Gestire i componenti condivisi
Un piano di controllo deve essere a conoscenza di tutti i componenti che non sono dedicati a tenant specifici, ma vengono invece condivisi. Alcuni componenti potrebbero essere condivisi tra tutti i tenant all'interno di un timbro. Altri componenti possono essere condivisi tra tutti i francobolli in un'area o anche condivisi a livello globale in tutte le aree e i francobolli. Ogni volta che viene eseguito l'onboarding, la riconfigurazione o l'offboarding di un tenant, il piano di controllo deve sapere cosa fare con questi componenti condivisi.
Alcuni componenti condivisi potrebbero dover essere riconfigurati ogni volta che un tenant viene aggiunto o rimosso. Si supponga, ad esempio, di avere un profilo Frontdoor di Azure condiviso a livello globale. Se si aggiunge un tenant con un nome di dominio personalizzato, potrebbe essere necessario aggiornare la configurazione del profilo per instradare le richieste per tale nome di dominio all'applicazione corretta. Analogamente, quando un tenant viene disattivato, potrebbe essere necessario rimuovere il nome di dominio personalizzato dal profilo frontdoor di Azure per evitare attacchi di acquisizione del sottodominio.
I componenti condivisi potrebbero avere regole di ridimensionamento complesse che il piano di controllo deve seguire. Si supponga, ad esempio, di seguire un approccio di compressione bin per distribuire i database dei tenant. Quando viene eseguito l'onboarding di un nuovo tenant, si aggiunge un nuovo database SQL di Azure per tale tenant e quindi lo si assegna a un pool elastico SQL di Azure. Potrebbe essere stato determinato che è necessario aumentare le risorse allocate al pool per ogni decimo database aggiunto. Quando si aggiunge o si rimuove un tenant, il piano di controllo deve rivalutare la configurazione del pool e decidere se modificare le risorse del pool. Quando si raggiunge il numero massimo di database che è possibile assegnare a un singolo pool elastico, è necessario creare un nuovo pool e iniziare a usare tale pool per i nuovi database tenant. Il piano di controllo deve assumere la responsabilità di gestire ognuno di questi componenti condivisi, ridimensionarli e riconfigurarli ogni volta che cambia qualcosa.
Quando il piano di controllo gestisce i componenti condivisi, è importante tenere presente le race condition, che possono verificarsi quando si verificano più operazioni in parallelo. Ad esempio, se si esegue l'onboarding di un nuovo tenant contemporaneamente all'offboarding di un tenant diverso, è necessario assicurarsi che lo stato finale finale sia coerente e soddisfi i requisiti di scalabilità.
Usare più piani di controllo
In un ambiente complesso, potrebbe essere necessario usare più piani di controllo, ognuno con aree diverse di responsabilità. Molte soluzioni multi-tenant seguono il modello Stamp di distribuzione e i tenant di partizione in più stamp. Quando si usa questo modello, è possibile creare piani di controllo separati per le responsabilità globali e di stamp.
Suggerimento
Il coordinamento tra più piani di controllo è complesso, quindi provare a ridurre al minimo il numero di piani di controllo compilati. La maggior parte delle soluzioni richiede un solo piano di controllo.
Piani di controllo globali
Un piano di controllo globale è in genere responsabile della gestione complessiva e del rilevamento dei tenant. Un piano di controllo globale potrebbe avere le responsabilità seguenti:
- Posizionamento del tenant. Il piano di controllo globale determina quale stamp deve essere usato da un tenant. Questa determinazione può essere determinata in base a fattori come l'area del tenant, l'utilizzo della capacità di ogni stamp e i requisiti del livello di servizio del tenant.
- Onboarding del tenant e gestione del ciclo di vita. Queste responsabilità includono il rilevamento di tutti i tenant in tutte le distribuzioni.
Piani di controllo stamp
Un piano di controllo stamp viene distribuito in ogni stamp di distribuzione ed è responsabile dei tenant e delle risorse allocate a tale stamp. Un piano di controllo stamp potrebbe avere queste responsabilità:
- Creazione e gestione di risorse specifiche del tenant all'interno del timbro, ad esempio database e contenitori di archiviazione.
- Gestione delle risorse condivise, incluso il monitoraggio dell'utilizzo delle risorse condivise e la distribuzione di nuove istanze quando si avvicinano alla capacità massima.
- Esecuzione di operazioni di manutenzione all'interno dello stamp, ad esempio operazioni di gestione e pulizia degli indici del database.
Il piano di controllo di ogni stamp si coordina con il piano di controllo globale. Si supponga, ad esempio, di iscriversi a un nuovo tenant. Il piano di controllo globale è inizialmente responsabile della selezione di un timbro per le risorse del tenant. Il piano di controllo globale richiede quindi al piano di controllo dello stamp di creare le risorse necessarie per il tenant.
Il diagramma seguente mostra un esempio di come i due piani di controllo possono coesistere in un unico sistema:
Piani di controllo tenant
I tenant possono usare un piano di controllo a livello di tenant per gestire le proprie risorse logiche o fisiche. Un piano di controllo tenant potrebbe avere le responsabilità seguenti:
- Gestione della configurazione specifica del tenant, ad esempio l'accesso utente.
- Operazioni di manutenzione avviate dal tenant, ad esempio il backup dei dati o il download di un backup precedente.
- Gestione degli aggiornamenti, se si consente ai tenant di controllare i propri aggiornamenti alle applicazioni.
Il diagramma seguente mostra un sistema complesso con un piano di controllo globale, piani di controllo stamp e un piano di controllo per ogni tenant:
Collaboratori
Questo articolo viene gestito da Microsoft. Originariamente è stato scritto dai seguenti contributori.
Autore principale:
- John Downs | Principal Software Engineer
Altri contributori:
- Mick Alberts | Writer tecnico
- Bohdan Cherchyk | Senior Customer Engineer, FastTrack per Azure
- Landon Pierce | Customer Engineer, FastTrack per Azure
- Daniel Scott-Raynsford | Partner Technology Strategist
- Arsen Vladimirintune | Principal Customer Engineer, FastTrack per Azure
Per visualizzare i profili LinkedIn non pubblici, accedere a LinkedIn.