Путь к размещению SQL Server в любом облаке, будь это Microsoft или другое, должен начинаться с тщательного планирования. Архитектурные решения, принятые на ранней стадии проекта, могут совершенно неожиданным образом повлиять на будущее проекта, причем не всегда это могут быть очевидно-решаемые проблемы. Планирование также включает в себя решение о том, в какой модели должен размещаться SQL Server — в модели IaaS (на виртуальной машине) или в модели PaaS (как SQL Azure DB). Разница между моделями заключается как в особенностях технологического плана, так и ценового, например уровни соглашения об обслуживании (SLA) обеих моделей, влияние латентности как на ранней стадии, так и на стадии выхода проекта в свет, автоматизации и многого другого.

В этой статье мы попробуем разобраться не только в том, какие технологические различия есть между IaaS и PaaS в Microsoft Azure, но и том, откуда может такая разница возникать, откуда могут возникать проблемы в PaaS, которых можно и не встретить в IaaS, и архитектуре этих решений, а также о том, что такое Azure SQL DB Premium и когда его нужно использовать.

Оглавление:
Выбираем между IaaS и Azure SQL DB
IaaS Way: общее описание и архитектура
PaaS Way: общее описание, архитектура и возможные проблемы
PaaS Way: безопасность
Azure SQL DB SLA — в чем различие от SLA SQL Server на виртуальной машине?
PaaS Way: High Availabiliy
Как выбрать режим использования Azure SQL DB? Уровень Premium — гарантия высокой производительности SQL Server как сервиса

Выбираем между IaaS и Azure SQL DB (PaaS)

В любом решении, управляющем данными с помощью платформы SQL Server, есть три варианта размещения этой платформы:
Локально, в собственной инфраструктуре
На виртуальной машине Azure (IaaS)
Как сервиса (Azure SQL DB)

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

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

В случае миграции перед нами возникает развилка — поскольку Azure SQL DB по функциональности местами сильно отличается от полноценного SQL Server, мы должны проанализировать нашу кодовую базу и базу данных и понять, потребуются ли изменения и насколько они критичны. Это очень важная развилка — если мы упустим тип данных, неподдерживаемый Azure SQL DB, то потеряем много времени и сил. С базами данных нам может помочь sqlazuremw.codeplex.com, который может проанализировать базу и сказать, что из нее не поддерживается в Azure SQL DB. И, если на этом шаге появится необходимость вносить серьезные изменения в наше решение, либо будет функциональность, которая не поддерживается в Azure SQL DB, но нужна нам, то дерево решения на этом обрывается и нам нужно использовать локальный SQL Server либо ставить его на виртуальную машину (IaaS).

Если же мы разрабатываем новое решение или имеем возможность внести некритичные изменения в мигрируемый проект, то следующий вопрос, встающий перед нами — это лимит на размер базу данных в Azure SQL DB, который равен 500 Гб. Достаточно ли этого нам? Каков будет прогнозируемый рост? Если мы понимаем, что не пробьем этот потолок, то можем смело использовать Azure SQL DB. Если понимаем, что когда-нибудь может возникнуть ситуация, в которой у нас будет 501 Гб, переходим на следующий шаг.

Можно ли перепроектировать архитектуру или реализовать шардинг собственными силами? Бывают ситуации и проекты, когда этого сделать нельзя — по разным причинам, от legacy-кода до проблем со временем. В Azure SQL DB нет механизма встроенного шардинга, поэтому его реализация ложится на плечи клиента. Если мы готовы взяться за это — то ничего не мешает нам использовать Azure SQL DB. Если нет — мы снова выходим на SQL Server на виртуальной машине или локально.

Посмотрим на различия и архитектуру обоих решений.

IaaS Way

Метод размещения SQL Server в виртуальной машине принципиально не отличается от установки его локально, однако дьявол кроется в мелочах, и мелочах, касающихся сложной дисциплины — оптимизации. Тезисно:

На виртуальную машину мы можем поставить полноценный SQL Server. Слово «полноценный» здесь важно, так как между SQL Server и Azure SQL DB, несмотря на общих родителей, существуют функциональные различия;
Образ виртуальной машины лежит на Microsoft Azure Storage, что накладывает ограничения оптимизационного характера — для того, чтобы повысить производительность дисков, нужно, например, объединить их в рейд. Виртуальная машина в Microsoft Azure по умолчанию не имеет дисков, которые можно объединить в рейд — при создании она получает два диска, причем один диск (D:) является временным, так как размещается на диске сервера, на котором в данный момент запущена машина, а второй (C:) размещается в виде блоба на Microsoft Azure Storage, и все I/O запросы идут через кэширующую прослойку. По этой причине производительность C: будет всегда меньше, чем D:, однако D: будет очищаться при каждой системной операции с виртуальной машине (в связи с переносом на другие физические ресурсы). Для создания рейда надо создать и подключить пустые диски данных (на портале, Powershell и много чем еще) к машине.

