Esercizio - Disponibilità elevata del livello Business critical

10 minuti

In questo esercizio si aggiornerà il database al livello business critical. Si vedrà come questo livello fornisce repliche in lettura e prestazioni migliori.

Si userà lo strumento ostress usato nell'esercizio precedente per creare un carico di lavoro. Si avvierà quindi un failover usando il modulo Azure PowerShell in Azure Cloud Shell. Infine, si osserverà l'effetto del failover sul carico di lavoro di ostress.

Disponibilità elevata di base nel livello di servizio business critical di Azure SQL

In questo esercizio verranno completati i passaggi seguenti:

Distribuire il database dell'esercizio precedente nel livello business critical.
Eseguire il carico di lavoro di ostress.
Usare PowerShell per avviare un failover.
Visualizzare i risultati in ostress.
Connettersi a una replica secondaria leggibile.

Distribuire lo stesso database nel livello business critical

In un modulo precedente è stato illustrato come ridimensionare un database usando T-SQL. L'obiettivo di questo esercizio è aggiornare il database usato nell'esercizio precedente dal livello per utilizzo generico al livello business critical. Si userà Azure Cloud Shell per aggiornare il database. Poiché è previsto un limite per la frequenza dei failover, si userà lo stesso database di esempio, assegnandogli però il nome AdventureWorks-bc.

Nel terminale di Azure Cloud Shell, a destra di questa pagina, eseguire lo script di PowerShell seguente per configurare l'ambiente:

$resourceGroup = "<rgn>[sandbox resource group name]</rgn>"
$database = "AdventureWorks-bc"
$server = Get-AzureRmSqlServer -ResourceGroupName $resourceGroup
$server = $server.ServerName

# Specify your default resource group and Azure SQL Database logical server
az configure --defaults group=$resourceGroup sql-server=$server

# Confirm the defaults are set
az configure --list-defaults

Eseguire questo comando per creare un database nel livello di servizio business critical:
```
az sql db create --name $database `
--edition BusinessCritical `
--family Gen5 `
--capacity 2 `
--sample-name AdventureWorksLT `
--read-scale Enabled `
--zone-redundant false
```
Il completamento di questo comando richiede tempo. Mentre è in esecuzione, è possibile esaminare alcuni parametri usati:
- family: questo parametro specifica la generazione dell'hardware. Per coerenza con l'esercizio precedente, è stato usato Gen5.
- capacity: questo parametro specifica il numero di unità di elaborazione di database (DTU) o di vCore. Per coerenza con l'esercizio precedente, sono stati usati 2 vCore.
- sample-name: per coerenza con l'esercizio precedente, è stato usato il database di esempio AdventureWorksLT.
- edition: il nome di questo parametro può confondere. Si riferisce al livello di servizio, che non corrisponde all'edizione usata in SQL Server.
- read-scale: questa opzione non è abilitata per impostazione predefinita, ma non prevede alcun costo aggiuntivo. Abilitandolo, si consente l'uso di una delle repliche secondarie come replica secondario leggibile.
- zone-redundant: per impostazione predefinita, questo parametro è impostato su false. È possibile impostarlo su true per ottenere una distribuzione con zone di disponibilità multiple senza costi aggiuntivi. Altre informazioni sulle zone di disponibilità verranno fornite nell'unità successiva.
  
  Nota
  
  Le zone di disponibilità sono presenti solo in aree specifiche. Attualmente non sono disponibili in Istanza gestita di SQL di Azure.
Dopo la creazione del database, verranno visualizzate informazioni dettagliate sugli aggiornamenti nell'output di Azure Cloud Shell. Saranno presenti due categorie principali, ma verranno visualizzati anche gli indicatori in diverse altre proprietà:
- currentServiceObjectiveName: deve essere BC_Gen5_2. BC sta per business critical.
- currentSku:
  - name: deve essere BC_Gen5.
  - tier: deve essere BusinessCritical.
Un altro modo per controllare il livello di servizio consiste nel passare al database nel portale di Azure. Nella scheda Panoramica esaminare quanto indicato in Piano tariffario.

Suggerimento

Ci sono molti altri modi per visualizzare questi aggiornamenti. Un modo consiste nell'usare SSMS. Se si fa clic con il pulsante destro del mouse sul database e si sceglie Proprietà>Configura SLO, è possibile visualizzare le modifiche.

Eseguire il carico di lavoro ostress

