Модели ценообразования и уровни обслуживания Azure

Tags: Azure

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

Есть две модели ценообразования, предлагаемые базой данных Azure. Поскольку модель ценообразования, основанная на DTU, используется в настоящее время, а модель ценообразования на основе V-Core находится в предварительном просмотре, в этой статье мы обсудим, как работает в Azure  модель ценообразования на основе DTU и охватим следующие темы:

1) Модель ценообразования на основе DTU

2) Уровни обслуживания по модели ценообразования на основе DTU и ее влияние на производительность приложений

2) Что такое DTU?

3) вычисление необходимых DTU с использованием DTU Calculator

Модель ценообразования на основе DTU:

Что такое DTU?

DTU или единица транзакций базы данных может быть определена как смешанная мера таких ресурсов, как память, CPU, Data IO, Log IO, которые будут доступны для базы данных Azure с определенным уровнем производительности. Это просто определяется, насколько мощна ваша база данных Azure и используется как единица сравнения. Чем выше DTU, тем выше производительность.

Пример:

Например, если 5 DTU занимает 100 секунд для выполнения 15 запросов, тогда 100 DTU займут 5 секунд для решения этих 15 запросов.

Различные уровни обслуживания в базовой модели ценообразования DTU:

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

 

Уровни обслуживания Azure

Мы можем дифференцировать эти 3 уровня обслуживания на основе приведенных ниже характеристик:

  • Размер - ограничение размера для базы данных Azure
  • Производительность - количество доступных DTU
  • Восстановление - количество дней для выполнения восстановления до определенного момента времени
  • Параллельность - количество попыток входа в систему / рабочие темы / параллельные сеансы
  • Дополнительные функции - количество возможностей, доступных только в классах высокого уровня обслуживания, таких как индексы OLTP и ColumnStore в памяти

Краткие характеристики ServiceTiers

 

Basic

Standard

Premium

Максимальный размер хранилища

2 GB

1 TB

4 TB

Максимальное число DTU

5

3000

4000

Восстановление по времени

7 дня

35 дня

35 дня

Ошибки входа

30

60 - 200

200 - 6400

Рабочие темы

30

60 - 200

200 - 6400

Сеансы

300

600 - 2400

2400 - 32000

OLTP внутри памяти

Не поддерживается

N/A

Поддерживается

Индексирование столбцов

Не поддерживается

S3 и выше

Поддерживается

 

Уровни Standard Service Tier

В Standard Service Tier, в зависимости от количества DTU, мы имеем различный уровень, начиная с S0 до S12. Это означает, что выше уровень, DTU и производительность.

 

Уровни

S0

S1

S2

S3

S4

S6

S7

S9

S12

Число DTU

10

20

50

100

200

400

800

1600

3000

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

Предел размера Standard Service Tier

Уровни Premium Service Tier

Также в Premium Service Tier в зависимости от количества DTU, мы имеем различный уровень, начиная с P1 до P15, которые приведены ниже:

 

Уровни

P1

P2

P4

P6

P11

P15

Число DTU

125

250

500

1000

1750

4000

Размер в GB

500

500

500

500

4000

4000

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

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

Обратите внимание: если вы обновите базу данных до более, чем 1 ТБ, вы не сможете понизить эту базу данных до 1 ТБ или ниже или до уровня производительности ниже P11. Вы не сможете добавить эту базу данных в эластичный бассейн. Использование восстановления, копирования или гео-репликации потребует более 1 ТБ памяти с уровнем производительности P11 или P15.

Калькулятор DTU

После того, как мы получили представление о DTU и уровнях обслуживания, возникает следующий вопрос: как узнать количество DTU, необходимое при миграции нашей базы данных SQL на Azure, потому что это, в конечном счете, поможет вам выбрать правильный уровень обслуживания. Чтобы помочь нам, у нас есть калькулятор DTU на http://dtucalculator.azurewebsites.net. Этот калькулятор DTU был разработан Джастином Хенриксеном, архитектором решений Azure в Microsoft.

Как работает калькулятор DTU:

Рабочий поток калькулятора DTU

 Как вы видели в приведенном выше рабочем потоке, чтобы узнать самое точное использование ресурсов нашей базы данных, нам сначала нужно убрать ниже упомянутые показатели использования на нашем SQL Server. Для получения правильных показателей производительности мы можем использовать одну из утилит: Command Line EXE или PowerShell Script. Эти утилиты можно загрузить с веб-сайта калькулятора DTU. Нам нужно взять репрезентативную рабочую нагрузку для получения наилучшего результата, который может потребоваться для запуска этих утилит, по крайней мере, от нескольких часов до нескольких дней.

  • Процессор -% Время процессора
  • Логический диск - Чтение дисков / сек.
  • Логический диск - Запись дисков / сек.
  • База данных - Лог-байты Сброс / сек

Когда мы загружаем утилиту командной строки и разархивируем ее, мы получили указанные ниже 2 файла:

Файлы служебной программы командной строки

Теперь, если вы откроете конфигурацию файла SqlDtuPerfmon.exe, вам, возможно, нужно будет позаботиться о выделенных ниже разделах и изменить их значение в соответствии с вашими потребностями.

Файл конфигурации - SqlDtuPerfmon.exe

1) В первом выделенном разделе с ключом как «SqlCategory», если вы не измените значение и выполните утилиту в имеющемся виде, она будет работать, если ваш экземпляр SQL-сервера является стандартным. Если экземпляр SQL Server является именованным экземпляром, вам необходимо изменить его значение. Также эта утилита работает на уровне экземпляра SQL не на уровне базы данных. Для конкретной базы данных SQL вам необходимо использовать другие DMV для записи этих данных.

Например, предположим, что мое имя экземпляра SQL - это DEV2K16, тогда мы получим значение, показанное ниже

<add key=”SqlCategory” value=”MSSQL$DEV2K16:Databases”/>

2) Во втором выделенном разделе значение 3600 представляет собой количество секунд, которое эта утилита будет запускаться для захвата репрезентативной рабочей нагрузки. По умолчанию это 1 час или 3600 секунд. Вы можете увеличить значение, согласно вашему требованию. Но убедитесь, что он работал достаточно долго, чтобы зафиксировать правильную репрезентативную рабочую нагрузку.

 

3) В третьем выделенном разделе значение представляет собой местоположение на сервере, где CSV-файл, содержащий вывод трассировки, будет сохранен. Убедитесь, что у пользователя есть необходимое разрешение для записи файла в этом месте или вы можете изменить его в другом месте.

Инструкции по выполнению файла утилиты упоминаются на веб-сайте DTUcalculator. Вы

  • Перед запуском утилиты / скрипта убедитесь, что никакие процессы, кроме SQL, не используют процессор, память и диск.
  • Нажмите ссылку и загрузите zip-файл на свой SQL-сервер и извлеките содержимое.
  • Если вы используете утилиту командной строки, щелкните правой кнопкой мыши файл .exe и выберите «Запуск от имени администратора»
  • Если вы используете сценарий PowerShell, перейдите в Windows PowerShell ISE и щелкните правой кнопкой по «Запуск от имени администратора». В Windows PowerShell ISE перейдите к файлу сценария sql-perfmon.ps1 и нажмите «F5», чтобы запустить скрипт.

Инструкция для выполнения Utility файлов

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

 

Выходные данные выполнения служебных файлов

После того как вы выполнили выполнение утилиты, вам необходимо загрузить файл CSV на сайт калькулятора DTU и нажать кнопку «Вычислить».

После анализа трассировки производительности калькулятор DTU дает результат, как показано на приведенных ниже скриншотах

 

Уровень Service Tier/Performance

 

Основываясь на использовании базы данных, мы рекомендуем перенаправить рабочую нагрузку SQL Server на Standart-S2. Этот уровень Service Tier/Performance должен покрывать приблизительно 96,97% вашего использования.

Примечание. Около 3,03% рабочей нагрузки приходится на более высокий уровень Service Tier/Performance. После переноса базы данных на Azure, вы должны оценить производительность своей базы данных, используя руководство, упомянутое в разделе информации выше.

На приведенном рисунке калькулятор DTU дает общую рекомендацию. Это интерактивная диаграмма, в которой вы можете перемещать мышь по различным секциям и видеть, сколько процентов выбранный уровень обслуживания может покрыть. Здесь, когда я перемещаю свой курсор в раздел S2, он показывает, что он будет охватывать 96,97% моей рабочей нагрузки.

 

DTU по времени

Если мы прокрутим вниз, мы увидим приведенную выше диаграмму, где в основном DTU меньше 50, но есть некоторые DTU, которые касаются отметки 125. Здесь я запускаю утилиту на несколько минут только для демонстрационной цели. Из-за этого значения времени имеют диапазон 0-1100 вместо 0-3600.

Ниже диаграммы есть ссылка View More details. Если мы нажмем на эту ссылку, она покажет рекомендации уровня обслуживания для разных ресурсов, таких как CPU, Iops & Log, как показано на скриншотах ниже. Все эти диаграммы являются интерактивными, где мы можем перейти к разным разделам уровня обслуживания и посмотреть, какова степень использования ресурсов, которую этот уровень будет охватывать.

 

Уровень Service Tier/Performance для CPU

Основываясь исключительно на использовании CPU, мы рекомендуем перенаправить рабочую нагрузку на SQL Server в Standart-S2. Этот уровень Service Tier/Performance  должен покрывать приблизительно 98,75% вашего использования.

Примечание. Около 1,25% рабочей нагрузки приходится на более высокий уровень Service Tier/Performance. После переноса базы данных на Azure, вы должны оценить производительность своей базы данных, используя руководство, упомянутое в разделе информации выше.

Уровень Service Tier/Performance для lops

Основываясь исключительно на использовании  lops, мы рекомендуем перенаправить рабочую нагрузку на SQL Server в Standart-S0. Этот уровень Service Tier/Performance  должен покрывать приблизительно 90,11% вашего использования.

Примечание. Около 9,89% рабочей нагрузки приходится на более высокий уровень Service Tier/Performance. После переноса базы данных на Azure, вы должны оценить производительность своей базы данных, используя руководство, упомянутое в разделе информации выше.

Уровень Service Tier/Performance для Log

Основываясь исключительно на использовании Log, мы рекомендуем перенаправить рабочую нагрузку на SQL Server в Basic. Этот уровень Service Tier/Performance  должен покрывать приблизительно 100% вашего использования.

Уровень Service Tier/Performance для CPU, lops и Log

Основываясь на использовании CPU, lops и Log, мы рекомендуем перенаправить рабочую нагрузку на SQL Server в Standart-S2. Этот уровень Service Tier/Performance  должен покрывать приблизительно 98,75% вашего использования CPU, 98,04% вашего использования lops, 100% вашего использования  Log.

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

Как вы видели на рисунке выше, вы можете навести указатель мыши на диаграмму, чтобы узнать, какой уровень обслуживания будет охватывать большинство требований. Здесь, если мы перейдем к стандарту-S2, мы увидим, что этот уровень обслуживания / уровень производительности покрывает большинство требований как 98,75% от CPU, 98,04% от IOP и 100,00% от использования Log.

Вывод:

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

  1. Модель ценообразования на основе DTU
  2. Модель ценообразования на основе vCore (в режиме предварительного просмотра)

В этой статье мы подробно обсудили модель ценообразования на основе DTU, а также различные уровни обслуживания, которые входят в эту модель цены. Здесь также содержится информация об уровне значения Standard Service Tier и Premium Service Tier. Также в этой статье представлена информация о ресурсах, которые Azure предлагает в этих категориях обслуживания и которые влияют на производительность приложений.

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

No Comments

Add a Comment