Esercizio - Disponibilità elevata del livello Per utilizzo generico

Completato

Nell'unità precedente è stata illustrata l'architettura a disponibilità elevata di Azure SQL. In questo esercizio si vedranno le analogie tra il comportamento del livello per utilizzo generico del database SQL di Azure e un'istanza del cluster di failover locale. La configurazione locale di questa funzionalità può richiedere molto tempo o risultare complessa, ma con Azure SQL è disponibile per impostazione predefinita.

In questo esercizio si userà lo strumento ostress, che probabilmente è già stato usato nel modulo 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 per utilizzo generico di Azure SQL

In questo esercizio verranno completati i passaggi seguenti:

1. Eseguire il carico di lavoro di ostress.
2. Verificare che l'ambiente sia configurato correttamente.
3. Usare PowerShell per avviare un failover del database SQL di Azure.
4. Visualizzare i risultati in ostress.
5. Cercare nel portale i segni che indicano che si è verificato un failover.

Eseguire il carico di lavoro ostress

Il primo passaggio consiste nella creazione di un carico di lavoro a esecuzione prolungata. Questo carico di lavoro consente di vedere in che modo un failover influisce sulla possibilità di leggere e scrivere i dati, nonché di verificare il tempo necessario per un failover nel livello di servizio per utilizzo generico del database SQL di Azure. Si userà ostress.

1. 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 file eseguibile di ostress si trova in questa cartella. È un file piccolo. Il carico di lavoro di ostress si connette ed esegue una query semplice 50.000 volte.

2. 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.

   .\ostress.exe -S"serverName.database.windows.net" -Q"SELECT COUNT(*) FROM SalesLT.Customer" -U"cloudadmin" -d"AdventureWorks" -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.

Usare PowerShell in Azure Cloud Shell per avviare un failover e osservare i risultati

1. 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"
   $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
   

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

3. Eseguire questo codice nel terminale di Azure Cloud Shell:

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

4. Osservare i risultati in ostress dalla finestra del prompt dei comandi. Mentre questo comando è in esecuzione, osservare le modifiche visualizzate nella finestra del prompt dei comandi. Si noterà che, durante il failover, non è possibile accedere al database. Il failover terminerà dopo circa 30 secondi e sarà possibile vedere che il carico di lavoro viene eseguito di nuovo correttamente. La logica di ripetizione dei tentativi nell'applicazione è importante perché, in caso di failover di Azure per diversi motivi, l'applicazione non deve arrestarsi in modo anomalo o interrompersi per un periodo di tempo superiore a quello necessario per il failover.

5. Questa capacità di creare un failover sul comando può risultare utile in determinati scenari. Si noti che il servizio applica alcune limitazioni affinché questa operazione non venga eseguita troppo spesso. Usare il comando seguente per provare a eseguire un altro failover:

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

   Verrà visualizzato un errore simile al seguente:

   Invoke-AzSqlDatabaseFailover: Long running operation failed with status 'Failed'. Additional Info:'There was a recent failover on the database or pool if database belongs in an elastic pool.  At least 15 minutes must pass between database failovers.'
   

6. A questo punto è possibile arrestare il carico di lavoro nella finestra del prompt dei comandi selezionando la finestra e quindi premendo CTRL+C. È possibile lasciare aperta la finestra perché nell'esercizio successivo si userà lo stesso carico di lavoro.

   Ci si può chiedere se esiste un modo per controllare se si è verificato un failover. Attualmente non è disponibile un chiaro messaggio che indica che si è verificato un failover, tuttavia Integrità risorse può essere un buon indicatore.

7. Nel portale di Azure passare al database SQL di Azure. Nel riquadro sinistro, in Guida, selezionare Integrità risorse. Tra 5 e 15 minuti dopo un failover, verrà visualizzato un evento di integrità simile a quello illustrato nello screenshot seguente. Questo evento può indicare diverse situazioni, ma una possibilità è che si sia verificato un evento in seguito a cui Azure ha eseguito il failover.