В последний раз Мы рассмотрели методы обновления с нулевым временем простоя, которые можно применять в рамках варианта PaaS для развертывания приложения Microsoft Azure. Сегодня мы сосредоточимся на методах, которые можно применять не только к облачным сервисам, но и к обычным виртуальным машинам в рамках развертывания IaaS.
Конечная точка со сбалансированной нагрузкой
Как мы знаем, любая виртуальная машина, обрабатывающая запросы к вашему приложению, делает это через определенный открытый порт (например, 80, 8080, 443 и т. д.).Если имеется несколько виртуальных машин, внутренний балансировщик нагрузки Microsoft Azure распределяет трафик между этими виртуальными машинами.
Давайте подумаем, как мы можем использовать эту возможность для обновления с нулевым временем простоя.
Представим, что у нас есть несколько виртуальных машин в рамках одного облачного сервиса.
Напомню, что внутренний балансировщик нагрузки перераспределяет трафик только в пределах одного DNS, то есть внутри одного облачного сервиса.
Пусть эти виртуальные машины используют версию 1.0 нашего приложения.
Задача, как всегда, незаметно для пользователя обновить приложение до версии 1.1. Подход конечной точки с балансировкой нагрузки предлагает следующий механизм: вы развертываете дополнительные виртуальные машины внутри существующей облачной службы, используя те же порты и конфигурацию, что и исходная версия.
Самый простой способ сделать это — масштабировать.
Допустим, было 2 машины, теперь стало 4. Это также позволит избежать падения производительности приложения во время обновления.
После этого вы поочередно обновляете версию приложения на виртуальных машинах внутри облачного сервиса.
Естественно, чтобы избежать перенаправления трафика на обновляемую виртуальную машину, мы должны отключить для нее соответствующий порт. После этого внутренний балансировщик нагрузки начинает перераспределять трафик между старой и новой версиями приложения.
Вы можете обновить все виртуальные машины, а можете обновить, скажем, 2 из 4, а затем просто удалить ненужные на старой версии приложения.
Скажем еще раз, уменьшив масштаб.
Давайте теперь посмотрим на плюсы и минусы этого подхода.
Плюсы:
- Простой процесс масштабирования
- Поддержка развертывания IaaS
- Никакого снижения производительности при обновлении приложения
- Дополнительные финансовые затраты необходимы только во время продления.
- Процесс обновления полностью ручной или требует автоматизации.
- Дополнительные расходы в процессе обновления
- Конфигурация виртуальных машин старой и новой версии должна совпадать.
- Обновление приложения в рамках развертывания PaaS не поддерживается.
Единственное отличие состоит в том, что механизм обновления должен выполняться вручную или автоматически, например, с помощью Microsoft Azure Automation.
Так что этот механизм обновления вполне применим на практике для приложений, развернутых в рамках IaaS.
Менеджер трафика
Все предыдущие методы, которые мы рассмотрели, подходят для использования только в рамках одного подхода к развертыванию приложений.Однако возникает закономерный вопрос.
Нет ли инструмента, который можно было бы использовать как при развертывании PaaS, так и при развертывании IaaS? Такой сервис действительно существует и называется он 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.
- Конфигурация виртуальных машин новой и старой версии приложения может отличаться
- При необходимости есть возможность «вернуть всё обратно»
- Дополнительные расходы на услугу «Диспетчер трафика»
- Дополнительные расходы в процессе обновления
- Процесс обновления полностью ручной или требует автоматизации.
- Обновление DNS-кеша регистратора имен требует времени.
Описываемый сервис имеет ряд достаточно серьезных преимуществ перед всеми описанными ранее.
Использование его в производственной среде вполне оправдано, но нужно помнить о дополнительных затратах при его использовании.
Это все, что я хотел рассказать вам о механизмах Zero Downtime Upgrade, которые можно применить на платформе Microsoft Azure. Вполне возможно, что я что-то упустил.
Дайте мне знать об этом в комментариях! Спасибо всем за внимание! Теги: #Microsoft Azure #azure
-
Развлечения Через Планшет Android
19 Oct, 24 -
Ампер, Андре Мари
19 Oct, 24 -
Алгоритм Соловея-Штрассена
19 Oct, 24 -
Первый Нетбук Lifebook От Fujitsu
19 Oct, 24 -
Кризис Видеокарты – Что Делать И Кто Виноват
19 Oct, 24 -
Linkmeup. Выпуск 4
19 Oct, 24 -
Google Camera – Хайп Или Замена Зеркалке?
19 Oct, 24
