Esercizio: Proteggere, monitorare e ottimizzare un database migrato

  • 20 minuti

Si supponga di lavorare come sviluppatore di database per l'organizzazione AdventureWorks. AdventureWorks si occupa della vendita di biciclette e parti di biciclette direttamente ai clienti finali e ai distributori da oltre un decennio. I sistemi archiviano le informazioni in un database di cui è stata precedentemente eseguita la migrazione a Database di Azure per PostgreSQL.

Dopo aver eseguito la migrazione, si vuole verificare che le prestazioni del sistema siano ottimali. Si decide di usare gli strumenti di Azure disponibili per monitorare il server. Per ridurre la possibilità di tempi di risposta lenti causati da eventi di contesa e latenza, si decide di implementare la replica in lettura. È necessario monitorare il sistema risultante e confrontare i risultati con l'architettura a server flessibile.

In questo esercizio si eseguiranno le seguenti attività:

  1. Configurare le metriche di Azure per il servizio Database di Azure per PostgreSQL.
  2. Eseguire un'applicazione di esempio che simula più utenti che eseguono query sul database.
  3. Visualizzare le metriche.

Configurare l'ambiente

Eseguire questi comandi dell'interfaccia della riga di comando di Azure nel Cloud Shell per creare un Database di Azure per PostgreSQL con una copia del database AdventureWorks. Tramite l'ultimo comando viene stampato il nome del server.

