Упражнение. Защита, мониторинг и настройка перенесенной базы данных

  • 20 мин

Вы являетесь разработчиком баз данных в компании AdventureWorks. AdventureWorks продал велосипеды и велосипедные части непосредственно конечным потребителям и распространителям в течение более десяти лет. Их системы хранят сведения в базе данных, которая ранее была перенесена в Базу данных Azure для PostgreSQL.

После выполнения миграции необходимо убедиться, что система работает хорошо. Вы решили использовать средства Azure, доступные для мониторинга сервера. Чтобы снизить вероятность медленного времени отклика, вызванного спором и задержкой, вы решили реализовать репликацию данных для чтения. Необходимо отслеживать полученную систему и сравнивать результаты с гибкой архитектурой сервера.

В этом упражнении выполняются следующие задачи:

  1. Настройте метрики Azure для службы Базы данных Azure для PostgreSQL.
  2. Запустите пример приложения, которое имитирует несколько пользователей, запрашивающих базу данных.
  3. Просмотр метрик.

Настройка среды

Выполните эти команды Azure CLI в Cloud Shell, чтобы создать базу данных Azure для PostgreSQL с копией базы данных adventureworks. Последние команды печатают имя сервера.

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

Настройка метрик Azure для службы Базы данных Azure для PostgreSQL

  1. С помощью веб-браузера откройте новую вкладку и перейдите на портал Azure.

  2. На портале Azure выберите Все ресурсы.

  3. Выберите имя сервера Базы данных Azure для PostgreSQL , начиная с adventureworks.

  4. В разделе Мониторинг выберите Метрики.

  5. На странице диаграммы добавьте следующую метрику:

    Недвижимость Ценность
    Область действия adventureworks[nnn]
    Пространство имен метрик Стандартные метрики сервера PostgreSQL
    Единица измерения Активные подключения
    Аггрегация Средняя

    Эта метрика отображает среднее количество подключений, сделанных на сервере каждую минуту.

  6. Выберите "Добавить метрику" и добавьте следующую метрику:

    Недвижимость Ценность
    Область действия adventureworks[nnn]
    Пространство имен метрик Стандартные метрики сервера PostgreSQL
    Единица измерения Процент использования ЦП
    Аггрегация Средняя

  7. Выберите "Добавить метрику" и добавьте следующую метрику:

    Недвижимость Ценность
    Область действия adventureworks[nnn]
    Пространство имен метрик Стандартные метрики сервера PostgreSQL
    Единица измерения Процент памяти
    Аггрегация Средняя

  8. Выберите "Добавить метрику" и добавьте следующую метрику:

    Недвижимость Ценность
    Область действия adventureworks[nnn]
    Пространство имен метрик Стандартные метрики сервера PostgreSQL
    Единица измерения Процент I/O
    Аггрегация Средняя

    Эти последние три метрики показывают, как ресурсы используются тестовым приложением.

  9. Установите диапазон времени для диаграммы на последние 30 минут.

  10. Выберите "Закрепить на панели мониторинга" и нажмите кнопку "Закрепить".

Запуск примера приложения, имитируемого несколькими пользователями, запрашивающими базу данных

  1. На портале Azure на странице сервера Базы данных Azure для PostgreSQL в разделе "Параметры" выберите "Строки подключения". Скопируйте строку подключения ADO.NET в буфер обмена.

  2. Перейдите в папку ~/workshop/migration_samples/code/postgresql/AdventureWorksSoakTest .

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

  3. Откройте файл App.config с помощью редактора кода:

    code App.config

  4. Замените значение Database на azureadventureworks, а ConnectionString0 замените строкой подключения из буфера обмена. Измените идентификатор пользователяна azureuser@adventureworks[nnn], а пароль — Pa55w.rd. Завершенный файл должен выглядеть примерно так:

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

    Замечание

    Игнорировать параметры ConnectionString1 и ConnectionString2 сейчас. Вы обновите эти элементы позже в лаборатории.

  5. Сохраните изменения и закройте редактор.

  6. В командной строке Cloud Shell выполните следующую команду, чтобы создать и запустить приложение:

    dotnet run

    Когда приложение запускается, он создает потоки, каждый поток, имитирующий пользователя. Потоки выполняют цикл, выполняя ряд запросов. Вы начнете замечать появление таких сообщений:

    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

    Оставьте приложение запущенным во время выполнения следующих действий.