В Microsoft Azure уже доступны готовые оптимизированные образы SQL Server (2008 R2 — 2014), которые можно использовать как с отдельно оплачиваемой лицензией, так и принеся свою лицензию (по License Mobility & Software Assurance).
Стандартизированное железо. В любом облаке вы получаете стандартизированное оборудование, и необходимо понимать, что оно чаще всего не имеет высокой настроенной производительности.

PaaS Way

PaaS-подход разительно отличается от IaaS наличием большего количества абстракций разработчика от инфраструктуры, ограничений и архитектурных изысков. В самом низу, на уровне инфраструктуры и оборудования, это, разумеется, то же самое стандартизированное оборудование, поэтому если использовать Shared-режим Azure SQL DB, то при наличии беспокойных соседей производительность может просесть совершенно неожиданным образом. В наличии также набор Soft/Hard ограничений, что сделано с понятной целью — если SQL Server на виртуальной машине администрируем мы, и с проблемами производительности и архитектуры разбираемся, в целом, опять же мы, то PaaS полностью управляется вендором, и необходимо сделать так, чтобы решение было высокомасштабируемым и отказоустойчивым, и беспокойные пользователи с большой сезонной нагрузкой не положили что-нибудь инфраструктурное.

При этом, как уже упоминалось выше, шардинг и прочие решения должны быть выполнены разработчиком — встроенных средств в Azure SQL DB пока нет.

Для того, чтобы лучше понять, что такое Azure SQL DB и как он работает, рассмотрим его архитектуру.

Первое, что нужно понимать — когда мы создаем сервер Azure SQL DB, на самом деле создается три сервера, которые, в общем-то, серверами и не являются вовсе — это реплики, запрос от клиента к которым проходит через точку входа TDS. Если сравнивать с традиционным решением, то в случае его IP сервера у нас ведет на сервер, в случае же Azure SQL DB — IP ведет на инфраструктуру.

Запрос отправляется по TDS в сервисный слой. Сервисный слой — это шлюз между клиентом и слоем платформенным, и здесь размещаются высокоуровневые сервисы обслуживания нашего Azure SQL DB — развертывание ресурсов, биллинг потребленных ресурсов, маршрутизатор запросов, и многое другое.

Дальше запрос маршрутизируется на платформенный слой, на котором работают инфраструктурные сервисы — то, что обеспечивает уже непосредственную функциональность SQL Server как сервиса. Это — последний слой абстракции над инфраструктурой, ниже — только оборудование.
Как видно из картинки, архитектура решения Azure SQL DB гораздо сложнее, нежели размещение SQL Server на виртуальной машине. На каждом слое также работает балансировка нагрузки и репликация, и все это работает в автоматическом режиме без участия человека.
С подобной архитектурой подход к решению возникающих проблем некоторым образом отличается от того, к чему мы уже привыкли. Средств для диагностики меньше, поэтому важно понимать, из-за чего возникает та или иная проблема. Если говорить о самых распространенных проблемах, то причины их возникновения можно разместить на слоях Azure SQL DB. Первый уровень проблем возникает уже на уровне TDS-коммуникаций. Здесь мы имеем большую латентность, нежели она наличествует в локальном развертывании, и различного рода флуктуации — в основном возникающие еще перед входом в инфраструктуру Azure SQL DB, то есть на сетевых магистралях, к Microsoft не относящихся. Этот момент важен, так как запрос может вернуться с таймаутом, и это нужно покрывать разработкой и планированием retry logic.

Когда запрос уже пришел в инфраструктуру, он проверяется внутренними средствами, и логин проходит через один шлюз вместе с другими запросами на это оборудование. Дальше открывается подключение, однако тут тоже может возникнуть таймаут, если операция не будет выполнена вовремя — и это тоже должно решаться retry logic.
Во время работы самого Azure SQL DB есть постоянная вероятность возникновения проблем на уровне платформенного слоя — как раз здесь действуют все ограничения, накладываемые вендором на Azure SQL DB, и, в случае их превышения, клиенту будет возвращена соответствующая ошибка. Здесь мы ничего поделать не можем, единственный вариант — обрабатывать эти ошибки на стороне клиента (список ошибок — msdn.microsoft.com/en-us/library/ff394106.aspx).
Резюмируя использование Azure SQL DB, мы должны понимать и обрабатывать следующие ситуации:

Клиент не должен быть далеко от Azure SQL DB в терминах географии. Если клиент расположен у нас локально, мы должны понимать, что у нас будут постоянные флуктуации сетевых магистралей, и реализовывать соответствующую обработку этих флуктуаций и ситуаций с возникновением ошибок по таймауту. Хорошим вариантом видится размещения клиента в облаке максимально рядом с Azure SQL DB.
В Azure SQL DB есть ограничения, которые введены не просто так. Если мы хотим комфортно работать, мы должны не брать сколько дают, а брать сколько нам надо, и учитывать, что connection pool не резиновый.
Особенности мультитенантности. Нигде нам не дадут гарантий по производительности, где ресурсы разделяются между клиентами. Здесь в случае Azure SQL DB возникает режим Premium, в котором нам дают зарезервированные ресурсы, которыми мы можем свободно пользоваться и быть уверенными, что их никто не заберет, если они будут стоять неиспользуемыми.

Мы посмотрели на то, как отличается архитектура нашего PaaS-решения от IaaS-решения. Как уже упоминалось, архитектура PaaS является более сложной технологически, так как клиенту должна обеспечиваться отказоустойчивость, быстрое развертывание и много другого в автоматическом режиме, и при этом надо закладываться на большое количество клиентов. Однако с усложнением архитектуры приходят также и более сложная диагностика проблем, ограничения и различия со стандартным SQL Server.
Давайте теперь посмотрим на еще один важный аспект — безопасность Azure SQL DB. Про безопасность виртуальных машин, а, значит, и SQL Server в них, написано здесь: blogs.msdn.com/b/albe/archive/2014/04/21/azure.aspx

PaaS Way: безопасность

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

Как уже было написано, SQL Azure Databases использует стандартный протокол SQL Server Tabular Data Stream (TDS), но разрешены исключительно шифрованные коммуникации. В SQL Server 2008 было введено новое средство: прозрачное шифрование данных (transparent data encryption, TDE), позволяющее полностью шифровать данные с минимальными усилиями. Однако на данный момент SQL Azure Databases не поддерживает шифрование на уровне базы данных. Следует заметить, что в настоящее время Azure SQL DB доступен только через TCP-соединения и только через порт 1433. Поэтому необходимо учитывать возможности шифрования ADO.NET и сертификаты. А, например, свойства соединения Encrypt = True и TrustServerCertificate = False обеспечат защиту передаваемых данных и помогут предотвратить атаки «человек посередине» (man-in-the-middle). Второе средство защиты Azure SQL DB, и, в общем-то, основное — брандмауэр Azure SQL DB, которым изначально блокируется весь доступ к серверу. Попытки подключения до соответствующей настройки будут безуспешны. Для начала работы с сервером Azure SQL DB нужно зайти на портал Azure SQL DB и определить настройки брандмауэра для доступа к вашему серверу. Брандмауэром SQL Azure можно управлять через портал Azure SQL DB или напрямую в главной базе данных с помощью хранимых процедур, таких как sp_set_firewall_rule и sp_delete_firewall_rule.

Как и в любой реализации SQL Server, управление пользовательскими учетными записями — еще один аспект, который нужно жестко контролировать.
Между SQL Server и SQL Azure Databases в контексте безопасности существует список различий:
Microsoft SQL Server поддерживает аутентификацию Windows Integrated с использованием параметров доступа из Active Directory; SQL Azure Databases поддерживает только SQL Server Authentication.
Microsoft SQL Server и SQL Azure Databases используют одну модель авторизации на основе пользователей и ролей, создаваемых в каждой базе данных и связываемых с логинами пользователей.
Microsoft SQL Server имеет стандартные роли уровня сервера такие как serveradmin, securityadmin и dbcreator. В SQL Azure Databases этих ролей нет. Вместо этого в SQL Azure Databases есть роль loginmanager (создание логинов) и dbmanager (создание и управление базами данных). Эти роли могут быть привязаны к пользователям в базе данных master.
Доступ к SQL Server и Azure SQL DB происходит по протоколу уровня приложения Tabular Data Stream (TDS), защищённому протоколом SSL, через порт TCP/1433. Использование SSL опционально для Microsoft SQL Server и обязательно для Azure SQL DB.
В SQL Server контроль доступа на основе IP должен быть осуществлен на уровне хоста или сети, с использованием брандмауэров. В Azure SQL DB есть встроенный брандмауэр, ограничивающий весь доступ к серверу Azure SQL DB до определения клиентов компьютеров, имеющих право доступа. Брандмауэр выдает доступ, основываясь на IP-адресе каждого запроса.
SQL Server предоставляет шифрование в режиме реального времени всех хранящихся данных на страничном уровне с использованием функциональности Transparent Data Encryption (TDE). TDE не поддерживается в Azure SQL DB.
В Azure SQL DB есть встроеннная защита от DDOS. В SQL Server таковой нет.
Azure SQL DB автоматически патчится и обновляется без простоев. SQL Server надо обновлять, и это может привести к даунтайму.

