Share via

  • Articolo

Connect (); 2018 problema speciale

Volume 33 numero 13

Database SQL di Azure - Introduzione a servizi di Database SQL di Azure

Dal Kevin Farlee; 2018 problema speciale

In occasione della conferenza Ignite, abbiamo annunciato l'anteprima pubblica di con Iperscalabilità di Database SQL di Azure, una nuova architettura di archiviazione fornendo un basato su SQL e il livello di servizio a scalabilità elevata per i database che si adatta on demand in base alle esigenze del carico di lavoro. Con Iperscalabilità di Database SQL di Azure, i database possono rapidamente la scalabilità automatica fino a 100TB, eliminando la necessità di pre-provisioning di risorse di archiviazione ed espandere in modo significativo il potenziale per la crescita di app senza la limitazione di dimensioni di archiviazione.

Rispetto ai livelli di servizio di Database SQL di Azure correnti, con Iperscalabilità di Database SQL di Azure offre le funzionalità aggiuntive seguenti:

  • Supporto per le dimensioni del database 100 TB +
  • Scalabilità rapida verso l'alto o basso e il ripristino di point-in-time, indipendentemente dalla dimensione del database
  • Meno operazioni di dimensioni dei dati
  • Maggiore velocità effettiva del log più livelli di servizio corrente
  • Scalabilità orizzontale sola lettura il carico di lavoro con le repliche di scalabilità in lettura senza copiare i dati

Nuova architettura

Con Iperscalabilità di Database SQL Azure è una rielaborazione fondamentali del motore di archiviazione all'interno del database SQL che è stato eseguito senza apportare modifiche nel motore di query che elabora le query e determina i comportamenti. Pertanto, sono state aggiunte nuove funzionalità significative senza introdurre eventuali problemi di compatibilità.

L'architettura con Iperscalabilità di Database SQL di Azure si interrompe il motore SQL monolitico in microservizi diversi progettati per l'ambiente cloud; Questi servizi disaccoppiare calcolo, di log e di archiviazione.

Come illustrato nella figura 1, il modello con Iperscalabilità di Database SQL di Azure è costituito da tre componenti principali:

  • Calcolo è il motore di query di SQL Server, la parte del motore di database che esegue la logica di query e determina la compatibilità con altre implementazioni di SQL, nonché i comportamenti quando viene valutata la query.
  • Server della pagina è una nuova architettura di scalabilità orizzontale per archiviare i dati che utilizza il componente del motore di archiviazione tradizionale e lo divide in un set di scalabilità orizzontale dei servizi, ognuno di essi gestisce un set definito di pagine di dati (nominalmente per un totale di 1 TB di pagine di dati).
  • Servizio di log è una nuova architettura di registrazione che gestisce il flusso di dati per i dati di log, controllando che aggiornamenti connessi ai dati di ottengano propagati a tutte le repliche di una pagina modificata e rese persistenti in modo permanente per esigenze future.

La nuova architettura con scalabilità elevatissima di Database SQL di Azure
Figura 1 la nuova architettura con scalabilità elevatissima di Database SQL di Azure

Nodi di calcolo

I nodi di calcolo esaminare come una tradizionale di SQL Server, ma senza file di dati locali o i file di log. I nodi di calcolo sono "server" che le applicazioni e gli utenti interagiscono con, se di l'aggiornamento dei dati (tramite il nodo di calcolo primario) o l'esecuzione di transazioni esclusivamente in sola lettura tramite uno dei database secondario leggibile nodi di calcolo.

