Содержание к диссертации
Введение
Глава 1. Обзор существующих решений 10
1.1 Понятия виртуализации 10
1.2 Виртуализация на уровне ОС 15
1.3 Контейнеры Linux 17
1.4 Запуск задач на вычислительных кластерах 20
1.5 Контейнеры для вычислительных кластеров 21
1.6 Виртуальные вычислительные сети 25
1.7 Анализ динамической миграции 26
1.8 Система управления ресурсами 31
Выводы по главе 1 40
Глава 2. Организация вычислений на кластере 41
2.1 Создание виртуальных кластеров 41
2.2 Выбор аппаратных и программных средств 41
2.3 Выбор средств для случая виртуализации на уровне ОС 42
2.4 Выбор узлов 46
2.5 Алгоритм кластеризации 51
2.6 Описание методики 53
Выводы по главе 2 55
Глава 3. Архитектура виртуальной вычислительной сети 56
3.1 Общие сведения 56
3.2 Виртуальные сети для контейнеров 56
3.3 Интерфейс veth 58
3.4 Интерфейс macvlan 61
3.5 Виртуальные сети для ВМ 66
3.6 Интерфейс vxlan 73
3.7 Тестирование виртуальных интерфейсов для контейнеров 73
3.8 Архитектура виртуальной сети 79
Выводы по главе 3 84
Глава 4. Миграция вычислительных задач 85
4.1 Миграция виртуальных машин 85
4.2 Миграция контейнеров 87
4.3 Миграция процессов 88
4.4 Средства для выполнения C/R процессов 90
4.5 Поддержка C/R системами управления ресурсами 91
4.6 Средства для выполнения миграции процессов 92
4.7 Поддержка миграции системами управления ресурсами 92
4.8 Методика миграции задач 93
Выводы по главе 4 102
Заключение 103
Список сокращений и условных обозначений 104
Библиографический список 106
- Понятия виртуализации
- Выбор узлов
- Тестирование виртуальных интерфейсов для контейнеров
- Методика миграции задач
Понятия виртуализации
Теперь во всем мире, информационные технологии (ИТ) занимают одну из ведущих ролей в жизнедеятельности человека. Благодаря внедрению на предприятия информационных систем и высокоэффективного программного обеспечения, ускоряется их деятельность и повышается качество их работы. Виртуализация — одна из таких технологий.
В компьютерных науках виртуализация заключается в создании виртуальной версии ресурса, такой как операционная система, сервер, устройство хранения. Она позволяет нескольким операционным системам или нескольким приложениям одновременно работать на одном физическом ПК. Она также позволяет использовать всю емкость физической машины, распределяя ее между разными пользователями. Также под технологиями виртуализации понимаются процессы преобразования аппаратного обеспечения в программное. Таким образом, с несколькими виртуальными машинами можно работать с общими аппаратными ресурсами. Общие подходы к виртуализации заключаются в проведении установки программного слоя либо непосредственно в операционные системы, либо в аппаратные компоненты компьютера. Установка программных слоев предполагает возможность по созданию виртуальных машин, распределению аппаратных ресурсов [1 - 6].
Виртуализация не новая технология. Она появилась в 1960-х с IBM, которая создал первую систему виртуализации серверов. В то время только несколько компаний уже имеют большие компьютеры, также называемые мейнфреймами (mainframes). Эти мэйнфреймы являются типами централизованных компьютеров, которые имеют очень высокую мощность, что позволяет им управлять сеансами разных пользователей разных терминалов, которые подключены к ним. Это означает, что это центральный компьютер, который выполняет все процедуры. Но проблема оптимизации аппаратных ресурсов уже возникает в то время. В 1967 году IBM представил первую систему на компьютере 360/67 для решения этой проблемы. Эта новая система, которая считается первой системой виртуализации, называлась CP/CMS. Его работа основана на интерактивном программном обеспечении для интерпретации команд (CMS) и генераторе виртуальных машин.
Архитектура x86 появилась в 1980-х годах, и ее популярность привела к появлению персональных компьютеров в нескольких компаниях. Вычислительная работа уже больше не выполняется одним центральным компьютером, как раньше. Мейнфреймы сменяются персональными компьютерами. Технология виртуализации используется все реже и реже. Потом появляется много приложений «клиент - сервер» что приводит к появлению распределенных вычислений [7 - 11].
В тоже время, анализ показывает, что в начале 2000-х годов технология виртуализации получила второе рождение с введением концепции полной виртуализации VMware-компании. Использование виртуализации становится широко распространенным. Появляются такие инструменты, как QEMU, KVM [12, 13], Хеп [14], Virtual Box [15]. Все эти инструменты позволили развить виртуализацию на архитектурах x86. В настоящее время виртуализация очень известна. Мы слышим о виртуализации везде, особенно с появлением облачных вычислений.
Как правила, существуют различные формы виртуализации:
виртуализация приложений;
виртуализация ОС;
виртуализация компьютерной сети;
виртуализация серверов;
виртуализация систем хранения;
виртуализация сервисов;
виртуализация персональных компьютеров (ПК). Виртуализация программного обеспечения предполагает, что хост-операционная система, на которой работает платформа виртуализации, управляет аппаратными ресурсами гостевой операционной системы и эмулирует работу аппаратных компонентов. Внедрение такой платформы довольно сложно.
В отличие от технологии программного обеспечения, аппаратная виртуализация позволяет получать изолированные гостевые системы, управляемые непосредственно гипервизором. Такой подход может облегчить реализацию платформы виртуализации.
Эмуляторы аппаратного обеспечения — в хост-системах проводится создание виртуальной машины, моделирующей какую-то иную аппаратную архитектуру.
Технологии полной виртуализации, использующие виртуальные машины и гипервизоры, выступающие в качестве посредника между гостевыми операционными системами и реальным оборудованием. Также производится перехват некоторых инструкций защищенного режима и их обработка внутри гипервизоров, поскольку доступность аппаратуры не может быть обеспечена посредством обращения из операционных систем, доступ к ней осуществляется посредством гипервизора [16 - 18].
Паравиртуализационные системы. Системы, требующие проведения модификации гостевых операционных систем. В данном случае обеспечиваются высокие показатели производительности, близкие к производительности невиртуализированных систем [19, 20].
Виртуализация на уровне операционной системы. Данная технология представляет собой операционную систему, которая установлена в одном экземпляре и изолирована от других серверов, работающих под ее управлением.
Одной из особенностей виртуализации является ее многозадачность. Точнее говоря, этот процесс может быть применен во многих областях ИТ. Виртуализация действительно очень популярна в современном мире. В практике можно виртуализировать почти все: сети, данные для хранения и приложения. Именно поэтому на базе этой технологии можно построить частное или публичное облако. Это обеспечивает целый ряд преимуществ применение виртуализации, что приводит к:
сокращению затрат на закупку и обслуживание физических серверов;
оптимизации использования вычислительных мощностей;
повышению энергоэффективности.
При этом виртуализация на уровне ОС - одна из наиболее распространенных на сегодняшний день.
В отличие от аппаратной виртуализации, которая эмулирует аппаратную среду и может запускать очень широкий спектр гостевых ОС, экземпляр операционной системы может быть запущен в контейнере только с тем же ядром, что и хост-операционная система. В этом случае нет дополнительных накладных расходов на ресурсы для эмуляции виртуального оборудования и выполнения полного экземпляра ОС, типичного для виртуализации оборудования.
Виртуализация на уровне ОС не работает с гипервизорами. Сама хост -операционная система несет ответственность за все — это означает разделение аппаратных ресурсов и независимую поддержку друг друга. И так любой пользователь может настроить контейнер в соответствии с его потребностями, установить программное обеспечение, перезагрузить или даже выключить.
Гипервизор - это программное обеспечение или аппаратная схема. Во время аппаратной виртуализации уникальную работу различных операционных систем на одном ПК обеспечивает гипервизор. В этом случае основной целью гипервизора является предоставление изолированной среды виртуальной машины, а также контроль доступа виртуальной машины и гостевой ОС к различным физическим ресурсам ПК [21].
Существуют 2 основных типа гипервизоров. Первый гипервизор запускается как программное обеспечение управления непосредственно на аппаратной стороне ПК. Операционная система виртуальных машин выполняется выше этого уровня. Этот тип гипервизора обеспечивает надежность, безопасность и производительность, поскольку его работа вообще не зависит от операционной системы. Существуют различные решения, которые используют этот тип гипервизора:
Citrix XenServer[22];
VMware ESX.
Гипервизор типа 2 работает в основном над операционной системой хоста. После этого все гостевые операционные системы виртуальных машин размещаются выше уровня. Примеры: VMware, Parallels[23], QEMU.
Первый гипервизор гораздо более эффективен, чем второй, поскольку он имеет большие возможности оптимизации и не нуждается в ресурсах для загрузки и поддержания операционной системы.
В заключение, анализ показывает, что лучше всего использовать виртуализацию на уровне ОС, потому что она наиболее производительна и удобна для большинства задач на сервере Linux. В этом случае создание и перезагрузка сервера будут максимально быстрыми, что упростит задачу переноса контейнеров Linux с одного сервера на другой.
Выбор узлов
Как было показано ранее, выбор физических узлов для развертывания виртуального кластера — один из ключевых вопросов. Возможность миграции ВМ накладывает еще большие ограничения. Как результат, для эффективной работы виртуальных кластеров с возможностью динамической миграции ВМ требуется грамотный выбор физических узлов, схожих по многим критериями.
Для решения данной задачи можно воспользоваться классификацией и/или кластеризацией имеющихся физических ресурсов. Под «классификацией» понимается распределение изучаемых объектов по некоторым признакам в рамках заранее оговоренных классов. Под «кластеризацией» понимается аналогичное разбиение множества объектов на несколько классов, однако в данном случае эти классы заранее неизвестны. В случае классификации используют обучающее множество для получения модели и тестовое множество для проверки модели. Решением задачи классификации является соотнесение изучаемых объектов с одним из заданных классов. Примеры алгоритмов кластеризации приведены в [74, 75], рассмотрение различных подходов и отдельных алгоритмов кластеризации можно найти в [76-79]. В случае же кластеризации классы неизвестны и получаются в процессе решения задачи кластеризации. Хотя число классов может быть задано заранее. Критерием принадлежности объекта к одному из кластеров (классов) является «достаточная степень схожести» объекта с другими объектами, уже отнесенными к этому классу. Критерием получения отдельных классов является «значительное отличие» объектов классов. И тот, и другой критерий в общем случае являются некоторыми эвристиками.
Для получения групп узлов, подходящих для развертывания и возможной миграции ВМ в рамках виртуальных кластеров, предлагается использовать кластеризацию узлов по их характеристикам, как аппаратным, так и программным. На первый взгляд, может показаться, что данная проблема может быть решена «вручную» и не требует средств автоматизации. Однако в современном мире существует множество различных аппаратных средств, значительно отличающихся по характеристикам. Разнообразие программных средств также велико. Так, существует множество различных операционных систем, в процессе разработки которых было выпущено множество различных версий. В случае использования виртуализации на уровне ОС даже простое обновление ОС одного из узлов может привести к тому, что контейнеры на других узлах не смогут мигрировать на этот узел. Кроме того, число узлов может быть очень велико, а в процессе эксплуатации физического кластера могут быть добавлены новые узлы. Таким образом, автоматизация процесса построения разбиения имеющихся узлов кластера и добавляемых в кластер позволит повысить скорость и точность выполнения данного процесса. Получение же оптимального разбиения — ключевая задача для создания динамически меняющегося набора виртуальных кластеров, особенно в случае виртуализации на уровне ОС.
В случае выбора метода для конкретного случая — разбиения физических узлов на группы - необходимо учитывать следующие особенности:
число узлов (объектов для кластеризации) может быть велико;
набор характеристик узлов (размерность вектора признаков), как аппаратных, так и программных, может быть очень большим;
встречаются и категориальные (например, архитектура), и числовые характеристики (например, тактовая частота процессора);
разные характеристики могут иметь разный вес. В общем случае отдельные характеристики могут иметь различный вес в случае рассмотрения их в свете конкретной задачи. Однако разбиение множества узлов на отдельные классы может быть выполнено как базовый этап, выполняемый перед назначением конкретных задач (контейнеров для задач). Такой этап позволит повысить скорость и эффективность назначения в дальнейшем.
Можно выделить, к примеру, следующие характеристики физического узла, важные в данном случае (для запуска виртуальных вычислительных кластеров, использующих виртуализацию на уровне ОС):
тип архитектуры узла (например, NUMA, SMP);
архитектура процессора;
тактовая частота процессора;
поддержка векторных операций процессором;
поддержка других расширений процессора;
количество АЛУ;
количество потоков;
количество ядер;
количество процессоров;
объем кэша L1 процессора;
объем кэша L2 процессора;
объем кэша L3 процессора;
объем оперативной памяти;
тип оперативной памяти;
частота шины памяти;
число каналов памяти;
объем жесткого диска (если диск имеется);
производительность жесткого диска (если диск имеется);
скорость сетевого соединения;
принадлежность узла к той или иной подсети (расположение узла в сети относительно других узлов) и скорость обмена данными с другими узлами данной подсети и с узлами в других подсетях;
ОС на узле;
версия ОС на узле;
конфигурация ОС;
наличие отдельных пакетов ПО на узле;
доступность отдельных файлов и директорий (например, по NFS) и производительность такого доступа.
Как видно, имеется множество характеристик, то есть размерность данных велика. Кроме того, отдельные характеристики и вовсе не определить в общем случае (например, наличие отдельных файлов, конфигурация ОС). При подготовке данных могут встретиться и другие проблемы.
Многие эффективные алгоритмы кластеризации работают хуже в случае данных большой размерности. Для их эффективной работы размерность данных необходимо сократить. Для этой цели можно применить факторный анализ, позволяющий выявить взаимосвязь между отдельными параметрами. И в данном случае такой анализ может быть проведен с большой эффективностью. К примеру, характеристики процессора определятся конкретной моделью. Можно рассмотреть отдельные семейства разного ценового диапазона и год выпуска: процессоры разных семейств разного года выпуска будут иметь разную производительность, таким образом, вместо множества отдельных характеристик процессора можно ввести всего пару параметров, отражающих его производительно сть.
Кроме того, можно убрать несущественные в данном случае характеристики — к примеру, можно сосредоточиться на возможности миграции ВМ, если на первый план выходит отказоустойчивость. Кроме того, многие характеристики можно убрать, учитывая особенности конкретной инфраструктуры. Так, в рамках вычислительных кластеров, необходимые директории (например, домашние директории пользователей), как правило, доступны со всех узлов по сети (например, по NFS). После выбора характеристик необходимо выполнить нормализацию значений.
Наконец, одним из главных факторов для узла кластера является его расположение в вычислительной сети. Предполагается, что узлы, принадлежащие одной подсети, могут обмениваться данными с большой скоростью, а узлы, лежащие в разных подсетях — с меньшей скоростью. Необходимо отметить, что определенная таким образом подсеть не всегда совпадает, к примеру, с подсетью I P.
Тестирование виртуальных интерфейсов для контейнеров
Для выбора архитектуры виртуальной вычислительной сети для кластера контейнеров было выполнено тестирование различных вариантов организации виртуальной сети, на двух различных типах вычислительных узлов. Рассматривались варианты использования физического сетевого адаптера без виртуализации, использование двух виртуальных интерфейсов — veth и macvlan, а также использование этих интерфейсов при объединении узлов с помощью туннеля, при помощи виртуального интерфейса vxlan (рассмотрено далее).
Тесты запускались на двух разных узлах (первого или второго типа), в контейнерах или без них. Узлы первого типа — узлы архитектуры x86, каждый узел с одним четырехядерным процессором. Узлы второго типа – узлы архитектуры x86, каждый узел с одним восьмиядерным процессором. На узлах первого типа (и в рамках контейнеров, запущенных на этих узлах) использовалась ОС Ubuntu 16.04 (официальный сайт ОС — [85]). На узлах второго типа (и в рамках контейнеров, запущенных на этих узлах) использовалась ОС Fedora 26 (официальный сайт ОС — [86]). Параметры сетевого стека во всех случаях выбирались стандартными для данной ОС (описание параметров стека TCP/IP в ОС Linux приведено, например, в [87]). Для тестов два узла первого типа соединялись напрямую, физические сетевые интерфейсы являлись интерфейсами стандартна Ethernet 1Gbit. Узла второго типа соединялись при помощи коммутатора Fast Ethernet (поддерживается скорость обмена данными до 100 Мбит/сек).
Для тестирования виртуальный сетей для контейнеров использовалась отдельное сетевое пространство имен (созданное при помощи «ip netns add» - при запуске процесса через «ip netns exec» также создавалось отдельное mount namespace).
Для сравнения виртуальных интерфейсов veth и macvlan и оценки возможных накладных расходов использовался следующие варианты. Для тестирования интерфейса veth создавался мост и парный интерфейс veth на каждом узле, участвующем в тестах. Один интерфейс veth «перемещался» в сетевое пространство имен контейнера и настраивался там, а другой интерфейс veth добавлялся в мост. В мост также добавлялся физический сетевой интерфейс для обеспечения связи между узлами.
Для тестирования интерфейса macvlan создавался интерфейс macvlan в режиме работы «bridge» с физическим сетевым устройством в качестве «нижележащего» устройства (для обеспечения связи между узлами) на каждом узле, участвующем в тестах. Такой интерфейс macvlan перемещался в сетевое пространство имен, связанное с контейнером.
Для тестирования интерфейса vxlan использовался как вариант использования vxlan вместе с veth или macvlan, так и вариант использования vxlan только с физическим сетевым интерфейсом. Для тестов vxlan (для всех вариантов) использовалось только два узла, между которыми создавался туннель.
При тестировании физического сетевого интерфейса (для получения базовых значений для оценки возможных накладных расходов при использовании виртуальных интерфейсов) использовался только физический сетевой интерфейс в сетевом пространстве имен по умолчанию, контейнеры не использовались.
В рамках тестирования основное внимание уделялось прикладным вычислительным задачам, поскольку в рамках данной работы рассматривается вариант использования контейнеров именно для создания вычислительных кластеров (к примеру, такой вариант рассматривается в [28]).
В качестве тестовых приложений были выбраны приложения OpenFOAM [88] и GROMACS [89]. Также выполнялся стандартный тест для оценки производительности узлов — тест LINPACK [90], а также стандартный тест для оценки производительности сети — тест iperf [91].
Сначала выполнялось тестирование сети с помощью программы Iperf (со стандартными опциями, использовался TCP/IP), позволяющей оценить производительность сети между клиентом и сервером. В качестве клиента выступал контейнер на одном узле, в качестве сервера — контейнер на другом узле, контейнеры объединены при помощи сети требуемой архитектуры (описание особенностей выполнения тестов приведено ранее). Для данного теста разница между veth и macvlan несущественна. Также незаметна и разница между использованием одного из виртуальных интерфейсов veth или macvlan и использованием одного физического интерфейса без виртуалных интерфейсов. А вот в случае использования vxlan наблюдается незначительное снижение производительности (и при использовании veth, и при использовании macvlan) из-за туннелирования. Результаты тестирования обычного физического интерфейса (eth), veth и macvlan с vxlan и без него представлены в таблице 3.1.
Для случая тестов LINPACK, Iperf и GROMACS разницы в производительности для указанных сетевых интерфейсов по сути нет. Разница между случаем eth, veth и macvlan практически незаметна на большинстве тестов, за исключением теста для солвера «interFoam». В случае этого теста заметна разница между veth и macvlan (или eth). Однако причина этого различия может быть объяснена особенностями работы сетевого стека: в случае veth стеку TCP/IP реже удается объединять данных в рамках больших пакетов, получается больше пакетов небольшой длины, как следствие — связанные с их обработкой накладные расходы. Причина того, что данные объединяются реже — проверка TCP «Small Queue Check» (в случае veth вызов функции-деструктора TCP происходит в процессе работы одной из функций veth, намного раньше, чем в случае macvlan, поэтому очередь для отправки раньше становится пустой и ограничение на объем данных в этой очереди не достигается).
Для случая использования vxlan на узлах второго типа также присутствуют некоторые накладные расходы, однако они не являются существенными (к примеру, на тесте Iperf для macvlan и vxlan было получено 90.9 Мбит/с вместо 94 Мбит/с для случая macvlan адаптера без vxlan). При этом использование vxlan дает возможность создания общей локальной сети «поверх» глобальной сети. Для возможности объединения нескольких локальных сетей с помощью vxlan можно использовать на узле устройства vxlan вместе с виртуальным мостом.
Методика миграции задач
В данной главе рассматривается методика обеспечения отказоустойчивой и надежной работы вычислительного кластера, использующего контейнеры, за счет миграции вычислительных задач.
Как было показано, C/R и миграция вычислительных задач — сложные процессы. Миграция вычислительных задач ставит множество вопросов, до конца так и нерешенных. Поэтому системы управления ресурсами, как правило, или не поддерживают миграцию задач, или задают значительные ограничения. Даже checkpoint/restart задачи на одном и том же узле требует решения множества вопросов.
Миграция же задач и вовсе, как правило, не поддерживается или поддерживается с ограничениями.
Для решения проблемы миграции задач в рамках данной работы предлагается использование контейнеров. В общем случае задача запускается на нескольких узлах. При этом на каждом из узлов может быть запущено множество процессов задачи, считающихся на нескольких процессорных ядрах.
При запуске без контейнера процессы используют сетевой интерфейс (или интерфейсы), доступный на узле, сетевое взаимодействие осуществляется с использованием этого интерфейса, используется один из заранее сконфигурированных IP-адресов. В таком случае миграция задач, использующих сеть, затруднена, так как процесс задачи использует IP-адрес узла. При миграции этот IP-адрес потребуется задать на другом узле, однако это невозможно, так как это приведет к конфликту IP-адресов в сети (узел, на котором считался процесс задачи и тот узел, на который он процесс был мигрирован должны получить одинаковые IP-адреса).
Использование нескольких IP-адресов для одного и того же сетевого интерфейса на узле для разных задач тоже проблематично: в этом случае потребуется ограничивать использование того или иного IP-адреса той или иной задачей, ведь при миграции IP-адрес должен быть удален с одного узла и добавлен на другом, однако, на первом узле этот IP-адрес может использоваться другой задачей.
Решением указанной проблемы может быть использование контейнеров. В этом случае для каждой группы процессов каждой задачи на узле создается отдельный контейнер, в котором эти процессы и работают.
Группа процессов задачи на узле — все процессы, созданные в рамках данной задачи на данном узле. Для каждой такой группы процессов на узле и создается контейнер.
При этом контейнер работает в отдельном сетевом пространстве имен с отдельным виртуальным сетевым интерфейсом. При этом для каждого такого интерфейса выделяется уникальный IP-адрес, а также MAC-адрес (они задаются для виртуального сетевого интерфейса контейнера).
На рисунке 4.1. представлена архитектура системы для работы методики для обеспечения миграции вычислительных задач в рамках вычислительного кластера, использующего контейнеры.
Таким образом, методику можно сформулировать следующим образом:
1. При запуске задачи выделить набор свободных IP-адресов (по количеству узлов для задачи), получить уникальные MAC-адреса.
2. Развернуть виртуальный кластер: на каждом узле для задачи создать контейнеры, необходимые виртуальные сетевые интерфейсы, настроить их, запустить необходимые сервисы (например, sshd).
3. Создать файл с узлами для задачи: вместо указания имен узлов, задать IP-адреса виртуального кластера.
4. Запустить скрипт задачи в рамках контейнера, запуск процессов на узлах должен быть выполнен с учетов файла со списком узлов, таким образом, процессы будут запущены в рамках контейнеров виртуального кластера.
5. При необходимости приостановить задачи (checkpoint).
6. В нужный момент — возобновить задачу (restart), предварительно восстановив настройки контейнера
7. Checkpoint/Restart выполняются с помощью CRIU (уcпешный C/R зависит от задачи, настроек ОС и параметров C/R).
Можно рассмотреть конкретный пример. Допустим, есть узлы кластера с одним сетевым интерфейсом на узел в подсети 192.168.1.0/24. Допустим, в рамках задачи запускается всего лишь 2 процесса, один на узле 10 с IP-адресом 192.168.1.10, другой — на узле 15 с IP-адресом 192.168.1.15. Процессы устанавливают соединение, при этом используются два этих IP-адреса. В определенный момент времени был выполнен checkpoint этой задачи — checkpoint двух этих процессов. Затем было принято решение об их миграции на два других узла — 20 с IP-адресом 192.168.1.20 и 25 с IP-адресом 192.168.1.25. Может ли быть выполнен успешный restart этих процессов на этих узлах? В общем случае нет, поскольку эти два процесса уже установили соединение с использованием IP-адресов 192.168.1.10 и 192.168.1.15. Эти IP-адреса недоступны на узлах 20 и 25. Создание аналогичного соединения с использованием других адресом проблематично, к тому же, в рамках самого приложения может быть привязка к определенному IP-адресу.
Изменение IP-адресов узлов 20 и 25 на IP-адреса узлов 10 и 15 невозможно, ведь на этих узлах уже могут считаться другие задачи, использующие эти адреса. Добавления IP-адресов узлов 10 и 15 также невозможно, ведь тогда случится конфликт IP-адресов в рамках одной подсети: узлы 10 и 15 по-прежнему должны использовать свои адреса.
Кроме того, приложения могут быть привязаны к определенному MAC-адресу сетевого интерфейса. Решением проблемы миграции задач может быть использование контейнеров. В этом случае для каждой группы процессов каждой задачи на узле создается отдельный контейнер, в котором эти процессы и работают. При этом контейнер работает в отдельном сетевом пространстве имен с отдельным виртуальным сетевым интерфейсом. При этом для каждого такого интерфейса выделяется уникальный IP-адрес, возможно в отдельной подсети.
Возвращаясь к примеру в этом случае для процесса задачи на 10 узле создается отдельный контейнер с виртуальным сетевым интерфейсом, интерфейсу присваивается IP-адрес, допустим 10.0.0.100. Для процесса задачи на узле 15 также создается контейнер с виртуальным сетевым интерфейсом, которому присваивается другой IP-адрес, допустим 10.0.0.101.
После checkpoint этих процессов их можно возобновить на узлах 20 и 25, поскольку теперь процессы привязаны к уникальным IP-адресам, выделенным специально для контейнеров. Итак, на узле 20 создается контейнер с виртуальным сетевым интерфейсом, ему присваивается такой же IP-адрес, который был выделен для интерфейса контейнера на узле 10 — 10.0.0.100. Аналогично на узле 25 создается контейнер с интерфейсом, которому присваивается IP-адрес интерфейса контейнера на узле 15 — 10.0.0.101. Теперь успешное возобновление процессов в этих контейнерах возможно, ведь с точки зрения процесса ни IP-адрес, ни даже MAC-адрес интерфейса (предполагается создание виртуального интерфейс с таким же MAC-адресом, как и у виртуального интерфейса на первоначальном узле) не поменялся.