Condividi tramite

Considerazioni per i piani di controllo multi-tenant

Una soluzione multi-tenant ha più piani e ogni piano ha le proprie responsabilità. Il piano dati consente a utenti e client di interagire con un sistema. Il piano di controllo gestisce attività di livello superiore, ad esempio il controllo di accesso, il provisioning e la manutenzione del sistema, in tutti i tenant per supportare le attività degli amministratori della piattaforma.

Diagramma che mostra una progettazione logica del sistema. Un singolo piano di controllo fornisce la gestione in più piani dati specifici del tenant.

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 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 lo visualizzano in genere come interfaccia principale per l'uso del sistema come previsto.

Al contrario, il piano di controllo esegue l'onboarding di nuovi tenant, crea database per ogni tenant ed esegue altre operazioni di gestione e manutenzione. Senza un piano di controllo, gli amministratori devono basarsi su processi manuali. In alcuni casi, le attività del piano dati e del piano di controllo diventano intrecciate, il che complica le soluzioni.

Molti sistemi complessi includono un piano di controllo. Ad esempio, il piano di controllo di Azure, Azure Resource Manager, è un set di API, strumenti e componenti back-end che distribuiscono e configurano le 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 descrivono come 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 il piano di controllo deve eseguire e come funziona. 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:

Se si usa il modello completamente multi-tenant e non si distribuiscono risorse specifiche del tenant, un piano di controllo di base potrebbe tenere traccia solo dei tenant e dei relativi metadati associati. Ad esempio, quando un nuovo tenant effettua l'iscrizione al servizio, il piano di controllo potrebbe aggiornare i record appropriati in un database in modo che il resto del sistema possa soddisfare le richieste del nuovo tenant.

Al contrario, se la soluzione usa un modello di distribuzione che richiede un'infrastruttura specifica del tenant, ad esempio il modello a tenant singolo automatizzato, il piano di controllo potrebbe avere più responsabilità. Potrebbe essere necessario distribuire o riconfigurare l'infrastruttura di Azure quando si esegue l'onboarding di un nuovo tenant. In questo scenario, il piano di controllo interagisce probabilmente con i piani di controllo per altri strumenti, ad esempio Resource Manager o il piano di controllo Kubernetes.

I piani di controllo avanzati possono assumere più responsabilità:

  • Operazioni di manutenzione automatizzate: Esegue operazioni di manutenzione comuni, tra cui 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: Alloca i tenant a distribuzioni o timbri esistenti in base a criteri quali obiettivi di utilizzo stamp, requisiti del tenant e strategie di compressione bin.

  • Ribilanciamento dei tenant: Ribilancia i tenant esistenti tra gli stamp di distribuzione man mano che cambia il loro utilizzo.

  • Rilevamento delle attività dei clienti: Si integra con soluzioni di gestione dei clienti esterne, come Dynamics 365, per tenere traccia delle attività dei clienti.

Definire l'ambito di un piano di controllo

Valutare attentamente quanto impegno dedicare alla creazione di un piano di controllo per la soluzione. Un piano di controllo non fornisce direttamente valore immediato al cliente, che può rendere difficile giustificare il lavoro di progettazione sulla progettazione e la creazione di un piano di controllo di alta qualità. Tuttavia, man mano che il sistema cresce e si espande, diventa sempre più necessario utilizzare la gestione e le operazioni automatizzate per mantenere il passo con la crescita.

In determinate situazioni, potrebbe non essere necessario un piano di controllo completo. Questo approccio può funzionare se il sistema ha meno di 10 tenant. Il team può assumere le responsabilità del piano di controllo e usare operazioni e processi manuali per eseguire l'onboarding e gestire i tenant. Tuttavia, è comunque necessario disporre di un processo e mantenere una posizione centrale per tenere traccia dei tenant e delle relative configurazioni.

Suggerimento

Se non si crea un piano di controllo completo, è comunque consigliabile applicare un approccio sistematico alle procedure di gestione:

  • Documentare accuratamente i processi.
  • Creare e riutilizzare script per le operazioni di gestione, quando possibile.

Se è necessario automatizzare i processi in futuro, la documentazione e gli script possono costituire la base del piano di controllo.

Man mano che il numero di tenant aumenta, è possibile trarre vantaggio dal monitoraggio di ciascun tenant e dall'applicazione di controlli sulla vostra gamma di risorse e tenant. È possibile notare che il team impiega molto tempo e impegno nella gestione dei tenant. Oppure si potrebbero notare bug o problemi operativi a causa di incoerenze nel modo in cui i membri del team eseguono attività di gestione. Se si verificano queste situazioni, prendere in considerazione la creazione di un piano di controllo più completo per assumere queste responsabilità.

Annotazioni

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 architettarlo. Un piano di controllo è un componente importante e merita lo stesso livello di pianificazione di qualsiasi altra parte dell'architettura.

