Компьютерный форум: Intinger - Просмотр профиля - Компьютерный форум

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

Как описывалось ранее, Fabric Controller принадлежат все ресурсы определенного центра обработки данных Windows Azure. Он также отвечает за назначение приложений физическим компьютерам. Очень важно, чтобы это действие выполнялось оптимальным образом. Для примера представим, что разработчик запрашивает для приложения пять экземпляров Web-роли и четыре экземпляра Worker-роли. При упрощенном назначении все эти экземпляры могли бы быть размещены в одной и той же стойке, обслуживаемой одним и тем же сетевым коммутатором. Если выйдет из строя стойка или коммутатор, все приложение станет недоступным. Учитывая, что задачей Windows Azure является обеспечение высокого уровня доступности, было бы крайне нежелательно делать приложение зависимым от единой точки отказа, как в представленном выше примере.
Чтобы исключить подобные ситуации, Fabric Controller группирует принадлежащие ему компьютеры в несколько доменов отказа. Каждый домен отказа — это часть центра обработки данных, где один сбой может закрыть доступ ко всему, что находится в этом домене. На рис. 16 это наглядно показано.
 5707419bce3d3238c042fd78b3085fbd1.png (119,4К)
Количество загрузок:: 0
Рис. 16. Fabric Controller помещает разные экземпляры приложения в разные домены отказа.

В этом простом примере приложение использует только два экземпляра Web-роли, а центр обработки данных разделен на два домена отказа. Когда Fabric Controller развертывает такое приложение, он помещает по одному экземпляру Web-роли в каждый домен отказа. Такая схема означает, что из-за одного сбоя оборудова-ния в центре обработки данных не будет прекращена работа всего приложения. Также напомним, что для Fabric Controller хранилище Windows Azure выглядит просто как еще одно приложение, то есть он не занимается репликацией данных. Вместо него эту задачу выполняет само приложение хранилища, заботясь о том, чтобы реплики всех используемых больших двоичных объектов, таблиц и очередей помещались в разные домены отказа.

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

Не следует путать домены обновления, являющиеся свойством приложения, с доменами отказа — свойством центра обработки данных. Однако у этих технологий есть общая цель — помочь Fabric Controller поддерживать непрерывную работу приложений Windows Azure.

Чтобы использовать хранилище Windows Azure, разработчик должен сначала создать учетную запись хранения. Для управления доступом к информации в такой учетной записи платформа Windows Azure выдает создателю секретный ключ. Каждый запрос, совершаемый приложением для получения информации в учетной записи хранения — больших двоичных объектов, таблиц и очередей, — должен иметь подпись, созданную с этим секрет-ным ключом. Другими словами, авторизация осуществляется на уровне учетной записи (хотя для больших двоичных объектов есть еще один вариант, который описывается далее). Хранилище Windows Azure не предоставляет списков управления доступом и других более детальных способов управления доступа к данным.

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

Чтобы идентифицировать определенный большой двоичный объект, приложение может предоставлять универсальный код ресурса (URI) в следующем виде:
http://<StorageAccount>.blob.core.windows.net/<Container>/<BlobName>,
где <StorageAccount> — это уникальный идентификатор, присвоенный при создании учетной записи хранения, а <Container> и <BlobName> — это наименования конкретного контейнера и большого двоичного объекта в этом контейнере.

Большие двоичные объекты бывают двух видов:

• Блочные BLOB-объекты, которые могут вмещать в себя до 200 гигабайт данных. Для более эффективной передачи они делятся на блоки. Если происходит сбой, отправку можно возобновить с последнего по времени блока, вместо того чтобы отправлять весь большой двоичный объект заново. После того как все блоки большого двоичного объекта загружены, его можно зафиксировать целиком. Страничные BLOB-объекты, каждый из которых может иметь размер до одного терабайта.
  
• Страничный BLOB-объект делится на 512-байтовые страницы, любые из которых может записывать и считывать приложение.

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

