Übung: Schützen, Überwachen und Optimieren einer migrierten Datenbank

Abgeschlossen

Sie arbeiten als Datenbankentwickler für die Organisation AdventureWorks. AdventureWorks verkauft seit über einem Jahrzehnt Fahrräder und Fahrradteile direkt an Endverbraucher und Händler. Ihre Systeme speichern Informationen in einer Datenbank, die Sie zuvor zu Azure-Datenbank für PostgreSQL migriert haben.

Nach dem Ausführen der Migration möchten Sie sicherstellen, dass das System gut funktioniert. Sie entscheiden sich für die Verwendung der verfügbaren Azure-Tools, um den Server zu überwachen. Um die Möglichkeit von langsamen Reaktionszeiten zu verringern, die durch Inhalt und Latenz verursacht werden, entscheiden Sie sich für die Implementierung der Lesereplikation. Sie müssen das resultierende System überwachen und die Ergebnisse mit der flexiblen Serverarchitektur vergleichen.

In dieser Übung führen Sie die folgenden Aufgaben aus:

1. Konfigurieren Sie Azure-Metriken für Ihre Azure-Datenbank für Den PostgreSQL-Dienst.
2. Führen Sie eine Beispielanwendung aus, die mehrere Benutzer simuliert, die die Datenbank abfragen.
3. Zeigen Sie die Metriken an.

Einrichten der Umgebung

Führen Sie diese Azure CLI-Befehle in der Cloud Shell aus, um eine Azure-Datenbank für PostgreSQL mit einer Kopie der Adventureworks-Datenbank zu erstellen. Die letzten Befehle drucken den Servernamen.

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 \
    --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

Konfigurieren von Azure-Metriken für Ihre Azure-Datenbank für Den PostgreSQL-Dienst

1. Öffnen Sie in einem Webbrowser eine neue Registerkarte, und navigieren Sie zum Azure-Portal.

2. Wählen Sie im Azure-Portal Alle Ressourcen aus.

3. Wählen Sie die Azure-Datenbank für PostgreSQL Servernamen ab Adventureworksaus.

4. Wählen Sie unter Überwachung die Option Metriken aus.

5. Fügen Sie auf der Diagrammseite die folgende Metrik hinzu:

   Eigentum	Wert
   Umfang	adventureworks[nnn]
   Metriknamespace	PostgreSQL-Serverstandardmetriken
   Metrik	Die aktiven Verbindungen.
   Aggregation	Avg

   Diese Metrik zeigt die durchschnittliche Anzahl von Verbindungen an, die pro Minute mit dem Server hergestellt wurden.

6. Wählen Sie Metrikhinzufügen aus, und fügen Sie die folgende Metrik hinzu:

   Eigentum	Wert
   Umfang	adventureworks[nnn]
   Metriknamespace	PostgreSQL-Serverstandardmetriken
   Metrik	CPU in Prozent
   Aggregation	Avg

7. Wählen Sie Metrikhinzufügen aus, und fügen Sie die folgende Metrik hinzu:

   Eigentum	Wert
   Umfang	adventureworks[nnn]
   Metriknamespace	PostgreSQL-Serverstandardmetriken
   Metrik	Arbeitsspeicher in Prozent
   Aggregation	Avg

8. Wählen Sie Metrikhinzufügen aus, und fügen Sie die folgende Metrik hinzu:

   Eigentum	Wert
   Umfang	adventureworks[nnn]
   Metriknamespace	PostgreSQL-Serverstandardmetriken
   Metrik	E/A in Prozent
   Aggregation	Avg

   Diese letzten drei Metriken zeigen, wie Ressourcen von der Testanwendung verbraucht werden.

9. Legen Sie den Zeitraum für das Diagramm auf letzte 30 Minutenfest.

10. Wählen Sie An Dashboard-anheften und dann anheften.

Ausführen einer Beispielanwendung, die mehrere Benutzer simuliert, die die Datenbank abfragen

1. Wählen Sie im Azure-Portal auf der Seite für Ihre Azure-Datenbank für PostgreSQL-Server unter EinstellungenVerbindungszeichenfolgenaus. Kopieren Sie die ADO.NET Verbindungszeichenfolge in die Zwischenablage.

2. Wechseln Sie zum Ordner ~/workshop/migration_samples/code/postgresql/AdventureWorksSoakTest Ordner.

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

3. Öffnen Sie die App.config Datei mit dem Code-Editor:

   code App.config
   

