Мониторинг производительности Базы данных SQL Azure в мультитенантном приложении SaaS и управление ею

  • Статья

Область применения:База данных SQL Azure

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

SaaS-приложение Wingtip Tickets c однотенантной базой данных создано на основе модели, предусматривающей использование одной базы данных для каждого объекта (клиента). Как и во многих приложениях SaaS, рабочую нагрузку клиента предсказать невозможно, так как пользователи могут покупать билеты в любое время. Чтобы воспользоваться преимуществами этого шаблона использования, базы данных клиента развертываются в эластичные пулы. Эластичные пулы оптимизируют затраты на решение за счет совместного использования ресурсов в нескольких базах данных. При использовании этого шаблона важно выполнять мониторинг использования ресурсов пула и базы данных, чтобы обеспечить достаточную загруженность пулов. Кроме того, необходимо убедиться, что отдельные базы данных имеют достаточно ресурсов, а пулы не превышают ограничения на использование единиц eDTU. В этом руководстве рассматриваются способы мониторинга баз данных и пулов и управления ими, а также приведены действия, которые необходимо предпринять в случае изменений рабочей нагрузки.

Из этого руководства вы узнаете, как выполнить следующие задачи:

  • Моделирование использования ресурсов в базах данных клиентов с помощью предоставленного генератора нагрузки.
  • Наблюдение за реакцией баз данных клиентов при увеличении нагрузки.
  • Увеличение масштаба эластичного пула из-за роста нагрузки на базу данных.
  • Подготовка второго эластичного пула для балансировки нагрузки базы данных.

Для работы с этим руководством выполните следующие предварительные требования:

Общие сведения о шаблонах управления производительностью SaaS

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

application diagram

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

Стратегии управления производительностью

  • Чтобы избежать необходимости вручную отслеживать производительность, наиболее эффективно настраивать оповещения, которые активируются при удалении баз данных или пулов из обычных диапазонов.
  • Чтобы управлять краткосрочными колебаниями объемов вычислительных ресурсов пула, вы можете масштабировать уровень единиц eDTU пула. Если эти колебания происходят постоянно и их можно предугадывать, масштабирование пула можно запланировать и этот процесс будет выполняться автоматически. Например,если рабочая нагрузка незначительная (ночью или на выходных), масштаб можно уменьшить.
  • Чтобы управлять долгосрочными колебаниями или изменениями числа баз данных, отдельные базы данных можно переместить в другие пулы.
  • Чтобы управлять временным возрастанием нагрузки отдельной базы данных, ее можно изъять из пула и назначить ей индивидуальный объем вычислительных ресурсов. После снижения нагрузки эту базу данных можно вернуть в пул. Если это известно заранее, базу данных можно переместить заблаговременно. Так вы сможете убедиться, что в ней всегда есть необходимые ресурсы, а также избежать влияния на другие базы данных в пуле. Если эта необходимость предсказуемая, например из-за увеличения уровня продаж билетов на популярное мероприятие, это поведение управления можно интегрировать в приложение.

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

При работе с большим количеством ресурсов можно использовать журналы Azure Monitor. Это отдельная служба Azure, которая предоставляет аналитические сведения на основе журналов, собранных в рабочей области Log Analytics. Журналы Azure Monitor могут собирать данные телеметрии из многих служб и использоваться для выполнения запросов и настройки оповещений.

Получение скриптов для SaaS-приложения Wingtip Tickets c однотенантной БД

Сценарии для приложения SaaS Wingtip Tickets c мультитенантной базой данных и исходный код этого приложения вы найдете в репозитории GitHub WingtipTicketsSaaS-DbPerTenant. Инструкции по скачиванию и разблокированию сценариев приложения SaaS Wingtip Tickets см. в статье Общие рекомендации по работе с примерами приложений SaaS Wingtip Tickets.

Подготовка дополнительных клиентов

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

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

  1. В интегрированной среде сценариев PowerShell откройте скрипт …\Learning Modules (Модули для обучения)\Performance Monitoring and Management (Мониторинг производительности и управление ею)\Demo-PerformanceMonitoringAndManagement.ps1. Не закрывайте этот скрипт, так как он еще понадобится в рамках этого руководства.
  2. Чтобы выбрать скрипт подготовки пакета клиентов, задайте параметр $DemoScenario = 1.
  3. Нажмите клавишу F5 для запуска скрипта.

Этот скрипт развернет 17 клиентов менее чем за 5 минут.