Еще один важный аспект больших двоичных объектов — это выполняемая ими функция в поддержке дисков Windows Azure. Чтобы лучше понять смысл выполняемой ими задачи, сначала нужно отметить, что экземпляры ролей могут по своему усмотрению осуществлять доступ к своей локальной файловой системе. Однако по умол-чанию это хранилище не является постоянным. Когда экземпляр прекращает работу, виртуальная машина и ее локальное хранилище уничтожаются. Однако если смонтировать диск Windows Azure для экземпляра, то можно сделать так, чтобы страничный BLOB-объект выглядел, как локальный диск с файловой системой NTFS. Данные, записываемые на диск, могут тут же записываться в базовый большой двоичный объект. Когда экземпляр не выполняется, эти данные постоянно хранятся в страничном BLOB-объекте и готовы для монтирования. Вот несколько примеров использования таких дисков: Разработчик может загрузить виртуальный жесткий диск с файловой системой NTFS, а затем смонтировать его в качестве диска Windows Azure. Это простой способ перемещения данных файловой системы между Windows Azure и локальной системой Windows Server.

Разработчик Windows Azure может установить и запустить систему базы данных MySQL в экземпляре роли Windows Azure, используя диск Windows Azure в качестве базового хранилища.

Таблицы

Большой двоичный объект прост для понимания — это всего лишь множество байтов. А вот с таблицами все немного сложнее. На рис. 14 наглядно показано, как соотносятся между собой части таблицы.
 81fe536e8ad6daaa7a3d6ea849e8f6bb1.png (145,53К)
Количество загрузок:: 0
Рис. 14. Таблицы предоставляют хранилище, основанное на сущностях.

Как показано на рисунке, в каждой таблице есть некоторое количество сущностей. У сущности может быть одно или несколько свойств, у каждого из которых есть имя, тип и значение. Поддерживаются разнообразные типы, в том числе Binary, Bool, DateTime, Double, GUID, Int, Int64 и String. Свойство может в разные моменты иметь разный тип в зависимости от хранящегося в нем значения. И не требуется, чтобы все свойства в одной сущности были одинакового типа, — разработчик может по своему усмотрению делать так, как удобно в разрабатываемом приложении.
Вне зависимости от содержимого сущности, ее размер может достигать 1 мегабайта, а доступ к ней всегда осуществляется как к единому целому. При чтении сущности возвращаются все ее свойства, а при записи — заменяются значения всех свойств. Можно автоматически обновлять группы сущностей в одной таблице, при этом либо все обновления будут выполнены успешно, либо все они будут отменены.
Между таблицами хранилища Windows Azure и реляционными есть несколько отличий. Во-первых, они не являются таблицами в обычном смысле этого слова. Во-вторых, к ним нельзя осуществлять доступ с помощью обычных средств ADO.NET, и они не поддерживают запросы SQL. Таблицы в хранилище Windows Azure не обязаны придерживаться жесткой схемы — свойства одной сущности могут быть различных типов, причем они могут меняться со временем. Возникает естественный вопрос: зачем? почему бы просто не поддерживать обычные реляционные таблицы со стандартными запросами SQL?


