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

  • 20 Minuten

Sie arbeiten als Datenbankentwickler für die Organisation AdventureWorks. AdventureWorks verkauft seit mehr als einem Jahrzehnt Fahrräder und Zubehör direkt an Endkunden und Vertriebspartner. In Ihren Systemen werden Informationen in einer Datenbank gespeichert, die Sie zuvor zu Azure Database for PostgreSQL migriert haben.

Nachdem Sie die Migration durchgeführt haben, möchten Sie sicherstellen, dass das System gut funktioniert. Sie entscheiden sich für die Verwendung der verfügbaren Azure-Tools zum Überwachen des Servers. Um die Wahrscheinlichkeit langsamer Reaktionszeiten aufgrund von Konflikten und Wartezeiten zu verringern, entscheiden Sie sich für die Implementierung der Lesereplikation. Sie müssen das resultierende System überwachen und die Ergebnisse mit der Architektur für Flexibler Server vergleichen.

Sie führen in dieser Übung die folgenden Aufgaben durch:

  1. Konfigurieren von Azure-Metriken für Ihren Azure Database for PostgreSQL-Dienst
  2. Ausführen einer Beispielanwendung, die Abfragen der Datenbank durch mehrere Benutzer simuliert
  3. Anzeigen der Metriken

Einrichten der Umgebung

Führen Sie die folgenden Azure CLI-Befehle in einer Cloud Shell-Instanz aus, um eine Azure Database for PostgreSQL-Instanz mit einer Kopie der Datenbank von AdventureWorks zu erstellen. Mit den letzten Befehlen wird der Servername ausgegeben.

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

Konfigurieren von Azure-Metriken für Ihren Azure Database for 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 den Namen des Azure Database for PostgreSQL-Servers aus, der mit adventureworks beginnt.

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

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

    Eigenschaft Wert
    Bereich adventureworks[nnn]
    Metriknamespace Standardmetriken für PostgreSQL-Server
    Metrik Die aktiven Verbindungen.
    Aggregation Avg

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

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

    Eigenschaft Wert
    Bereich adventureworks[nnn]
    Metriknamespace Standardmetriken für PostgreSQL-Server
    Metrik CPU in Prozent
    Aggregation Avg

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

    Eigenschaft Wert
    Bereich adventureworks[nnn]
    Metriknamespace Standardmetriken für PostgreSQL-Server
    Metrik Arbeitsspeicher in Prozent
    Aggregation Avg

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

    Eigenschaft Wert
    Bereich adventureworks[nnn]
    Metriknamespace Standardmetriken für PostgreSQL-Server
    Metrik E/A in Prozent
    Aggregation Avg

    Diese letzten drei Metriken veranschaulichen den Ressourcenverbrauch durch die Testanwendung.

  9. Legen Sie als Zeitbereich Letzte 30 Minuten fest.

  10. Wählen Sie An Dashboard anheften und anschließend Anheften aus.

Ausführen einer Beispielanwendung, die Abfragen der Datenbank durch mehrere Benutzer simuliert

  1. Wählen Sie im Azure-Portal auf der Seite für Ihren Azure Database for PostgreSQL-Server unter Einstellungen die Option Verbindungszeichenfolgen aus. Kopieren Sie die ADO.NET-Verbindungszeichenfolge in die Zwischenablage.

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

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

  3. Öffnen Sie die Datei „App.config“ im Code-Editor:

    code App.config

  4. Ersetzen Sie den Wert von Database durch azureadventureworks und den Wert von ConectionString0 durch die Verbindungszeichenfolge aus der Zwischenablage. Ändern Sie die Benutzer-ID in azureuser@adventureworks[nnn], und legen Sie das Kennwort auf Pa55w.rd fest. Die fertige Datei sollte dem nachstehenden Beispiel ähneln:

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

    Die Einstellungen ConnectionString1 und ConnectionString2 können Sie vorerst ignorieren. Diese Informationen werden später im Lab geändert.

  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, generiert sie einige Threads, die jeweils einen Benutzer simulieren. Die Threads führen eine Schleife aus, die mehrere Abfragen ausführt. Dabei werden Meldungen wie die unten dargestellten angezeigt:

    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

    Setzen Sie die Ausführung der App fort, 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 mit den Metriken zu Ihrem Azure Database for PostgreSQL-Dienst sollte angezeigt werden.

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

  4. Setzen Sie die App-Ausführung für mehrere Minuten fort (je länger, desto besser). Nach einer gewissen Zeit sollten die Metriken im Diagramm dem Muster in der folgenden Abbildung ähneln:

    Image showing the metrics gathered while the sample app is running

    Dieses Diagramm veranschaulicht die folgenden Punkte:

    • Die CPU arbeitet mit voller Kapazität, und die Auslastung erreicht sehr schnell 100 %.
    • Die Anzahl der Verbindungen steigt langsam an. Die Beispielanwendung ist so konzipiert, dass sie in schneller Folge 101 Clients startet. Der Server ist aber nur in der Lage, einige wenige Verbindungen gleichzeitig zu verarbeiten. Die Anzahl von Verbindungen, die bei jedem „Schritt“ im Diagramm hinzugefügt werden, wird kleiner, und die Zeit zwischen den „Schritten“ erhöht sich. Nach ungefähr 45 Minuten konnte das System nur 70 Clientverbindungen einrichten.
    • Die Arbeitsspeicherauslastung nimmt im Lauf der Zeit konstant zu.
    • Die E/A-Auslastung liegt nahe null. Alle von der Clientanwendung benötigten Daten werden derzeit im Arbeitsspeicher zwischengespeichert.

    Wenn Sie die Anwendung lange genug ausführen, werden Sie sehen, dass es zu Verbindungsfehlern kommt und die Fehlermeldungen aus der folgenden Abbildung ausgegeben werden.

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

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