Просмотр метрик

  1. Вернитесь на портал Azure.

  2. В области слева выберите панель мониторинга.

    Вы увидите диаграмму, отображающую метрики для службы Базы данных Azure для PostgreSQL.

  3. Выберите диаграмму, чтобы открыть ее в области метрик .

  4. Разрешите приложению работать в течение нескольких минут (чем дольше, тем лучше). По мере прохождения времени метрики на диаграмме должны выглядеть следующим образом:

    Изображение, показывающее метрики, собранные во время выполнения примера приложения

    На этой диаграмме выделены следующие моменты:

    • ЦП работает на полной мощности; загрузка достигает 100% очень быстро.
    • Число подключений медленно растет. Пример приложения предназначен для запуска 101 клиентского приложения в быстрой последовательности, но сервер может справиться только с открытием нескольких подключений за раз. Количество подключений, добавленных на каждом шаге диаграммы, становится меньше, и время между шагами увеличивается. Через 45 минут система могла установить только 70 клиентских подключений.
    • Использование памяти постоянно увеличивается со временем.
    • Использование операций ввода-вывода близко к нулю. Все данные, необходимые клиентским приложениям, в настоящее время кэшируются в памяти.

    Если приложение работает достаточно долго, вы увидите, что подключения начинают давать сбои, а сообщения об ошибках будут показаны на следующем изображении.

    Изображение, показывающее ошибки подключения, которые могут возникать, когда у сервера недостаточно доступных ресурсов

  5. В Cloud Shell нажмите клавишу ВВОД, чтобы остановить приложение.

Настройка сервера для сбора данных о производительности запросов

  1. На портале Azure на странице сервера Базы данных Azure для PostgreSQL в разделе "Параметры" выберите параметры сервера.

  2. На странице параметров сервера задайте следующие параметры значения, указанные в таблице ниже.

    Параметр Ценность
    pg_qs.max_query_text_length 6000
    pg_qs.query_capture_mode ВСЕ
    pg_qs.replace_parameter_placeholders НА
    pg_qs.retention_period_in_days 7
    pg_qs.track_utility НА
    pg_stat_statements.track ВСЕ
    pgms_wait_sampling.history_period 100
    pgms_wait_sampling.query_capture_mode ВСЕ

  3. Нажмите кнопку "Сохранить".

Изучение запросов, выполняемых приложением с помощью хранилища запросов

  1. Вернитесь в Cloud Shell и перезапустите пример приложения:

    dotnet run

    Разрешите приложению работать в течение 5 минут до продолжения.

  2. Оставьте приложение запущенным и переключитесь на портал Azure

  3. На странице сервера Базы данных Azure для PostgreSQL в разделе "Интеллектуальная производительность" выберите "Аналитика производительности запросов".

  4. На странице "Аналитика производительности запросов" на вкладке "Длительные запросы" установите значение "Число запросов" равным 10, установите "Выбор по" значением "среднее", и установите значение "Время" на "Последние 6 часов".

  5. Над диаграммой выберите несколько раз "Увеличить" (значок увеличительного стекла со знаком "+"), чтобы сосредоточиться на последних данных.

    В зависимости от того, сколько времени вы позволили запустить приложение, вы увидите диаграмму, аналогичную приведенной ниже. Хранилище запросов агрегирует статистику запросов каждые 15 минут, поэтому на каждой строке отображается относительное время, затраченное каждым запросом за каждый 15-минутный период:

    Изображение, показывающее статистику для длительных запросов, захваченных с помощью хранилища запросов

  6. Наведите указатель мыши на каждую панель, чтобы просмотреть статистику запросов за этот период времени. Три запроса, которые система тратит большую часть времени на выполнение:

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

    Эта информация полезна для администраторов мониторинга системы. Понимание запросов, выполняемых пользователями и приложениями, позволяет понять выполняемые рабочие нагрузки и, возможно, рекомендации разработчикам приложений о том, как они могут улучшить свой код. Например, необходимо ли приложению получить все 121 000 строк из таблицы sales.salesorderdetail ?

Изучите ожидания, возникающие с помощью Хранилища запросов

  1. Перейдите на вкладку "Статистика ожидания ".

  2. Задайте для параметра "Время" значение "Последние 6 часов", задайте для параметра "Группа по" значение "Событие" и задайте для параметра "Максимальное число групп" значение 5.

    Как и на вкладке "Длительные запросы" , данные агрегируются каждые 15 минут. В таблице ниже показано, что система подвергалась двум типам события ожидания:

    • Клиент: ClientWrite. Это событие ожидания возникает, когда сервер записывает данные (результаты) обратно клиенту. Это не указывает на ожидания, возникающие при записи в базу данных.
    • Клиент: ClientRead. Это событие ожидания возникает, когда сервер ожидает чтения данных (запросов или других команд) от клиента. Оно не связано с временем, потраченным на чтение из базы данных.

    Изображение, показывающее статистику ожидания, записанную с помощью хранилища запросов

    Замечание

    Операции чтения и записи в базу данных указываются событиями ввода-вывода , а не событиями клиента . Пример приложения не ожидает никаких операций ввода-вывода, так как все необходимые данные кэшируются в памяти после первого чтения. Если показатели показывают, что память подходит к концу, вы, вероятно, начнете замечать возникновение событий ожидания ввода-вывода.

  3. Вернитесь в Cloud Shell и нажмите клавишу ВВОД, чтобы остановить приложение-пример.