Il nodo di calcolo primaria scrive i record di log delle transazioni dell'area di destinazione del servizio di log e recupera le pagine di dati dai server di pagina, se non presenti nella cache dati locale o del estensione di Pool di Buffer resiliente (RBPEX). Questa è tutta la logica di esecuzione di query in cui risiede e che per la logica viene modificata dalle altre modalità di distribuzione SQL. Per mantenere questo livello superiore del motore SQL sostanzialmente invariato, è possibile mantenere la compatibilità completa con altre modalità di distribuzione di SQL mettendo a disposizione le nuove funzionalità rivoluzionaria che offrono i componenti di archiviazione separato. Perché sono stati separati i nodi di calcolo che contiene il motore di query dalla risorsa di archiviazione, si tratta in modo efficace senza stati, ovvero che è possibile perdere un nodo di calcolo senza pericolo per tutti i dati affatto. Significa anche che è possibile aumentare le risorse di calcolo o verso il basso senza spostare tutti i dati, che offre flessibilità impareggiabile per la scalabilità verso l'alto o verso il basso le risorse a verrà.

Mi occuperò ulteriori funzionalità a disponibilità elevata (HA) in un secondo momento.

Servizio di registrazione

Il servizio Registro externalizes il log delle transazioni di un database con scalabilità elevatissima. L'istanza primaria di calcolo scrive i record del log direttamente in archiviazione Premium di Azure gestita dal servizio log (il "area di destinazione" nella figura 1). Il servizio di registrazione recupera i record del log da dell'area di destinazione e lo rende disponibile per i server di pagina e calcolo secondario. Il servizio di log anche trasferisce il carico di record del log di archiviazione maggiori risparmi a lungo termine per consentire il ripristino temporizzato in.

Poiché dell'area di destinazione è l'archiviazione Premium di Azure, che offre resilienza e disponibilità elevata incorporata, i record del log sono persistenti e sicure, non appena sono scritte per l'area di destinazione. Con la confrontabili AlwaysOn disponibilità gruppi architettura a disponibilità elevata per on-premises SQL Server, un commit della transazione deve essere inviato a un quorum di repliche secondarie tramite il protocollo di rete e ha ricevuto un acknowledgement da cui il quorum di repliche prima di transazione può essere considerata per essere completati e l'esito positivo restituito all'applicazione chiamante. L'operazione può richiedere un periodo di tempo rispetto a con l'architettura con scalabilità elevatissima notevolmente maggiore. È possibile avere completa a disponibilità elevata senza tempi di attesa per i nodi secondari confermare la ricezione dei record di log. Ciò significa che anche con disponibilità elevata completa, sono presenti le latenze di log-to-end di 2 ms intervallo. Quando diventa disponibile la tecnologia di archiviazione SSD extra di Azure, questa latenza verrà ridotto da 2,5 ms a intorno 0.4ms per l'archivio dati remoto, completamente duraturo e resiliente.

