1. Основные аспекты перехода на облачную базу данных (“+” и “-“)

Облачные вычисления (cloud computing) — это инновационная технология, объединяющая ИТ-ресурсы различных аппаратных платформ и предоставляющая пользователю доступ к ним через Интернет. Вместе с тем, облачные вычисления — это и бизнес-модель, согласно которой пользователь оплачивает лишь реально потребляемые им ресурсы.

Основными отличиями облачных вычислений от технологий виртуализации являются высокая автоматизация всего жизненного цикла компонентов инфраструктуры и превращение ее из ресурса в услугу.

Достоинства:№ 1 Стоимость. Как обычно в облачных решениях преимущества цены складываются, как их низких начальных затрат, так и более низкой стоимости эксплуатации. Выбирая, облачные базы данных компания может сэкономить на зарплатах администраторов баз данных. Действительно квалифицированных специалистов на рынке мало и часто те, что уже есть в компании перегружены текущими задачами, а взять новых не позволяет бюджет и корпоративная политика. В облаке нет необходимости заботиться о настройках сервераБД, да и цена поддержки обычно оказывается значительно меньше.

№ 2 Замена персонала — высокая доступность — общее требование для современных ИТ-систем. К сожалению, небольшая перегруженная команда собственных специалистов по БД не всегда может обеспечить необходимый уровень сервиса. Здесь на помощь приходят, как облачные решения, которые обещают очень высокий уровень доступности, так и классический ИТ-аутсорсинг. Почасовая оплата труда может быть эффективным способом организации поддержки, в том числе в вечернее время, выходные и праздничные дни.

№ 3 Упреждающий подход — навыки собственных экспертов по СУБД, часто оказываются востребованными во многих проектах. При этом жизненно важные задачи мониторинга и управления базой данных оказываются непрофильным занятием для ИТ-специалистов. У перегруженной более приоритетными заданиями команды специалистов по БД не остается времени на проактивную работу. Кстати, подписывая договор с внешним провайдером стоит убедиться, что в него включен проактивный мониторинг — впоследствии это избавляет от кучи проблем.

№ 4 Идти в ногу со временем — администраторам БД и организациям в которых они работают, нужно держаться в курсе новейших технологий БД. Программное обеспечение БД становится все более сложным, а обучение специалистов все более дорогим. Внешний провайдер может оперативно прикрыть пробелы в знаниях и в опыте собственно команды.

№ 5 Отсутствие опыта — на самом деле множество компаний вообще не имеет специалистов по БД в штате. Одно дело запустить SQL Server или MySQL на сервереи обеспечить работу приложения. Совсем другая ситуация — исправить ошибки в БД и оптимизировать ее работу. Собственная ИТ-команда может справляться некоторое время, но при появлении реальных проблем, организации придется срочно искать внешнего специалиста. В облаке, узкие места вашей БД становятсяголовной больюпровайдера. К тому же крупная компания вполне может нанять действительно высококлассных специалистов по БД, вам остается только прорваться со своей проблемой через первыую линию поддержки.

Недостатки:

• Постоянное соединение с сетью Интернет. Cloud Computing всегда требует соединения с сетью Интернет. Или почти всегда. Некоторые "облачные" программы загружаются на локальный компьютер и используются в то время, когда Интернет недоступен. В остальных случаях, если нет доступа в Интернет - нет работы, программ, документов. Это наверное самый сильный аргумент против Cloud Computing. Но признайтесь честно, как сейчас современному человеку обойтись без услуг, доступных в сети Интернет? Также не обойтись, как и без мобильного телефона, платежных карт и многого другого. Многие уже ни дня не могут обойтись без электронной почты. Поэтому, учитывая развитие современного мира, Интернет будет доступен всегда и везде, где Вы находитесь, как, например, электричество и вода.