4. Ersetzen Sie den Wert Database durch azureadventureworks, und ersetzen Sie ConectionString0 durch die Verbindungszeichenfolge aus der Zwischenablage. Ändern Sie die Benutzer-ID in azureuser@adventureworks[nnn], und legen Sie das Kennwort auf Pa55w.rdfest. Die fertige Datei sollte ähnlich wie im folgenden Beispiel aussehen:

   <?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>
   

   Hinweis

   Ignorieren Sie die einstellungen ConnectionString1 und ConnectionString2. Sie aktualisieren diese Elemente später in der Übung.

5. Speichern Sie die Änderungen, und schließen Sie den Editor.

6. Führen Sie an der Cloud Shell-Eingabeaufforderung den folgenden Befehl aus, um die App zu erstellen und auszuführen:

   dotnet run
   

   Wenn die App gestartet wird, werden Threads von jedem Thread, der einen Benutzer simuliert, spawnsiert. Die Threads führen eine Schleife aus, wobei eine Reihe von Abfragen ausgeführt wird. Es werden Nachrichten wie die folgenden Nachrichten angezeigt, die angezeigt werden:

   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
   

   Lassen Sie die App ausgeführt, während Sie die nächsten Schritte ausführen.

Anzeigen der Metriken

1. Kehren Sie zum Azure-Portal zurück.

2. Wählen Sie im linken Bereich Dashboard-aus.

   Das Diagramm sollte die Metriken für Ihre Azure-Datenbank für PostgreSQL-Dienst anzeigen.

3. Wählen Sie das Diagramm aus, um es im Bereich Metriken zu öffnen.

4. Lassen Sie die Ausführung der App für mehrere Minuten zu (je länger, desto besser). Während der Zeitübergänge sollten die Metriken im Diagramm dem Muster ähneln, das in der folgenden Abbildung dargestellt ist:

   

   In diesem Diagramm werden die folgenden Punkte hervorgehoben:

   • Die CPU wird in voller Kapazität ausgeführt; Die Auslastung erreicht 100% sehr schnell.
   • Die Anzahl der Verbindungen steigt langsam an. Die Beispielanwendung ist so konzipiert, dass 101 Clients schnell hintereinander gestartet werden, der Server kann jedoch nur einige Verbindungen gleichzeitig öffnen. Die Anzahl der Verbindungen, die zu jedem "Schritt" im Diagramm hinzugefügt wurden, wird kleiner, und die Zeit zwischen "Schritten" nimmt zu. Nach ca. 45 Minuten konnte das System nur 70 Clientverbindungen herstellen.
   • Die Speicherauslastung nimmt im Laufe der Zeit immer weiter zu.
   • Die E/A-Auslastung liegt nahe null. Alle daten, die von den Clientanwendungen benötigt werden, werden derzeit im Arbeitsspeicher zwischengespeichert.

   Wenn die Anwendung lange genug ausgeführt wird, werden verbindungen gestartet, wobei die Fehlermeldungen in der folgenden Abbildung angezeigt werden.

   

5. Drücken Sie in der Cloud Shell die EINGABETASTE, um die Anwendung zu beenden.

Konfigurieren des Servers zum Sammeln von Abfrageleistungsdaten

1. Wählen Sie im Azure-Portal auf der Seite für Ihre Azure-Datenbank für PostgreSQL-Server unter EinstellungenServerparameteraus.

2. Legen Sie auf der Seite Serverparameter die folgenden Parameter auf die werte fest, die in der folgenden Tabelle angegeben sind.

   Parameter	Wert
   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. Wählen Sie Speichern aus.

Untersuchen der abfragen, die von der Anwendung mithilfe des Abfragespeichers ausgeführt werden

1. Kehren Sie zur Cloud Shell zurück, und starten Sie die Beispiel-App neu:

   dotnet run
   

   Zulassen, dass die App 5 Minuten lang ausgeführt wird, bevor Sie fortfahren.

2. Lassen Sie die App ausgeführt, und wechseln Sie zum Azure-Portal.

3. Wählen Sie auf der Seite für Ihre Azure-Datenbank für PostgreSQL-Server unter Intelligente LeistungAbfrageleistungserblickaus.

4. Legen Sie auf der Seite Abfrageleistungserblick auf der Registerkarte Abfragen mit langer AusführungAnzahl der Abfragen auf 10 fest, legen Sie Ausgewählt durch auf durchschnittlichefest, und legen Sie den Zeitraum auf letzten 6 Stundenfest.

