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

    У минулий раз ми розглянули методи 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. Цілком можливо, що я щось упустив. Відписуйтеся в коментарях з цього приводу!
 
Спасибі всім за увагу!
    
Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.