Файл: Основы_обл_техн_лекции.pdf

Рисунок 6-1. Компоненты платформы Windows Azure и Комплекта средств разработки. Экономическая обстановка Microsoft во время выпуска платформы Azure

акцентировала внимание на снижении затрат, что является основным поводом для использования Azure мелкими, средними и крупными ИТ отделами.

Microsoft разработали платформу Azure, позволив .NET разработчикам усилить их опыт создания в Visual Studio 2008 (и выше) ASP.NET веб приложений и Windows Communication Framework (WCF) сервисов. Проекты веб приложений запускаются в изолированной версии Internet Information Services (IIS) 7. Веб приложения и веб сервисы запускаются в частично доверенном механизме защиты, позволяющем ограничивать доступ коду к ресурсам компьютера (Code Access Security), который приблизительно соответсвует среднему уровню доверия ASP.NET и ограничивает доступ к некоторым ресурсам операционной системы. Комплект средств разработки Windows Azure (Март 2009) позволяет использоваться полный доступ к ресурсам компьютера для запуска не

.NET кода, использования .NET библиотек, которые требуют полного доверия и процесс обработки взаимодействия, используя программные каналы (Pipe). Microsoft обещает поддержку запуска программного кода Ruby, PHP и Python в «облачной» платформе. Исходный вариант платформы разработки был ограничен средой программирования Visual Studio 2008 и выше с планом на поддержку инструментов Eclipse. Платформа Windows Azure поддерживает веб стандарты и протоколы включая SOAP, HTTP, XML, Atom и AtomPub.

Исходной точкой входа для разработчиков Azure для размещения ASP.NET приложений в облако является портал Windows Azure по адресу https://windows.azure.com/Cloud/Provisioning/Default.aspx. Портал требует входа с

76

использованием Windows Live ID. Предварительная версия Azure (Community Technical Previews , CTPs) требует разных токенов для:

Windows Azure, которая включает:

Azure Hosted service;

Storage Accounts; SQL Azure

Live службы, которые ключают:

Live Framework: Предварительная версия;

Live Services: существующие интерфейсы прикладного программирования. Live сервисы: существующие интерфейсы прикладного программирования не

являются частью предварительной версии и не требуют токена. С начала 2009 года Windows Azure токен дает право на одну учетную запись Hosted Service, две учетные записи для Storage. Вы запрашиваете токены Azure через страницу Microsoft Connect, на которую можно попасть со страницы портала.

На рисунке 6.1 показана страница учетной записи, которая содержит ссылки на страницы настроек и управления SQL Azure, сервисами .NET и Live сервисами. Эта страница также позволяет вам получать Azure и Live Framework CTP токены. Страница Live Alerts позволяет настроить, как и когда получать сообщения, содержащие критические сигналы приложения, информационные бюллетени и обновления портала.

Предварительная версия марта 2009 года включает геолокацию, которая позволяет владельцам учетных записей выбрать центры обработки данных для расположения Hosted Services и Storage Accounts. Например, USA-Northwest (Quincy, WA) и USA-Southeast (San Antonio, TX.). Вы можете добавить наборы Hosted Services и Storage Accounts в группу,

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

Вы можете вставить GUID полученные в сообщении от члена команды Azure в текстовое окно Resource Token ID и нажать Claim Token для добавление еще одной или больше точки входа для подходящего объекта или нескольких объектов в список.

Если вы хотите разрабатывать веб сайты с поддержкой Live Framework или Mesh (программный комплекс для синхронизации данных в кроссплатформенных средах разработанный компанией Microsoft) веб приложений, необходимо запросить токен Live Framework по email meshctpe@microsoft.com. После того, как вы получите Live Framework

токен, вы можете скачать и установить текущие версии Live Framework SDK и Live Framework Tools для Visual Studio по ссылкам указанным на странице http://dev.live.com/liveframework/sdk/. Вы должны оплатить Live Framework токен для того,

чтобы скачать Live SDK и дополнительные инструменты. Нет необходимости использовать учетную запись Windows Azure для тестирования Azure Hosted Services and Storage Services, потому что платформа разработки Azure эмулирует «облачные» сервисы Azure на вашем компьютере.

Windows Azure Storage

Хранилище Windows Azure Storage обеспечивает разработчикам возможность хранения данных в облаке. Приложение может выполнять доступ к своим данным в любой момент времени из любой точки планеты, хранить любой объем данных и как угодно долго. При этом данные гарантированно не будут повреждены и утеряны. Windows Azure Storage предлагает богатый набор абстракций данных:

Windows Azure Table – обеспечивает структурированное хранилище состояний сервиса.

Windows Azure Blob – обеспечивает хранилище больших элементов данных.

77

