SQL Azure. Введение.
Как известно из курса диамата, движение материи во времени и пространстве происходит по спирали. Эта закономерность развития является общей, присущей всем явлениям окружающей действительности, в том числе прекрасному миру вычислительной техники, в котором нам с вами выпало счастье подвизаться. Никуда от нее не денешься (я про закономерность). Диалектика, брат (с) Шилов.
Движение в сторону облачных вычислений является новым модным веянием времени, которому все должны мы неудержимо следовать, дабы не прослыть ретроградами. Таким образом, за 30±5 лет история совершила виток, вернувшись к идее выделенных вычислительных центров, разумеется, на новом качественном уровне. Теперь не нужно переться в машинный зал с колодой перфокарт, да и где его там найти, в Облаке? Не говоря уже про перфокарты. Рассматривая персональные и облачные вычисления как противоположности, можно воочию ощутить действие закона единства и борьбы, перехода накопившихся количественных изменений в качественные и отрицания отрицания. Следует отдать должное, старина Гегель был мудрый мужик.
Когда-то давно, когда компьютеры были большие, альтернативы датацентрам попросту не было. Появление персональных компьютеров эксплуатировало низменные частнособственнические инстинкты человечества. Теперь каждый стал хозяином своих программ. Кончилось время мироеда-оператора, по настроению назначавшего приоритеты выполнения. Также сказался такой важный двигатель прогресса, как лень. Персоналки избавляли от необходимости тащиться в ВЦ, чтобы поиграться в посадку на Луну на БЭСМ-6. Все было под рукой, что в конечном счете обусловило невиданную популярность РС в полном соответствии с прогнозами экспертов. "Ни у кого не может возникнуть необходимость иметь компьютер в своем доме. Для этого нет никаких причин" (с) Кеннет Олсон (основатель и президент DEC) 1977 г. "В середине 70-х кто-то обратился ко мне с идеей, которую сейчас, наверное, можно назвать персональным компьютером. Мысль заключалась в том, что нам следовало использовать процессор 8080 вместе с клавиатурой и монитором, а затем продавать эти машины на внутреннем рынке. Я тогда спросил, для чего все это? Единственное, что я услышал в ответ, было создание кухонного компьютера для домохозяек, который хранил бы в памяти всяческие кулинарные рецепты. Лично я ничего полезного в этом не усмотрел, поэтому больше мы к этой идее не возвращались" (с) Гордон Мур (председатель совета директоров и основатель Intel). До кучи сюда же можно отнести 640К, которые должно хватить каждому - (с) не помню, кто, 1981. По мере роста памяти, процессорной мощи и аппетитов обозначились три источника и две составные части, которые стали влиять на радостную восходящую линию бурного расцвета персональных вычислений, загибая ее в виток эволюционной спирали, туда, в сторону старых добрых ВЦ. Это виртуализация, удаленная обработка данных, масштабирование и аренда необходимых мощностей + аутсорсинг непрофильных процессов. По большому счету, клиента не волнует, где, на каком сервере или серверах выполняются его запросы. Для него это выглядит как обло и стозевно чудище, куда добавляются сервера по мере надобности или выбывают на профилактику. Работоспособность системы, номенклатура и качество предоставляемых ей сервисов обеспечивается на заявленном уровне, и вся эта внутренняя кухня ему без интереса. Большое, цельное и расплывчатое, скрывающее в себе детали реализации, у кого-то из маркетологов вызвало ассоциации с облаком, хотя, возможно, это название пришло по аналогии из сетевых диаграмм, где им еще с 60-х годов обозначались внешние сервисы типа общественных коммунальных служб, которые гарантированно предоставят мусор или вывезут электроэнергию и о природе которых можно не беспокоиться. В результате на свет появилось что-то непонятное, что потребовалось для начала как-нибудь обозвать. Специалисты из берклиевской лаборатории распределенных систем напряглись и выдали: "Cloud Computing refers to both the applications delivered as services over the Internet and the hardware and systems software in the datacenters that provide those services". Как водится, возникли аналитики, превозносящие преимущества нового подхода. Абстрагируемость пользователя от управляемой извне инфраструктуры - поддержка и масштабирование приложений в компании не требует инвестиций в инфраструктуру, привлечения временнЫх и людских ресурсов. Использование технологий виртуализации делает вычислительные ресурсы автономными и взаимно независимыми. Эластичность ресурсов - возможность быстро нарастить инфраструктурную мощь без необходимости наращивания затрат на оборудование и программное обеспечение. Pay-for-play - оплата только за используемые ресурсы, например, время работы приложения, объем данных и количество операций с данными (транзакций), сетевой трафик и т.д. Форрестер нарисовал веселую картинку на манер диаграммы эволюции гомо сапиенс от dial-up, ISDN, T1, T3 через Internet Access Point servers access, racks for your equipment at Internet Access Point к hosted applications on servers at Internet Access Point и далее к dynamic Internet-optimized infrastructure for hosting your applications и SaaS. Возникли модные понятия IaaS (Amazon EC2), PaaS (Amazon S3, Microsoft Windows Azure, Google Apps), SaaS (Microsoft Office365, Google Docs) и прочие ааSы. Наученная опытом с браузером, Microsoft решила не запускать процесс, а с самого начала принять в нем деятельное участие, как обычно, постаравшись возглавить. Объективности ради следует отметить, что в 1996 г. ускорить наступление светлого будущего собирался ее лучший друг в лице Oracle, который с выходом SQL Server 6.х неожиданно для себя узнал, что у Microsoft тоже есть сервер баз данных, и это уже не Sybase. Ну, по крайней мере, не совсем. Обладая неплохим на тот момент соотношением цена-качество (сейчас-то, понятно, куда как лучше) Microsoft SQL Server стал активно выдавливать Oracle со среднего бизнеса. В качестве ассиметричного ответа тот выпустил NC (сетевой компьютер) - бездисковую (следовательно, без этих ваших Windows+Office) рабочую станцию с минимальным юниксом и Х-терминалом. Приложения скачивались по Сети и тут же запускались, т.к. устанавливать их было некуда. Однако низкие скорости интернет-соединений в то время и стремительное удешевление традиционных ПК привели к тому, что идея залезть поперед естественного хода эволюции провалилась.
Пройдет еще лет 20-30, может, меньше, и на смену концепции облачных вычислений снова придет некогда популярная идея персонального компьютинга, обогатившаяся к тому времени новыми технологическими и программно-архитектурными достижениями. Те же аналитики, которые сейчас расхваливают Облако как "эффективный инструмент повышения прибыли и расширения каналов продаж для ISV благодаря динамическому предоставлению услуг, когда можно производить оплату по факту и регулировать объем своих ресурсов в зависимости от реальных потребностей без долгосрочных обязательств", станут (если доживут) критиковать его недостатки, например, полную зависимость от провайдера облачных услуг и качества связи, и превозносить "новый тектонический сдвиг в индустрии ПО". И возвратится ветер на круги своя. Но всему свое время. Тема нашего нынешнего обсуждения - облачные базы данных, а именно - SQL Server в Облаке.
Идеологически SQL Azure наряду с Windows Azure и App Fabric является ключевым компонентом облачной вычислительной платформы Microsoft для создания и использования приложений там же, в Облаке. Первая серьезная попытка запихнуть SQL Server в Облако состоялась на 20-м году его жизни под кодовым названием проекта Sitka. Для создававшейся платформы разработки облачных приложений позарез требовался сервис хранения и обработки данных. В марте 2008 г. на конференции MIX’08 были анонсированы SQL Server Data Services. На SQL Server это тогда мало походило, поэтому 27 октября 2008 г. их переименовали просто в SQL Data Services (SDS):
.
Рис.1
Собственно, от SQL там тоже было мало чего. Поддерживалась нереляционная 3-уровневая модель: участник (Authority), контейнер (Container) и сущность (Entity). Authority было аналогом пространства имен, например, leshik.data.database.windows.net, где leshik – аuthority, а все остальное – адрес сервиса SDS. В аuthority входили контейнеры, а в контейнер – сущности. Контейнер являлся неким родовым понятием и определял границы операций, например, область поиска. Аналогом контейнера выступала, скорее, база данных, хотя многие уподобляли его таблице. Сущность была просто набором свойств. Каждое свойство имело имя и, соответственно, значение. Т.е. аналогом из .NET Framework выступал Dictionary в смысле набора пар Key/Value. Аналогом в БД для свойства являлось поле, а сущности – запись. Имелось еще такое понятие, как эккаунт. Он выступал единицей биллинга, т.е. на него выставлялся счет за пользование услугами. Эккаунт мог иметь много authorities. Каждому эккаунту поначалу выдавалось 20 мегабайт обычных сущностей на контейнер и 500 мегабайт блобовских. По осени на РDC'08 ограничения ослабили до, соответственно, 100 МБ и 1 ГБ. Давалось 50 гиг места на все authorities и 1000 контейнеров на authority. Поддерживался неSQLный язык запросов, по своему синтаксису очень напоминающий LINQ. Программный доступ для операций создания, чтения, обновления, удаления происходил через протоколы REST:
Рис.2
или SOAP:
Рис.3
При одновременной работе нескольких пользователей поддерживались оптимистичные блокировки:
Рис.4
Имелась утилита навроде bcp, позволявшая загружать в SDS XML-файлы вида
<Customer xmlns:s="http://schemas.microsoft.com/sitka/2008/03/"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:x="http://www.w3.org/2001/XMLSchema">
<s:Id>ALFKI</s:Id>
<CompanyName xsi:type="x:string">Alfreds Futterkiste</CompanyName>
<ContactName xsi:type="x:string">Maria Anders</ContactName>
<ContactTitle xsi:type="x:string">Sales Representative</ContactTitle>
<Address xsi:type="x:string">Obere Str. 57</Address>
<City xsi:type="x:string">Berlin</City>
<Region xsi:type="x:string" xsi:nil="true"></Region>
<PostalCode xsi:type="x:string">12209</PostalCode>
<Country xsi:type="x:string">Germany</Country>
<Phone xsi:type="x:string">030-0074321</Phone>
<Fax xsi:type="x:string">030-0076545</Fax>
</Customer>
<Customer xmlns:s="http://schemas.microsoft.com/sitka/2008/03/"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:x="http://www.w3.org/2001/XMLSchema">
<s:Id>ANATR</s:Id>
...
так что перенос таблицы с on-premise SQL Server в Облако требовал предварительного выполнения SQL-запроса вида
Рис.5
результат которого уже подавался на вход утилите загрузки:
Рис.6
Все это благополучно просуществовало до марта 2009 г. и было похоронено на очередной конференции MIX, где объявили, что вместо АСЕ станет поддерживаться привычный реляционный облик БД, вместо запросов SLINQ - Т-SQL, а вместо доступа по REST и SOAP - доступ по протоколу TDS. Таким образом, работа с SQL Server в Облаке будет мало чем отличаться от работы с локальным SQL Server. 1 февраля 2010 г. считается официальной датой рождения SQL Azure в ее нынешнем виде. В этот день официально состоялся переход от СТР к коммерческой эксплуатации в виде двух SKU (редакции Web и Business, отличающиеся размерами БД) - была объявлена полная поддержка SLA в 21 стране. 17 февраля вышел SQL Azure Service Update (SU) 1, в котором была добавлена поддержка миграции между редакциями - ALTER DATABASE ... MODIFY (MAXSIZE = ... GB) | (EDITION = 'web' | 'business'), добавлена поддержка DMV sys.dm_exec_connections, sys.dm_exec_requests, sys.dm_exec_sessions и др., улучшен алгоритм прекращения излишне затянувшихся транзакций, Idle Connection Timeout (время бездействия соединения, по прошествии которого оно считается дохлым и отрубается) увеличено с 5 до 30 мин. 16 апреля 2010 г. в SQL Azure была добавлена функциональность Multiple Active Resultsets (MARS) и поддержки Data-Tier Applications (DAC). 25 июня в составе SQL Azure SU3 была добавлена поддержка геопространственных типов и HierarchyID, а также увеличен максимальный размер базы данных в бизнес-редакции - с 10 до 50 гигабайт. 21 июля вышел CTP1 проекта Хьюстон - легковесного средства администрирования и написания запросов к БД SQL Azure через Веб, которое не требует установки специальных клиентов/технологий, кроме Silverlight. 12 августа появился очередной СТР проекта Даллас - DataMarket-секции Windows Azure Marketplace, которая включает данные, изображения, веб-сервисы от различных поставщиков и открытых авторитетных источников, предоставляющих наборы данных по демографии, окружающей среде, финансам, статистике, погоде, спорту и др. с доступной поверх аналитикой. 24 августа в составе SU4 была добавлена функциональность Database Copy - CREATE DATABASE destination_database_name AS COPY OF [source_server_name.]source_database_name - асинхронное создание полной копии базы данных на этом же или ином сервере SQL Azure. 22 октября в SU5 была добавлена поддержка практически всех запросных хинтов, что и в on-premise SQL Server, Error Messages, sp_tableoption. 28 октября на keynote сессии PDC 2010 было объявлено, что в Облако переезжают службы отчетности, а также СТР2 утилиты двусторонней синхронизации между on-premise и облачной БД SQL Azure Data Sync. 2011-й год прошел относительно спокойно. В майском обновлении появилась возможность иметь несколько серверов на подписку (коснемся в следующем посте) и REST API для задач администрирования (разберем его через пост). Продолжали допиливать облачный репортинг, синхронизацию, портал управления и другие инструменты, обеспечивая симметричность с Денали, который вначале собирались назвать SQL Server 2011, но передумали и назвали SQL Server 2012. Столько новшеств, что за три года никак не управиться. В SQL Azure существенные новшества произошли под занавес года - в традиционном сервис-релизе, приуроченном к PDC. Новый метро-стиль Database Management Portal (модный плиточный интерфейс а ля Windows 8, Windows 7 Phone и др.) способен резко повысить производительность и эффективность. Сейчас плитка это вообще очень круто и актуально, практически, как нано. У нас вот давеча тоже везде выламывали асфальт и укладывали плиткo. Ну и по мелочи в SR Q4 еще вошлo увеличение максимального размера базы до 150 ГБ и горизонтальное масштабирование облачного SQL Server (шардинг), позволяющее "размазывать" базу данных по федерации серверов - то, чего пока так и не научился делать on-premise SQL Server.
Обращаться к облачному SQL Server можно как из приложений Windows Azure, так и из on-premise приложений, для которых работа с ним практически не отличается от работы с обычным SQL Server. SQL Azure функционирует во всех 6-ти облачных датацентрах Microsoft: North-central US (Chicago, IL); South-central US (San Antonio, TX); North Europe (Dublin, Ireland); West Europe (Amsterdam, Netherlands); East Asia (Hong Kong); South East Asia (Singapore). SQL Azure продается в виде подписки и не существует в виде коробки, лицензии, набора открытых технологических инструкций, которые бы позволили развернуть подобную вещь в частном облаке. Я не буду останавливаться подробно на внутреннем устройстве SQL Azure, потому что, во-первых, с практической точки зрения оно представляет сугубо общеобразовательный интерес. Влиять на него все равно нельзя, остается воспринимать как данность. Возможности администратора базы данных SQL Azure существенно ограничены по сравнению с обычным SQL Server и концентрируются, в основном, на логических задачах. Собственно, за это и боролись - как мы помним, одна из основных идей Облака состоит в снижении административных издержек. Мы рассмотрим типовые задачи администрирования SQL Azure в последующих постах. Во-вторых, лучше Kalen Delaney вопросы внутреннего устройства SQL Server мало кому удается осветить, поэтому за подробностями отсылаю к ее статье Inside SQL Azure. Архитектурно SQL Azure можно представить в виде слоеного пирога из 4-х уровней: клиентского, сервисного, платформенного и инфраструктурного:
Рис.7
С позиций СУБД основным является платформенный уровень. Он состоит из SQL Server, SQL Azure Fabric и Management Services. Физически это много однородных машин, каждая из которых согласно Делани (не путать с Денали) имеет 8 ядер, 32 гига памяти, 10-12 SATA дисков и гигабитную сетевую карту. На каждой установлен экземпляр SQL Server, основанный на движке 2008 R2. Ключевое слово здесь - основанный, т.е. он не является точной копией SQL Server Standard или Enterprise, с которым привычно иметь дело. Мне сложно назвать обычный SQL Server физическим, потому что его, как и любую программу, нельзя потрогать руками. Но сервер, который мы создаем перед созданием баз, заходя в SQL Azure, является еще более нематериальным. Это просто TDS endpoint:
Рис.8
Соответственно, нужно провести разделение между логической с точки зрения пользователя и физической базой, как это выглядит с точки зрения SQL Server. На каждой ноде создается одна физическая база, в которой лежат базы разных пользователей. которые у Делани называются партициями. Очевидно, что они не имеют общего с партиционированием таблиц и индексов. При внимательном прочтении возникает другой вопрос. Делани пишет, что физическая БД может содержать до 650 партиций. Тогда средний размер диска должен составлять 650 * 150 / 10 = 9750 ГБ. А ведь из них наверняка какой-никакой RAID сделан. Либо спецификация устарела, либо админы SQL Azure пользуются тем, что не у всех еще базы выросли до 150 гиг и комбинируют их с мелкими, либо под партицией понимается не база, а ее кусок, даже когда речь не идет о шардинге. Хотя у Делани явно сказано, что each partition contains one SQL Azure client database, either a primary or secondary replica. Как бы то ни было, без какого-либо участия с нашей стороны партиция автоматически реплицируется еще в две физические базы (понятно, на других серверах).
Рис.9
На данный момент все три реплики живут в пределах одного центра обработки данных, поэтому если мы создадим базу, например, в Гонконге, а из Южно-Китайского моря вылезет Годзилла и сожрет тамошний датацентр, база будет гарантированно потеряна. Но поскольку по статистике Годзиллы выползают редко, считается, что SQL Azure обеспечивает высокую доступность в размере 99.9%. Созданием реплик, назначением, кто из них будет первичной, а кто вторичными, и автоматическим failover (промоутить вторичную до первичной, если та сдохла, завести новую вторичную и т.д.) занимается SQL Azure Fabric. Пользовательские операции чтения-записи выполняются против первичной реплики и асинхронно распространяются на остальные. Транзакция фиксируется по кворумному принципу, как при синхронном мирроринге. Коммит происходит, если первичная реплика и одна из вторичных подтвердили запись в свои журналы транзакций. В документации написано, что SQL Azure Fabric еще отвечает за балансировку нагрузки. От этого случается когнитивный диссонанс, потому что какой, в самом деле, load balancing, если только что говорилось, что аll your request are served by only one instance, and the other replicas are for reliability and durability? На самом деле, Load Balancer uses a just in time methodology by selecting the location of the primary and secondary replicas of a new database based on current load on nodes within a cluster, что означает, что если нода становится перегруженной, первичная реплика перемещается на другую. Самый простой способ это сделать - переключить первичную реплику с одной из вторичных, если машина со вторичной репликой загружена меньше. В платформенном уровне остается еще компонент Management Services. Он отвечает за мониторинг здоровья data nodes, накатку на них патчей, вообще автоматическую инсталляцию.
Непосредственно над платформой располагается сервисный уровень, главной задачей которого является маршрутизация соединений, т.е. привязывание пользовательских хотелок с конкретными физическими серверами уровня платформы.
Рис.10
Под кластерами здесь понимаются группы машин с одинаковой ролью. Узлы из группы Master Cluster обладают знанием о том, на каких физических серверах хранятся реплики, соответствующие той или иной пользовательской базе, убеждаются в том, что все реплики дееспособны и каждая партиция имеет положенное количество реплик. Кроме этого, в функции сервисного уровня входит биллинг.
Самым нижним уровнем является инфраструктурный. Он используется совместно различными сервисами центра обработки данных, обеспечивая администрирование аппаратной части и операционных систем. Самый верхний - уровень клиентского приложения на ASP.NET, C#, VB, Powershell, PHP, Ruby и т.д. обращающегося к SQL Azure посредством ADO.NET или ODBC. Оно может располагаться в Windows Azure или вне датацентра Microsoft. Клиентский API инициирует TDS-соединение к SQL Azure на порт 1433, которое маршрутизируется сервисным уровнем к соответствующему экземпляру SQL Server на уровне платформы.