• Плохо работает с медленным Интернет-доступом. Многие "облачные" программы требуют хорошего Интернет-соединения с большой пропускной способностью. Если Вы "счастливый" обладатель модема 56К, Вам можно только посочуствовать. Сегодня все реже и реже встречаются старые неоптоволоконные магистрали для сети Интернет, скорости доступа постоянно растут, а цены - снижаются.

• Программы могут работать медленнее чем на локальном компьютере. Некоторые программы, в которых требуется передача значительного количества информации, будут работать на локальном компьютеребыстрее не только из-за ограничений скорости доступа в Интернет, но и из-за загруженности удаленных серверов и проблем на пути между пользователем и "облаком".

• Не все программы или их свойства доступны удаленно. Если сравнивать программы для локального использования и их "облачные" аналоги, последние пока проигрывают в функциональности. Например, таблицы Google Docs имеют гораздо меньше функций и возможностей, чем Microsoft Excel.

• Безопасность данных может быть под угрозой. Здесь ключевым является слово "может". Все зависит от того, кто предоставляет "облачные" услуги. Если этот кто-то надежно шифрует Ваши данные, постоянно делает их резервные копии, уже не один год работает на рынке подобных услуг и имеет хорошую репутацию, то угрозы безопасности данных может никогда не случиться. Как сказал известнейший специалист по криптографии и компьютерной безопасности Брюс Шнайер, весь сопрос в доверии.

• Если Ваши данные в "облаке" потеряны, они потеряны навсегда. Это факт. Но потерять данные в "облаке" гораздо сложнее, чем на локальном компьютере.

характеристики облачных вычислений^[8]:

• Самообслуживание по требованию (англ.self service on demand), потребитель самостоятельно определяет и изменяет вычислительные потребности, такие как серверное время, скорости доступа и обработки данных, объём хранимых данных без взаимодействия с представителем поставщика услуг;

• Универсальный доступ по сети, услуги доступны потребителям по сети передачи данных вне зависимости от используемого терминального устройства;

• Объединение ресурсов (англ.resource pooling), поставщик услуг объединяет ресурсы для обслуживания большого числа потребителей в единый пул для динамического перераспределения мощностей между потребителями в условиях постоянного изменения спроса на мощности; при этом потребители контролируют только основные параметры услуги (например, объём данных, скорость доступа), но фактическое распределение ресурсов, предоставляемых потребителю, осуществляет поставщик (в некоторых случаях потребители всё-таки могут управлять некоторыми физическими параметрами перераспределения, например, указывать желаемый центр обработки данных из соображений географической близости);

• Эластичность, услуги могут быть предоставлены, расширены, сужены в любой момент времени, без дополнительных издержек на взаимодействие с поставщиком, как правило, в автоматическом режиме;

• Учёт потребления, поставщик услуг автоматически исчисляет потреблённые ресурсы на определённом уровне абстракции (например, объём хранимых данных, пропускная способность, количество пользователей, количество транзакций), и на основе этих данных оценивает объём предоставленных потребителям услуг.

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

С точки зрения потребителя, эти характеристики позволяют получить услуги с высоким уровнем доступности(англ.high availability) и низкими рисками неработоспособности, обеспечить быстрое масштабирование вычислительной системы благодаря эластичности без необходимости создания, обслуживания и модернизации собственной аппаратной инфраструктуры.

2. Службы обработки данных в Azure

Windows Azure, SQL Azure и связанные с ними службы предусматривают возможности для хранения данных и управления ими разными способами. Имеются следующие службы и компоненты управления данными:

• Хранилище Windows Azure. Обеспечивает четыре основные службы для длительного хранения данных в облаке. Эти службы поддерживают интерфейс REST, доступ к которому осуществляется как из приложений, размещенных в Windows Azure, так и из локальных (удаленных) приложений. Сведения об интерфейсе REST API см. в разделе «Справочник по интерфейсу REST API служб хранения Windows Azure». Ниже перечислены четыре службы хранения.

  • Служба таблиц Windows Azure предоставляет механизм хранения данных в виде таблиц и поддерживает запросы для управления данными. Служба таблиц Azure — это предложение NoSQL, обеспечивающее хранение данных без схемы. Она предназначена прежде всего для тех случаев, когда необходимо хранить большие тома данных, при этом их требуется легко извлекать и обновлять. Дополнительные сведения см. в разделах «Основные понятия службы таблиц» и «Интерфейс REST API службы таблиц».

  • Служба больших двоичных объектов (BLOB) предоставляет ряд контейнеров, предназначенных для хранения текстовых и двоичных данных. Предусмотрены как контейнеры блочных больших двоичных объектов для потоковой передачи данных, так и контейнеры страничных BLOB-объектов для операций произвольного чтения и записи. Дополнительные сведения см. в разделах «Основные сведения о блочных и страничных больших двоичных объектах» и «Интерфейс REST API службы больших двоичных объектов».

  • Служба очередей предоставляет механизм для надежного и постоянного обмена сообщениями между экземплярами ролей, например между веб-ролью и рабочей ролью. Дополнительные сведения см. в разделах «Основные понятия службы очередей» и «Интерфейс REST API службы очередей».

  • Диски Windows Azure предоставляют приложениям механизм для подключения однотомного VHD-диска с файловой системой NTFS как страничного большого двоичного объекта, а также передачи и загрузки виртуальных дисков через BLOB. Дополнительные сведения см. в разделе «Диск Windows Azure».

• База данных SQL Azure. Это облачная служба Database Services с высокой степенью доступности и масштабируемости, основанная на технологии SQL Server, которая поддерживает популярную модель реляционных баз данных на основе T-SQL. Ее можно использовать с приложениями, размещенными в Windows Azure, и с другими приложениями, работающими локально или размещенными на других площадках. Дополнительные сведения см. в разделе «База данных SQL Azure».

• Синхронизация данных. SQL Azure Data Sync — это облачная служба синхронизации данных, основанная на технологиях Microsoft Sync Framework. Эта служба обеспечивает двустороннюю синхронизацию данных и предоставляет возможности по управлению данными, позволяя легко распределять их между несколькими базами данных SQL Azure, а также между локальными базами данных и базами данных SQL Azure. Дополнительные сведения см. в «Центре разработчиков Microsoft Sync Framework».

• Служба кэширования. Эта служба предоставляет для приложений распределенный кэш в памяти с малой задержкой и высокой пропускной способностью, не требующий установки и управления, размер которого динамически увеличивается или уменьшается по мере необходимости. Может использоваться для кэширования данных приложений, получения сведений о состоянии сеансов ASP. NET, а также для кэширования страниц ASP.NET. Дополнительные сведения см. в разделе «Служба кэширования (Windows Azure)».

3. Общая архитектура SQL Azure

Уровень клиента

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

Существует несколько параметров, доступных приложению, для обращения к База данных SQL Azure. Дополнительные сведения о поддержке средств и драйверов см. в разделах Поддержка средств и программ базы данных SQL Azure и Рекомендации и ограничения в базе данных SQL Azure.

Уровень служб

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

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

Уровень платформы

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

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

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

Уровень инфраструктуры

Уровень инфраструктуры реализует администрирование аппаратной части и операционных систем, поддерживающих уровень служб.

4. Виды ролей, их особенности

Вычислительная среда Windows Azure состоит из платформы для приложений и служб, размещенных в одной или нескольких ролях. В Windows Azure можно реализовать следующие типы ролей.

• Эмулятор вычислений Windows Azure (веб-роли и рабочие роли). Приложение Windows Azure состоит из одной или нескольких размещенных ролей, запущенных в центрах обработки данных Azure. Как правило, существует хотя бы одна веб-роль, доступная пользователям приложения. Веб-роль поддерживается службами IIS 7.0 и ASP.NET. Приложение может содержать дополнительные роли, включая рабочие, которые обычно используются для выполнения фоновых задач обработки и поддержки для веб-ролей. Дополнительные сведения см. в разделах «Общие сведения о создании размещенной службы для Windows Azure» и «Построение приложения, работающего в размещенной службе».

