Блог Сергея Байдачного

Мой блог о технологиях

Управление экземплярами в Windows Azure

5 комментариев

Сегодня Microsoft предлагает несколько способов, позволяющих получить доступ к Windows Azure на бесплатной основе. В Украине Вы можете получить доступ на 24-часа и 30 дней, не считая MSDN и возможностей, предлагаемых на http://azure.com. Однако, особенность первых двух программ состоит в том, что Вам не нужно вводить данные кредитной карты, что не позволит Вам перерасходовать лимит предоставляемых возможностей (хоть и случайно).

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

Основное ограничение предлагаемых программ, это предоставление только одного Hosted Service. Под Hosted Service мы будем понимать некое виртуальное окружение разработчика, позволяющее развернуть пакет и конфигурационный файл в Облако, задать сертификаты для организации https, поддерживать работы ролей. При этом Hosted Service обладает DNS (например, dev-club.cloudapp.net).

image

Как я уже отметил, по тестовым программам предоставляется только один Hosted Service, что может навести на мысль о том, что попробовать развернуть сложное решение не получится. Например, я хочу развернуть решение, содержащее веб-сайт, веб-службы и рабочую роль. Подобное решение я могу разрабатывать как независимые службы, разворачиваемые и конфигурируемые в отдельных пакетах. В этом случае нам необходимо иметь три Hosted Services. Однако следует обращать внимание не на количество Hosted Services, а на количество экземпляров (серверов), предоставляемых внутри одного Hosted Service. По предлагаемым программам их 3.

Обычно несколько экземпляров внутри одного окружения используются для организации масштабирования. Например, Ваш сайт не справляется с нагрузкой, и Вы добавляете в Ваше окружение еще несколько экземпляров, что позволяет увеличить нагрузку. Но в условиях «дефицита» Hosted Services Вы можете все Ваши компоненты конфигурировать и разворачивать как один пакет, размещая различные роли на различных экземплярах. Таким образом, имея три экземпляра в своем распоряжении, я могу развернуть до трех различных ролей. Более трех ролей развернуть нельзя, так как каждая роль должна владеть своим экземпляром (хотя для веб-сайтов есть свои особенности, которые мы также рассмотрим).

Итак, если Вы решили развернуть несколько ролей внутри одного окружения, то от Вас особо ничего и не требуется. Создайте новый Windows Azure Project в Visual Studio (или Web Developer Express) и добавьте необходимые роли к проекту (сразу или в процессе).

image

Все дело в конфигурации. Visual Studio тут же конфигурирует Ваши роли для развертывания в одном Hosted Service, на разные экземпляры. Рассмотрим сгенерированные конфигурационные файлы.

Конфигурационным файлом, настраивающим Ваше окружение (Hosted Service) является ServiceConfiguration.csсfg. Именно тут указывается, какие роли будут развернуты и какое количество экземпляров должно быть выделено для каждой роли. Обращаю Ваше внимание на то, что данный файл разворачивается отдельно от пакета и может быть модифицирован в процессе работы окружения. Например, Вам необходимо увеличить количество экземпляров под рабочую роль, Вы просто изменяете атрибут count в элементе Instances. Последнее можно выполнить через панель управления службами или с помощью специального API.

Второй конфигурационный файл ServiceDefinition.csdef используется для более гибкой конфигурации каждой роли. Например, Вы развернули две Web роли. Поскольку для окружения выдается одно имя DNS, то логично, что одна из Web ролей сможет работать на 80 порту, а вторая на любом другом (оба сайта на 80 порту работать не могут под одним DNS). Именно подобные настройки и конфигурируются в этом файле. Поскольку любые изменения в ServiceDefinition.csdef кардинально влияют на работу окружения, то файл разворачивается внутри пакета и не может быть модифицирован в процессе работы окружения. Если Вы решили что-то поменять, то необходимо выполнить повторное развертывание пакета в Ваше окружение, что приведет к временной его остановке.

Модифицировать этот файл можно как непосредственно, так и используя мастер в Visual Studio. Для перехода к мастеру достаточно щелкнуть на соответствующую роль в Visual Studio, что позволит Вам модифицировать только ту часть конфигурационного файла, которая относится к выбранной роли.

image

Несмотря на обилие конфигурационных элементов, сейчас нас будут интересовать лишь два, это Sites и Endpoints.

С помощью элемента Endpoints (или соответствующей вкладки мастера), Вы можете определить параметры доступа к роли через DNS, указав порт, протокол (http или https), закрыв или открыв роль для доступа снаружи. Наиболее интересным параметром является порт. Именно возможность указать порт позволяет организовать работу нескольких служб в рамках одного DNS. Если Вы не планируете получать доступ к роли (например, у вас есть Рабочая роль, которая обрабатывает очередь сообщений, но не предусматривает прямой коммуникации), то элементы Endpoint могут полностью отсутствовать. Создав необходимые роль, внимательно посмотрите, правильно ли Visual Studio расставил порты и, при необходимости, поправьте их.

