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

Давайте рассмотрим тему, которая не в полной мере раскрыта в современном мире ИТ: живая миграция контейнеров, как она работает за кулисами и какие проблемы решает. Спрос на данную технологию продолжает стремительно расти, поскольку она открывает новые возможности, предоставляя больше свободы в управлении жизненным циклом приложений.

Живая миграция — что это?

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

Проблемы, которые решает живая миграция

Существует несколько проблем, которые может решить живая миграция:

Период простоя во время обслуживания аппаратуры
Для того, чтобы модифицировать/заменить аппаратное оборудование, системный администратор должен перенести всех пользователей с одного аппаратного узла на другой без простоя и прерывания работы, что само по себе является сложно-выполнимой, а зачастую и вообще невозможной задачей.

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

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

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

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

Запланированные периоды простоя. Для выполнения технических работ по обслуживанию кластера, нужно пройти три шага:
1. Заранее уведомить пользователей (владельцев приложений) об окне обслуживания и возможном периоде простоя
2. Отключить аппаратное оборудование
3. Подключить обратно только после того, как все необходимые изменения будут выполнены В этом случае проблемой является относительно большой период простоя.

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

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

Как же работает Живая Миграция, преимущества и примеры ее использования, а также возможные подводные камни можно узнать в полной версии статьи на Хабре habrahabr.ru/...any/jelastic/blog/313512

👍ПодобаєтьсяСподобалось0
До обраногоВ обраному0
LinkedIn
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

мало того, что репост на убогий Хабр, так еще ********* перевод
www.infoq.com/.../container-live-migration

стыд и позор.

Почему убогий, Егор?

Продолжая тему, оригинал

********* перевода
написан
Ruslan Synytsky is CEO and co-founder of Jelastic

Что же мы видим перейдя на
убогий Хабр?
Блог компании Jelastic

Автор: @jelastic
😕

З.ы. спасибо за юзер кейс, как не упоминая о чем-то в статье, упомянуть об этом несколько раз в комментариях используя «наброс» и «анонимов» 😉

Виноват. Смотрел только на автора статьи на хабре и здесь.
Статью просто видел намного раньше на указанном ресурсе, чем тут.

А хабр убог by design, но это совсем другая история :)

Підписатись на коментарі