Considerazioni

Queste considerazioni implementano i pilastri di Azure Well-Architected Framework, che è un set di principi guida che possono essere usati per migliorare la qualità di un carico di lavoro. Per altre informazioni, vedere Well-Architected Framework.

Un piano di controllo funziona come proprio sistema, pertanto è consigliabile considerare tutti e cinque i pilastri del frameworkWell-Architected quando si progetta uno. Le sezioni seguenti evidenziano aree specifiche su cui concentrarsi.

Affidabilità

L'affidabilità garantisce che l'applicazione possa soddisfare gli impegni assunti dai clienti. Per maggiori informazioni, consultare la sezione Elenco di controllo per la revisione della progettazione per l'affidabilità.

I piani di controllo spesso fungono da componenti critici per la missione. È necessario pianificare il livello di resilienza e affidabilità appropriato necessario al piano di controllo.

Valutare l'impatto di un'interruzione del piano di controllo. In casi estremi, un'interruzione potrebbe rendere l'intera soluzione non disponibile. Anche se il piano di controllo non è un singolo punto di guasto, un'interruzione potrebbe causare i problemi seguenti:

  • Il sistema non può 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 disabilitare o riconfigurare un tenant in risposta a un evento imprevisto di sicurezza.

  • 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 le prestazioni potrebbero peggiorare.

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 possono essere diversi dagli obiettivi offerti dai clienti.

Sicurezza

La sicurezza offre garanzie contro attacchi intenzionali e l'uso improprio dei dati e dei sistemi preziosi. Per maggiori informazioni, consultare la sezione Elenco di controllo per la revisione della progettazione per la 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, inclusi i tipi seguenti:

  • Accesso non autorizzato ai segreti: Una piattaforma di controllo potrebbe avere accesso a chiavi e segreti per tutti i utenti. Un attaccante che ha accesso al piano di controllo può accedere ai dati o alle risorse di qualsiasi tenant.

  • Uso improprio delle funzionalità di distribuzione: Un piano di controllo può spesso distribuire nuove risorse in Azure. Gli utenti malintenzionati potrebbero sfruttare il tuo piano di controllo per distribuire le proprie risorse nelle tue sottoscrizioni, incorrendo potenzialmente in addebiti elevati.

  • Negazione del servizio: Se un utente malintenzionato riesce a disabilitare il control plane, possono causare danni sia immediati che a lungo termine al sistema e all'azienda. Per potenziali conseguenze del tempo di inattività del piano di controllo, vedere Affidabilità.

Quando si progetta e si implementa un piano di controllo, è necessario seguire le procedure consigliate per la sicurezza e creare un modello di minaccia completo. Questo modello deve identificare e mitigare potenziali minacce e problemi di sicurezza nella soluzione.

Eccellenza operativa

L'eccellenza operativa copre i processi operativi che distribuiscono un'applicazione e lo mantengono in esecuzione nell'ambiente di produzione. Per maggiori informazioni, consultare la sezione Elenco di controllo per la revisione della progettazione per l'eccellenza operativa.

Un piano di controllo è un componente critico, quindi è 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 distribuire le risorse di non produzione. Pianificare la pulizia rapida delle risorse di test in modo che non accumulino addebiti accidentalmente.

Pianifica anche come gestire l'accesso del tuo team al piano di controllo. Concedere solo le autorizzazioni necessarie ai membri del team per svolgere le proprie mansioni. Questo approccio consente di evitare eventi imprevisti di sicurezza e ridurre l'effetto di errori di configurazione accidentali.

Componenti

Non esiste un singolo modello per la creazione di un piano di controllo. I componenti che progetti e costruisci dipendono dai tuoi requisiti. La maggior parte dei piani di controllo è costituita da API e componenti di lavoro in background. In alcune soluzioni, un piano di controllo include anche un'interfaccia utente, che il team o persino i clienti potrebbero usare.

Isolare il piano di controllo dai carichi di lavoro del tenant

È necessario separare le risorse del piano di controllo dalle risorse che servono i piani dati dei tenant. Ad esempio, usare server di database separati, server applicazioni e altri componenti. Mantenere le risorse del piano di controllo in un gruppo di risorse di Azure dedicato, separate dalle risorse specifiche del tenant.

L'isolamento del piano di controllo offre i vantaggi seguenti:

  • È 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.

  • Una netta separazione crea una testa di blocco tra i piani di controllo e i piani dati, che consente di evitare che i problemi dei vicini rumorosi si distribuissero attraverso la soluzione.

  • I piani di controllo sono in genere sistemi con privilegi elevati con livelli elevati di accesso. L'isolamento del piano di controllo riduce la probabilità che una vulnerabilità di sicurezza consenta 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

