| Новые программы oszone.net |  |
В прошлой статье мы рассмотрели общие (и местами продвинутые) моменты, которые могут стать решающими в процессе выбора между размещением SQL Server как PaaS и размещением его на виртуальной машине. Эта статья является переводом статьи зарубежного коллеги Igor Pagliai "Azure SQLDB Basic, Standard and Premium Tiers - Quick glimpse and first impressions". В ней мы углубимся в то, что собой представляют новые режимы работы Microsoft Azure SQL Database. Резюмируем прошлую статью: Выбираем 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 на виртуальной машине, оцените ниженаписанное и подумайте еще раз:
В случае режима 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:
С 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. Резюме За период использования новых режимов у меня скопилось несколько интересных наблюдений:
В конце давайте расскажу про будущее Web/Business - поддержка этих режимов будет отключена через год после 24 апреля 2014. Подробнее по ссылке ниже. Web and Business Edition Sunset FAQ
Теги:
SQL Database Premium.
Комментарии посетителей
Комментарии отключены. С вопросами по статьям обращайтесь в форум.
|
|
