Разработка приложений под Windows Azure. Хранилища данных. Часть №3. Основы SQL Azure и SQL Azure Data Sync.

В заключительной части серии публикаций, связанных с хранением данных в Windows Azure, я бы хотел поверхностно коснуться технологии SQL Azure, а также логически связанной с ней технологией синхронизации данных SQL Azure Sync.
Итак, мы с вами познакомились с нереляционными хранилищами данных, которые в принципе могут покрыть все наши требования по хранению данных в облаке. Но что если нам все таки необходим реляционный движок, либо переход от реляционной модели хранения данных к нереляционной слишком ресурсоемкий и дорогой для нас. Для этих целей платформа Windows Azure предоставляет нам высокомасштабируемое и чрезвычайно отказоустойчивое решение под названием SQL Azure.
Архитектура.
Если кратко описать SQL Azure, то это прежде всего реляционная база данных в облаке. Вся архитектура SQL Azure направлена на удовлетворение 2-х основных требований – это масштабируемость и доступность. На сегодняшний день большинство высоконагруженных проектов хранят свои данные в реляционной базе данных. Как правило она лежит на мощнейшей машине и достигает в размерах нескольких терабайтов. Например, на проекте над которым я работаю сейчас используется машина
представленная на рисунке ниже:

Этот монстр отвечает только за базу данных. Да, бесспорно он позволяет обрабатывать огромное количество запросов и надеюсь будет делать это на протяжении значительного промежутка времени. Но, что если нагрузка будет возрастать и такое решение перестанет с ней справляться ? Выход один – это покупка нового железа. Понятное дело, что такие чрезвычайно производительные машины стоят немало. Поэтому решение с использованием одной громадной базы данных и мощного сервера для ее обслуживания является очень слабо масштабируемым. Кроме того такое решение является единой точкой отказа. Если упадет сервер базы данных – умрет проект. Да, конечно есть решения для повышения отказоустойчивости, из которых наиболее популярным стало создание резервных копий. Но и в случае использования бекапов как правило уходит значительный промежуток времени в течении которого бекап восстанавливается, следовательно проект в это время не работает. Если же мы используем  технологию SQL Azure, то мы автоматически получаем 3 реплики, одна из которых является ведущей и 2 резервных. Архитектура такого решения представлена ниже:

В такой схеме если мы по каким-то причинам теряем ведущую реплику, все запросы автоматически перенаправляются на запасную и она объявляется основной. То есть нам не нужно заботиться  о создании резервных копий, нам не нужно заботиться о обработке падений инстансов. Это ВСЕ ЗА НАС ДЕЛАЕТ Windows Azure, тем самым обеспечивая чрезвычайную отказоустойчивость. Другое не менее важное преимущество, которое предоставляет нам SQL Azure – это высокая доступность. Давайте посмотрим на концептуальную схему SQL Azure, которую мне удалось раскопать в интернете.

Здесь мы видим несколько уровней. Что не может не радовать это то, что протокол общения между клиентом и базой данных остается неизменным - это все тот же Tabular Data Stream, благодаря чему мы можем использовать наши любимые технологии доступа к данным, будь то Entity Framework либо Plain Old ADO.NET, они будут прекрасно функционировать совместно с облачной базой данных. Итак, допустим наше приложение запрашивает какие-либо данные из базы данных. В первую очередь запрос проходит через балансировщик нагрузки и перенаправляется к базе данных. Следует понимать, что база данных в SQL Azure не лежит на отдельной физической машине и не обрабатывается отдельным экземпляром SQL Server. Она скорее является виртуальной базой данных. Точно также как у нас может быть множество баз на одном экземпляре SQL сервера, точно также наши облачные базы данных могут находится под опекой разных серверов. Именно для определения конкретного экземпляра SQL-сервера  и необходимы гейтвеи, которые как бы находятся над каждой базой данных. Эта архитектура позволяет размазывать запросы между всеми базами данных тем самым повышая их доступность.
Взаимодействие с SQL Azure.
В первую очередь нам необходимо создать аккаунт SQL Azure. Делается это на dev-портале. После чего мы сможем создавать логические сервера и подключать к ним базы данных. Сразу же хотел бы отметить, что размер одной бд ограничен 50 Гб. Это ни в коем случае не связано с нехваткой места в Windows Azure либо какими-то техническими неисправностями. Все дело в идее, как я уже говорил Microsoft не хочет просто напросто переносить вашу гигантскую базу данных в облако. Это не масштабируемое решение, имеющее массу недостатков. Microsoft предлагает нам другую концепцию, согласно которой наша гигантская база данных размазывается по всему датацентру в виде относительно небольших частей – это называется шардинг данных. Именно для реализации шардинга и упрощения механизма взаимодействия со всеми шардами на последнем PDC была представлена технология SQL Azure Federation, которая призвана к автоматизации перевода наших гигантских баз данных на более оптимальную и масштабируемую  технологию распределения данных. Помните, SQL Azure спроектирована с одной целью – это МАСШТАБИРОВАНИЕ, поэтому стоит рационально подходить к данным, которые будут храниться в бд.
После создания аккаунта и нашей первой базы данных встает логический вопрос: “Как управлять нашей бд ?”. И ответ очень прост: “Используйте нашу любимую SQL Server Managment Studio”. Все что нам нужно будет сделать это проставить в окне соединения URI нашей базы данных и криденшиалы для доступа к ней.