Скрипт New-TenantBatch использует вложенный или связанный набор шаблонов Resource Manager для создания пакета клиентов, который по умолчанию копирует базу данных basetenantdb на сервер каталога, чтобы создать базы данных клиента, а затем регистрирует их в этом каталоге и, наконец, инициализирует их с именем клиента и типом объекта. Это согласуется с принципом подготовки приложением нового клиента. Все изменения, внесенные в базу данных basetenantdb, применяются к подготовленным после клиентам. Сведения о выполнении изменения схемы имеющихся баз данных клиентов, в том числе о basetenantdb базе данных, см. в статье Управление схемой для нескольких клиентов в приложении SaaS Wingtip.

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

Предоставляется скрипт Demo-PerformanceMonitoringAndManagement.ps1 для моделирования рабочих нагрузок, выполняющихся во всех клиентских базах данных. Нагрузка создается с помощью одного из доступных сценариев нагрузки:

Демонстрация Сценарий
2 Создание нагрузки с обычной интенсивностью (около 40 DTU)
3 Создание нагрузки с более длительными и частыми пиками на базу данных.
4 Создание нагрузки с более частым использованием единиц DTU при пиках на базу данных (около 80 DTU).
5 Создание нормальной нагрузки с высокой нагрузкой на отдельный клиент (около 95 DTU).
6 Создание неравномерной нагрузки между несколькими пулами.

Генератор нагрузки применяет искусственную нагрузку на ЦП каждой базы данных клиента. Он запускает задание в каждой базе данных клиента, которое периодически вызывает хранимую процедуру, за счет чего создается нагрузка. Уровень (в единицах eDTU), продолжительность и интервалы нагрузки во всех базах данных отличаются, что позволяет моделировать непредсказуемую активность клиента.

  1. В интегрированной среде сценариев PowerShell откройте скрипт …\Learning Modules (Модули для обучения)\Performance Monitoring and Management (Мониторинг производительности и управление ею)\Demo-PerformanceMonitoringAndManagement.ps1. Не закрывайте этот скрипт, так как он еще понадобится в рамках этого руководства.
  2. Чтобы выполнить скрипт создания нагрузки с обычной интенсивностью, задайте параметр $DemoScenario = 2.
  3. Нажмите клавишу F5, чтобы применить эту нагрузку ко всем базам данных клиента.

SaaS-приложение Wingtip Tickets c однотенантной базой данных — это приложение SaaS, а реальная нагрузка в таких приложениях обычно непредсказуема и возникает время от времени. Для ее моделирования генератор нагрузки создает случайную нагрузку, распределенную во всех клиентах. Чтобы появился шаблон нагрузки, необходимо несколько минут, поэтому генератор нагрузки должен работать около 3–5 минут. Затем можно приступить к отслеживанию нагрузки в разделах ниже.

Важно!

Генератор нагрузки выполняется как ряд заданий в локальном сеансе PowerShell. Не закрывайте вкладку Demo-PerformanceMonitoringAndManagement.ps1. Если закрыть эту вкладку или приостановить работу компьютера, выполнение заданий в генераторе нагрузки прекратится. Генератор нагрузки остается в состоянии job-invoking, в котором он создает нагрузку на любого из новых клиентов, подготовленных после запуска генератора. Нажмите клавиши CTRL+C, чтобы остановить вызов новых заданий и выйти из скрипта. Генератор нагрузки продолжит работу, но только в имеющихся клиентах.

Мониторинг использования ресурсов на портале Azure

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

  1. Откройте портал Azure и перейдите к серверу tenants1-dpt-<пользователь>.
  2. Прокрутите вниз и найдите эластичные пулы. Затем щелкните Pool1. В этом пуле содержатся все созданные ранее базы данных клиента.

Просмотрите диаграммы Наблюдение за пулами эластичных БД и Наблюдение за эластичными базами данных.

Значения на диаграмме использования ресурсов пула основаны на совокупном использовании ресурсов всеми находящимися в нем базами данных. На диаграмме базы данных показаны пять наиболее активных баз данных.

database chart

Так как в пуле есть и другие базы данных, на этой диаграмме также показана активность без учета этих 5 баз данных. Чтобы просмотреть дополнительные сведения, щелкните Использование ресурсов базы данных:

database resource utilization

Настройка оповещений производительности в пуле