• Виртуальная машина (роль ВМ). Эта роль позволяет разместить собственный экземпляр операционной системы Windows Server 2008 R2 Enterprise или Windows Server 2008 R2 Standard в центре обработки данных Windows Azure. 

• Web-роль — веб-роли в Windows Azure имеют особое назначение: предоставление выделенного веб-сервера служб IIS для размещения интерфейсных веб-приложений. Веб-роли позволяют легко и быстро развертывать веб-приложения с последующим масштабированием вычислительных ресурсов в соответствии с потребностями.

• Worker-роль — приложения, размещенные в рабочих ролях, могут выполнять асинхронные, продолжительные или непрерывные задачи независимо от действий пользователей. Изоляция фоновых процессов приложения в рабочей роли и размещение интерфейсной части в веб-роли позволяет эффективнее распределить логику приложения и более точно управлять масштабированием приложения

• VM-роль — роли виртуальной машины позволяют разворачивать в Windows Azure пользовательский образ операционной системы. Роль виртуальной машины используется, когда для работы приложения требуется внести в настройки серверной ОС большое количество изменений и этот процесс невозможно автоматизировать. Роль виртуальной машины позволяет полностью контролировать среду выполнения приложения и переносить существующие приложения в облако.

5. Сравнение sql Azure и Microsoft sql Server

Если вы решите запустить SQL Server на виртуальной машине в облаке, то вы несете ответственность за управление операционной системой и установку SQL Server, а также за своевременную установку обновлений с исправлениями, конфигурацию согласно правилам безопасности и т. д. Для устойчивости платформа Windows Azure хранит копии виртуальных машин, и вы можете выбрать учетную запись хранилища для хранения копий в различных центрах обработки данных. Но в этом случае вы платите за хранилище BLOB-объектов, в котором находятся эти копии.

Если вы выбираете базу данных SQL, то корпорация Майкрософт беретна себя все задачи управления. Однако выбор модели PaaS означает, что вы теряете определенный уровень контроля над вашей средой.

С точки зрения затрат ситуация более сложная, поскольку имеется три основных варианта хранилища данных SQL:

• Приобретение лицензии на SQL Server, установка и запуск его на виртуальной машине Windows Azure. В этом случае у вас появится возможность повторно использовать существующую лицензию, SQL Server оплачивается заранее, поэтому в начале проекта необходимо выбрать лицензию на ту версию SQL Server, которая наилучшим образом подходит для вашего приложения.

• Использование образа виртуальной машины Windows Azure с уже установленным SQL Server. В этом случае взимается почасовая оплата за использование SQL Server, причем в любой момент можно прекратить работу и перейти на большую или меньшую виртуальную машину. Этот вариант также предполагает использование модели IaaS, поскольку вы несете ответственность за управление операционной системой и установку SQL Server.

• Использование базы данных Windows Azure SQL. В этом сценарии можно выбрать гибкую схему оплаты по факту использования, но теперь для развертывания хранилища данных SQL в Windows Azure используется модель PaaS. После создания логического экземпляра серверабазы данных SQL можно легко и быстро создать несколько баз данных без необходимости управления самимсервером. Windows Azure автоматически управляет распределением баз данных между всеми физическимисерверами.

6.Уровни клиента, служб и платформы в архитектуре sql Azure

Уровень клиента

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

Существует несколько параметров, доступных приложению, для обращения к База данных SQL Azure. Дополнительные сведения о поддержке средств и драйверов см. в разделах Поддержка средств и программ базы данных SQL Azure и Рекомендации и ограничения в базе данных SQL Azure.

Уровень служб

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

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

Уровень платформы

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

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

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