Windows Azure Queue – обеспечивает диспетчеризацию асинхронных заданий для реализации обмена данными между сервисами.

Azure Table Services

Windows Azure Table - структурированное хранилище, которе поддерживает высокомасштабируемые таблицы в облаке, которые могут содержать миллиарды сущностей и терабайты данных. По мере увеличения трафика, система будет эффективно масштабироваться, автоматически подключая тысячи серверов. Структурированное хранилище реализовано в виде таблиц (Tables), в которых располагаются сущности (Entities), содержащие ряд именованных свойств (Properties). Вот некоторые из основных характеристик Windows Azure Table:

Поддержка LINQ, ADO .NET Data Services и REST.

Контроль типов во время компиляции при использовании клиентской библиотеки

ADO .NET Data Services.

Богатый набор типов данных для значений свойств.

Поддержка неограниченного количества таблиц и сущностей без ограничения размеров таблиц.

Поддержка целостности для каждой сущности.

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

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

Рассмотрим модель данных таблицы Windows Azure Table:

Учетная запись хранилища (Storage Account) – для доступа к Windows Azure Storage приложение должно использовать действительную учетную запись. Новую учетную запись можно создать через веб-интерфейс портала Windows Azure. Как только учетная запись создана, пользователь получает 256-разрядный секретный ключ, который впоследствии используется для аутентификации запросов этого пользователя к системе хранения. В частности, с помощью этого секретного ключа создается подпись HMAC SHA256 для запроса. Эта подпись передается с каждым запросом данного пользователя для обеспечения аутентификации. Имя учетной записи входит в состав имени хоста в URL. Для доступа к таблицам используется следующий формат имени хоста: <имяУчетнойЗаписи>.table.core.windows.net.

Таблица (Table) – содержит набор сущностей. Область действия имен таблиц ограничена учетной записью. Приложение может создавать множество таблиц в рамках учетной записи хранилища.

Сущность (строка) (Entity (Row)) – Сущности (сущность является аналогом «строки») – это основные элементы данных, хранящиеся в таблице. Сущность включает набор свойств. В каждой таблице имеется два свойства, которые образуют уникальный ключ для сущности.

Свойство (столбец) (Property (Column)) – Представляет отдельное значение сущности. Имена свойств чувствительны к регистру. Для значений свойств поддерживается богатый набор типов.

Ключ секции (PartitionKey) – Первое свойство ключа каждой таблицы. Эта система использует данный ключ для автоматического распределения сущностей таблицы по множеству узлов хранения.

78

Ключ строки (RowKey) – Второе свойство ключа таблицы. Это уникальный ID сущности в рамках секции. PartitionKey в сочетании с RowKey уникально идентифицирует сущность в таблице.

Временная метка (Timestamp) – Каждая сущность имеет версию, сохраняемую системой.

Секция (Partition) – Набор сущностей в таблице с одинаковым значением ключа секции.

Порядок сортировки (Sort Order) – Для CTP-версии предоставляется всего один индекс, в котором все сущности сортированы по PartitionKey и затем по RowKey. Это означает, что запросы с указанием этих ключей будут более эффективными, и все возвращаемые результаты будут сортированы по PartitionKey

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

Рассмотрим некоторые дополнительные сведения о сущностях:

Сущность может иметь до 255 свойств, включая обязательные системные свойства: PartitionKey, RowKey и Timestamp. Имена всех остальных свойств сущностей определяются приложением.

Свойства PartitionKey и RowKey строкового типа.

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

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

Суммарный объем всех данных сущности не может превышать 1 МБ. Сюда входит размер имен свойств, а также размер значений свойств или их типов, включая и два обязательных свойства ключей (PartitionKey и RowKey).

Поддерживаются типы Binary, Bool, DateTime, Double, GUID, Int, Int64, String.

Ограничения представлены в таблице ниже.

Windows Azure Table обеспечивает возможность масштабирования таблиц до тысяч узлов хранения через распределение сущностей в таблице. При распределении сущностей желательно обеспечить, чтобы сущности, входящие в одно множество, располагались в одном узле хранения. Приложение формирует эти множества соответственно значениям свойства PartitionKey сущностей.

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

Рисунок 6.1 Примеры секций

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

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

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

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

В примере выше секцию образуют все версии одного документа. Таким образом, для извлечения всех версий данного документа необходимо выполнить доступ всего к одной секции. Чтобы получить все версии документов, измененные до 5/30/2007, придется запрашивать несколько секций, что будет не так эффективно и более ресурсоемко, поскольку по запросу должны будут проверяться все секции, которые к тому же могут располагаться на разных узлах хранения.

Выбор ключа секции важен с точки зрения обеспечения эффективного масштабирования приложения. При этом необходимо найти компромисс между

80