Infine, i record del log sono persistenti in archiviazione Standard di Azure per l'archiviazione a lungo termine e viene recuperato lo spazio dell'area di destinazione. I record del log in archiviazione di Azure vengono mantenuti, purché il periodo di conservazione dei backup configurato per il database, pertanto non è necessario eseguire i backup del log delle transazioni. È sufficiente mantenere i dati di log online, che consente in effetti un log delle transazioni infinito (entro i limiti del periodo di conservazione dei backup configurato dall'utente).

Server della pagina

Il server della pagina ospitare e gestire i file di dati. Che utilizzano il flusso di registrazione dal servizio di log e applicare le modifiche dei dati descritte nel flusso di log per i file di dati. Le richieste di lettura di pagine di dati che non sono presenti nella cache dati locale o RBPEX le risorse di calcolo vengono inoltrate al server di pagina che possiede le pagine rilevanti. Nel server della pagina, i file di dati sono persistenti in archiviazione di Azure e sono molto memorizzato nella cache tramite le proprie cache basata su SSD RBPEX.

Ogni server di pagina gestisce le pagine che rappresentano circa 1TB di dati, in modo che il server della pagina viene scalato orizzontalmente in unità pari a circa 1TB. Il motore di nodi di calcolo/query modella ogni server di pagine come un 1 TB di dati di file, dall'ID di pagina (File con ID: Pagina file), si sa esattamente quale server pagina ospita la pagina richiesta.

I dati per ogni server di pagine in definitiva sono persistente nell'archiviazione Standard di Azure, che offre disponibilità e resilienza completa.  In questo modo, si può resistere alla perdita di un server intera pagina senza rischiare di eventuali perdite di dati, mentre i dati sono completamente disponibili dall'archiviazione di Azure, è possibile ricostruire completamente i server di pagine da tali dati, se necessario.

I dati per ogni server di pagina sono completamente memorizzati nella cache nella propria cache RBPEX SSD locale, in modo che nell'operazione, nessuna richiesta di dati che mai inoltrato per l'archiviazione di Azure il backup di server di pagina, perché può sempre essere soddisfatta dalla cache locale RBPEX.

Verrà creato più server di pagina per un database di grandi dimensioni. Quando il database cresce e lo spazio disponibile nel server di pagina esistenti è inferiore alla soglia, viene aggiunto automaticamente un nuovo server di pagina al database. Server della pagina sta lavorando in modo indipendente, si può aumentare il database senza vincoli di risorse locali.

Disponibilità elevata e ripristino di emergenza (DR)

Automated Backup e ripristino temporizzato in In un database con Iperscalabilità, dei file di dati di snapshot dai server di pagina, sfruttando le funzionalità di archiviazione blob di Azure periodicamente per sostituire lo streaming tradizionali backup. In questo modo è possibile eseguire il backup di un database molto grande in solo pochi secondi senza alcun impatto per il carico di lavoro in esecuzione. Con i record del log archiviati nel servizio di log, è possibile ripristinare il database in qualsiasi punto nel tempo durante la conservazione, che è sette giorni nell'anteprima pubblica ed è configurabile fino a 35 giorni al momento della disponibilità generale (GA), ovvero in un tempo molto breve , indipendentemente dalle dimensioni del database. I dati di ogni pagina del server sono stabile in modo indipendente, con nessuna necessità di sincronizzare le istantanee, in modo da tale origine potenziali di ritardo viene eliminata, anche.

Altamente disponibili componenti ognuno dei componenti nell'architettura con Iperscalabilità di Database SQL di Azure è progettato per garantire la disponibilità elevata in modo che non vi sarà alcun interruzioni nell'accesso al database:

  • I nodi di calcolo presentano almeno una replica in esecuzione e a caldo in qualsiasi momento. In caso di errore del nodo di calcolo o il failover, la replica verrà immediatamente subentrerà al ruolo primario, mantenendo il database online e disponibili. Una replica di sostituzione può essere avviata molto rapidamente e può preparare le cache come attività in background senza influire sulle prestazioni di produzione. Le altre repliche possono essere configurati per la lettura di tipo scale-out. Questa architettura, i nodi di calcolo sono senza stati in modo efficace.
  • Pagina su ogni server dispongono di una replica standby online con le cache RBPEX completamente popolata, in modo che siano disponibili per intervenire in caso di server di pagina attiva in caso di errore. Anche in questo caso, dal momento che senza stati all'esterno di dati memorizzati nella cache, un sostituto può risultare online molto rapidamente, senza il rischio di perdita di dati.
  • Il servizio di log non ha una riserva a caldo, ma non è necessaria perché il servizio di log non è disponibili dati memorizzati nella cache e può essere sostituito più rapidamente poiché Impossibile failover su una replica standby. I dati che sono gestiti dal servizio log si trovano prima di tutto nell'area di destinazione, che è resiliente archiviazione Premium di Azure (presto l'archiviazione SSD extra) e in definitiva è persistente nell'archiviazione Standard di Azure per conservazione a lungo termine.

Pertanto, come può notare, non sia presente alcun componente che rappresenta un singolo punto di guasto. Tutti i componenti con Iperscalabilità hanno active attivazioni modalità standby, fatta eccezione per il servizio di log, e tutti i dati è supportata da archiviazione di Azure completamente resilienti.