5. Wählen Sie über dem Diagramm Zoom in (das Lupensymbol mit dem Zeichen "+" ) ein paar Mal aus, um in den neuesten Daten einzublenden.

   Je nachdem, wie lange die Anwendung ausgeführt werden darf, wird ein Diagramm ähnlich wie folgt angezeigt. Der Abfragespeicher aggregiert die Statistiken für Abfragen alle 15 Minuten, sodass jede Leiste die relative Zeit anzeigt, die von jeder Abfrage in jedem 15-Minuten-Zeitraum verbraucht wird:

   

6. Zeigen Sie mit der Maus auf jede Leiste, um die Statistiken für die Abfragen in diesem Zeitraum anzuzeigen. Die drei Abfragen, mit denen das System die meiste Zeit verbringt, sind:

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

   Diese Informationen sind nützlich für administratoren, die ein System überwachen. Wenn Sie Einblicke in die von Benutzern und Apps ausgeführten Abfragen erhalten, können Sie die ausgeführten Workloads verstehen und möglicherweise Empfehlungen für Anwendungsentwickler abgeben, wie sie ihren Code verbessern können. Ist es beispielsweise erforderlich, dass eine Anwendung alle 121.000 Zeilen aus der sales.salesorderdetail Tabelle abruft?

Überprüfen von Wartezeiten, die mithilfe des Abfragespeichers auftreten

1. Wählen Sie die Registerkarte "Statistik warten" aus.

2. Legen Sie den Zeitraum auf letzten 6 Stundenfest, legen Sie Gruppe nach auf Ereignis-fest, und legen Sie die Maximale Anzahl von Gruppen auf 5fest.

   Wie bei den Abfragen mit langer Ausführung Registerkarte werden die Daten alle 15 Minuten aggregiert. Die Tabelle unterhalb des Diagramms zeigt, dass das System zwei Arten von Wartezeitereignissen unterliegt:

   • Client: ClientWrite. Dieses Wait-Ereignis tritt auf, wenn der Server Daten (Ergebnisse) zurück in den Client schreibt. Es nicht angeben, dass beim Schreiben in die Datenbank Wartezeiten auftreten.
   • Client: ClientRead. Dieses Wait-Ereignis tritt auf, wenn der Server auf das Lesen von Daten (Abfrageanforderungen oder anderen Befehlen) von einem Client wartet. Es ist nicht mit dem Lesen aus der Datenbank verknüpft.

   erfassten Wartezeitstatistiken

   Hinweis

   Lese- und Schreibvorgänge in die Datenbank werden durch IO--Ereignisse und nicht durch Client--Ereignisse angegeben. Die Beispielanwendung wartet nicht, da alle benötigten Daten nach dem ersten Lesen im Arbeitsspeicher zwischengespeichert werden. Wenn die Metriken gezeigt haben, dass der Arbeitsspeicher niedrig war, werden wahrscheinlich E/A-Warteereignisse angezeigt.

3. Kehren Sie zur Cloud Shell zurück, und drücken Sie die EINGABETASTE, um die Beispielanwendung zu beenden.

Hinzufügen von Replikaten zum Azure-Datenbankdienst für PostgreSQL

1. Wählen Sie im Azure-Portal auf der Seite für Ihre Azure-Datenbank für PostgreSQL-Server unter EinstellungenReplikationaus.

2. Wählen Sie auf der Seite Replikation+ Replikat hinzufügenaus.

3. Geben Sie auf der Seite PostgreSQL-Server- im Feld Servernameadventureworks[nnn]-replica1ein, und wählen Sie dann OKaus.

4. Wenn das erste Replikat erstellt wird (es dauert mehrere Minuten), wiederholen Sie den vorherigen Schritt, und fügen Sie ein weiteres Replikat mit dem Namen adventureworks[nnn]-replica2hinzu.

5. Warten Sie, bis sich der Status beider Replikate von Deploying in Available ändert, bevor Sie fortfahren.

   

Konfigurieren der Replikate zum Aktivieren des Clientzugriffs

1. Wählen Sie den Namen des adventureworks[nnn]-replica1 Replikats aus. Sie werden zu der Seite für die Azure-Datenbank für PostgreSQL-Seite für dieses Replikat umgeleitet.
2. Wählen Sie unter Einstellungen die Option Verbindungssicherheit aus.
3. Legen Sie auf der Seite VerbindungssicherheitZugriff auf Azure-Dienste zulassen auf ON-fest, und wählen Sie dann Speichernaus. Diese Einstellung ermöglicht Anwendungen, die Sie mit der Cloud Shell ausführen, um auf den Server zuzugreifen.
4. Wenn die Einstellung gespeichert wird, wiederholen Sie die vorherigen Schritte, und ermöglichen Sie Azure-Diensten den Zugriff auf die adventureworks[nnn]-replica2 Replikats.

