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

  • 20 мин

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

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

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

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

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

Чтобы создать Базу данных Azure для PostgreSQL с копией базы данных AdventureWorks, выполните следующие команды Azure CLI в Cloud Shell. Последние команды выводят имя сервера.

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

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

  1. В веб-браузере откройте новую вкладку и перейдите на Портал Azure.

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

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

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

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

    Свойство Значение
    Область adventureworks[nnn]
    Пространство имен метрики Стандартные метрики сервера PostgreSQL
    Metric Активные подключения
    Агрегат Avg

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

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

    Свойство Значение
    Область adventureworks[nnn]
    Пространство имен метрики Стандартные метрики сервера PostgreSQL
    Metric Процент загрузки ЦП
    Агрегат Avg

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

    Свойство Значение
    Область adventureworks[nnn]
    Пространство имен метрики Стандартные метрики сервера PostgreSQL
    Metric Процент памяти
    Агрегат Avg

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

    Свойство Значение
    Область adventureworks[nnn]
    Пространство имен метрики Стандартные метрики сервера PostgreSQL
    Metric Процент операций ввода-вывода
    Агрегат Avg

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

  9. На диаграмме установите диапазон времени Последние 30 минут.

  10. Выберите Закрепить на панели мониторинга, затем выберите Создать.

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

  1. На странице сервера Базы данных Azure для PostgreSQL на портале Azure в разделе Параметры выберите Строки подключения. Скопируйте строку подключения 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 и замените ConectionString0 на строку подключения из буфера обмена. Измените идентификатор пользователя на 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. Пусть приложение поработает в течение нескольких минут (чем дольше, тем лучше). С течением времени метрики на диаграмме должны выглядеть примерно так, как показано на следующем рисунке.

    Image showing the metrics gathered while the sample app is running

    Эта диаграмма демонстрирует следующие моменты.

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

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

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

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

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

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

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

    Параметр Значение
    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. Выберите Сохранить.

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

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

    dotnet run

    Прежде чем продолжить, дайте приложению поработать в течение примерно 5 минут.

  2. Оставьте приложение работать и перейдите на портал Azure.

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

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

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

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

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

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

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

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

Проверка всех ожиданий, возникающих при использовании хранилища запросов

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

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

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

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

    Image showing the wait statistics captured by using Query Store

    Примечание.

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

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

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

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

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

  3. На странице Сервер PostgreSQL в поле Имя сервера введите adventureworks[nnn]-replica1 и нажмите кнопку OK.

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

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

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

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

  1. Выберите имя реплики adventureworks[nnn]-replica1. Вы будете перенаправлены на страницу Базы данных Azure для PostgreSQL для этой реплики.
  2. В разделе Параметры выберите Безопасность подключения.
  3. На странице Безопасность подключения установите для параметра Разрешить доступ к службам Azure значение ВКЛ. и нажмите Сохранить. Этот параметр разрешает для приложений, запускаемых с помощью 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, но в элементах Server и User ID текст 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 подключение, как и было необходимо. Более того, система может работать без сбоев в подключениях.

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

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

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

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