В прошлый раз мы рассмотрели методы Zero Downtime Upgrade, которые могут быть применены в рамках PaaS варианта развертывания приложения Microsoft Azure. Сегодня мы сосредоточимся на способах, которые можно применить не только к облачным сервисам, а обычным виртуальным машинам в рамках IaaS развертывания.

Load Balanced Endpoint

Как мы знаем любая виртуальная машина, которая обсуживает запросы к вашему приложению делает это через определенный открытый порт (к примеру 80, 8080, 443 и т.д.). Если виртуальных машин несколько, то внутренний балансировщик нагрузки Microsoft Azure распределяет трафик между этими виртуальными машинами. Давайте подумаем, как можно использовать эту возможность для Zero Downtime Upgrade.

Представим, что у нас есть несколько виртуальных машин в рамках одного облачного сервиса. Напомню, что к внутренний балансировщик нагрузки перераспределяет трафик только в рамках одного DNS, то есть в рамках одного облачного сервиса.

Пускай на этих виртуальных машинах используется версия 1.0 нашего приложения. Задача как всегда обновить приложение до версии 1.1 незаметно для пользователя.

Подход Load Balanced Endpoint предлагает следующий механизм: вы разворачиваете дополнительные виртуальные машины в рамках существующего облачного сервиса с использованием тех же самых портов и конфигурации как исходная версия. Проще всего это сделать с помощью масштабирования (scaling). Допустим было 2 машины, стало 4. Это также позволит избежать просадки производительности приложения во время обновления.

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

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

Давайте теперь посмотрим на плюсы и минусы такого подхода.

Плюсы:

Простой процесс масштабирования
Поддержка IaaS развертывания
Отсутствие просадки по производительности во время обновления приложения
Дополнительные финансовые затраты нужны только на момент обновления

Минусы:

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

Как мы видим данный способ представляет собой практически кальку с Fault/Update доменов, которые использует Microsoft для обеспечения 99,95% SLA для нескольких виртуальных машин в рамках облачных сервисов или availability set. Разница лишь в том, что механизм обновления необходимо производить вручную либо автоматизировать с помощью Microsoft Azure Automation к примеру.

Так что данный механизм обновления вполне применим на практике для приложений, развернутых в рамках IaaS.

Traffic Manager

Все предыдущие методы, которые мы рассматривали пригодны для использования только в рамках одного подхода к развертыванию приложения. Однако возникает логичный вопрос. Неужели нет такого средства, которое можно было бы использовать как в PaaS, так и в IaaS развертывании?

Такой сервис действительно есть и называется он – Traffic Manager. В то время как внутренний балансировщик нагрузки для конкретного облачного сервиса не представляется возможным настроить, Traffic Manager предоставляет возможность конфигурации распределения трафика.

Распределять трафик можно не только между разными виртуальными машинами, но и облачными сервисами, а также определять алгоритм, по которому этот самый трафик будет распределяться.

Итак, для того чтобы реализовать сценарий Zero Downtime Upgrade при использовании Traffic Manager нам необходимо направить пользовательский трафик не на DNS конкретного облачного сервиса, а на DNS, который определяется при создании профиля Traffic Manager. Он будет иметь вид {name}.trafficmanager.net. Естественно при необходимости его можно привязать к нужному CNAME регистратора имен.

Допустим версия 1.0 нашего приложения размещена в рамках prod.cloudapp.net облачного сервиса. Для новой версии мы создаем отдельный облачных сервис. Допустим stage.cloudapp.net. После развертывания новой версии приложения мы можем перенаправить трафик со старой версии приложения на новую.

Соответственно, как только весь трафик ушел на новую версию приложения старое окружение может быть удалено.

Давайте теперь посмотрим на плюсы и минусы такого подхода.

Плюсы:

Изолированное окружение для тестирования
Поддержка виртуальных машин, облачных сервисов, а также веб-сайтов Microsoft Azure
Конфигурация виртуальных машин новой и старой версии приложения могут отличаться
При необходимости есть возможность «вернуть все назад»

Минусы:

Дополнительные затраты на Traffic Manager сервис
Дополнительные затраты в процессе обновления
Процесс обновления полностью ручной либо требует автоматизации
Обновление DNS кэша регистратора имен требует времени

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

Это все, что я хотел вам рассказать о механизмах Zero Downtime Upgrade, которые могут быть применены на платформе Microsoft Azure. Вполне возможно, что я что-то упустил. Отписывайтесь в комментариях по этому поводу!

Спасибо всем за внимание!

Zero Downtime Upgrade для приложения в Microsoft Azure. Часть 2: IaaS