Сервисы хранения данных в Windows Azure. VM - роль

VM - роль в Windows Azure предназначена для облегчения процесса миграции существующих Windows Server приложений в "облачную" структуру.

VM - роль предоставляет сервисы на уровне инфраструктуры ( IaaS ), облегчая процессы контроля и управления инфраструктуры для администраторов и разработчиков.

Отметим, что остальные роли (веб и прикладная) находятся "над" VM -ролью, позволяя тем самым разработчикам, чья деятельность осуществляется на более высоких уровнях абстракции, концентрироваться непосредственно на приложении, а не на ОС, на котором оно базируется.

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

Таким образом, роль виртуальной машины позволяет создавать пользовательский образ виртуального жесткого диска (на основе Windows Server 2008 R2) и размещать его в "облаке".

Фактически VM - роль это виртуальная машина, но обладающая рядом особенностей:

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

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

Каждая виртуальная машина создается при развертывании прикладных сервисов. Все виртуальные машины располагаются в центрах обработки данных Microsoft.

О ценах и лицензировании можно узнать из п. №1 списка материалов для самостоятельного изучения.

Сервисы хранения данныx

Хранение данных в Windows Azure обеспечивается набором сервисов под общим названием Windows Azure Storage . Каждый из сервисов подходит для хранения определенного типа данных:

• Table - сервис, позволяет хранить структурированные данные в таблице, доступ к которым осуществляется через REST API ;
• Queue - сервис, позволяет организовать неограниченное хранилище сообщений;
• Blob - сервис, позволяет хранить текстовую и бинарную информацию в специально организованных контейнерах.

Отметим, что Table - хранилище не является аналогом реляционного хранилища данных. В данной концепции, под таблицей понимается коллекция сущностей ( Entities ), подобных кортежам в реляционном подходе. Сущность же представляет собой набор свойств ( Properties ). Свойство же является парой "имя (name) - типизированное значение (typed value)". Продолжая аналогию, сущности можно соотнести с полями в таблице в реляционном хранилище.

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

Таким образом, таблица состоит из набора объектов, каждый из которых имеет набор названий свойств и их значений. Объект может иметь до 256 свойств.

В табличном хранилище, к примеру, могут храниться состояния веб - приложений, текущее состояние пользовательских объектов (заказ, группа контактов) и т.д.

Для хранения бинарных (blob ) объектов используется интерфейс, позволяющий сохранять именованные файлы вместе с метаданными.

Blob - объекты делятся на:

• блочные, оптимизированные для потокового ввода - вывода, размер объекта не может превышать 200 Гб;
• страничные, оптимизированные для случайных операций ввода - вывода, размер объекта не может превышать 1 Тб.

Хранилище бинарных объектов больше подходит для хранения резервных копий, изображений, документов и т.д.

Очередь ( Queue ) является хранилищем сообщений, как правило, обеспечивает коммуникации между различными ролями Windows Azure . Сообщения хранятся в очередях, размер сообщений ограничен 8 Кб. При этом возможно использование неограниченного числа очередей, число сообщений в очереди также не имеет ограничений.

Подробнее о table , blob и queue сервисах будет рассказано в лекциях №11-16.

Кроме специализированных сервисов хранения данных Windows Azure поддерживает традиционные файловые операции, за счет поддержки NTFS формата.

NTFS тома хранятся как отформатированные виртуальные диски в страничных бинарных объектах. Работающие приложения могут сохранять состояния на томах. Доступ к диску осуществляется через стандартный NTFS интерфейс .

Каждая учетная запись Windows Azure Storage может хранить до 100 Тб данных.

С точки зрения архитектуры, существует 3 основных уровня доступа к данных в Windows Azure Storage :

1. Front - End (FE) уровень. Принимает поступающие запросы, авторизация и аутентификация также осуществляются на данном уровне. После аутентификации запросы направляются на сервер ( partition server ), на соответствующем уровне. На FE уровне хранится карта секторов ( partition map ), что позволяет направлять запрос напрямую необходимому серверу.
2. Уровень секторов ( partition layer ). Данный уровень управляет разделением данных в системе, обеспечивая доступ к необходимым серверам, автоматическую балансировку нагрузки секторов. Единственный partition - сервер может обслуживать множество секторов.
3. Уровень распределенной файловой системы ( Distributed and replicated file system - DFS ). Уровень, на котором фактически хранится информация, отвечающий за распределение и репликацию данных по всем серверам хранения. Каждый из DFS серверов доступен для любого partition - сервера .

Рис. 7.1. Уровни доступа к данным Windows Azure Storage (источник - http://blogs.msdn.com/b/windowsazurestorage/archive/2010/12/30/windows-azure-storage-architecture-overview.aspx)

Список дополнительных материалов для самостоятельного изучения

VM - роль

1. http://www.microsoft.com/windowsazure/compute/#vmrole
2. http://msdn.microsoft.com/en-us/library/gg465398.aspx

Windows Azure Storage

1. http://www.oszone.net/13891/Windows-Azure-Storage
2. http://blogs.msdn.com/b/windowsazurestorage/archive/2010/12/30/windows-azure-storage-architecture-overview.aspx
3. http://blogs.msdn.com/b/windowsazurestorage/archive/2010/11/23/windows-azure-storage-client-library-potential-deadlock-when-using-synchronous-methods.aspx