Чтобы настроить оповещение в пуле, которое активируется при более >75 % использования, сделайте следующее:

  1. На портале Azure щелкните сервер tenants1-dpt-<пользователь> и выберите Pool1.

  2. Щелкните Правила оповещения, а затем выберите + Добавить оповещение:

    add alert

  3. Укажите имя, например High DTU.

  4. Задайте следующие значения:

    • "Метрика": eDTU percentage (Процент eDTU);
    • "Условие": "Больше";
    • "Пороговое значение": 75;
    • "Период": "За последние 30 минут".

  5. Добавьте адрес электронной почты в поле Additional administrator email(s) (Дополнительные адреса электронной почты администратора) и нажмите кнопку ОК.

    set alert

Увеличение масштаба загруженного пула

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

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

При долгосрочных повышениях нагрузки мы советуем оптимизировать использование индексов и запросов, чтобы улучшить производительность базы данных. В зависимости от чувствительности приложения к проблемам с производительностью мы советуем увеличить масштаб пула до достижения 100 % использования единиц eDTU. А оповещения позволяют предупредить об этом событии заранее.

Вы можете смоделировать загруженный пул, увеличив созданную генератором нагрузку. При более частых и длительных пиковых нагрузках баз данных повышается общая нагрузка на пул. Требования отдельных баз данных не изменяются. Масштаб пула можно легко увеличить на портале или с помощью PowerShell. В рамках этого руководства используется портал.

  1. Чтобы выполнить скрипт создания нагрузки с более длительными и частыми пиками на базу данных, задайте параметр $DemoScenario = 3. Это позволит повысить интенсивность общей нагрузки пула, не изменяя необходимую пиковую нагрузку каждой базы данных.

  2. Нажмите клавишу F5, чтобы применить эту нагрузку ко всем базам данных клиента.

  3. Выберите Pool1 на портале Azure.

Просмотрите показатели использования eDTU пула с более высокой нагрузкой на диаграмме выше. Нагрузка начинает повышаться через несколько минут. Но вы сразу увидите, что пул начал достигать порогового значения использования, и когда нагрузка перейдет в устойчивое состояние, в пуле возникнет перегрузка.

  1. Чтобы увеличить масштаб пула, щелкните Настроить пул в верхней части страницы Pool1.
  2. Установите ползунок eDTU пула в положение 100. При изменении числа единиц eDTU пула индивидуальные параметры баз данных не изменяются (максимально на каждую базу данных по прежнему выделяется 50 единиц eDTU). Параметры каждой базы данных можно просмотреть справа в колонке Настроить пул.
  3. Щелкните Сохранить, чтобы отправить запрос для масштабирования пула.

Вернитесь к колонке Pool1>Обзор, чтобы просмотреть диаграммы мониторинга. Следите за эффектом предоставления пула дополнительных ресурсов (хотя с несколькими базами данных и случайной нагрузкой не всегда легко увидеть окончательно до тех пор, пока вы не будете работать в течение некоторого времени). Посмотрев на диаграммы, примите во внимание следующее: предельное значение на верхней диаграмме теперь составляет 100 единиц eDTU, а на нижней — по прежнему 50, так как максимально на каждую базу данных выделяется 50 единиц eDTU.

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

Распределение нагрузки между пулами

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

  1. На портале Azure откройте сервер tenants1-dpt-<пользователь>.

  2. Щелкните + Создать пул, чтобы создать пул на текущем сервере.

  3. В шаблоне Эластичный пул сделайте следующее.

    1. В поле Имя введите Pool2.

    2. Укажите ту же ценовую категорию (Пул "Стандартный").

    3. Щелкните Настроить пул.

    4. Задайте для параметра eDTU пула значение 50 eDTU.

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

    6. Выберите 10 любых баз данных, переместите их в новый пул, а затем нажмите кнопку Выбрать. Если генератор нагрузки запущен, службе уже известно, что для профиля производительности пула требуется пул, размер которого превышает значение по умолчанию в 50 eDTU, и рекомендует начинать с параметра 100 eDTU.

      recommendation

    7. В этом руководстве оставьте значение по умолчанию в 50 единиц eDTU и нажмите кнопку Выбрать еще раз.

    8. Нажмите кнопку ОК, чтобы создать пул и переместите в него выбранные базы данных.

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

Выберите Pool2 (на сервере tenants1-dpt-<пользователь>), чтобы открыть пул и отслеживать его производительность. Если он не отображается, дождитесь завершения подготовки нового пула.

Использование ресурсов в пуле Pool1 снизилось, а нагрузка равномерно распределена между ним и пулом Pool2.

Управление производительностью отдельной базы данных

Если нагрузка отдельной базы данных в пуле постоянно высокая, в зависимости от конфигурации пула это может влиять на ресурсы в пуле и другие базы данных. Если эта активность не прекращается в течение некоторого времени, базу данных можно временно изъять из пула. Это позволяет настроить для базы данных необходимые дополнительные ресурсы и изолирует ее от других баз данных.

Ниже приведены действия, которые моделируют высокую нагрузку на базу данных Contoso Concert Hall из-за увеличения уровня продаж билетов на популярный концерт.

  1. В интерактивной среде сценариев PowerShell откройте скрипт …\Demo-PerformanceMonitoringAndManagement.ps1.

  2. Чтобы создать нормальную нагрузку с высокой нагрузкой на отдельный клиент (около 95 DTU), задайте для параметра $DemoScenario значение 5.

  3. Задайте параметр $SingleTenantDatabaseName = contosoconcerthall.

  4. Чтобы выполнить скрипт, нажмите клавишу F5.

  5. На портале Azure перейдите к списку баз данных на сервере tenants1-dpt-<пользователь>.

  6. Щелкните базу данных contosoconcerthall.

  7. Щелкните пул, в котором содержится contosoconcerthall. Пул можно найти в разделе Эластичный пул.

  8. Проверьте диаграмму Наблюдение за пулами эластичных БД и найдите показатели использования eDTU пула с более высокой нагрузкой. Через минуту или две должна начать расти нагрузка, а вы должны увидеть, что пул достигает порогового значения использования.

  9. Проверьте экран Наблюдение за эластичными базами данных. На нем показаны наиболее активные базы данных за последний час. База данных contosoconcerthall также должна появиться в этом списке.

  10. Щелкните диаграммуНаблюдение за эластичными базами данных. После этого откроется страница Использование ресурсов базы данных, где вы можете просмотреть сведения о любой базе данных. Так вы можете просмотреть сведения для базы данных contosoconcerthall.

  11. В списке баз данных щелкните contosoconcerthall.

  12. Выберите Ценовая категория (единицы DTU масштабирования), чтобы открыть страницу Настройка производительности, на которой можно настроить индивидуальный объем вычислительных ресурсов для базы данных.

  13. Перейдите на вкладку Стандартный, чтобы открыть параметры масштабирования на уровне "Стандартный".

  14. Установите ползунок DTU в положение 100 единиц DTU. Обратите внимание, что это соответствует цели обслуживания S3.

  15. Щелкните Применить, чтобы изъять базу данных из пула и назначить ей уровень Стандартный S3.

  16. После масштабирования просмотрите показатели базы данных contosoconcerthall и эластичного пула Pool1 в соответствующих колонках.

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

Другие шаблоны управления производительностью

Упреждающее масштабирование. В упражнении выше показано, как масштабировать изолированную базу данных. При увеличении объема продаж билетов в приложении Wingtips базу данных Contoso Concert Hall можно заранее изъять из пула. В противном случае можно реализовать отправку оповещений, чтобы определять активность в пуле или базе данных. Вы не хотите узнать об этом от других клиентов в пуле, жалуясь на снижение производительности. Если клиент может предсказать, как долго ему потребуются дополнительные ресурсы, вы можете настроить модуль runbook службы автоматизации Azure, чтобы изъять базу данных из пула, а затем вернуть ее по заданному расписанию.

Самостоятельное масштабирование клиента. Масштабирование легко выполняется через API управления. Вы можете легко реализовать масштабирование баз данных клиента в приложении клиента и предоставить эту возможность как компонент службы SaaS. Например, позвольте клиентам самостоятельно выполнять масштабирование, что позволит напрямую снизить расходы.

Масштабирование пула по расписанию в соответствии с шаблонами использования

Если показатель общего использования клиента можно спрогнозировать, реализуйте масштабирование по расписанию с помощью службы автоматизации Azure. Например, после 18:00 масштаб пула можно уменьшить, а в рабочие дни в 06:00 обратно увеличить.

Дальнейшие действия

Из этого руководства вы узнаете, как выполнить следующие задачи:

  • Моделирование использования ресурсов в базах данных клиентов с помощью предоставленного генератора нагрузки.
  • Наблюдение за реакцией баз данных клиентов при увеличении нагрузки.
  • Увеличение масштаба эластичного пула из-за роста нагрузки на базу данных.
  • Подготовка второго эластичного пула для балансировки нагрузки базы данных.

Restore a single tenant database (Восстановление базы данных отдельного клиента)

Дополнительные ресурсы