7. Механизмы обеспечения доступности в SQL Azure

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

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

Locally Redundant Storage (LRS) предоставляет хранилище с высокой степенью долговечности и доступности внутри одной географической локации (региона). Платформа хранит три реплики каждого элемента данных в одной главной географической локации, что гарантирует, что эти данные можно будет восстановить после сбоя общего характера (например, выхода из строя диска, узла, корзины и так далее) без простоя аккаунта хранилища и, соответственно, не влияя на доступность и долговечность хранилища. Все операции записи в хранилище выполняются синхронно в три реплики в трех различных доменах ошибок (fault domain), и только после успешного завершения всех трех операций возвращается код об успешном завершении транзакции. В случае использования локального избыточного хранилища, если датацентр, в котором размещены реплики данных, будет по какой-либо причине выведен из строя полностью, Microsoft свяжется с клиентом и сообщит о возможной потере информации и данных, используя контакты, приведенные в подписке клиента.

Geo Redundant Storage (GRS) предоставляет гораздо более высокую степень долговечности и безопасности, размещая реплики данных не только в главной географической локации, но и в какой-либо дополнительной в том же регионе, но за сотни километров. Все данные в сервисах хранилища блобов и таблиц географически реплицируются. С географически избыточным хранилищем платформа сохраняет опять же три реплики, но в двух локациях. Таким образом, если датацентр перестанет работать, данные будут доступны из второй локации. Как и в случае первой опции избыточности, операции записи данных в главной географической локации должны быть подтверждены перед тем, как система вернет код успешного завершения операции. По подтверждению операции в асинхронном режиме происходит репликация в другую географическую локацию. Рассмотрим, как происходит географическая репликация.

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

7. Реплики. Отказ основной и дополнительных реплик.

Отказ основной реплики

Все операции чтения и записи сначала выполняются в основной реплике. Поэтому отказ основной

реплики выявляется незамедлительно и препятствует дальнейшему выполнению работы. При

переконфигурации в случае отказа основной реплики диспетчер разделов выбирает одну из

дополнительных реплик и назначает ее основной. Как правило, в качестве новой основной

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

Процедура присвоения дополнительной реплике статуса основной не вызывает простоя базы

данных и не заметна для большинства пользователей. Шлюз передаст клиентскому приложению

сообщение об отключении, после чего приложение должно незамедлительно выполнить попытку

повторного подключения. Распространение информации о новой основной реплике по всем

серверам шлюза может занять до 30 секунд. Поэтому рекомендуется попробовать подключиться

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

Отказ дополнительной реплики

При отказе дополнительной реплики у базы данных остается только две реплики для кворумной

фиксации. Процедура реконфигурации схожа с процедурой, которая выполняется после отказа

основной реплики, когда статус одной из дополнительных реплик повышается до основной. В

обоих случаях остается только одна дополнительная реплика. После короткого ожидания

диспетчер разделов пытается определить, носит ли этот отказ постоянный характер, чтобы создать

новую дополнительную реплику.

В некоторых случаях, например при отказе или обновлении операционной системы, отказ

дополнительной реплики может иметь кажущийся характер. Неработоспособность

дополнительной реплики на отказавшем узле может быть всего лишь временной. Поэтому

мгновенного создания новой реплики не происходит. Если дополнительная реплика возвращается

в рабочее состояние, выполняются команды проверки данных (checkdisk и т. п.) для

подтверждения работоспособности реплики.

Если реплика остается в нерабочем состоянии в течение более двух часов, диспетчер разделов

приступает к созданию новой реплики для ее замены. В некоторых случаях такое фиксированное

время ожидания не является оптимальным решением, например при отказе компьютера по

причине невосстановимого аппаратного сбоя. Новые выпуски платформы SQL Database, возможно,

будут содержать функции определения различных типов отказов реплик, а также иметь

возможность более оперативного устранения последствий невосстановимых сбоев.