Come nell'esercizio precedente, si userà ostress per eseguire ripetutamente una query sul database SQL di Azure.

Se è stato chiuso il prompt dei comandi usato nell'esercizio precedente, aprire una nuova finestra del prompt dei comandi nel computer locale. Usare cd per passare alla directory nel repository clonato o scaricato in precedenza che contiene il modulo di disponibilità. Usare ad esempio questo comando:
```
cd C:\Users\username\mslearn-azure-sql-fundamentals\05-Availability
```
Il carico di lavoro di ostress si connette ed esegue una query semplice 50.000 volte.
Usare lo script di ostress seguente per eseguire il carico di lavoro. Sostituire serverName con il nome del server logico del database SQL di Azure. Sostituire password con la password. Questo comando è leggermente diverso da quello dell'esercizio precedente. Il nome del database è ora AdventureWorks-bc.
```
.\ostress.exe -S"serverName.database.windows.net" -Q"SELECT COUNT(*) FROM SalesLT.Customer" -U"cloudadmin" -d"AdventureWorks-bc" -P"password" -n1 -r50000
```
Se il carico di lavoro viene eseguito correttamente, il risultato della query, 847, verrà visualizzato ripetutamente nella finestra del prompt dei comandi.

Se si vuole arrestare l'esecuzione del carico di lavoro di ostress prima del completamento, è possibile premere CTRL+C nel terminale.

Se si vuole eseguire di nuovo il carico di lavoro, eseguire un'altra volta il comando.

Avviare un failover e visualizzare i risultati

Configurare le finestre in modo che sia possibile visualizzare il browser e la finestra del prompt dei comandi contemporaneamente.

Eseguire il codice seguente nel terminale di Azure Cloud Shell. Il comando è uguale a quello usato nell'esercizio precedente.

# create a failover
Invoke-AzSqlDatabaseFailover -ResourceGroupName $resourceGroup `
    -ServerName $server `
    -DatabaseName $database

Mentre questo comando è in esecuzione, osservare le modifiche visualizzate nel terminale. Si noterà che, durante il failover, non è possibile accedere al database. Questo intervallo di tempo è molto breve. Dopo la disconnessione, sarà possibile riconnettersi dopo circa 5 secondi. Questo failover è oltre sei volte più veloce rispetto a quello del livello per utilizzo generico.

Tenere presente che i database o le istanze gestite nel livello di servizio Business Critical hanno essenzialmente un gruppo di disponibilità AlwaysOn distribuito in background, quindi quando si esegue il failover, tutto ciò che accade è una modifica nei puntatori nel back-end quando Azure reindirizza l'utente a uno dei database secondari. È per questo motivo che il failover è molto più veloce rispetto a quanto avviene nel livello per utilizzo generico.

Connettersi alla replica di sola lettura

Poiché è stato abilitato il parametro read-scale, è possibile usare una delle repliche secondarie per i carichi di lavoro di sola lettura. Per accedere alla replica di sola lettura nelle applicazioni, è sufficiente aggiungere questo parametro alla stringa di connessione per un database:

ApplicationIntent=ReadOnly;

In SSMS creare una nuova connessione di query. Selezionare File>Nuovo>Query del motore di database.
Nella finestra di dialogo Connetti al server usare la configurazione usata per connettersi al server logico del database SQL di Azure, ovvero l'opzione Autenticazione di SQL Server. Selezionare Opzioni.
Selezionare Proprietà connessione e quindi Reimposta tutto. In Connetti al database selezionare Sfoglia server e quindi selezionare il database AdventureWorks-bc. Seleziona OK.
Selezionare Parametri aggiuntivi per la connessione e incollare quanto segue nella casella di testo. Selezionare Connetti.
```
ApplicationIntent=ReadOnly;
```
Con SSMS, è necessario specificare il server e il database per la connessione di sola lettura. Ciò è necessario perché possono esserci più database in un server con funzionalità diverse per le repliche secondarie leggibili.
Come test, provare a eseguire la query seguente nella nuova query del motore di database. Osservare i risultati. Sono quelli previsti?
```
SELECT DATABASEPROPERTYEX(DB_NAME(), 'Updateability')
```
Facoltativamente, è possibile riconnettersi e aggiornare i parametri aggiuntivi per la connessione. Sostituire ReadOnly con ReadWrite. Verificare che si stia accedendo alla replica primaria di lettura/scrittura. ReadWrite è il valore predefinito, quindi, se non si seleziona alcun valore, si otterrà quanto segue: