В прошлой статье мы рассмотрели общие (и местами продвинутые) моменты, которые могут стать решающими в процессе выбора между размещением 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 - новые режимы
После прочтения статьи по ссылке выше очевидно бросаются в глаза две вещи - предсказуемая производительность и усовершенствованная высокая доступность + отказоустойчивость. В моем топ-листе "что хочется больше всего", выстроенном по мотивам опыта работы с 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