Итак, различия в безопасности есть, и их надо предусматривать. Иногда блокером является отсутствие TDE, иногда оно таковым не является — все зависит от решения. А следующим блоком предлагаю посмотреть на различия в SLA.

Azure SQL DB SLA — в чем различие от SLA SQL Server на виртуальной машине?

SLA — обязательная часть любого коммерческого развертывания. SLA на Azure SQL DB является более гранулярным, нежели SLA SQL Server на виртуальной машине, с позиции того, что SLA предоставляется на непосредственно сервис Azure SQL DB, а не на низлежащую инфраструктуру и виртуальную машину (но не SQL Server) в случае IaaS. Это принципиально важно. SLA на Azure SQL DB равен 99.9%, что означает 10 часов даунтайма в календарный год, которые уходят на обслуживание сервиса. Об обслуживании клиентов предупреждают заранее.

PaaS Way: High Availability

Azure SQL DB изначально закладывается под High Availability, и все компоненты архитектуры являются отказоустойчивыми. При этом важно понимать, что стандартные для SQL Servr концепции HA к Azure SQL DB неприменимы (опять же за счет архитектурных различий). Внутри Azure SQL DB есть механизмы, которые реплицируют все записи в три реплики по разным серверам, что обеспечивает 99.9% SLA. При этом одна реплика является первичной — на нее идет операция записи и, если она подтверждается, все реплицируется синхронным образом во вторичные реплики.

Если мы хотим реплицировать Azure SQL DB собственными силами, никто не мешает делать это с помощью, например, Data Sync.

Как выбрать режим работы Azure SQL DB?

Начиная с апреля 2014 года меняются режимы работы Azure SQL DB — отменяются старые режимы Web/Business, основной фокус которых был сконцентрирован вокруг размера базы данных, новые же — Basic/Standard/Premium — сконцентрированы полностью на предоставлении гарантий по производительности. На рисунке изображено простое дерево принятия решения о том, какой из новых режимов в каких условиях использовать. Нужно, однако, понимать, что, несмотря на предоставление некоторого уровня производительности режимами Basic/Standard, режим Premium отличается повышенными значениями всех показателей — начиная от того, что база в режиме Premium может быть до 500 Гб и заканчивая тем, что железных гарантированных ресурсов гораздо больше, нежели в Basic/Standard, поэтому, если вы планируете размещать в Azure SQL DB решение, которое очень требовательно к ресурсам и, прежде всего, к пикам использования, использование режима Premium гораздо более предпочтительно.

Отдельного рассмотрения требует режим Premium. Он предназначен, как уже было сказано, для проектов, которым требуется гарантированная высокая степень производительности. Для того, чтобы оценить эту производительность, был разработан специальный тест Azure SQL Database Benchmark
(делающий подсчеты значений, используемых в различных задачах OLTP. Ресурсы и мощность каждого режима и уровень производительности в Azure SQL DB Benchmark выражается в Database Throughput Units (DTU). DTU предоставляет способ измерения относительного уровня производительности на основе CPU, памяти и операций R/W. Таким образом, удвоение DTU практически означает удвоение мощности ресурса, отведенного под базу. Тест Azure SQL DB Benchmark учитывает еще Transaction Rate, который выражается в транзакциям на один юнит, при этом время сокращается для более мощных режимов (basic — на час, standard — на минуты, и premium позволяет выполнять большое количество параллельных транзакций в секунду), и предсказуемость, или гарантию по времени ответа.
По этому тесту самым мощным режимом является Premium. Так, от самого простого режима Basic, который имеет 1 DTU, Premium уровня P3 имеет 800 DTU, то есть, по факту, является мощнее в 800 раз, при этом увеличивается еще и гарантия производительности.

Подробнее про новые режимы работы Azure SQL DB можно почитать на официальной странице — msdn.microsoft.com/en-US/library/azure/dn741340.aspx

Резюме

SQL Azure Databases – SQL Server в режиме PaaS. Со своими ограничениями, со своими функциями, которых нет в SQL Server (в основном касающимися отказоустойчивости и автоматизации таких задач, как балансировка нагрузки), SQLAD может быть средством, которое будет использоваться вместо локального развертывания в целях абстрагирования от задач инфраструктурных, однако важно и нужно понимать, что имеющиеся ограничения должны серьезнейшим образом повлиять на процессы обсуждения и планирования разрабатываемого проекта. Однозначно сказать, какой подход (IaaS или PaaS) будет лучше сейчас и потом, нельзя, однако данные и размышления, приведенные в статье, могут помочь в этом деле.

SQL Server в облаке Microsoft Azure: PaaS vs IaaS