Jeden Server neu starten

Hinweis

Das Konfigurieren der Replikation erfordert nicht, dass Sie einen Server neu starten. Der Zweck dieser Aufgabe besteht darin, Arbeitsspeicher und alle zusätzlichen Verbindungen von jedem Server zu löschen, sodass die Metriken, die beim erneuten Ausführen der Anwendung gesammelt werden, sauberen.

1. Wechseln Sie zur Seite für die adventureworks[nnn] Server.
2. Wählen Sie auf der Seite ÜbersichtNeu startenaus.
3. Wählen Sie im Dialogfeld ServerneustartJaaus.
4. Warten Sie, bis der Server neu gestartet wird, bevor Sie fortfahren.
5. Starten Sie nach demselben Verfahren die adventureworks[nnn]-replica1 und adventureworks[nnn]-replica2- server neu.

Neukonfigurieren der Beispielanwendung für die Verwendung der Replikate

1. Bearbeiten Sie in der Cloud Shell die App.config Datei.

   code App.config
   

2. Fügen Sie die Verbindungszeichenfolgen für die einstellungen ConnectionString1 und ConnectionString2 hinzu. Diese Werte sollten mit ConnectionString0-identisch sein, aber mit dem Text adventureworks[nnn] durch adventureworks[nnn]-replica1 und adventureworks[nnn]-replica2 im Server und Benutzer-ID Elemente ersetzt.

3. Legen Sie die einstellung NumReplicas auf 3fest.

   Die App.config-Datei sollte nun wie folgt aussehen:

   <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. Speichern Sie die Datei, und schließen Sie den Editor.

5. Starten Sie die App erneut, die ausgeführt wird:

   dotnet run
   

   Die Anwendung wird wie zuvor ausgeführt. Diesmal werden die Anforderungen jedoch auf die drei Server verteilt.

6. Zulassen, dass die App einige Minuten lang ausgeführt werden kann, bevor Sie fortfahren.

Überwachen der App und Beobachten der Unterschiede in den Leistungsmetriken

1. Lassen Sie die App ausgeführt, und kehren Sie zum Azure-Portal zurück.

2. Wählen Sie im linken Bereich Dashboard-aus.

3. Wählen Sie das Diagramm aus, um es im Bereich Metriken zu öffnen.

   Denken Sie daran, dass in diesem Diagramm die Metriken für den Adventureworks*[nnn]*-Server angezeigt werden, aber nicht die Replikate. Die Last für jedes Replikat sollte viel gleich sein.

   Das Beispieldiagramm veranschaulicht die Metriken, die für die Anwendung über einen Zeitraum von 30 Minuten gesammelt wurden, vom Start aus. Das Diagramm zeigt, dass die CPU-Auslastung noch hoch war, aber die Arbeitsspeicherauslastung war niedriger. Darüber hinaus hat das System nach ca. 25 Minuten Verbindungen für über 30 Verbindungen hergestellt. Dies scheint möglicherweise kein günstiger Vergleich mit der vorherigen Konfiguration zu sein, die nach 45 Minuten 70 Verbindungen unterstützt hat. Die Workload wurde jedoch nun auf drei Server verteilt, die alle auf derselben Ebene ausgeführt wurden, und alle 101 Verbindungen wurden eingerichtet. Darüber hinaus konnte das System ausgeführt werden, ohne Verbindungsfehler zu melden.

   

   Sie können das Problem der CPU-Auslastung beheben, indem Sie auf ein höheres Preisniveau mit mehr CPU-Kernen skalieren. Das in dieser Übung verwendete Beispielsystem wird mithilfe der Basic Preisstufe mit 2 Kernen ausgeführt. Wenn Sie zur Allgemeinen Preisstufe wechseln, erhalten Sie bis zu 64 Kerne.

4. Kehren Sie zur Cloud Shell zurück, und drücken Sie die EINGABETASTE, um die App zu beenden.

Sie haben gesehen, wie Sie die Serveraktivitäten mithilfe der im Azure-Portal verfügbaren Tools überwachen. Außerdem haben Sie erfahren, wie Sie die Replikation konfigurieren und erfahren, wie das Erstellen schreibgeschützter Replikate die Arbeitsauslastung in leseintensiven Datenszenarien verteilen kann.