Обратите внимание, что для Web ролей конкретный Endpoint прописывается с помощью элемента Binding:

   1:      <Sites>
   2:        <Site name="Web">
   3:          <Bindings>
   4:            <Binding name="Endpoint1" endpointName="Endpoint1" />
   5:          </Bindings>
   6:        </Site>
   7:      </Sites>
   

Если Вы были достаточно внимательными, то у Вас должен был возникнуть вопрос, почему мы можем задать целую коллекцию Endpoints или Sites для одной Web роли, ведь веб-приложение у нас одно. И вот тут мы рассмотрим еще одну возможность, позволяющую Вам использовать выделенные экземпляры на полную – создание нескольких веб-сатов или виртуальных приложений внутри одной Web роли.

Начиная с конца прошлого года, Web роли в Windows Azure стали размещать под управлением полноценного Internet Information Service (Full IIS). А раз мы имеем дело с полноценным IIS, то создавать веб-сайт или виртуальную директорию внутри одной роли можно без особых проблем.

Начнем с создания полноценного веб-сайта. К сожалению, Visual Studio пока не позволяет автоматизировать этот процесс. Поэтому Вам необходимо выполнить несколько действий.

Первым делом добавьте новый Web Site в Ваш проект. Этот сайт не будет добавлен как отдельная Web роль, да и в финальный пакет пока входить не будет. Поскольку Вы вряд ли решите разворачивать в Azure исходный код, выполните команду Publish Web Site, задав директорию для выходных файлов, готовых для развертывания (вероятнее всего Вы прекомпилируете все файлы). Вот эту директорию и можно использовать как исходную для развертывания еще одного веб-сайта.

На втором этапе необходимо модифицировать ServiceDefinition.csdef, тут Вы добавляете внутрь уже существующей Web роли еще один раздел Site, где указываете стандартные параметры (имя, Endpoint):

   1:        <Site name="Web" physicalDirectory="..\PrecompiledWeb\WebSite3">
   2:          <Bindings>
   3:            <Binding name="Endpoint1" endpointName="Endpoint1" 
   4:               hostHeader="www.dev-club.com.ua" />
   5:          </Bindings>
   6:        </Site>
 

Вот этот блок и позволяет включить подготовленный сайт в Ваш проект. При этом, Вы можете совершенно спокойно использовать один и тот же Endpoint для нескольких приложений, задав атрибут hostHeader, где указываете имя хоста, которое будет использоваться для доступа к сайту. Аналогичный подход можно использовать, если Вы хотите создать несколько сайтов, ссылающихся на одну физическую директорию (причем все они создаются под управлением различных Application Pool).

Таким образом, несколько сайтов на одном экземпляре – не проблема. Вот только нужно сделать какие-то вещи «руками».

Аналогично можно разворачивать и виртуальные директории внутри любого из сайтов. Для этого используется два элемента: VirtualApplication, позволяющий задать имя виртуальной директории, а также путь к физическому каталогу; VirtualDirectory – используется внутри VirtualApplication и позволяет сформировать структуру виртуальных директорий виртуального приложения.

Таким образом, используя три экземпляра, Вы можете создавать любое количество сайтов и веб-служб на одном из них, а два экземпляра у Вас еще остаются для развертывания Рабочей роли (или двух), а также для масштабирования решенияJ

Чтобы увидеть все эти вещи в действии, Вы можете использовать скрипты из Windows Azure Training Kit, а также посетить наш Online training по Windows Azure.

Реклама

Written by Sergiy Baydachnyy

29.03.2011 в 11:18

Опубликовано в Windows Azure

Tagged with ,

комментариев 5

Subscribe to comments with RSS.

  1. Серега, дал бы людям ссылку на правильный ресурс
    http://things.smarx.com/

    shatokhin

    29.03.2011 at 12:53

  2. […] я писал ранее, сегодня у разработчиков много различных […]


Добавить комментарий

Заполните поля или щелкните по значку, чтобы оставить свой комментарий:

Логотип WordPress.com

Для комментария используется ваша учётная запись WordPress.com. Выход / Изменить )

Фотография Twitter

Для комментария используется ваша учётная запись Twitter. Выход / Изменить )

Фотография Facebook

Для комментария используется ваша учётная запись Facebook. Выход / Изменить )

Google+ photo

Для комментария используется ваша учётная запись Google+. Выход / Изменить )

Connecting to %s

%d такие блоггеры, как: