Живая миграция контейнеров: взгляд изнутри
Підписуйтеся на Telegram-канал «DOU #tech», щоб не пропустити нові технічні статті
Давайте рассмотрим тему, которая не в полной мере раскрыта в современном мире ИТ: живая миграция контейнеров, как она работает за кулисами и какие проблемы решает. Спрос на данную технологию продолжает стремительно расти, поскольку она открывает новые возможности, предоставляя больше свободы в управлении жизненным циклом приложений.
Живая миграция — что это?
Живая миграция контейнеров подразумевает собой процесс перемещения приложения между разными физическими машинами или облаками без прерывания работы приложения и разрыва связи с пользователем. Память, файловая система и сетевое соединение контейнеров, запущенные поверх «голой» аппаратуры, передаются от исходного хост-компьютера к месту назначения, поддерживая рабочее состояние без прерывания работы.
Проблемы, которые решает живая миграция
Существует несколько проблем, которые может решить живая миграция:
Период простоя во время обслуживания аппаратуры
Для того, чтобы модифицировать/заменить аппаратное оборудование, системный администратор должен перенести всех пользователей с одного аппаратного узла на другой без простоя и прерывания работы, что само по себе является сложно-выполнимой, а зачастую и вообще невозможной задачей.
Несбалансированная загрузка кластера
При слишком высокой нагрузке на аппаратный узел, необходимо выполнить процесс ребалансировки, для чего нужно будет внедрить специфические конфигурации приложения, что в свою очередь сузит/уменьшит выбор рабочих нагрузок, которые могут хоститься в кластере
Проблемы с облаком
На современном ИТ рынке представлено много разных облачных решений, и время от времени у них случаются различные казусы, такие как период простоя, изменение ценовой политики или даже ухудшение качества предоставляемых услуг. В большинстве случаев, невозможно мигрировать приложение с одного облачного провайдера на другой.
Альтернативные Решения
Все выше упомянутые проблемы можно решить, и сейчас мы расскажем несколько вариантов решения данных проблем без помощи живой миграции.
Запланированные периоды простоя. Для выполнения технических работ по обслуживанию кластера, нужно пройти три шага:
1. Заранее уведомить пользователей (владельцев приложений) об окне обслуживания и возможном периоде простоя
2. Отключить аппаратное оборудование
3. Подключить обратно только после того, как все необходимые изменения будут выполнены В этом случае проблемой является относительно большой период простоя.
Перенаправление трафика. Чтобы выполнить обслуживание кластера необходимо восстановить копию каждого приложения в другом аппаратном узле, затем перенаправить трафик к этой новой копии и закрыть предыдущую. В этом случае проблемой является сложность данного процесса — необходимо иметь специально разработанные приложения для получения высокой доступности и синхронизации данных. Кроме того, для выполнения этой задачи может потребоваться больше аппаратных ресурсов.
Микросервисы. Детальное деление сервисов приложений на отдельные контейнеры и их распределение по различным физическим серверам помогает избежать периодов простоя в случае сбоя аппаратного обеспечения. Вышедшие из строя контейнеры будут автоматически восстановлены в активном аппаратном узле. Однако в этом случае проблемой является опять же сложность данного процесса, поскольку приложения в кластере должны быть разработаны таким образом, чтобы можно было управлять высокой доступностью и восстановлением процесса после сбоя.
Как же работает Живая Миграция, преимущества и примеры ее использования, а также возможные подводные камни можно узнать в полной версии статьи на Хабре habrahabr.ru/...any/jelastic/blog/313512
3 коментарі
Додати коментар Підписатись на коментаріВідписатись від коментарів