Creazione di un nuovo Database su scala molto vasta

È possibile creare un nuovo Database con scalabilità elevatissima nello stesso modo che si crea qualsiasi altro Database SQL di Azure usando il portale di Microsoft Azure, PowerShell o Azure Resource Manager (ARM).

In questo caso, viene illustrato il metodo per creare un Database con scalabilità elevatissima usando PowerShell. Si noti che questo non è diverso dallo script standard per la creazione di qualsiasi Database SQL di Azure, fatta eccezione per il parametro - RequestedServiceObjectiveName. Nell'esempio seguente, si utilizzerà il HS_Gen5_8, ovvero un Database SQL con Iperscalabilità, sull'hardware di generazione 5, con otto core. Naturalmente, se si dispone già di un gruppo di risorse e un server logico, è possibile ignorare le parti dello script.

Innanzitutto, occorre eseguire consiste nell'avviare Azure Cloud Shell. Cloud Shell è una shell interattiva gratuita che è possibile usare per eseguire i passaggi illustrati in questo articolo. Include strumenti comuni di Azure preinstallata e configurata per l'utilizzo con il proprio account. È possibile fare semplicemente clic sul pulsante Copia per copiare il codice e quindi incollare il codice in Cloud Shell e premere INVIO per eseguirlo.

Esistono diversi modi per avviare Cloud Shell. Tra il sono più semplice per entrambi aprire Cloud Shell nel browser visitando shell.azure.com/powershell e facendo clic su Avvia Cloud Shell pulsante oppure facendo clic sul Cloud Shell pulsante menu in alto a destra del portale di Azure. Consiglia di che usare il secondo metodo. Accedere al portale di Azure all'indirizzo portal.azure.com usando l'account che dispone dell'accesso alla sottoscrizione di Azure. Quindi fare clic sul collegamento, come illustrato nella figura 2.

L'avvio di Cloud Shell dal portale di Azure
Figura 2, l'avvio di Cloud Shell dal portale di Azure

È quindi possibile incollare lo script illustrato nella figura 3 nella finestra Cloud Shell ed eseguirlo per creare un gruppo di risorse, un Server logico SQL e un database. Si noti che il nome del gruppo di risorse sia impostato su"myResourceGroup" e a un numero casuale, ad esempio "MyResourceGroup-2088327474". Altri oggetti vengono denominati in modo analogo. Tuttavia, è possibile personalizzare questi nomi se risulta più semplice.

Figura 3 Creazione di un gruppo di risorse, Server logico SQL e Database