I piani di controllo spesso eseguono operazioni a esecuzione prolungata che richiedono il coordinamento tra più sistemi. Queste operazioni possono anche avere modalità di errore complesse, quindi è necessario scegliere tecnologie che supportano operazioni o flussi di lavoro a esecuzione prolungata.

Ad esempio, quando si esegue l'onboarding di un nuovo tenant, il piano di controllo potrebbe eseguire le azioni seguenti in sequenza:

  1. Distribuire un nuovo database. Il completamento di questa operazione di distribuzione di Azure potrebbe richiedere alcuni minuti.

  2. Aggiornare il catalogo dei metadati del tenant. Questa azione potrebbe comportare l'esecuzione di un comando su un database SQL di Azure.

  3. Inviare un messaggio di posta elettronica di benvenuto al nuovo tenant. Questa azione richiama un'API non Microsoft per inviare il messaggio di posta elettronica.

  4. Aggiornare il sistema di fatturazione per prepararsi alla fatturazione del nuovo tenant. Questa azione richiama un'API non Microsoft che occasionalmente non riesce.

  5. Aggiornare il sistema CRM (Customer Relationship Management) per tenere traccia del nuovo tenant. Questa azione richiama un'API non Microsoft.

Se un passaggio della sequenza ha esito negativo, considerare come rispondere:

  • 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, potresti decidere di consentire che l'aggiornamento al sistema di fatturazione fallisca, anche se il team di vendita può aggiungere manualmente il cliente successivamente.

  • Abbandonare il flusso di lavoro e attivare un processo di ripristino manuale.

Considerare anche l'esperienza utente per ogni scenario di errore.

Gestire i componenti condivisi

Un piano di controllo deve riconoscere tutti i componenti condivisi anziché dedicati a tenant specifici. 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. Quando si effettua l'inserimento, la riconfigurazione o l'eliminazione di un tenant, il piano di controllo deve sapere come gestire questi componenti condivisi.

Alcuni componenti condivisi richiedono la riconfigurazione quando i tenant vengono aggiunti o rimossi. 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, il piano di controllo potrebbe dover 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. Ad esempio, se si usa un approccio di compressione bin per distribuire i database dei tenant, il piano di controllo deve assegnare ogni nuovo database a un pool elastico SQL di Azure.

È possibile determinare 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 usarlo per i nuovi database tenant. Il piano di controllo deve gestire ognuno di questi componenti condivisi, inclusi il ridimensionamento e la riconfigurazione quando si verificano modifiche.

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 che gestiscono aree diverse. Molte soluzioni multi-tenant seguono il modello Stamp di distribuzione e i tenant di partizione in più stamp. In questo modello è possibile creare piani di controllo separati per le responsabilità globali e di stamp.

Suggerimento

Il coordinamento tra più piani di controllo aggiunge complessità, 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 gestisce in genere la gestione complessiva e il tracciamento dei tenant. Un piano di controllo globale può 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 a livello di servizio del tenant.

  • Onboarding e gestione del ciclo di vita del tenant: Queste responsabilità includono il tracciamento di tutti i tenant attraverso le distribuzioni.

Piani di controllo stamp

Ogni timbro di distribuzione include il proprio piano di controllo del timbro, che gestisce i tenant e le risorse assegnati a quella timbratura. Un piano di controllo può avere le responsabilità seguenti:

  • Provisioning delle risorse tenant: Crea e gestisce risorse specifiche del tenant all'interno della piattaforma, ad esempio database e contenitori di archiviazione.

  • Gestione risorse condivise: Monitora l'utilizzo delle risorse condivise e distribuisce nuove istanze quando si avvicinano alla capacità massima.

  • Operazioni di manutenzione: Gestisce le attività all'interno dell'ambito, come la gestione degli indici e le operazioni di pulizia nel database.

Il piano di controllo di ogni stamp si coordina con il piano di controllo globale. Ad esempio, se un nuovo tenant si iscrive, il piano di controllo globale potrebbe inizialmente selezionare 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 come due piani di controllo possano coesistere in un unico sistema.

Diagramma che mostra una progettazione logica del sistema. La progettazione ha un piano di controllo globale e piani di controllo stamp.

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 può avere le seguenti responsabilità:

  • Gestione della configurazione: Gestisce la configurazione specifica del tenant, ad esempio l'accesso utente.

  • Operazioni di manutenzione avviate dal tenant: Supporta operazioni come il backup dei dati o il download di backup precedenti.

  • Gestione aggiornamenti: Esegue gli aggiornamenti se si consente ai tenant di controllare i propri aggiornamenti alle applicazioni.

Il diagramma seguente mostra un sistema complesso che include un piano di controllo globale, piani di controllo stamp e piani di controllo tenant.

Diagramma che mostra una progettazione logica del sistema. La progettazione ha un piano di controllo globale, piani di controllo stamp e piani di controllo tenant.

Contributori

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

Autore principale:

Altri collaboratori:

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

Passo successivo