Ćwiczenie: ochrona, monitorowanie i dostrajanie zmigrowanej bazy danych

  • 20 min

Pracujesz jako deweloper bazy danych w organizacji AdventureWorks. AdventureWorks od ponad dekady sprzedaje rowery i części rowerowe bezpośrednio konsumentom końcowym i dystrybutorom. Ich systemy przechowują informacje w bazie danych, która została wcześniej zmigrowana do usługi Azure Database for PostgreSQL.

Po przeprowadzeniu migracji chcesz mieć pewność, że system działa prawidłowo. Decydujesz się używać narzędzi platformy Azure dostępnych do monitorowania serwera. Aby złagodzić możliwość wolnych czasów odpowiedzi spowodowanych rywalizacją i opóźnieniami, decydujesz się zaimplementować replikację odczytu. Musisz monitorować wynikowy system i porównywać wyniki z architekturą serwera elastycznego.

W tym ćwiczeniu wykonasz następujące zadania:

  1. Konfigurowanie metryk platformy Azure dla usługi Azure Database for PostgreSQL.
  2. Uruchom przykładową aplikację, która symuluje wielu użytkowników, którzy wysyłają zapytania do bazy danych.
  3. Wyświetl metryki.

Konfigurowanie środowiska

Uruchom te polecenia interfejsu wiersza polecenia platformy Azure w usłudze Cloud Shell, aby utworzyć bazę danych platformy Azure for PostgreSQL z kopią bazy danych adventureworks. Ostatnie polecenia będą wyświetlać nazwę serwera.

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

Konfigurowanie metryk platformy Azure dla usługi Azure Database for PostgreSQL

  1. Za pomocą przeglądarki internetowej otwórz nową kartę i przejdź do witryny Azure Portal.

  2. W witrynie Azure Portal wybierz pozycję Wszystkie zasoby.

  3. Wybierz nazwę serwera usługi Azure Database for PostgreSQL rozpoczynającą się od adventureworks.

  4. W obszarze Monitorowanie wybierz pozycję Metryki.

  5. Na stronie wykresu dodaj następującą metryki:

    Właściwości Wartość
    Zakres adventureworks[nnn]
    Przestrzeń nazw metryki Metryki standardowe serwera PostgreSQL
    Metric Aktywne Połączenie
    Agregacja Średnia

    Ta metryka wyświetla średnią liczbę połączeń wykonanych z serwerem w każdej minucie.

  6. Wybierz pozycję Dodaj metryki i dodaj następującą metryki:

    Właściwości Wartość
    Zakres adventureworks[nnn]
    Przestrzeń nazw metryki Metryki standardowe serwera PostgreSQL
    Metric Procent procesora CPU
    Agregacja Średnia

  7. Wybierz pozycję Dodaj metryki i dodaj następującą metryki:

    Właściwości Wartość
    Zakres adventureworks[nnn]
    Przestrzeń nazw metryki Metryki standardowe serwera PostgreSQL
    Metric Procent pamięci
    Agregacja Średnia

  8. Wybierz pozycję Dodaj metryki i dodaj następującą metryki:

    Właściwości Wartość
    Zakres adventureworks[nnn]
    Przestrzeń nazw metryki Metryki standardowe serwera PostgreSQL
    Metric Procent operacji we/wy
    Agregacja Średnia

    Te trzy ostatnie metryki pokazują, jak zasoby są używane przez aplikację testowa.

  9. Ustaw zakres czasu wykresu na Wartość Ostatnie 30 minut.

  10. Wybierz pozycję Przypnij do pulpitu nawigacyjnego, a następnie wybierz pozycję Przypnij.

