Изучение Fabric Controller в Windows Azure

Forum Forum Софт Windows Изучение Fabric Controller в Windows Azure

Просмотр 1 сообщения - с 1 по 1 (всего 1)
  • Автор
    Сообщения
  • #7799
    Intinger
    Участник

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

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

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

    [attachment=51:5707419bce3d3238c042fd78b3085fbd1.png]

    Рис. 16. Fabric Controller помещает разные экземпляры приложения в разные домены отказа.

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

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

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

Просмотр 1 сообщения - с 1 по 1 (всего 1)
  • Для ответа в этой теме необходимо авторизоваться.