# Set the resource group name and location for your server
$resourcegroupname = "myResourceGroup-$(Get-Random)"
$location = "westus2"
# Set an admin login and password for your server
$adminlogin = "ServerAdmin"
$password = "ChangeYourAdminPassword1"
# Set server name - the logical server name has to be unique in the system
$servername = "server-$(Get-Random)"
# The sample database name
$databasename = "mySampleDatabase"
# The IP address range that you want to allow to access your server
$startip = "0.0.0.0"
$endip = "0.0.0.0"
# Create a resource group
$resourcegroup = New-AzureRmResourceGroup -Name $resourcegroupname -Location $location
# Create a server with a system-wide unique server name
$server = New-AzureRmSqlServer -ResourceGroupName $resourcegroupname `
  -ServerName $servername `
  -Location $location `
  -SqlAdministratorCredentials $(New-Object -TypeName
    System.Management.Automation.PSCredential -ArgumentList $adminlogin,
    $(ConvertTo-SecureString -String $password -AsPlainText -Force))
# Create a server firewall rule that allows access from the specified IP range
$serverfirewallrule = New-AzureRmSqlServerFirewallRule
  -ResourceGroupName $resourcegroupname `
    -ServerName $servername `
    -FirewallRuleName "AllowedIPs" -StartIpAddress $startip -EndIpAddress $endip
# Create a blank database with the Hyperscale, Gen5, two-core performance level
$database = New-AzureRmSqlDatabase  -ResourceGroupName $resourcegroupname `
  -ServerName $servername `
  -DatabaseName $databasename `
  -RequestedServiceObjectiveName "HS_Gen5_2" `
  -SampleName "AdventureWorksLT"
Echo $servername
# Clean up deployment
# Remove-AzureRmResourceGroup -ResourceGroupName $resourcegroupname

Nello script, il server viene creato nell'area WestUS2. A questo punto, su scala molto vasta non è disponibile in tutte le aree di Azure, in modo che è possibile mantenere i dati nelle WestUS2, che è attivo, oppure provare un'altra area. Se si verifica un errore di "edizione specificata non è disponibile. Scegliere un'edizione diversa,"indica che l'area scelta è non ancora abilitata su scala molto vasta. È possibile provare un'altra area o usare WestUS2.

Un altro oggetto che è configurato per l'utente è la regola del firewall che concede l'accesso al server. Lo script di esempio imposta startip sia endip 0.0.0.0, che non consente l'accesso. Individuazione al nuovo server nel portale, facendo clic su "Mostra impostazioni firewall" e quindi facendo clic su "Aggiungi IP client," che consentirà di aggiungere una regola firewall che consenta di computer corrente per connettersi al database, è possibile aggiungere l'indirizzo per il computer specifico.

Una volta creati i database e server e vengono modificate le regole del firewall, è possibile connettersi al database usando SQL Server Management Studio (SSMS). Lo script visualizza il nome che assegnato a SQL Server. È sufficiente aggiungere ". database.windows.net" al nome del server quando ci si connette. Il nome utente e password sono contenuti in questo script (Naturalmente, è possibile e consigliabile modificarli su un valore solo si conosce). A questo punto, si è connessi al nuovo database su scala molto vasta.

Altri metodi per la creazione di database SQL di Azure su scala molto vasta reperibili bit.ly/2QoTLbj.

L'architettura di Database di ultima generazione

Con questa breve panoramica, si è visto che con Iperscalabilità di Database SQL di Azure è una nuova architettura rivoluzionaria che ha il vantaggio di fornire la piena compatibilità con versioni precedenti di motori di SQL univoco. Con Iperscalabilità di Azure SQL Database è davvero intuitivo cloud e offre vantaggi significativi in scala, prestazioni e gestibilità. Eliminando comuni operazioni di dimensioni dei dati, è in grado di offrire funzionalità molto grandi dimensioni Database (VLDB) senza le problematiche VLDB tipiche. Per altri dettagli, consultare la pagina di "Livello Hyperscale Service (anteprima) per un massimo di 100TB" al bit.ly/2TTJkeK.

Kevin Farleeha più di 30 anni nel settore del software di gestione l'archiviazione e database. Nel suo ruolo corrente come l'entità program manager del team di Database SQL di Microsoft, esercita nello sviluppo di funzionalità Hyperscale VLDB di database SQL di Azure.

Grazie per i seguenti esperti Microsoft per la revisione dell'articolo: Alain Dormehl, Xiaochen Wu
Alain Dormehl è un Senior Program Manager del team di Database SQL di Azure in Microsoft, in base a Redmond. Egli ha ricoperto diversi ruoli di Microsoft e si dedica al prodotto e funzionalità di sviluppo per i database SQL di Azure. Ha oltre dieci anni di esperienza con SQL Server ed è stato un primi ed evangelist per Azure. Seguirlo su Twitter @APSolutely

Xiaochen Wu è un senior program manager del team SQL in Microsoft. Ha lavorato su diverse funzionalità e i prodotti in SQL Server e database SQL di Azure negli ultimi 10 anni. Seguirlo su Twitter @allenwux

Discutere di questo articolo nel forum di MSDN Magazine