Добавление реплик в службу Базы данных Azure для PostgreSQL

  1. На портале Azure на странице сервера Базы данных Azure для PostgreSQL в разделе "Параметры" выберите "Репликация".

  2. На странице репликации нажмите кнопку +Добавить реплику.

  3. На странице сервера PostgreSQL в поле имени сервера введите adventureworks[nnn]-replica1, а затем нажмите кнопку ОК.

  4. При создании первой реплики (занимает несколько минут), повторите предыдущий шаг и добавьте другую реплику adventureworks[nnn]-replica2.

  5. Дождитесь, пока состояние обеих реплик изменится с развертывания на доступно, прежде чем продолжить.

    Изображение страницы репликации для Базы данных Azure для PostgreSQL. Добавлены две реплики.

Настройка реплик для включения клиентского доступа

  1. Выберите название реплики adventureworks[nnn]-replica1. Вы перенаправляетесь на страницу Базы данных Azure для PostgreSQL, относящуюся к этой реплике.
  2. В разделе Параметры выберите Безопасность подключения.
  3. На странице "Безопасность подключения" задайте для параметра "Разрешить доступ к службам Azure " в ON, а затем нажмите кнопку "Сохранить". Этот параметр позволяет приложениям, запущенным с помощью Cloud Shell, получить доступ к серверу.
  4. При сохранении параметра повторите предыдущие шаги и разрешите службам Azure доступ к реплике adventureworks[nnn]-replica2 .

Перезапуск каждого сервера

Замечание

Настройка репликации не требует перезапуска сервера. Цель этой задачи — очистить память и любые ненужные подключения с каждого сервера, чтобы метрики, собранные при запуске приложения, были чистыми.

  1. Перейдите на страницу сервера adventureworks[nnn] .
  2. На странице обзора нажмите кнопку "Перезапустить".
  3. В диалоговом окне "Перезапуск сервера" нажмите кнопку "Да".
  4. Дождитесь перезапуска сервера перед продолжением.
  5. После выполнения той же процедуры перезапустите серверы adventureworks[nnn]-replica1 и adventureworks[nnn]-replica2 .

Перенастройка примера приложения для использования реплик

  1. В Cloud Shell измените файл App.config.

    code App.config

  2. Добавьте строки подключений для параметров ConnectionString1 и ConnectionString2 . Эти значения должны совпадать со значениями ConnectionString0, но с заменой текста adventureworks[nnn] на adventureworks[nnn]-replica1 и adventureworks[nnn]-replica2 в элементах Сервер и Идентификатор пользователя.

  3. Задайте для параметра NumReplicasзначение 3.

    Теперь файл App.config должен выглядеть следующим образом:

    <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. Сохраните файл и закройте редактор.

  5. Запустите приложение снова:

    dotnet run

    Приложение работает как раньше. Однако на этот раз запросы распределяются по трем серверам.

  6. Разрешите приложению работать в течение нескольких минут, прежде чем продолжать работу.

Мониторинг приложения и наблюдение за различиями в метриках производительности

  1. Оставьте приложение запущенным и вернитесь на портал Azure.

  2. В области слева выберите панель мониторинга.

  3. Выберите диаграмму, чтобы открыть ее в области метрик .

    Помните, что данная диаграмма отображает метрики для сервера adventureworks*[nnn]*, но не для реплик. Нагрузка для каждой реплики должна быть одинаковой.

    Пример диаграммы иллюстрирует метрики, собранные для приложения в течение 30 минут, от запуска. На диаграмме показано, что загрузка ЦП по-прежнему высока, но использование памяти было ниже. Кроме того, примерно через 25 минут система установила подключения для более чем 30 линий. Это может показаться не благоприятным сравнением с предыдущей конфигурацией, которая поддерживала 70 подключений через 45 минут. Однако рабочая нагрузка теперь распределялась по трем серверам, которые все работали на одном уровне производительности, и все 101 подключение было установлено. Кроме того, система смогла выполнять работу, не сообщая о каких-либо сбоях подключения.

    Изображение, показывающее метрики для сервера Базы данных Azure для PostgreSQL во время запуска приложения, после настройки репликации

    Вы можете решить проблему использования ЦП, масштабируя до более высокой ценовой категории с большим количеством ядер ЦП. Система, используемая в этой лаборатории, работает на базе ценового уровня "Базовый", с 2 ядрами. Переход на ценовую категорию общего назначения предоставляет до 64 ядер.

  4. Вернитесь в Cloud Shell и нажмите клавишу ВВОД, чтобы остановить приложение.

Вы узнали, как отслеживать активность сервера с помощью средств, доступных на портале Azure. Вы также узнали, как настроить репликацию и как создавать реплики, доступные только для чтения, могут распределять рабочую нагрузку в сценариях с интенсивным чтением данных.