Konfigurieren des Servers zum Erfassen von Daten zur Abfrageleistung

  1. Wählen Sie im Azure-Portal auf der Seite für Ihren Azure Database for PostgreSQL-Server unter Einstellungen die Option Serverparameter aus.

  2. Legen Sie auf der Seite Serverparameter die folgenden Parameter auf die Werte in der nachstehenden Tabelle fest.

    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 der Anwendung mit dem Abfragespeicher

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

    dotnet run

    Lassen Sie die App 5 Minuten lang laufen, bevor Sie fortfahren.

  2. Lassen Sie die App laufen, und wechseln Sie zum Azure-Portal.

  3. Wählen Sie auf der Seite für Ihren Azure Database for PostgreSQL Server unter Intelligente Leistung die Option Query Performance Insight aus.

  4. Legen Sie auf der Seite Query Performance Insight auf der Registerkarte Abfragen mit langer Ausführungszeit die Anzahl der Abfragen auf „10“, Ausgewählt nach auf avg und Zeitraum auf Letzte 6 Stunden fest.

  5. Wählen Sie über dem Diagramm die Option Zoom ein (das Lupensymbol mit dem +-Zeichen) einige Male aus, um die neuesten Daten anzuzeigen.

    Je nachdem, wie lange die Anwendung ausgeführt wurde, wird ein Diagramm ähnlich dem unten dargestellten angezeigt. Im Abfragespeicher werden die Statistiken für Abfragen alle 15 Minuten aggregiert, sodass jeder Balken die relative Zeit anzeigt, die jede Abfrage im jeweiligen 15-minütigen Zeitraum verbraucht hat:

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

  6. Zeigen Sie mit der Maus auf die einzelnen Balken, um die Statistiken zu den Abfragen in diesem Zeitraum anzuzeigen. Die drei Abfragen, für die das System den größten Teil der Zeit benötigt, sind:

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

    Diese Informationen helfen dem Administrator bei der Überwachung des Systems. Wenn Sie Erkenntnisse über die von Benutzern und Apps ausgeführten Abfragen haben, können Sie die ausgeführten Workloads besser verstehen und den Anwendungsentwicklern ggf. Empfehlungen zur Verbesserung ihres Codes geben. Ist es z. B. für eine Anwendung wirklich erforderlich, alle mehr als 121.000 Zeilen aus der Tabelle sales.salesorderdetail abzurufen?

Überprüfen aller Warteereignisse mit dem Abfragespeicher

  1. Wählen Sie die Registerkarte Wartestatistik aus.

  2. Legen Sie Zeitraum auf Letzte 6 Stunden, Gruppieren nach auf Ereignis und Maximale Anzahl von Gruppen auf 5 fest.

    Wie bei der Registerkarte Abfragen mit langer Ausführungszeit werden die Daten alle 15 Minuten aggregiert. In der Tabelle unter dem Diagramm sehen Sie, dass im System zwei Arten von Warteereignissen aufgetreten sind:

    • Client: ClientWrite. Dieses Warteereignis tritt auf, wenn der Server Daten (Ergebnisse) zurück an den Client schreibt. Es weist nicht darauf hin, dass beim Schreiben in die Datenbank Wartezeiten aufgetreten sind.
    • Client: ClientRead. Dieses Warteereignis tritt auf, wenn der Server auf das Lesen von Daten (Abfrageanforderungen oder andere Befehle) von einem Client wartet. Es hängt nicht mit der Zeit zusammen, die für das Lesen aus der Datenbank aufgewandt wurde.

    Image showing the wait statistics captured by using Query Store

    Hinweis

    Lese- und Schreibvorgänge in der Datenbank werden durch E/A-Ereignisse und nicht durch Clientereignisse angezeigt. Die Beispielanwendung verursacht keine E/A-Warteereignisse, da alle benötigten Daten nach dem ersten Lesevorgang im Arbeitsspeicher zwischengespeichert werden. Wenn die Metriken darauf hindeuten, dass der Arbeitsspeicher knapp wird, beginnen möglicherweise auch E/A-Warteereignisse aufzutreten.

  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 Database for PostgreSQL-Dienst

  1. Wählen Sie im Azure-Portal auf der Seite für Ihren Azure Database for PostgreSQL-Server unter Einstellungen die Option Replikation aus.

  2. Wählen Sie auf der Seite Replikation die Option + Replikat hinzufügen aus.

  3. Geben Sie auf der Seite PostgreSQL-Server im Feld Servername den Namen adventureworks[nnn]-replica1 ein, und wählen Sie dann OK aus.

  4. Nachdem das erste Replikat erstellt wurde (dies dauert mehrere Minuten), wiederholen Sie den vorherigen Schritt und fügen ein weiteres Replikat mit dem Namen adventureworks[nnn]-replica2 hinzu.

  5. Warten Sie, bis der Status beider Replikate von Bereitstellung wird durchgeführt in Verfügbar geändert wird, bevor Sie fortfahren.

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

Konfigurieren der Replikate zum Aktivieren des Clientzugriffs

  1. Wählen Sie den Namen des Replikats adventureworks[nnn]-replica1 aus. Sie öffnen damit die Seite von Azure Database for PostgreSQL für dieses Replikat.
  2. Wählen Sie unter Einstellungen die Option Verbindungssicherheit aus.
  3. Legen Sie auf der Seite Verbindungssicherheit die Option Zugriff auf Azure-Dienste erlauben auf EIN fest, und wählen Sie dann Speichern aus. Mit dieser Einstellung können Anwendungen, die Sie mithilfe der Cloud Shell ausführen, auf den Server zugreifen.
  4. Nachdem die Einstellung gespeichert wurde, wiederholen Sie die vorherigen Schritte und gewähren Azure-Diensten den Zugriff auf das Replikat adventureworks[nnn]-replica2.

Neustarten der einzelnen Server

Hinweis

Wenn Sie die Replikation konfigurieren, müssen Sie den entsprechenden Server nicht neu starten. Der Zweck dieser Aufgabe besteht darin, den Arbeitsspeicher und alle überflüssigen Verbindungen der einzelnen Server zu bereinigen, damit die Metriken, die bei der erneuten Ausführung der Anwendung gesammelt werden, unverfälscht sind.

  1. Wechseln Sie zur Seite für den Server adventureworks[nnn].
  2. Wählen Sie auf der Seite Übersicht die Option Neu starten aus.
  3. Wählen Sie im Dialogfeld Server neu starten die Option Jaaus.
  4. Warten Sie, bis der Server neu gestartet wurde, bevor Sie fortfahren.
  5. Wiederholen Sie das Verfahren, um die Server adventureworks[nnn]-replica1 und adventureworks[nnn]-replica2 neu zu starten.

Neukonfigurieren der Beispielanwendung für die Verwendung der Replikate

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

    code App.config

  2. Fügen Sie die Verbindungszeichenfolgen für die Einstellungen ConnectionString1 und ConnectionString2 hinzu. Diese Werte sollten mit dem von ConnectionString0 übereinstimmen, wobei adventureworks[nnn] in den Elementen Server und User Id durch adventureworks[nnn]-replica1 und adventureworks[nnn]-replica2 ersetzt wurde.

  3. Legen Sie die Einstellung NumReplicas auf 3 fest.

    Die Datei „App.config“ sollte nun in etwa 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-Ausführung erneut:

    dotnet run

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

  6. Lassen Sie die App einige Minuten laufen, bevor Sie fortfahren.

Überwachen der App und Untersuchen der Unterschiede bei den Leistungsmetriken

  1. Lassen Sie die App laufen, und wechseln Sie zurück zum Azure-Portal.

  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 Server „adventureworks*[nnn]*“ und nicht für die Replikate angezeigt werden. Die Last sollte bei den Replikaten nahezu identisch sein.

    Das Beispieldiagramm veranschaulicht die Metriken, die über einen Zeitraum von 30 Minuten nach dem Start für die Anwendung erfasst wurden. Das Diagramm zeigt, dass die CPU-Auslastung nach wie vor hoch war, die Arbeitsspeicherauslastung jedoch niedriger. Außerdem hatte das System nach ungefähr 25 Minuten über 30 Verbindungen hergestellt. Dies scheint im Vergleich zur vorherigen Konfiguration, bei der nach 45 Minuten 70 Verbindungen unterstützt wurden, nicht besonders vorteilhaft zu sein. Allerdings wurde die Workload nun auf drei Server verteilt, die alle auf der gleichen Ebene arbeiteten und damit alle 101 Verbindungen herstellen konnten. Außerdem meldete das System während der Ausführung keine Verbindungsfehler.

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

    Sie können das Problem der CPU-Auslastung beheben, indem Sie eine Skalierung auf einen höheren Tarif mit mehr CPU-Kernen durchführen. Das in diesem Lab verwendete Beispielsystem wird im Tarif Basic mit 2 Kernen ausgeführt. Wenn Sie zum Tarif Universell 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 nun gesehen, wie Sie die Serveraktivität mithilfe der im Azure-Portal verfügbaren Tools überwachen. Außerdem haben Sie erfahren, wie Sie die Replikation konfigurieren und wie Sie durch das Erstellen schreibgeschützter Replikate die Workload in leseintensiven Szenarien verteilen.