Кроме студии мы также имеем возможность использования специализированного менеджера баз данных на dev-портале (кодовое имя Houston). Проект позиционируется как часть development-портала, с его помощью можно создавать таблицы, представления, хранимые процедуры, создавать запросы и просматривать результаты их выполнения, а также много много чего другого.

То есть как мы видим у нас есть полная свобода выбора инструментария по управлению облачными базами данных. Следует отметить, что работа с SQL Azure сводится к логическому администрированию баз данных (создание схемы и управление, оптимизация запросов, управление политикой безопасности), физический уровень (балансировка нагрузки, восстановление в случае сбоя и др. ) остается под опекой Windows Azure.
Следующий вопрос, который я хотел бы прояснить это безопасность. На данный момент мы можем соединяться с облачной базой данных только при помощи SQL Server аутентификации. Система интегрированной безопасности пока что не поддерживается, но в будущем и это обещают исправить при помощи механизма Domain Join и Windows Azure Connect.
SYNC.
Следующая удобная технология, о которой я хотел бы вкратце рассказать – это Data Sync.

Очень часто у нас есть несколько реплик баз данных и нам необходимо синхронизировать эти базы между собой. Это могут быть как облачные базы данных (несколько экземпляров SQL Azure баз данных, находящихся в разных датацентрах) так и on-premise базы данных. Кроме того имеет смысл сценарий хранения резервной копии вашей облачной базы данных на своем сервере. С помощью какой технологии мы можем удовлетворить все эти требования? Ответ: “SQL Azure Data Sync”. Центральная консоль управления находится  на dev-портале. С ее помощью мы имеем возможность определять кто синхронизируется и с кем, создавать синхронизационные группы, устанавливать направления синхронизации и порядок решения конфликтов. На данный момент эта технология находится с CTP версии, поэтому значительно ограничена. Сейчас пока что мы можем синхронизировать между собой только облачные базы данных .Построен Data Sync на базе Microsoft Synchronization Framework, прекрасной технологии, позволяющей синхронизировать наверное все, что можно себе представить .
Создание первичной инфраструктуры.
Для того, чтобы начать пользоваться всеми возможностями SQL Azure необходимо в первую очередь создать логический сервер на dev-портале. В процессе создания нас попросят выбрать подписку, расположение сервера и логин/пароль админа. После чего открывается рабочая область сервера, где мы получаем возможность добавления новой базы данных к текущему серверу.

После успешного добавления базы получим на выходе следующую картину.

Нажмем кнопку Manage и автоматически перейдем на сайт проекта Houston, где в принципе можно выполнять любые манипуляции над выбранной базой данных. Также как я уже говорил выше можно пользоваться SQL Server Management Studio, необходимо только прописать адрес сервера и аутентификационные данные.
На этом я хотел бы закончить серию  публикаций посвященных хранению данных в облаке. Мы с вами получили представление о нереляционных способах хранения данных, а именно о блобах, дисках, очередях и таблицах, а также о реляционных вариантах таких как SQL Azure. В последующих публикациях поговорим о диагностике в облаке, а также о безопасности, кешировании и еще о многом интересном . Спасибо за внимание !