Жива міграція контейнерів: погляд зсередини

Сьогодні ми розглянемо тему, яка не повною мірою розкрито в сучасному світі ІТ: жива міграція контейнерів, як вона працює за лаштунками і які проблеми вирішує. Попит на дану технологію продовжує стрімко зростати, оскільки вона відкриває нові можливості, надаючи більше свободи в управлінні життєвим циклом додатків.

Жива міграція – що це?

Жива міграція контейнерів передбачає собою процес переміщення програми між різними фізичними машинами або хмарами без переривання роботи програми і розриву зв'язку з користувачем. Пам'ять, файлова система і мережеве з'єднання контейнерів, запущені поверх «голої» апаратури, передаються від вихідного хост-комп'ютера до місця призначення, підтримуючи робочий стан без переривання роботи.
image


Проблеми, які вирішує жива міграція

Існує кілька проблем, які може вирішити жива міграція:

  • Період простою під час обслуговування апаратури
Для того, щоб модифікувати/замінити апаратне обладнання, системний адміністратор повинен перенести всіх користувачів з одного апаратного вузла на інший без простою і переривання роботи, що само по собі є важко здійсненним, а часто і взагалі неможливою завданням.

  • Незбалансована завантаження кластера
При дуже високому навантаженні на апаратний вузол, необхідно виконати процес ребалансування, для чого потрібно буде впровадити специфічні конфігурації програми, що в свою чергу звузить/зменшить вибір робочих навантажень, які можуть хоститься в кластері

  • Проблеми з хмарою
На сучасному ІТ ринку представлено багато різних хмарних рішень, і час від часу у них трапляються різні казуси, такі як період простою, зміна цінової політики або навіть погіршення якості наданих послуг. У більшості випадків, неможливо мігрувати додаток з одного хмарного провайдера на інший.

Альтернативні Рішення

Всі вище згадані проблеми можна вирішити, і зараз ми розповімо декілька варіантів вирішення даних проблем без допомоги живої міграції.

  • Заплановані періоди простою. Для виконання технічних робіт по обслуговуванню кластера, потрібно пройти три кроки:

    1. Заздалегідь повідомити користувачів (власників додатків) про вікні обслуговування і можливе періоді простою
    2. Вимкнути апаратне обладнання
    3. Підключити назад тільки після того, як всі необхідні зміни будуть виконані. У цьому випадку проблемою є відносно великий період простою.
  • Перенаправлення трафіку. Щоб виконати обслуговування кластера необхідно відновити копію кожного додатка в іншому апаратному сайті, потім перенаправити трафік до цієї нової копії і закрити попередню. У цьому випадку проблемою є складність даного процесу необхідно мати спеціально розроблені програми для отримання високої доступності та синхронізації даних. Крім того, для виконання цієї задачі може знадобитися більше апаратних ресурсів.
  • Микросервисы. Детальний розподіл сервісів додатків на окремі контейнери та їх розподілення по різним фізичним серверів допомагає уникнути періодів простою в разі збою апаратного забезпечення. Вийшли з ладу контейнери будуть автоматично відновлені в активному апаратному сайті. Однак у цьому випадку проблемою є знову ж таки складність даного процесу, оскільки програми в кластері повинні бути розроблені таким чином, щоб можна було керувати високою доступністю і відновленням процесу після збою.

Як Працює Жива Міграція

Давайте розглянемо процес живої міграції з технічної сторони на прикладі наступної схеми:

image

  • Вихідний Вузол (Source Node) — місце розташування контейнера перед живою міграцією
  • Вузол призначення (Destination Node) — місце розташування контейнера після живої міграції
Щоб виконати міграцію, платформа заморожує контейнер у вихідному вузлі, блокуючи пам'ять, процеси, файлову систему і мережеві з'єднання, і зберігає стан цього контейнера. Після цього він копіюється в вузол призначення. Платформа відновлює стан і розморожує контейнер в даному вузлі. Потім, у вихідному вузлі здійснюється процес швидкого очищення даних мігруючого контейнера.

Все досить просто: ви отримуєте, копіюєте і відновлюєте стан контейнера. Проте, в цьому випадку потрібно брати до уваги період заморозки, який потрібно враховувати при розробці (архітектури) додатків, так як цей момент може виявитися критичним для деяких з них.

Існує два способи здійснення живої міграції. Одним з них є попереднє копіювання пам'яті. Якщо ви хочете перенести контейнер, платформа направить отслеживаемую пам'ять на вихідний вузол, і буде копіювати цю пам'ять одночасно з вузлом призначення до тих пір, поки різниця не стане мінімальним. Після цього платформа заморожує контейнер, отримує решту стан, переносить його на вузол призначення, відновлює і розморожує його.