Ответ кроется в главной задаче Windows Azure — поддержке приложений с высокой степенью масштабируемости. Традиционные реляционные базы данных могут масштабироваться, обслуживая все большее число пользователей, и для этого нужно, чтобы СУБД выполнялась на более мощных компьютерах. Однако для одновременной поддержки действительно огромного числа пользователей хранилище должно масштабироваться горизонтально, а не вертикально. Для этого механизм хранилища должен стать проще, а традиционные реляционные таблицы со стандартным SQL не очень для этого подходят. Решение данной задачи — это структура такого типа, как в таблицах Windows Azure.
Для применения таблиц разработчикам придется немного пересмотреть концепции, поскольку привычные реляционные принципы не получится применить без корректировок. И все же для создания хорошо масштабируемых приложений такой подход является оптимальным. Он позволяет разработчикам не беспокоиться о масштабах — они просто могут создавать новые таблицы, добавлять новые сущности, а об остальном позаботится Windows Azure. Также исключается значительная часть работы по поддержке СУБД, поскольку эту задачу Windows Azure берет на себя. В конечном итоге все это позволяет разработчикам сосредо-точиться на создаваемом приложении, не отвлекаясь на хранение и администрирование больших объемов данных.
Как и для всего остального в хранилище Windows Azure, для доступа к таблицам используется подход RESTful. Для этого приложение .NET может использовать сервисы данных WCF, скрывая базовые запросы HTTP. Любое приложение, созданное на основе .NET или других средств, также может по своему усмотрению использовать такие запросы напрямую. Например, запрос в отношении конкретной таблицы выражается как HTTP GET в отношении универсального кода ресурса (URI), форматированного следующим образом:
http://<StorageAccount>.table.core.windows.net/<TableName>?$filter=<Query>
где <TableName> обозначает запрашиваемую таблицу, а <Query> содержит запрос, который должен быть выполнен в отношении этой таблицы. Если запрос возвращает большое количество результатов, разработчик может получить маркер продолжения, который можно передать следующему запросу. Это позволяет поэтапно, фрагментами извлекать полный набор результатов.
Таблицы Windows Azure могут не подходить для некоторых сценариев хранения, и для их использования разра-ботчикам нужно будет освоить некоторые новшества. Однако для приложений, которым требуется высокая степень масштабируемости, таблицы являются оптимальным решением.

Очереди

В то время как таблицы и большие двоичные объекты предназначены прежде всего для хранения данных и доступа к данным, главной задачей очередей является обеспечение связи между различными частями приложения Windows Azure. Как и для всего остального в хранилище Windows Azure, для доступа к очередям используется подход RESTful. И приложения Windows Azure, и внешние приложения ссылаются на очередь, используя универсальный код ресурса (URI) в следующем формате:
http://<StorageAccount>.queue.core.windows.net/<QueueName>

Как описывалось ранее, очереди используются в основном для обеспечения взаимодействия между экземплярами Web-ролей и Worker-ролей. На рис. 15 показано, как это выглядит.
 9f6a2cdc312b8a6aaec68e60de4882851.png (66,68К)
Количество загрузок:: 0
Рис. 15. Сообщения ставятся в очередь, выводятся из очереди, обрабатываются, а затем явным образом удаляются из очереди.

В типовом сценарии выполняется несколько экземпляров Web-роли, каждый из которых принимает задания от пользователей (шаг 1). Чтобы передать задание экземплярам Worker-роли, экземпляр Web-роли записывает сообщение в очередь (шаг 2). В таком сообщении, размер которого может доходить до 8 килобайт, может содержаться универсальный код ресурса (URI), указывающий на большой двоичный объект, сущность в таблице или на что-то еще — на усмотрение приложения. Экземпляры Worker-роли считывают сообщения из очереди (шаг 3) и затем выполняют задание, запрашиваемое в сообщении (шаг 4). Важно отметить, что при чтении сообщения из очереди сообщение фактически не удаляется. Вместо этого сообщение на определенный период времени (по умолчанию — на 30 секунд) становится невидимым для других читателей. Когда экземпляр Worker-роли завершает выполнение запрошенного в сообщении задания, он должен явным образом удалить это сообщение из очереди (шаг 5).

Разделение экземпляров Web-ролей и экземпляров Worker-ролей оправдано. За счет этого пользователю не придется ждать, пока будет обработано большое задание, а также упрощается масштабируемость — для этого достаточно просто добавить дополнительные экземпляры Web-роли или Worker-роли. Но зачем сделано так, что экземпляры должны явным образом удалять сообщения? Дело в том, что такой подход позволяет справ-ляться со сбоями. Если экземпляр Worker-роли, который извлекает сообщение, обрабатывает его успешно, то он удалит это сообщение, пока оно еще невидимо, то есть в течение 30-секундного промежутка. Но если экземпляр Worker-роли выводит сообщение из очереди, а затем происходит сбой, прежде чем указанная в этом сообщении работа выполнена, то он не удалит сообщение из очереди. Когда истечет срок невидимости сообщения, оно снова появится в очереди и будет прочитано другим экземпляром Worker-роли. Таким образом гарантируется, что каждое сообщение будет обработано хотя бы один раз.

Как следует из этого описания, семантика очередей хранилища Windows Azure отличается от очереди сообщений Microsoft Message Queuing (MSMQ) и других привычных технологий очередей. Например, традиционная система очередей может обеспечивать семантику «первым пришел — первым обслужен», гарантируя, что каждое сообщение будет доставлено в точности один раз. Очереди хранилища Windows Azure не дают таких обещаний. Как описывалось выше, сообщение может быть доставлено несколько раз и нет гарантии, что сообщения будут доставлены в каком-то определенном порядке. Работа в облаке имеет свои особенности, и разработчикам нужно к ним приспособиться.
При поддержке компании Microsoft
Далее мы рассмотрим Изучение Fabric Controller в Windows Azure

Как и большинство технологий, вычисления в Windows Azure эволюционировали с момента первого выпуска. Например, в первоначальном варианте код в Web-ролях и Worker-ролях можно было выполнять только в поль-зовательском режиме. Однако в настоящее время роли обоих типов предоставляют возможность использования повышенных привилегий, благодаря чему приложения могут выполняться в административном режиме. Это может пригодиться для приложений, которым, например, требуется установить компонент COM — в первом выпуске Windows Azure это было бы проблематично.
Но при этом нужно иметь в виду, что каждый экземпляр Web-роли или Worker-роли запускается «с чистого листа». Операционная система в виртуальной машине — это стандартный образ, определяемый платформой Windows Azure. Следовательно, все установки ПО, выполняемые ролью, должны совершаться при каждом создании нового экземпляра. Это не создает трудностей при простых установках, таких как добавление одного компонента COM. Но, предположим, экземпляру нужно установить много программных продуктов для выполнения своих задач. Если выполнять такие действия при каждом создании нового экземпляра роли, это занимало бы слишком много времени.

Исключение таких задержек — одна из главных задач VM-ролей. Вместо того чтобы требовать установки ПО при каждом создании экземпляра, все необходимое ПО можно включить в виртуальный жесткий диск, с которым затем будет создаваться экземпляр VM-роли. Такой вариант может выполняться значительно быстрее, чем при использовании Web-ролей и Worker-ролей с повышенными привилегиями. Такое решение может также пригодиться, если в процессе установки необходимо ручное вмешательство — ведь оно не допускается в Windows Azure.

Еще одно изменение по сравнению с первоначальной версией Windows Azure заключается в том, что теперь платформа поддерживает доступ по протоколу удаленного рабочего стола. Например, это может пригодиться при отладке, чтобы разработчик мог напрямую получить доступ к определенному экземпляру. Однако не следует ожидать поддержки инфраструктуры виртуальных рабочих столов — в Windows Azure (по крайней мере, в настоящее время) не предусмотрена поддержка такого сценария.

Другие важные возможности вычислений Windows Azure были доступны уже с первого выпуска этой технологии. Например, Windows Azure позволяет разработчику указывать, в каком центре обработки данных должно выпол-няться приложение и где должны храниться его данные. Разработчик может также указать, что определенная группа приложений и данных (в том числе данные в SQL Azure) должна располагаться в одном и том же центре обработки. С самого начала Microsoft предоставляет центры обработки данных Windows Azure в Соединенных Штатах, Европе и Азии, и в дальнейшем их география будет расширяться.
При поддержке компании Microsoft
Далее мы рассмотрим Изучение сервиса хранилища в Windows Azure

Для понимания возможностей Windows Azure мы рассмотрели базовую информацию об этой платформе и базовые типовые сценарии применения. Однако возможности этой технологии намного шире. И в этом разделе более подробно рассматриваются некоторые интересные аспекты.

Создание приложений Windows Azure
Для разработчиков создание приложений Windows Azure в основном напоминает разработку обычных приложений Windows. Поскольку платформа поддерживает и приложения .NET, и приложения, созданные с помощью неуправляемого кода, разработчики могут использовать средства, наиболее удобные для решения их задач. Чтобы сделать разработку удобнее, в Visual Studio предоставляются шаблоны проектов для создания приложений Windows Azure. Также есть возможность напрямую загружать приложения из Visual Studio в Windows Azure.