Uruchamianie przykładowej aplikacji, która symuluje wielu użytkowników, którzy wysyłają zapytania do bazy danych

  1. W witrynie Azure Portal na stronie serwera usługi Azure Database for PostgreSQL w obszarze Ustawienia wybierz pozycję ciągi Połączenie ion. Skopiuj parametry połączenia ADO.NET do schowka.

  2. Przejdź do folderu ~/workshop/migration_samples/code/postgresql/AdventureWorksSoakTest .

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

  3. Otwórz plik App.config przy użyciu edytora kodu:

    code App.config

  4. Zastąp wartość Database wartością azureadventureworks i zastąp ciąg ConectionString0 parametry połączenia ze schowka. Zmień identyfikator użytkownika na azureuser@adventureworks[nnn], a następnie ustaw wartość Hasło na Pa55w.rd. Ukończony plik powinien wyglądać podobnie do poniższego przykładu:

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

    Uwaga

    Ignoruj ustawienia Połączenie ionString1 i Połączenie ionString2 na razie. Te elementy zostaną zaktualizowane później w laboratorium.

  5. Zapisz zmiany i zamknij edytor.

  6. W wierszu polecenia usługi Cloud Shell uruchom następujące polecenie, aby skompilować i uruchomić aplikację:

    dotnet run

    Po uruchomieniu aplikacji zostanie zduplikowana liczba wątków, z których każdy wątek symuluje użytkownika. Wątki wykonują pętlę, uruchamiając serię zapytań. Zostaną wyświetlone komunikaty, takie jak pokazane poniżej:

    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

    Pozostaw aplikację uruchomioną podczas wykonywania następnych kroków.

Wyświetlanie metryk

  1. Wróć do witryny Azure Portal.

  2. W okienku po lewej stronie wybierz pozycję Pulpit nawigacyjny.

    Powinien zostać wyświetlony wykres przedstawiający metryki dla usługi Azure Database for PostgreSQL.

  3. Wybierz wykres, aby otworzyć go w okienku Metryki .

  4. Zezwól aplikacji na uruchomienie przez kilka minut (im dłużej, tym lepiej). W miarę upływu czasu metryki na wykresie powinny przypominać wzorzec przedstawiony na poniższej ilustracji:

    Image showing the metrics gathered while the sample app is running

    Ten wykres wyróżnia następujące kwestie:

    • Procesor CPU działa w pełnej pojemności; wykorzystanie osiąga 100% bardzo szybko.
    • Liczba połączeń powoli rośnie. Przykładowa aplikacja została zaprojektowana tak, aby uruchamiać klientów 101 w krótkim odstępie czasu, ale serwer może poradzić sobie tylko z otwieraniem kilku połączeń naraz. Liczba połączeń dodanych na każdym "kroku" na wykresie jest coraz mniejsza, a czas między "krokami" rośnie. Po około 45 minutach system mógł ustanowić tylko 70 połączeń klienckich.
    • Wykorzystanie pamięci stale rośnie wraz z upływem czasu.
    • Wykorzystanie operacji we/wy jest zbliżone do zera. Wszystkie dane wymagane przez aplikacje klienckie są obecnie buforowane w pamięci.

    Jeśli opuścisz aplikację wystarczająco długo, zobaczysz, że połączenia zaczynają się wieść, a komunikaty o błędach są wyświetlane na poniższej ilustracji.

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

  5. W usłudze Cloud Shell naciśnij klawisz Enter, aby zatrzymać aplikację.

Konfigurowanie serwera w celu zbierania danych wydajności zapytań

  1. W witrynie Azure Portal na stronie serwera usługi Azure Database for PostgreSQL w obszarze Ustawienia wybierz pozycję Parametry serwera.

  2. Na stronie Parametry serwera ustaw następujące parametry na wartości określone w poniższej tabeli.

    Parametr Wartość
    pg_qs.max_query_text_length 6000
    pg_qs.query_capture_mode ALL
    pg_qs.replace_parameter_placeholders NA
    pg_qs.retention_period_in_days 7
    pg_qs.track_utility NA
    pg_stat_statements.track ALL
    pgms_wait_sampling.history_period 100
    pgms_wait_sampling.query_capture_mode ALL

  3. Wybierz pozycję Zapisz.