image

Інший спосіб —пост-копіювання пам'яті, або іншими словами — лінива міграція. Система спочатку заморожує контейнер у вихідному вузлі, отримує стан найбільш швидко мінливих сторінок пам'яті, переносить стан на вузол призначення, відновлює його і розморожує контейнер. Інша частина стану у фоновому режимі копіюється з вихідного вузла на вузол призначення.

image

Зазвичай, в залежності від програми, час заморожування для кожного контейнера займає від 5 до 30 секунд. Це дійсно короткий термін у порівнянні з можливими годинами простою під час обслуговування кластера.

Приклади Використання Живої Міграції

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

  • Перерозподіл завантаження
Жива міграція дозволяє пере-балансувати (рівномірно розподілити) навантаження з допомогою міграції контейнерів з одного апаратного вузла в інший. Цей сценарій також можна автоматизувати, активований спеціальний алгоритм диспетчеризації і відповідні тригери.

image

  • Висока доступність між зонах доступності в центрах обробки даних (ЦОД)
Провайдер хмарних послуг може попередньо сконфігурувати і запропонувати набір зон доступності апаратних засобів усередині одного або декількох центрів обробки даних. Як результат, кінцеві користувачі одержують більше можливостей для забезпечення високої доступності, здійснюючи живу міграцію контейнерів без участі адміністраторів системи з однієї зони доступності в іншу.

  • Перехід до іншого хмарного провайдера
Жива міграція надає користувачам свободу вибору — вони не прив'язані до певного хмарного провайдера, і можуть перенести свої додатки на альтернативне хмара, без змін конфігурації і повторного розгортання під час міграції.

image

Можливі Підводні Камені і Недоліки

При всіх перевагах живої міграції, також існують кілька недоліків, які потрібно приймати до уваги перед початком міграції:

  • Під час живої міграції ви можете помітити деяке зниження продуктивності поки що контейнер знаходиться у стані заморозки. Для деяких додатків це критичний недолік, так як вони не сприймають будь-яке зниження продуктивності (наприклад, монолітні високонавантажених онлайн додатки). Однак, короткочасне заморожування не є серйозним недоліком для більшості додатків в інтернеті, особливо якщо говорити про веб-додатках.
  • Інша складність пов'язана з великим обсягом швидко мінливих даних, які не так легко перенести від одного хмарного провайдера до іншого. Період очікування і великий обсяг даних можуть перешкоджати успішному виконанню живої міграції.
  • Публічні IP-адреси в мульти-хмарі. Неможливо перенести контейнери з публічним IP-адресою від одного хмарного провайдера до іншого, оскільки IP-адреса прив'язаний до конкретного провайдера.
  • Якщо додаток всередині контейнера використовує пропріетарний API або пропрієтарні хмарні сервіси конкретного хмарного провайдера, виконати живу міграцію з одного хмари на інше може бути дуже складно або навіть неможливо.

Жива Міграція на Сучасному IT-Ринку

Які компанії пропонують живу міграцію контейнерів на сьогоднішній день?

  • Virtuozzo – ця компанія, насправді, створила технологію живої міграції контейнерів; вони були піонерами у цій сфері і на сьогоднішній момент пропонують движок живої міграції, що дозволяє проводити атомарну міграцію контейнера з одного фізичного хоста на інший.
  • runC від Open Containers Initiative є ще одним багатообіцяючим контейнерним рішенням з підтримкою живої міграції на базі CRIU.
  • Jelastic пропонує платформу з оркестрацией контейнерів, яка надає живу міграцію як атомарних контейнерів, так і додатків зі складною топологією розгортання між апаратними хостами, зонами доступності, центрами обробки даних і хмарними провайдерами.

Демо: Міграція Minecraft в Режимі Реального Часу

Для того, щоб побачити процес міграції додатки Minecraft з AWS на Azure в режимі реального часу без простоїв, перегляньте наступне відео:



Жива міграція контейнерів все ще є відносно новою технологією на ринку. Тим не менш, переваги цієї технології для сучасного бізнесу очевидні — ніяких простоїв під час обслуговування, не потрібно витрачати багато зусиль на підготовку і перевірку. Саме тому жива міграція є відмінним рішенням для кращої доступності та гнучкості. Поділіться своїм досвідом міграції контейнерів між хмарами або датацентрами в режимі реального часу.
Джерело: Хабрахабр

0 коментарів

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