Одно очевидное различие между облачными и локальными технологиями заключается в том, что приложения Windows Azure выполняются не локально. Потенциально это может несколько усложнить разработку. Чтобы облегчить эту задачу, Microsoft предоставляет фабрику развертывания — версию среды Windows Azure, которая выполняется на компьютере разработчика.

Фабрика развертывания выполняется на одном настольном или серверном компьютере. Это эмулятор функцио-нальных возможностей Windows Azure в облаке, включая Web-роли, Worker-роли, VM-роли и все три варианта хранилища Windows Azure. Разработчик может создать приложение Windows Azure, развернуть его в фабрике развертывания и выполнять практически так же, как в реальной среде Windows Azure. Например, можно указывать количество выполняемых экземпляров для каждой роли, использовать очереди для связи между экземплярами и делать практические все, что можно делать в реальной среде Windows Azure. После того как приложение создано и протестировано локально, разработчик может загрузить код и сведения о конфигурации, а затем запустить это приложение.

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

У приложения, помещенного в промежуточную область, есть DNS-имя в виде <GUID>.cloudapp.net, где в качестве <GUID> используется глобальный уникальный идентификатор, назначенный платформой Windows Azure. Для рабочей среды разработчик выбирает DNS-имя в том же домене, например myazureservice.cloudapp.net. Чтобы использовать настраиваемый домен, а не домен cloudapp.net от Microsoft, владелец приложения может создать DNS-псевдоним с помощью стандартной записи CNAME.

Когда приложение будет доступно из внешнего мира, пользователям, скорее всего, понадобится каким-то образом идентифицировать себя. Для этой цели Windows Azure позволяет разработчикам использовать любой механизм проверки подлинности на основе HTTP. Например, в приложении ASP.NET можно использовать поставщика членства для хранения собственного идентификатора пользователя и пароля или какой-нибудь другой способ вроде сервиса Microsoft Windows Live ID. Приложения Windows Azure могут также использовать Windows Identity Foundation (WIF) для реализации удостоверения, основанного на утверждениях. Выбор варианта — полностью на усмотрение разработчика приложения.
При поддержке компании Microsoft
Далее мы рассмотрим Изучение сервиса вычислений в Windows Azure

В то время как Windows Azure предоставляет широкий спектр возможностей, приложению нередко требуется только одна из них. Представим локальное или размещаемое приложение, которому нужно хранить большие объемы данных. Например, предприятие хочет архивировать старую электронную почту, чтобы сэкономить деньги на хранилище, но при этом обеспечить доступность архива со старой почтой. Новостному веб-сайту, размещенному на стороннем хостинге, может понадобиться масштабируемое и доступное из любой точки мира хранилище для больших объемов текстов, графики, видеоматериалов и сведений о профилях пользователей. Создатели сайта для публикации фотографий могут захотеть делегировать сложные задачи хранения информации надежному стороннему поставщику услуг. Во всех этих случаях можно применить хранилище Windows Azure, как показано на рис. 13.
 264706fa63a489dcd1bd68c0d04470081.png (108,65К)
Количество загрузок:: 0
Рис. 13. Локальное или размещаемое приложение может использовать объекты BLOB или таблицы Windows Azure для хранения данных в облаке.

Как упоминалось ранее, приложение, размещаемое локально или на стороннем хостинге, может напрямую осуществлять доступ к хранилищу Windows Azure. Хотя такой доступ может быть медленнее, чем использование локального хранилища, этот вариант, скорее всего, будет дешевле, а масштабируемость и надежность — выше. Для некоторых приложений такой компромисс определенно имеет смысл. На рисунке это не показано, но приложения могут по схожей схеме использовать SQL Azure.
При поддержке компании Microsoft
Далее мы рассмотрим Подробное рассмотрение возможностей Windows Azure. Создание приложений Windows Azure