Badanie zapytań uruchamianych przez aplikację przy użyciu magazynu zapytań

  1. Wróć do usługi Cloud Shell i uruchom ponownie przykładową aplikację:

    dotnet run

    Zezwól aplikacji na uruchomienie przez 5 minut przed kontynuowaniem.

  2. Pozostaw uruchomioną aplikację i przejdź do witryny Azure Portal

  3. Na stronie serwera usługi Azure Database for PostgreSQL w obszarze Inteligentna wydajność wybierz pozycję Szczegółowe informacje o wydajności zapytań.

  4. Na stronie Szczegółowe informacje o wydajności zapytań na karcie Długotrwałe zapytania ustaw wartość Liczba zapytań na 10, ustaw wartość Wybrana według na ś średni i ustaw wartość Okres na Ostatnie 6 godzin.

  5. Nad wykresem wybierz pozycję Powiększ (ikona lupy z znakiem "+" kilka razy, aby pracować do domu w najnowszych danych.

    W zależności od tego, jak długo zezwolisz na uruchomienie aplikacji, zostanie wyświetlony wykres podobny do przedstawionego poniżej. Magazyn zapytań agreguje statystyki dla zapytań co 15 minut, więc każdy pasek pokazuje względny czas używany przez każde zapytanie w każdym 15-minutowym okresie:

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

  6. Umieść kursor myszy na każdym pasku, aby wyświetlić statystyki zapytań w tym okresie. Trzy zapytania, które system spędza większość czasu, to:

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

    Te informacje są przydatne w przypadku monitorowania systemu przez administratora. Wgląd w zapytania uruchamiane przez użytkowników i aplikacje umożliwia zrozumienie wykonywanych obciążeń i ewentualnie zalecenia dla deweloperów aplikacji na temat sposobu ulepszania kodu. Czy na przykład aplikacja musi pobrać wszystkie 121 000 wierszy z tabeli sales.salesorderdetail ?

Sprawdź wszystkie oczekiwania, które występują przy użyciu magazynu zapytań

  1. Wybierz kartę Statystyki oczekiwania.

  2. Ustaw wartość Przedział czasu na Ostatnie 6 godzin, ustaw opcję Grupuj według na Zdarzenie i ustaw wartość Maksymalna liczba grup na 5.

    Podobnie jak na karcie Długotrwałe zapytania , dane są agregowane co 15 minut. Poniższa tabela pokazuje, że system był przedmiotem dwóch typów zdarzeń oczekiwania:

    • Klient: ClientWrite. To zdarzenie oczekiwania występuje, gdy serwer zapisuje dane (wyniki) z powrotem do klienta. Nie wskazuje to oczekiwania poniesione podczas zapisywania w bazie danych.
    • Klient: ClientRead. To zdarzenie oczekiwania występuje, gdy serwer oczekuje na odczyt danych (żądania zapytania lub inne polecenia) od klienta. Nie jest ona skojarzona z czasem spędzonym na odczytywaniu z bazy danych.

    Image showing the wait statistics captured by using Query Store

    Uwaga

    Odczyt i zapis w bazie danych są wskazywane przez zdarzenia we /wy, a nie zdarzenia klienta . Przykładowa aplikacja nie powoduje zaczekania operacji we/wy, ponieważ wszystkie wymagane dane są buforowane w pamięci po pierwszym odczycie. Jeśli metryki wykazały, że pamięć była niska, prawdopodobnie pojawią się zdarzenia oczekiwania we/wy.

  3. Wróć do usługi Cloud Shell i naciśnij klawisz Enter, aby zatrzymać przykładową aplikację.

Dodawanie replik do usługi Azure Database for PostgreSQL

  1. W witrynie Azure Portal na stronie serwera usługi Azure Database for PostgreSQL w obszarze Ustawienia wybierz pozycję Replikacja.

  2. Na stronie Replikacja wybierz pozycję + Dodaj replikę.

  3. Na stronie serwera PostgreSQL w polu Nazwa serwera wpisz adventureworks[nnn]-replica1, a następnie wybierz przycisk OK.

  4. Po utworzeniu pierwszej repliki (potrwa to kilka minut), powtórz poprzedni krok i dodaj kolejną replikę o nazwie adventureworks[nnn]-replica2.

  5. Przed kontynuowaniem poczekaj, aż stan obu replik zmieni się z Wdrażanie na Dostępne .

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

Konfigurowanie replik w celu włączenia dostępu klienta

  1. Wybierz nazwę repliki adventureworks[nnn]-replica1 . Nastąpi przekierowanie na stronę dla strony usługi Azure Database for PostgreSQL dla tej repliki.
  2. W obszarze Ustawienia wybierz pozycję Zabezpieczenia Połączenie ion.
  3. Na stronie zabezpieczeń Połączenie ion ustaw opcję Zezwalaj na dostęp do usług platformy Azure na wartość WŁĄCZONE, a następnie wybierz pozycję Zapisz. To ustawienie umożliwia aplikacjom uruchamianym przy użyciu usługi Cloud Shell dostęp do serwera.
  4. Po zapisaniu ustawienia powtórz poprzednie kroki i zezwól usługom platformy Azure na dostęp do repliki adventureworks[nnn]-replica2 .

Uruchom ponownie każdy serwer

Uwaga

Konfigurowanie replikacji nie wymaga ponownego uruchomienia serwera. Celem tego zadania jest wyczyszczenie pamięci i wszelkich dodatkowych połączeń z każdego serwera, dzięki czemu metryki zebrane podczas ponownego uruchamiania aplikacji są czyste.

  1. Przejdź do strony serwera adventureworks[nnn].
  2. Na stronie Przegląd wybierz pozycję Uruchom ponownie.
  3. W oknie dialogowym Ponowne uruchamianie serwera wybierz pozycję Tak.
  4. Przed kontynuowaniem poczekaj na ponowne uruchomienie serwera.
  5. Wykonując tę samą procedurę, uruchom ponownie serwer adventureworks[nnn]-replica1 i adventureworks[nnn]-replica2 .

Ponowne konfigurowanie przykładowej aplikacji do używania replik

  1. W usłudze Cloud Shell edytuj plik App.config.

    code App.config

  2. Dodaj parametry połączeń dla ustawień Połączenie ionString1 i Połączenie ionString2. Te wartości powinny być takie same jak wartości Połączenie ionString0, ale z tekstem adventureworks[nnn] zastąpione adventureworks[nnn]-replica1 i adventureworks[nnn]-replica2 w elementach Server i User Id.

  3. Ustaw ustawienie NumReplicas na 3.

    Plik App.config powinien teraz wyglądać podobnie:

    <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. Zapisz plik i zamknij edytor.

  5. Uruchom ponownie aplikację:

    dotnet run

    Aplikacja będzie działać tak jak poprzednio. Jednak tym razem żądania są dystrybuowane na trzech serwerach.

  6. Zezwól aplikacji na uruchomienie przez kilka minut przed kontynuowaniem.

Monitorowanie aplikacji i obserwowanie różnic w metrykach wydajności

  1. Pozostaw uruchomioną aplikację i wróć do witryny Azure Portal.

  2. W okienku po lewej stronie wybierz pozycję Pulpit nawigacyjny.

  3. Wybierz wykres, aby otworzyć go w okienku Metryki .

    Pamiętaj, że na tym wykresie są wyświetlane metryki serwera adventureworks*[nnn]*, ale nie repliki. Obciążenie każdej repliki powinno być takie samo.

    Na przykładowym wykresie przedstawiono metryki zebrane dla aplikacji w okresie 30 minut od uruchomienia. Wykres pokazuje, że wykorzystanie procesora CPU było nadal wysokie, ale wykorzystanie pamięci było niższe. Ponadto po około 25 minutach system nawiązał połączenia dla ponad 30 połączeń. Może to nie wydawać się korzystne porównanie z poprzednią konfiguracją, która obsługiwała 70 połączeń po 45 minutach. Jednak obciążenie zostało rozłożone na trzy serwery, które działają na tym samym poziomie, a wszystkie 101 połączeń zostało ustanowionych. Ponadto system był w stanie kontynuować działanie bez zgłaszania błędów połączenia.

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

    Problem wykorzystania procesora CPU można rozwiązać, skalując w górę do wyższej warstwy cenowej z większą częścią rdzeni procesora CPU. Przykładowy system używany w tym laboratorium działa przy użyciu warstwy cenowej Podstawowa z 2 rdzeniami. Zmiana warstwy cenowej Ogólnego przeznaczenia na 64 rdzenie.

  4. Wróć do usługi Cloud Shell i naciśnij klawisz Enter, aby zatrzymać aplikację.

Wiesz już, jak monitorować aktywność serwera przy użyciu narzędzi dostępnych w witrynie Azure Portal. Wiesz również, jak skonfigurować replikację i dowiedzieć się, jak tworzenie replik tylko do odczytu może dystrybuować obciążenie w scenariuszach danych intensywnie korzystających z odczytu.