SERVERNAME="adventureworks$((10000 + RANDOM % 99999))"
PUBLICIP=$(wget http://ipecho.net/plain -O - -q)
git clone https://github.com/MicrosoftLearning/DP-070-Migrate-Open-Source-Workloads-to-Azure.git workshop

az postgres server create \
    --resource-group <rgn>[sandbox resource group name]</rgn> \
    --name $SERVERNAME \
    --location westus \
    --admin-user awadmin \
    --admin-password Pa55w.rdDemo \
    --version 10 \
    --storage-size 5120

az postgres db create \
    --name azureadventureworks \
    --server-name $SERVERNAME \
    --resource-group <rgn>[sandbox resource group name]</rgn>

az postgres server firewall-rule create \
    --resource-group <rgn>[sandbox resource group name]</rgn> \
    --server $SERVERNAME \
    --name AllowMyIP \
    --start-ip-address $PUBLICIP --end-ip-address $PUBLICIP

PGPASSWORD=Pa55w.rdDemo psql -h $SERVERNAME.postgres.database.azure.com -U awadmin@$SERVERNAME -d postgres -f workshop/migration_samples/setup/postgresql/adventureworks/create_user.sql

PGPASSWORD=Pa55w.rd psql -h $SERVERNAME.postgres.database.azure.com -U azureuser@$SERVERNAME -d azureadventureworks -f workshop/migration_samples/setup/postgresql/adventureworks/adventureworks.sql 2> /dev/null

echo "Your PostgreSQL server name is:\n"
echo $SERVERNAME.postgres.database.azure.com

Configurare le metriche di Azure per il servizio Database di Azure per PostgreSQL

  1. Usando un Web browser, aprire una nuova scheda e passare al portale di Azure.

  2. Nel portale di Azure selezionare Tutte le risorse.

  3. Selezionare il nome del server di Database di Azure per PostgreSQL che inizia con adventureworks.

  4. In Monitoraggio selezionare Metrica.

  5. Nella pagina del grafico aggiungere la metrica seguente:

    Proprietà valore
    Scope adventureworks[nnn]
    Spazio dei nomi della metrica Metriche standard del server PostgreSQL
    Metric Connessioni attive
    Aggregazione Avg

    Questa metrica visualizza il numero medio di connessioni effettuate al server ogni minuto.

  6. Selezionare Aggiungi metrica e aggiungere la metrica seguente:

    Proprietà valore
    Scope adventureworks[nnn]
    Spazio dei nomi della metrica Metriche standard del server PostgreSQL
    Metric Percentuale CPU
    Aggregazione Avg

  7. Selezionare Aggiungi metrica e aggiungere la metrica seguente:

    Proprietà valore
    Scope adventureworks[nnn]
    Spazio dei nomi della metrica Metriche standard del server PostgreSQL
    Metric Percentuale di memoria
    Aggregazione Avg

  8. Selezionare Aggiungi metrica e aggiungere la metrica seguente:

    Proprietà valore
    Scope adventureworks[nnn]
    Spazio dei nomi della metrica Metriche standard del server PostgreSQL
    Metric Percentuale I/O
    Aggregazione Avg

    Queste tre metriche finali mostrano il modo in cui le risorse vengono utilizzate dall'applicazione di test.

  9. Impostare l'intervallo di tempo su Ultimi 30 minuti.

  10. Selezionare Aggiungi al dashboard e quindi Aggiungi.

Eseguire un'applicazione di esempio che simula più utenti che eseguono query sul database

  1. Nel portale di Azure, nella pagina del server di Database di Azure per PostgreSQL, in Impostazioni selezionare Stringhe di connessione. Copiare la stringa di connessione ADO.NET negli Appunti.

  2. Passare alla cartella ~/workshop/migration_samples/code/postgresql/AdventureWorksSoakTest.

    cd ~/workshop/migration_samples/code/postgresql/AdventureWorksSoakTest

  3. Modificare il file App.config usando l'editor di codice:

    code App.config

  4. Sostituire il valore del database con azureadventureworks e sostituire ConectionString0 con la stringa di connessione negli Appunti. Modificare l'ID utente in azureuser@adventureworks[nnn] e impostare la password su Pa55w.rd. Il file completato dovrebbe avere un aspetto simile all'esempio seguente:

    <?xml version="1.0" encoding="utf-8" ?>
<configuration>
    <appSettings>
        <add key="ConnectionString0" value="Server=adventureworks101.postgres.database.azure.com;Database=azureadventureworks;Port=5432;User Id=azureuser@adventureworks101;Password=Pa55w.rd;Ssl Mode=Require;" />
        <add key="ConnectionString1" value="INSERT CONNECTION STRING HERE" />
        <add key="ConnectionString2" value="INSERT CONNECTION STRING HERE" />
        <add key="NumClients" value="100" />
        <add key="NumReplicas" value="1"/>
    </appSettings>
</configuration>

    Nota

    Per il momento, ignorare le impostazioni ConnectionString1 e ConnectionString2. Questi elementi verranno aggiornati in un secondo momento nel lab.

  5. Salvare le modifiche e chiudere l'editor.

  6. Al prompt di Cloud Shell eseguire questo comando per creare ed eseguire l'app:

    dotnet run

    All'avvio dell'app, verrà generato un certo numero di thread, ciascuno dei quali simula un utente. I thread attivano un ciclo, eseguendo una serie di query. Si inizierà a visualizzare messaggi simili a quelli mostrati di seguito:

    Client 48 : SELECT * FROM purchasing.vendor
Response time: 630 ms

Client 48 : SELECT * FROM sales.specialoffer
Response time: 702 ms

Client 43 : SELECT * FROM purchasing.vendor
Response time: 190 ms

Client 57 : SELECT * FROM sales.salesorderdetail
Client 68 : SELECT * FROM production.vproductanddescription
Response time: 51960 ms

Client 55 : SELECT * FROM production.vproductanddescription
Response time: 160212 ms

Client 59 : SELECT * FROM person.person
Response time: 186026 ms

Response time: 2191 ms

Client 37 : SELECT * FROM person.person
Response time: 168710 ms

    Lasciare l'app in esecuzione mentre si eseguono i passaggi successivi.

Visualizzare le metriche

  1. Tornare al portale di Azure.

  2. Selezionare Dashboard nel riquadro a sinistra.

    Il grafico visualizzerà le metriche per il servizio Database di Azure per PostgreSQL.

  3. Selezionare il grafico per aprirlo nel riquadro Metrica.

  4. Consentire l'esecuzione dell'app per alcuni minuti (i risultati saranno migliori se l'esecuzione sarà prolungata). Con il passare del tempo, le metriche nel grafico devono essere simili a quelle illustrate nell'immagine seguente:

    Image showing the metrics gathered while the sample app is running

    Questo grafico evidenzia i punti seguenti:

    • La CPU viene eseguita a piena capacità, l'utilizzo raggiunge il 100% molto rapidamente.
    • Il numero di connessioni aumenta lentamente. L'applicazione di esempio è progettata per avviare 101 client in rapida successione, ma il server può solo far fronte all'apertura di alcune connessioni alla volta. Il numero di connessioni aggiunte a ogni "passaggio" nel grafico si riduce e l'intervallo tra "passaggi" aumenta. Dopo circa 45 minuti, il sistema è stato in grado di stabilire solo 70 connessioni client.
    • L'utilizzo della memoria aumenta in modo coerente nel tempo.
    • L'utilizzo di I/O è vicino a zero. Tutti i dati richiesti dalle applicazioni client sono attualmente memorizzati nella cache.

    Se si lascia l'applicazione in esecuzione abbastanza a lungo, verranno visualizzate le connessioni che iniziano ad avere esito negativo, con i messaggi di errore mostrati nell'immagine seguente.

    Image showing the connection errors that can occur when the server has insufficient resources available

  5. In Cloud Shell premere INVIO per arrestare l'applicazione.

Configurare il server per la raccolta dei dati sulle prestazioni delle query

  1. Nel portale di Azure, nella pagina del server di Database di Azure per PostgreSQL, in Impostazioni selezionare Parametri del server.

  2. Nella pagina Parametri del server impostare i parametri seguenti sui valori specificati nella tabella seguente.

    Parametro Valore
    pg_qs.max_query_text_length 6000
    pg_qs.query_capture_mode ALL
    pg_qs.replace_parameter_placeholders ON
    pg_qs.retention_period_in_days 7
    pg_qs.track_utility ON
    pg_stat_statements.track ALL
    pgms_wait_sampling.history_period 100
    pgms_wait_sampling.query_capture_mode ALL

  3. Seleziona Salva.

Esaminare le query eseguite dall'applicazione usando Query Store

  1. Tornare a Cloud Shell e riavviare l'app di esempio:

    dotnet run

    Prima di continuare, consentire l'esecuzione dell'app per 5 minuti.

  2. Lasciare l'app in esecuzione e passare al portale di Azure.

  3. Nella pagina per il server di Database di Azure per PostgreSQL, in Prestazioni intelligenti selezionare Informazioni dettagliate prestazioni query.

  4. Nella pagina Informazioni dettagliate prestazioni query, nella scheda Query a esecuzione prolungata, impostare Numero di query su 10,Selezionato da su Media e Periodo su Ultime 6 ore.

  5. Sopra il grafico, selezionare Zoom avanti (icona della lente di ingrandimento con il segno "+") un paio di volte, per visualizzare i dati più recenti.

    A seconda del tempo necessario per l'esecuzione dell'applicazione, viene visualizzato un grafico simile a quello illustrato di seguito. Query Store aggrega le statistiche per le query ogni 15 minuti, in modo che ogni barra indichi il tempo relativo utilizzato da ogni query in un periodo di 15 minuti:

    Image showing the statistics for long running queries captured by using Query Store

  6. Per visualizzare le statistiche per le query in un determinato periodo di tempo, posizionare il puntatore del mouse su una barra alla volta. Le tre query in cui il sistema impiega la maggior parte del tempo di esecuzione sono:

    SELECT * FROM sales.salesorderdetail
SELECT * FROM sales.salesorderheader
SELECT * FROM person.person

    Queste informazioni sono utili per un amministratore che monitora un sistema. La possibilità di ottenere informazioni dettagliate sulle query eseguite da utenti e app consente di comprendere i carichi di lavoro eseguiti ed eventualmente di consigliare agli sviluppatori di applicazioni come migliorare il codice. Ad esempio, è veramente necessario che un'applicazione recuperi tutte le oltre 121.000 righe dalla tabella sales.salesorderdetail?

Esaminare le attese che si verificano usando Query Store

  1. Selezionare la scheda Statistiche di attesa.

  2. Impostare Periodo su Ultime 6 ore, Raggruppa per su Evento e Numero massimo di gruppi su 5.

    Come per la scheda Query a esecuzione prolungata, i dati vengono aggregati ogni 15 minuti. La tabella sotto il grafico mostra che il sistema ha sperimentato due tipi di eventi di attesa:

    • Client: ClientWrite. Questo evento di attesa si verifica quando il server scrive i dati (risultati) nel client. Non indica le attese verificatesi durante la scrittura nel database.
    • Client: ClientRead. Questo evento di attesa si verifica quando il server è in attesa di leggere i dati (richieste di query o altri comandi) da un client. Non è associato al tempo impiegato per la lettura dal database.

    Image showing the wait statistics captured by using Query Store

    Nota

    Le operazioni di lettura e scrittura nel database sono indicate dagli eventi I/O anziché dagli eventi Client. L'applicazione di esempio non è soggetta ad alcuna attesa di I/O perché tutti i dati necessari vengono memorizzati nella cache dopo la prima lettura. Se la metrica indica che la memoria è insufficiente, è probabile che si verifichino eventi di I/O in attesa.

  3. Tornare a Cloud Shell e premere INVIO per arrestare l'applicazione di esempio.

Aggiungere repliche al servizio Database di Azure per PostgreSQL

  1. Nel portale di Azure, nella pagina del server di Database di Azure per PostgreSQL, in Impostazioni selezionare Replica.

  2. Nella pagina Replica selezionare + Aggiungi replica.

  3. Nella pagina Server PostgreSQL digitare adventureworks[nnn]-replica1 nella casella Nome server e quindi selezionare OK.

  4. Quando è stata creata la prima replica (sono necessari alcuni minuti), ripetere il passaggio precedente e aggiungere un'altra replica denominata adventureworks[nnn]-replica2.

  5. Prima di continuare, attendere che lo stato di entrambe le repliche venga modificato da Distribuzione a Disponibile.

    Image showing the Replication page for Azure Database for PostgreSQL. Two replicas have been added.

Configurare le repliche per abilitare l'accesso client

  1. Selezionare il nome della replica adventureworks[nnn]-replica1. Si passerà alla pagina di Database di Azure per PostgreSQL relativa alla replica.
  2. In Impostazioni selezionare Sicurezza connessione.
  3. Nella pagina Sicurezza connessione impostare Consenti l'accesso a Servizi di Azure su ATTIVATO e quindi selezionare Salva. Questa impostazione consente alle applicazioni che vengono eseguite usando Cloud Shell di accedere al server.
  4. Quando l'impostazione è stata salvata, ripetere i passaggi precedenti e consentire ai servizi di Azure di accedere alla replica adventureworks[nnn]-replica2.

Riavviare ogni server

Nota

Per la configurazione della replica non è necessario riavviare un server. Lo scopo di questa attività è cancellare la memoria e tutte le connessioni estranee da ogni server, in modo che le metriche raccolte durante l'esecuzione dell'applicazione siano pulite.

  1. Passare alla pagina del server adventureworks[nnn].
  2. Nella pagina Panoramica selezionare Riavvia.
  3. Nella finestra di dialogo Riavvia server selezionare Sì.
  4. Prima di continuare, attendere che il server sia stato riavviato.
  5. Seguendo la stessa procedura, riavviare i server adventureworks[nnn]-replica1 e adventureworks[nnn]-replica2.

Riconfigurare l'applicazione di esempio per l'uso delle repliche

  1. In Cloud Shell modificare il file App.config.

    code App.config

  2. Aggiungere le stringhe di connessione per le impostazioni ConnectionString1 e ConnectionString2. Questi valori devono essere uguali a quelli di ConnectionString0, ma con il testo adventureworks[nnn] sostituito con adventureworks[nnn]-replica1 e adventureworks[nnn]-replica2 negli elementi Server e ID utente.

  3. Impostare il valore di NumReplicas su 3.

    Il file App.config finale dovrebbe avere ora un aspetto simile al seguente:

    <configuration>
    <appSettings>
        <add key="ConnectionString0" value="Server=adventureworks101.postgres.database.azure.com;Database=azureadventureworks;Port=5432;User Id=azureuser@adventureworks101;Password=Pa55w.rd;Ssl Mode=Require;" />
        <add key="ConnectionString1" value="Server=adventureworks101-replica1.postgres.database.azure.com;Database=azureadventureworks;Port=5432;User Id=azureuser@adventureworks101-replica1;Password=Pa55w.rd;Ssl Mode=Require;" />
        <add key="ConnectionString2" value="Server=adventureworks101-replica2.postgres.database.azure.com;Database=azureadventureworks;Port=5432;User Id=azureuser@adventureworks101-replica2;Password=Pa55w.rd;Ssl Mode=Require;" />
        <add key="NumClients" value="100" />
        <add key="NumReplicas" value="3"/>
    </appSettings>
</configuration>

  4. Salvare il file e chiudere l'editor.

  5. Avviare di nuovo l'app in esecuzione:

    dotnet run

    L'applicazione verrà eseguita come in precedenza. Questa volta, tuttavia, le richieste vengono distribuite tra i tre server.

  6. Prima di continuare, consentire l'esecuzione dell'app per alcuni minuti.

Monitorare l'app e osservare le differenze nelle metriche delle prestazioni

  1. Lasciare l'app in esecuzione e tornare al portale di Azure.

  2. Selezionare Dashboard nel riquadro a sinistra.

  3. Selezionare il grafico per aprirlo nel riquadro Metrica.

    Tenere presente che in questo grafico vengono visualizzate le metriche per il server adventureworks[nnn], ma non le repliche. Il carico per ogni replica deve essere molto simile.

    Il grafico di esempio illustra le metriche raccolte per l'applicazione in un periodo di 30 minuti dall'avvio. Il grafico mostra che l'utilizzo della CPU era ancora elevato, ma che l'utilizzo della memoria era ridotto. Inoltre, dopo circa 25 minuti, il sistema ha stabilito oltre 30 connessioni. Questo potrebbe non sembrare un confronto favorevole alla configurazione precedente, che supportava 70 connessioni dopo 45 minuti. Tuttavia, il carico di lavoro è stato distribuito tra tre server, che erano tutti in esecuzione allo stesso livello, e tutte le 101 connessioni sono state stabilite. Inoltre, il sistema è stato in grado di continuare l'esecuzione senza segnalare errori di connessione.

    Image showing the metrics for the Azure Database for PostgreSQL server while running the application, after replication was configured

    È possibile risolvere il problema di utilizzo della CPU ridimensionando il piano tariffario a un livello superiore con più core CPU. Il sistema di esempio usato in questo lab viene eseguito con il piano tariffario Base con 2 core. Se si passa al piano tariffario Per utilizzo generico, si otterranno fino a 64 core.

  4. Tornare a Cloud Shell e premere INVIO per arrestare l'app.

A questo punto, si è appreso come monitorare l'attività del server usando gli strumenti disponibili nel portale di Azure. Si è inoltre appreso come configurare la replica e come creare repliche di sola lettura per distribuire il carico di lavoro in scenari di dati a elevato utilizzo di lettura.