Azure SQLDB Basic, Standard and Premium Tiers – Quick glimpse and first impressions – Russian version


В прошлой статье мы рассмотрели общие (и местами продвинутые) моменты, которые могут стать решающими в процессе выбора между размещением SQL Server как PaaS и размещением его на виртуальной машине. Эта статья является переводом статьи зарубежного коллеги Igor Pagliai "Azure SQLDB Basic, Standard and Premium Tiers - Quick glimpse and first impressions". В ней мы углубимся в то, что собой представляют новые режимы работы Microsoft Azure SQL Database.

Резюмируем прошлую статью:

Выбираем SQL Server на ВМ, если:

Необходима полная совместимость с функциональностью локального SQL Server

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

Необходимы гибкие средства контроля над низлежащей инфраструктурой

Выбираем Microsoft Azure SQL Databases, если:

Создается совершенно новое приложение

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

Как следствие прошлого пункта, хочется полностью сконцентрироваться на самом проекте

Устраивает уровень контроля, в который не входит низлежащая инфраструктура

Перейдем к статье.

Azure SQL Database - новые режимы

http://blogs.msdn.com/b/windowsazure/archive/2014/04/24/azure-sql-database-introduces-new-service-tiers.aspx

После прочтения статьи по ссылке выше очевидно бросаются в глаза две вещи - предсказуемая производительность и усовершенствованная высокая доступность + отказоустойчивость. В моем топ-листе "что хочется больше всего", выстроенном по мотивам опыта работы с ISV, анонсированная функциональность предполагает решение самых приоритетных вещей. Однако, для конечного пользователя, что изменилось по сравнению с традиционными режимами Web/Business? В этом контексте нужно рассмотреть три аспекта - стоимость, производительность и HA&DR. Давайте начнем с таблицы.

Примечание: если вы использовали Premium раньше и удивлены отсутствием уровня P4, не волнуйтесь - P4 был переименован в P3.

Стоимость

С анонсом режимов Basic, Standard и Premium биллинг Azure SQL DB концептуально сместились из модели за-объем к модели, компонентами которой являются различные уровни гарантированной производительности и HA&DR. Пример: с Web/Business факт наличия 100 баз данных по 1 Гб был сравним факту наличия одной большой базы на 100Гб с позиции стоимости. В новых режимах ситуация другая - вы платите за возможности базы, которые тоже включают, но не ограничиваются, максимальный размер базы. За последние два года я видел много партнеров и клиентов, использовавших мультитенантность и шардинг на базисе 1 БД <=> 1 Тенант, сейчас же необходимо переключиться на новый концептуальный подход - после решения использовать какой-то конкретный режим, например, Standard, для оптимизации стоимости вам нужно собрать вместе максимально возможный размер данных (тенантов, пользователей) для того, чтобы достичь максимального размера БД в 250 Гб (конечно, если решение позволяет такое сделать). Все это отражено на официальной странице с ценами для Azure SQL DB: 

http://azure.microsoft.com/en-us/pricing/details/sql-database/#basic-standard-and-premium

После изучения этой странице я заметил интересную штуку относительно биллинга, которая специфична не для Azure SQL DB, но для Azure в целом:

Зачем этот выбор регионов? Я выяснил, что сейчас стоимость Azure может варьироваться в зависимости от региона, в котором размещаются ваши ресурсы. По этому поводу возникает несколько интересных соображений. Перейдем к соображениям по поводу стоимости. Если внимательно посмотреть на стоимость Premium, вы можете удивиться цене. Если думаете, что она слишком высока, особенно в сравнении с SQL Server на виртуальной машине, оцените ниженаписанное и подумайте еще раз:

  • Каждая БД в Azure SQL DB реплицируется три раза для обеспечения высокой доступности и отказоустойчивости. Реплики располагаются в одном датацентре, но оплачивается только одна.
  • Если размещать SQL Server на виртуальной машине в конфигурации HA, надо создать как минимум 3 виртуальных машины для группы доступности AlwaysOn + две виртуальных машины для Active Directory.
  • Каждая база Azure SQL DB автоматически резервируется до 35 дней (зависит от режима), при этом хранилище бесплатно, тогда как в IaaS все это обеспечить надо самому.
  • В Azure SQL DB не надо тратиться на управления, Azure сама позаботится практически обо всем.
  • На данный момент нет возможности сделать группу доступности AlwaysOn и поместить в нее ресурсы в нескольких датацентрах.
  • Развернуть уже готовую инфраструктуру с Azure SQL DB можно за несколько минут, тогда как ручная настройка AlwaysOn займет часы и потребует специальных знаний.

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

Производительность

Первый вопрос, который может возникнуть, особенно если уже есть база в режиме Web/Business, это насколько производительнее новые режимы? Что здесь важно - это не вычислительная мощность новых режимов, но тот факт, что у вас теперь есть гарантия получения определенного уровня ресурсов и производительности, которой не было раньше. Я общался с несколькими партнерами и обнаружил общее недопонимание, поэтому давайте разберемся в этом вопросе, так как я считаю это важным. Сначала посмотрим на сессии и потоки, описание которых приведено по ссылке.

Azure SQL Database Resource Governance

http://msdn.microsoft.com/en-us/library/azure/dn338078.aspx

Как можно увидеть в статье, в режимах Web/Premium максимальное количество параллельных запросов равно 180, если же превышаем это количество, то получаем ошибку 10928 - ключевое здесь то, что 180 является максимумом, но, если система слишком загружена, по факту вы можете иметь это значение, но в виде НУЛЯ. Другими словами, здесь нет гарантии предоставления ресурсов, и по этой причине новые режимы ведут себя иначе - теперь вы можете использовать то количество ресурсов, которое гарантируется режимом, то есть Минимум = Максимум. Важным последствием нового подхода к управлению ресурсами является то, что ваш проект теперь будет иметь более предсказуемый уровень производительности, более устойчивое выполнение запросов и время ответа.

Уровни производительности - новая концепция, которая была введена в Azure SQL DB для решения проблемы пользователей №1 - возможности иметь предсказуемый уровень производительности, таким образом минимизируя факт работы в мультитенантной среде, где надо делиться ресурсами с соседями. Ниже - таблица с описанием того, что эти режимы нам предлагают (http://msdn.microsoft.com/library/azure/dn741336.aspx):

В таблице отсутствует очень интересный момент - данные о памяти, CPU и IOPS. Можно, конечно, подумать, что их забыли, но есть другое объяснение, которое не подкреплено официальными заявлениями, но выглядящее для меня интересным. Если бы даже они и были, то, когда мы создали бы новую базу Azure SQL DB используя режим Premium, мы бы увидели, что уровень оперирует термином DTU, и больше ничем.

По ссылке ниже написано, что DTU расшифровывается как “Database Throughput Units”, и это хороший способ, на мой взгляд, абстрагировать производительность базы данных от низлежащей инфраструктуры Azure SQL DB. Если даже в будущем эта низлежащая инфраструктура изменится, уровень производительности, выделенный вам, останется прежнем, и будет выражаться в логической единице, измеряющей то, что нам действительно важно - транзакциях, а не том, как много CPU/RAM будет иметь наш сервер.

Azure SQL Database Benchmark Overview

http://msdn.microsoft.com/en-us/library/azure/dn741327.aspx

В качестве последнего утверждения о производительности я приведу данные о том, как в новых режимах измеряется Performance SLA:

  • Basic: предназначен для приложений с небольшими транзакционными требованиями. Производительность исходит из предсказуемой часовой нагрузки.
  • Standard: предназначен для бизнес-приложений в облаке. Средний уровень производительности и бизнес-функциональности. Исходит из предсказуемой минутной нагрузки. 
  • Premium: предназначен для критичных баз. Premium предоставляет наибольший уровень гарантированной производительности и доступ к продвинутым функциям системы. Исходит из секундной нагрузки.

С Premium можно иметь базу данных размером до 500GB.

HA&DR

Позвольте сначала представить новый SLA в 99.95% для всех новых режимов. Небольшое, на первый взгляд, увеличение этого показателя очень важно для достижения уровня HA SLA, предлагаемого конкурентами, и выравнивания уровня SLA с другими сервисами Azure. Лично я надеюсь, что в будущем Azure Storage пойдет по той же дороге и увеличит свой SLA, который сейчас равен 99.90%. Очень важной функцией новых режимов является возможность самовосстановления базы данных, которое можно сделать с портала, Powershell или с помощью API.

Azure SQL Database Backup and Restore

http://msdn.microsoft.com/en-us/library/azure/jj650016.aspx

Обратите внимание на две важных вещи - у всех режимов разные retention-периоды - это раз. И два - только Standard/Premium дают функцию восстановления point-in-time, с Basic же инкрементального резервирования нет, поэтому есть возможность восстановиться только на последнюю полную копию. Еще я заметил интересную вещь - всегда, когда тестируешь что-то новое, начинаешь замечать интересные функции:

С этой функцией можно восстанавливать удаленные таблицы бесплатно, то есть такой аналог Корзины. Я опишу подробнее эту функцию потом, но сейчас надо уточнить, что можно восстанавливать конкретную точку в зависимости от режима:

Последняя новая, и очень важная, функция в HA&DR - активная георепликация. 

Active Geo-Replication for Azure SQL Database

http://msdn.microsoft.com/en-us/library/azure/dn741339.aspx

Теперь у вас есть возможность асинхронно реплицировать транзакции одной базы на другую, в другом экземпляре или даже датацентре - хорошо здесь наличие гарантии RPO < 5 минут, но помните, что эта функция доступна только в Premium. Она очень полезна не только для обеспечения отказоустойчивости, но и разгрузки Read-Only операций, так как можно иметь до 4 вторичных реплик. Кроме этого, надо учитывать, что за вторичные реплики надо платить. Автоматический failover недоступен, так как эта функция обеспечивает DR, но не HA.

Резюме

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

  • Я очень рад, что клиенты с платным уровнем техподдержки Azure и Premier Support теперь могут получить поддержку для Azure SQL DB в preview - Basic, Standard и Premium. Приятно видеть, что политика изменилась, теперь клиенты могут использовать обновленные сервисы сразу же с нормальной поддержкой, но все же надо понимать, что нет гарантии SLA до официального релизма.
  • Эластичность - краеугольный камень в любом облачном сервисе, и в Azure SQL DB у вас есть возможность переходить из одного режима в другой, но будьте аккуратны - время на эту операцию может повлиять на производительность, если база в production. Кроме этого изменение режима может потребовать перенос внутренней копии вашей базы с одного сервера на другой, и здесь уже нет SLA на то, сколько это может занять.
  • Во время моих тестов я сразу обратил внимание, что есть ограничение на количество изменений режимов в день - режим можно поменять до 4 раз в день, но Web/Business не считаются.
  • Оценка стоимости происходит раз в день на одну базу, в зависимости от того, какой старший режим использовался - это означает, что, если вы за день переключились с Basic на Premium P1, то оценка стоимости будет произведена на основе Premium P1, но не обоих режимов.
  • По умолчанию на один экземпляр Azure SQL DB есть лимит на две базы данных, но, как вы видите ниже, можно поднять запрос в техподдержку и увеличить этот лимит.

В конце давайте расскажу про будущее Web/Business - поддержка этих режимов будет отключена через год после 24 апреля 2014. Подробнее по ссылке ниже.

Web and Business Edition Sunset FAQ

http://msdn.microsoft.com/library/azure/dn741330.aspx

По этой ссылке также важная информация по отказу от поддержки сервиса федераций: 

The current implementation of Federations will be retired with Web and Business edition

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

Igor Pagliai,

Twitter автора (@igorpag).

Skip to main content