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.
Si applica a:
Database SQL di Azure
Questo articolo illustra il provisioning e la catalogazione dei nuovi tenant, in un modello o schema di database partizionato multi-tenant.
Questo articolo include due parti principali:
Descrizione concettuale del provisioning e della catalogazione dei nuovi tenant.
Esercitazione che evidenzia il codice script di PowerShell che esegue il provisioning e la catalogazione.
- L'esercitazione utilizza l'applicazione SaaS Wingtip Tickets, adattata al modello multi-tenant con database suddiviso.
Modello di database
In questa sezione vengono illustrati i concetti del modello di database partizionato multi-tenant.
In questo modello con partizionamento multi-tenant, ogni database contiene schemi di tabella che includono una chiave del tenant nella chiave primaria delle tabelle che archiviano i dati del tenant. La chiave del tenant consente a ogni singolo database di archiviare 0, 1 o molti tenant. L'uso di database partizionati semplifica il supporto del sistema applicativo per un numero molto elevato di tenant. Tutti i dati per un tenant vengono archiviati in un database. Un grande numero di tenant viene distribuito tra i numerosi database suddivisi. Un database di catalogo archivia le associazioni di ciascun tenant al relativo database.
Isolamento e costo inferiore
Un tenant che dispone di un database a se stesso gode dei vantaggi dell'isolamento. Il tenant può avere il database ripristinato in una data precedente senza essere limitato dall'impatto su altri tenant. Le prestazioni del database possono essere regolate per ottimizzare specificamente un inquilino, anche in questo caso senza dover compromettere gli altri. Il problema è che l'isolamento costa più di quanto costa condividere un database con altri tenant.
Quando viene effettuato il provisioning di un nuovo tenant, può condividere un database con altri tenant oppure inserirlo nel proprio nuovo database. In seguito è possibile cambiare idea e spostare il database nell'altra situazione.
I database con più tenant e tenant singoli vengono misti nella stessa applicazione SaaS per ottimizzare i costi o l'isolamento per ogni tenant.
Modello di catalogo inquilino
Quando si dispone di due o più database che contengono almeno un tenant, l'applicazione deve avere un modo per individuare il database in cui è archiviato il tenant di interesse corrente. Un database di catalogo memorizza questa mappatura.
Chiave del tenant
Per ogni tenant, l'applicazione Wingtip può derivare una chiave univoca, ovvero la chiave del tenant. L'app estrae il nome del tenant dall'URL della pagina Web. L'app esegue l'hashing del nome per ottenere la chiave. L'app usa la chiave per accedere al catalogo. Il catalogo incrocia le informazioni sul database in cui il tenant è archiviato. L'app usa le informazioni sul database per connettersi. È anche possibile usare altri schemi di chiave del tenant.
L'uso di un catalogo consente di modificare il nome o la posizione di un database tenant dopo il provisioning senza interrompere l'applicazione. In un modello di database multi-tenant, il catalogo supporta lo spostamento di un tenant tra database.
Metadati del tenant oltre le informazioni di posizione
Il catalogo può anche indicare se un tenant è offline per la manutenzione o altre azioni. E il catalogo può essere esteso per archiviare altri metadati del tenant o del database, ad esempio gli elementi seguenti:
- Livello di servizio o edizione di un database.
- Versione dello schema del database.
- Nome dell'inquilino e SLA (accordo sul livello di servizio).
- Informazioni per abilitare la gestione delle applicazioni, il supporto tecnico o i processi devops.
Il catalogo può essere usato anche per abilitare la creazione di report tra tenant, la gestione dello schema e l'estrazione dei dati a scopo di analisi.
Libreria client di database elastici
In Wingtip il catalogo viene implementato nel database tenantcatalog . Il tenantcatalog viene creato usando le funzionalità di gestione delle partizioni della libreria client del database elastico (EDCL). La libreria consente a un'applicazione di creare, gestire e usare una mappa partizioni archiviata in un database. Una mappa shard associa la chiave del tenant al suo shard, cioè al database partizionato.
Durante il provisioning di un tenant, le funzioni EDCL possono essere usate dalle applicazioni o dagli script di PowerShell per creare le voci nella mappa delle partizioni. Successivamente, è possibile usare le funzioni EDCL per connettersi al database corretto. EdCL memorizza nella cache le informazioni di connessione per ridurre al minimo il traffico sul database del catalogo e velocizzare il processo di connessione.
Importante
Non modificare i dati nel database del catalogo tramite accesso diretto. Gli aggiornamenti diretti non sono supportati a causa del rischio elevato di danneggiamento dei dati. Modificare invece i dati di mapping usando solo le API EDCL.
Modello di provisioning del cliente
Lista di controllo
Quando si vuole effettuare il provisioning di un nuovo tenant in un database condiviso esistente, del database condiviso è necessario porre le domande seguenti:
- Ha spazio sufficiente per il nuovo tenant?
- Include tabelle con i dati di riferimento necessari per il nuovo tenant oppure è possibile aggiungere i dati?
- Ha la variante appropriata dello schema di base per il nuovo cliente?
- Si trova nella posizione geografica appropriata vicino al nuovo tenant?
- Si tratta del livello di servizio appropriato per il nuovo tenant?
Quando si vuole che il nuovo tenant sia isolato nel proprio database, è possibile crearlo per soddisfare le specifiche per il tenant.
Dopo il completamento del provisioning, è necessario registrare il tenant nel catalogo. Infine, è possibile aggiungere la mappatura del tenant per fare riferimento alla partizione appropriata.
Modello di database
Effettuare il provisioning del database eseguendo script SQL, distribuendo un file bacpac o copiando un database modello. Le app Wingtip copiano un database modello per creare nuovi database tenant.
Come qualsiasi applicazione, Wingtip si evolverà nel tempo. A volte Wingtip richiederà modifiche al database. Le modifiche possono includere gli elementi seguenti:
- Schema nuovo o modificato.
- Dati di riferimento nuovi o modificati.
- Attività di manutenzione del database di routine per garantire prestazioni ottimali dell'app.
Con un'applicazione SaaS, queste modifiche devono essere distribuite in modo coordinato in una flotta potenzialmente elevata di database tenant. Affinché queste modifiche siano presenti nei database tenant futuri, è necessario incorporarle nel processo di provisioning. Questa sfida viene esaminata ulteriormente nell'esercitazione sulla gestione dello schema.
Sceneggiature
Gli script di provisioning del tenant in questo tutorial supportano entrambi gli scenari seguenti.
- Provisioning di un tenant in un database esistente condiviso con altri inquilini.
- Configurazione di un tenant nel proprio database.
I dati del tenant vengono inizializzati e quindi registrati nella mappa dei frammenti del catalogo. Nell'app di esempio, ai database che contengono più tenant viene assegnato un nome generico, ad esempio tenants1 o tenants2. Ai database che contengono un singolo tenant viene assegnato il nome del tenant. Le convenzioni di denominazione specifiche utilizzate nell'esempio non sono una parte critica del modello, poiché l'uso di un catalogo consente di assegnare qualsiasi nome al database.
Inizio dell'esercitazione
In questa esercitazione si apprenderà come:
- Effettuare il provisioning di un tenant in un database multi-tenant
- Effettuare il provisioning di un tenant in un database a tenant singolo
- Effettuare il provisioning di un batch di tenant in database multi-tenant e a tenant singolo
- Registrare una mappatura di database e tenant in un catalogo
Prerequisiti
Per completare questa esercitazione, assicurarsi che siano completati i prerequisiti seguenti:
Azure PowerShell è installato. Per informazioni dettagliate, vedere Introduzione ad Azure PowerShell
L'app Wingtip Tickets SaaS Multi-tenant Database è distribuita. Per completare la distribuzione in meno di cinque minuti, consultare Distribuire e esplorare l'applicazione database multi-tenant SaaS Wingtip Tickets
Ottenere gli script Wingtip e il codice sorgente:
- Gli script del database multi-tenant Wingtip Tickets e il codice sorgente dell'applicazione sono disponibili nel repository GitHub WingtipTicketsSaaS-MultitenantDB .
- Vedere le indicazioni generali per i passaggi per scaricare e sbloccare gli script Wingtip.
Effettuare il provisioning di un tenant in un database condiviso con altri tenant
In questa sezione viene visualizzato un elenco delle azioni principali per il provisioning eseguite dagli script di PowerShell. Usare quindi il debugger di PowerShell ISE per esaminare gli script per visualizzare le azioni nel codice.
Azioni principali del provisioning
Di seguito sono riportati gli elementi chiave del flusso di lavoro di provisioning attraverso cui si passa:
Calcolare la nuova chiave del tenant: viene usata una funzione hash per creare la chiave del tenant dal nome del tenant.
Controllare se la chiave del tenant esiste già: il catalogo viene controllato per assicurarsi che la chiave non sia già stata registrata.
Inizializzare il tenant nel database tenant predefinito: il database tenant viene aggiornato per aggiungere le nuove informazioni sul tenant.
Registrare il tenant nel catalogo: l'associazione tra la nuova chiave del tenant e il database esistente di tenants1 viene aggiunta al catalogo.
Aggiungere il nome del tenant a una tabella di estensione del catalogo: il nome della sede viene aggiunto alla tabella Tenants nel catalogo. Questa aggiunta mostra come il database del catalogo può essere esteso per supportare dati aggiuntivi specifici dell'applicazione.
Aprire la pagina Eventi per il nuovo tenant: la pagina degli eventi Bushwillow Blues viene aperta nel browser.
Passaggi del debugger
Per capire come l'app Wingtip realizza il provisioning di nuovi tenant in un database condiviso, aggiungi un punto di interruzione e segui passo dopo passo il flusso di lavoro:
In PowerShell ISE aprire ...\Learning Modules\ProvisionTenants\Demo-ProvisionTenants.ps1 e impostare i parametri seguenti:
- = $TenantNameBushwillow Blues, il nome di una nuova sede.
- = $VenueTypeblues, uno dei tipi di locali predefiniti: blues, musicaclassica, dance, jazz, judo, corseautomobilistiche, multipurpose, opera, musicarock, soccer (minuscolo, senza spazi).
- = $DemoScenario1, per configurare un tenant in un database condiviso con altri tenant.
Aggiungere un punto di interruzione posizionando il cursore in un punto qualsiasi della riga 38, la riga che indica: New-Tenant ', quindi premere F9.
Eseguire lo script premendo F5.
Dopo l'arresto dell'esecuzione dello script nel punto di interruzione, premere F11 per entrare nel codice.
Traccia l'esecuzione dello script utilizzando le opzioni di menu Debug, F10 e F11, per eseguire passo passo o entrare nelle funzioni chiamate.
Per altre informazioni sul debug degli script di PowerShell, vedere Suggerimenti sull'uso e il debug degli script di PowerShell.
Effettuare il provisioning di un tenant nel proprio database
Azioni principali del provisioning
Di seguito sono riportati gli elementi chiave del flusso di lavoro che si esegue durante la traccia dello script:
Calcolare la nuova chiave del tenant: viene usata una funzione hash per creare la chiave del tenant dal nome del tenant.
Controllare se la chiave del tenant esiste già: il catalogo viene controllato per assicurarsi che la chiave non sia già stata registrata.
Creare un nuovo database tenant: il database viene creato copiando il database basetenantdb usando un modello di Resource Manager. Il nuovo nome del database si basa sul nome del tenant.
Aggiungere un database al catalogo: il nuovo database tenant viene registrato come partizione nel catalogo.
Inizializzare il tenant nel database tenant predefinito: il database tenant viene aggiornato per aggiungere le nuove informazioni sul tenant.
Registrare il tenant nel catalogo: la mappatura tra la nuova chiave del tenant e il database sequoiasoccer è aggiunta al catalogo.
Il nome del tenant viene aggiunto al catalogo: il nome della sede viene aggiunto alla tabella di estensione Tenants nel catalogo.
Aprire la pagina Eventi per il nuovo tenant: la pagina Sequoia Soccer Events viene aperta nel browser.
Passaggi del debugger
Segui ora il processo di script durante la creazione di un tenant nel proprio database:
Ancora in ...\Learning Modules\ProvisionTenants\Demo-ProvisionTenants.ps1 impostare i parametri seguenti:
- = $TenantNameSequoia Soccer, nome di una nuova sede.
- $VenueType = calcio, uno dei tipi di locali predefiniti: blues, musicaclassica, dance, jazz, judo, motociclismo, multipurpose, opera, rockmusic, soccer (minuscolo, senza spazi).
- $DemoScenario = 2, per configurare un tenant nel proprio database.
Aggiungere un nuovo punto di interruzione posizionando il cursore in un punto qualsiasi della riga 57, la riga che indica: & $PSScriptRoot\New-TenantAndDatabase ', e premere F9.
Eseguire lo script premendo F5.
Dopo che l'esecuzione dello script si arresta al punto di interruzione, premere F11 per entrare nel codice. Usare F10 e F11 per passare sopra e entrare nelle funzioni per tracciare l'esecuzione.
Effettuare il rifornimento di un lotto di tenant
Questo esercizio fornisce un batch di 17 inquilini. È consigliabile effettuare il provisioning di questo batch di tenant prima di iniziare altre esercitazioni su Wingtip Tickets, per avere più database disponibili.
In PowerShell ISE aprire ...\Learning Modules\ProvisionTenants\Demo-ProvisionTenants.ps1 e modificare il parametro $DemoScenario in 4:
- $DemoScenario = 4, per eseguire il provisioning di un lotto di tenant in un database condiviso.
Premere F5 ed eseguire lo script.
Verificare il set distribuito di tenant
In questa fase, hai una combinazione di tenant distribuiti in un database condiviso e tenant distribuiti nei propri database. Il portale di Azure può essere usato per esaminare i database creati. Nel portale di Azure aprire il server tenants1-mt-USER<> passando all'elenco dei server SQL. L'elenco dei database SQL deve includere il database tenants1 condiviso e i database per i tenant presenti nel proprio database:
Mentre il portale di Azure mostra i database tenant, non consente di visualizzare i tenant all'interno del database condiviso. L'elenco completo dei tenant può essere visualizzato nella pagina Web del Hub Eventi di Wingtip ed esplorando il catalogo.
Uso della pagina hub eventi Wingtip Tickets
Aprire la pagina Hub eventi nel browser (http:events.wingtip-mt.<USER.trafficmanager.net>)
Uso del database di catalogo
L'elenco completo dei tenant e del database corrispondente per ognuno è disponibile nel catalogo. Viene fornita una vista SQL che aggiunge il nome del tenant al nome del database. La vista dimostra bene il valore di estensione dei metadati archiviati nel catalogo.
- La vista SQL è disponibile nel database tenantcatalog.
- Il nome del tenant viene archiviato nella tabella Tenant.
- Il nome del database viene memorizzato nelle tabelle di Gestione del Sharding.
In SQL Server Management Studio (SSMS), connettersi al server del tenant in catalog-mt.<USER>.database.windows.net, con Login = developer e Password = P@ssword1
In Esplora Oggetti di SSMS, sfogliare le viste nel database tenantcatalog.
Fare clic con il pulsante destro del mouse sulla vista TenantsExtended e scegliere Seleziona le Prime 1000 Righe. Annotare la mappatura tra il nome del tenant e il database per i diversi tenant.
Altri modelli di provisioning
Questa sezione illustra altri modelli di provisioning interessanti.
Pre-provisioning di database nei pool elastiche
Il modello di pre-provisioning sfrutta il fatto che quando si usano pool elastici, la fatturazione è per il pool non per i database. I database possono quindi essere aggiunti a un pool elastico prima che siano necessari senza incorrere in costi aggiuntivi. Questa pre-visione riduce significativamente il tempo impiegato per effettuare il provisioning di un tenant in un database. Il numero di database di cui è stato effettuato il pre-provisioning può essere modificato in base alle esigenze per mantenere un buffer adatto alla velocità di provisioning prevista.
Provisioning automatico
Nel modello di provisioning automatico viene usato un servizio di provisioning dedicato per effettuare automaticamente il provisioning di server, pool e database in base alle esigenze. Questa automazione include il pre-provisioning dei database nei pool elastici. Se i database vengono rimossi ed eliminati, le lacune create nei pool elastici possono essere riempite dal servizio di provisioning in base alle esigenze.
Questo tipo di servizio automatizzato potrebbe essere semplice o complesso. Ad esempio, l'automazione potrebbe gestire il provisioning tra più aree geografiche e potrebbe configurare la replica geografica per il ripristino di emergenza. Con il modello di provisioning automatico, un'applicazione client o uno script inoltra una richiesta di provisioning a una coda, affinché venga elaborata da un servizio di provisioning. Lo script quindi sonderebbe per rilevare il completamento. Se si usa il pre-provisioning, le richieste verranno gestite rapidamente, mentre un servizio in background gestirà il provisioning di un database sostitutivo.
Risorse aggiuntive
Passaggi successivi
In questa esercitazione si è appreso come:
- Effettuare il provisioning di un singolo tenant in un database multi-tenant condiviso e nel proprio database
- Effettuare il provisioning di un batch di tenant aggiuntivi
- Esamina i dettagli dell'approvvigionamento dei clienti e registrali nel catalogo