Математическая модель восстановления дерева процессов при живой миграции контейнеров тема диссертации и автореферата по ВАК РФ 05.13.18, кандидат наук Кудинова Марина Викторовна

• Кудинова Марина Викторовна
• кандидат наук
• 2019

Оглавление диссертации кандидат наук Кудинова Марина Викторовна

1.2 Актуальность темы

1.3 Область из которой появилась задача

1.3.1 Определения и история

1.3.2 Живая миграция

1.3.3 Инструменты для живой миграции. CRIU

1.3.4 Сохраняемые параметры

1.3.5 Восстановление из пространства пользователя

1.3.6 Когда мигрируем

1.3.7 Куда мигрируем

1.4 Степень разработанности темы исследования

1.4.1 Алгоритмической подход к решению задачи восстановления дерева процессов при миграции

1.4.2 Подходы к определению порядка операций

1.4.3 Сохранение информации о создании процессов

1.5 Цели и задачи

1.6 Научная новизна

1.7 Теоретическая и практическая значимость работы

1.8 Методология и методы исследования

1.9 Положения, выносимые на защиту

1.10 Степень достоверности и апробация результатов

1.11 Структура и объем диссертации

2 Глава 1. Формализация исследуемых механизмов и объектов

2.1 Особенности системных вызовов ядра Linux

2.1.1 Рассматриваемые параметры процессов

2.1.2 PID namespace

2.1.3 Системные вызовы и их влияние на параметры процессов

2.1.4 Обоснование выбора параметров для построения математической модели

2.2 Формализация дерева процессов

2.2.1 Пример дерева процессов

2.2.2 Пример изменения дерева процессов

2.3 Формализация операций над деревом процессов

2.3.1 Операции над деревом процессов

2.4 Формализация операций

2.4.1 Действие операций на дерево процессов

2.4.2 Дополнительные ограничения и порядок операций

2.5 Требования к математической модели

2.6 Обоснование выбора представления математической модели

3 Глава 2. Плоские матрицы

3.1 Матричное представление

3.1.1 Как строится математическая модель

3.2 Вид матриц

3.2.1 Дополнительные столбцы

3.2.2 Размер и форма матриц

3.2.3 Вид матрицы дерева Т

3.2.4 Вид матрицы операций Р

3.3 Общий вид уравнения

3.3.1 Входные параметры и результаты математической модели

3.3.2 Общий вид уравнения для матрицы Т

3.3.3 Покомпонентный вид выражения для матрицы Т

3.3.4 Выводы о виде уравнений (4) и (5)

3.3.5 Оценка количества операций

3.4 Частные случаи

3.4.1 Случай fork и setsid

3.4.2 Добавляется операция exit(). Одна операция влияет на только на один процесс

3.4.3 Добавляется операция exit(). Одна операция влияет на несколь ко процессов одновременно

3.5 Дополнительные ограничения

3.5.1 Дополнительные ограничения для случая fork()

3.5.2 Дополнительные ограничения для случая fork() + setsidQ

3.5.3 Упрощение системы уравнений

Глава 3. Многомерная математическая модель

4.1 Операции над деревом процессов в представлении многомерных матриц

4.1.1 Fork

4.1.2 Setsid

4.1.3 Exit

4.2 Общий вид операций

4.3 Итерационное уравнение

4.4 Естественные ограничения на выполняемые операции над деревом процессов

4.5 Плюсы и минусы использования многомерных матриц

4.6 Состояние дерева после п произведенных операций для частного случая fork

4.6.1 Возможные пути решения

4.7 Таблица взаимодействия операций.

Случай: fork(), setsidQ, exit()

4.7.1 Таблица взаимодействия операций

4.8 Упрощение вида уравнений

4.8.1 Проекции на плоскости {pid; sid} и {pid; ppid}

4.8.2 Действие операций в этих плоскостях

4.8.3 Вывод уравнения для плоскости {pid; sid}

4.8.4 Система уравнений

4.9 Возможные пути решения. Алгебра логики

4.10 Программный комплекс и численный эксперимент

4.10.1 Выбранный способ решения задачи

4.10.2 Алгоритм определения порядка операций

4.10.3 Проведение эксперимента и анализ результатов

4.10.4 Преобразование к виду алгебры логики для случая fork

4.10.5 Вывод формулы для элементов итоговой матрицы на шаге п131

4.10.6 Получение выражения Л, описывающего систему

4.10.7 Упрощение выражения для Л и получение упорядоченного набора операций

4.10.8 Не единственность решения

4.10.9 Корректность дерева

4.10.10 Расчеты для случая трех системных вызовов

4.10.11 Возможные конфигурации деревьев

5 Заключение

5.1 Основные результаты и выводы диссертации

5.2 Перспективы дальнейшей работы

5.3 Итоги Список литературы

1 Введение

Введение диссертации (часть автореферата) на тему «Математическая модель восстановления дерева процессов при живой миграции контейнеров»

1.1 Общая характеристика работы

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

1.2 Актуальность темы

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

Современные облачные системы обычно создаются с использованием раз-

личных средств виртуализации: Виртуальных Машин (VM) или Контейнеров (СТ). Первые позволяют запускать различные Операционные Системы (OS) и предоставляют лучшую изоляцию, в то время как вторые позволяют делать значительно более высокую плотность виртуальных окружений (density), поскольку контейнеры запущенные на одной машине работают на одном и том же ядре ОС. Одна из основных проблем управления облачными системами -балансировка/перераспределение нагрузки (load balancing).

Нагрузка на разные машины (хосты) в облаке не одинакова, и балансировка нагрузки помогает справиться или даже избежать ситуаций, когда один хост полностью загружен, в то время как другой имеет небольшую нагрузку или даже находится в режиме ожидания (idle). Основным механизмом решения этой проблемы является живая миграция Виртуальных Сред (или Виртуальных Окружений, VE, термин, описывающий как виртуальные машины, так и контейнеры) с одной физической машины(хоста) на другую. Миграция виртуальных сред - это очень частая операция в облачных системах, и любая проблема, возникающая во время нее, оказывает большое влияние на работу облака, его стабильность и доступность.

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

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

динамической (живой) миграции на другой хост передаются не только данные, но и состояние контейнера, которое включает состояние каждого процесса в дереве процессов СТ. То есть, состояния процессов CT (например, принадлежащих одному пространству имен (namespace) или/и одной контрольной группе (cgroup)) сохраняются и отправляются на второй хост; процессы CT на первом хосте уничтожаются, а соответствующие процессы с такими же состояниями создаются на втором хосте. Проблемы могут возникнуть во время шага, когда процессы с предопределенными состояниями создаются на втором хосте. Эти проблемы возникают при любой попытке восстановить дерево процессов CT: не только во время миграции, но и при восстановлении CT из контрольной точки, например с помощью CRUI (Check-point Restore In User space - утилиты производящей сохранение ("заморозку") состояния процессов, восстановление их в таком же состоянии из контрольной точки; используется для живой миграции, создания контрольных точек (checkpoint), и т.д.).

Одной из важнейших задач, которые решаются при миграции (или в CRIU), является восстановление из контрольной точки (checkpoint'а) исходного состояния каждого из замороженных процессов. Восстанавливается принадлежавшая каждому процессу память, открытые файлы и точки монтирования, регистры процессора и ядерные объекты, открытые сессии, атрибуты и права доступа. В особенности, после восстановления должны совпадать идентификатор процесса (pid), его сессия (sid), группа. Важно создать новый процесс в правильном пространстве имен. Кроме этого важно сохранить (вернее, заново создать) взаимосвязи между процессами, такие как соотношения родитель-ребенок (parent/child), разделяемую память и настроить совместный доступ к другим разделяемым ресурсам.

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

ние взаимосвязей вида родитель-ребенок и принадлежности процесса к тоже же самой сессии, которая была до миграции (сохранения/заморозки состояния дерева процессов) контейнера.

Поскольку восстановление дерева процессов (например, с помощью CRIU) происходит в пространстве пользователя, а не в ядре, то нельзя просто воссоздать все необходимые ядерные объекты. Можно изменять параметры процесса, такие как его идентификатор (pid = process ID), родитель (ppid = parent ID), сессия (sid = session ID) только при помощи соответствующих системных вызовов, например, fork(), setsidQ и exit().

Поэтому, чтобы создать на новой системе процессы с такими же параметрами важно создавать их в правильном порядке. Например, если есть процесс с pid 9. sid 9. ppid 7. то нужно сначала создать процесс с pid 7. из него с помощью системного вызова fork создать дочерний процесс с pid=9, и уже в нем сделать setsidQ.

В течение жизни CT процессы создаются и уничтожаются, их состояния меняются. A API ядра Linux часто не предоставляет средств для перевода процесса непосредственно в определенное состояние. В таких случаях процесс с необходимым состоянием может быть создан только с использованием последовательности системных вызовов. Можно заметить, что разные операции по-разному изменяют разные параметры состояния процесса и что параметры разных процессов взаимозависимы. Более того, состояние каждого процесса содержит только его текущие параметры и не содержит никакой исторической информации. Например, о создателе процесса или была ли смена родителя. Вот почему понимание порядка операций, необходимых для восстановления дерева процессов CT с использованием только информации о состоянии дерева процессов, является сложным.

В этом случае становится критически важна последовательность операций,

и

которая производилась над деревом процессов, и привела в итоге к формированию текущего дерева процессов (т.е, того его состояния, которое нужно восстановить). Однако, при сохранении состояния процессов не доступна информация о том, в какой конкретно последовательности производились операции. Следовательно, возникает необходимость по итоговому дереву процессов найти последовательность системных вызовов, которые привели к его созданию.

Однако, на практике по итоговому состоянию дерева процессов бывает довольно сложно понять, как именно оно было построено. Например, если в системе некоторые процессы становятся child-геарег'ами (или, иначе, sub-геарег'ами). Это процессы, к которым могут repatent'htbcfl ("переподчинятьсят.е., становиться их непосредственными потомками) их более дальние потомки (в случае, если процесс, который до этого значился их родителем, завершается). В таком случае, при завершении какого-либо процесса (т.е., если, например, он выполнил системный вызов exitQ), все его потомки сменят родителя не на init'a (как это было бы в обычной ситуации), а на того child-reaper'a, который является их ближайшим предком. Иными словами, процессы child-reaper'ы, это такие процессы, которые могут корректно обрабатывать завершение не только их непосредственных потомков (своих child'oB), но и вообще всех своих потомков (т.е., потомков его потомков), в этом они похожи на init, и именно поэтому к ним может производиться reparent.

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

Иными словами, тема диссертации является актуальной, поскольку рассматриваемые в данной диссертационной работе проблемы обусловлены научной и

прикладной значимостью задачи создания высоко- производительных, доступных и надежных облачных систем.

1.3 Область из которой появилась задача 1.3.1 Определения и история

Сейчас особенно популярными становятся облачные технологии. То есть, технологии, когда где-то "в облаке"находятся все данные и работают программы, а пользователи могут подключаться к ним со своих компактных, не очень мощных устройств. Рабочую часть облака составляют виртуализованные серверы - физические машины, на которых работают несколько виртуальных окружений.

Современные облачные системы строятся на базе виртуализованных серверов. Например, такой подход позволять повышать отказоустойчивость кластера. То есть, на в физических машинах в них работает несколько виртуальных.

Виртуализация - это способ абстрагирования реального используемого объекта от концептуального представления о нем у его пользователя. В контексте ОС это способ запустить одну ОС (она называется "гостевой ОС"или "контейнером в зависимости от типа виртуализации) внутри другой (она называется "хостом"). Виртуальной машиной называется специальное окружение, в котором гостевая ОС может исполняться, как будто она установлена на реальном железе. Хотя на самом деле, это окружение - создается программой работающей на хостовой системе - гипервизором.

Гипервизор, также иногда называемый монитором виртуальных машин, это программа, позволяющая на одном компьютере (хосте) запускать несколько операционных систем (называемых гостевыми). Название это возникло из того, что, фактически, гипервизор находится на уровень выше супервизора (систе-

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

Отдельно следует упомянуть контейнерную виртуализацию, как технологию разрывающую связь между уровнями привилегий в одной системе. Контейнерная виртуализация - это подвид виртуализации, в котором виртуализируется только пространство пользователя, а ядро остается общим для всех контейнеров. Для пользователя контейнер может быть неотличим от выделенного ему сервера, поэтому ОС контейнеры еще так же называют виртуальными выделенными серверами. [8, 9, 10]

CT - может быть перезагружен независимо от остальных, имеет своего пользователя, IP-адрес, имеет свой диск, подсеть, память, файлы (изолированные от других контейнеров). С точки зрения ядра, контейнер - это набор процессов, изолированных от всех остальных контейнеров и хостовой системы. Это означает, что процессы внутри контейнера взаимодействуют только друг с другом: межпроцессные отношения (отношения родитель-потомок (parent-child)) и межпроцессное взаимодействие - находятся в границах контейнера. [7]

Плюсы относительно виртуальных машин - экономия места, можно развернуть гораздо больше контейнеров, по сравнению с числом виртуальных машин, на одном и том же оборудовании. Минусы - все эти контейнеры будут иметь одинаковую операционную систему (хотя возможен запуск разных дистрибутивов одной ОС), т.к. имеют общее ядро. [11, 12]

Использование контейнеров в облачных системах, во-первых, позволяют клиентам работать совершенно изолированно и безопасно, например, для каждого

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

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

1.3.2 Живая миграция

Живая миграция (Live Migration) - технология переноса изолированного виртуального окружения (контейнера или виртуальной машины) с одной физической машины на другую, при которой конечный пользователь не замечает, что работа останавливалась. Т.е., остановка происходит на очень короткий срок. Например, так, чтобы за это время не было разорвано ни одно TCP соединение.

Так как контейнер - изолированный объект, то его состояние может быть сохранено в файле на диске, и, соответственно, восстановлено из этого файла на другой машине. [7]

Таким образом, миграция контейнера включает в себя собой сохранение состояния контейнера и последующее полное восстановление его состояния. Или, если кратко, checkpoint/restore. Сохранение в разных источниках называют -checkpoint или dump, восстановление - restore, restart или восстановлением из контрольной точки.

При живой миграции выполняется следующее [7]:

1. Файловая система контейнера передается на принимающий (destination) хост. Можно сказать, что туда копируется диск контейнера.

2. Текущее состояние контейнера (состояние всех его процессов и снимок памяти) сохраняется в файле на диске (dump file).

3. Dump файл передается на принимающий (destination) хост.

4. Состояние контейнера восстанавливается из dump файла на принимающем хосте.

Следует отметить, что если при восстановлении на принимающем (destination) хосте возникла ошибка, то контейнер на первом (source) хосте может продолжить свою работу. А если восстановление прошло успешно, то контейнер на первом хосте обычно "убивают"(т.е., завершают все его процессы).

Кроме того, для оптимизации времени миграции передача данных может быть итеративной или "lazy"(no требованию).

1.3.3 Инструменты для живой миграции. CRIU

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

Список некоторых проектов, которые позволяют выполнять checkpoint / restart [7]:

• CRUI [7, 14]

• TCPCP (TCP Connection Passing) [17]

Каждая из этих систем имеет свои достоинства и недостатки. Их можно условно разделить на группы по тому, какой механизм заложен в основе:

дется из userspace): CRIU

Для работы с большими кластерами необходимы инструменты, позволяющие перераспределять нагрузку между машинами. Часто для балансировки нагрузки используют живую миграцию виртуальных машин и контейнеров. Одним из распространённых инструментов, позволяющих производить живую миграцию и работающих на OS Linux, является CRIU(Checkpoint/RestoreInUserspace). Этот программный инструмент позволяет "заморозить"работающее приложение (или даже часть приложения, например, как весь контейнер, так и один процесс, или группу процессов), сохранить его состояние в файл (например, как набор файлов на диске), и восстановить (например, уже на другой машине) приложение ровно в том же состоянии, в котором оно было в момент "заморозки".

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

Подробнее о том, как работать с CRIU можно найти в [14, 24].

CRIU имеет следующие плюсы: скорость, виртуализация PID, поддержка миграции сетевых подключений, минимизация размеров образа СТ.[7]

Для того, чтобы миграция работала нормально, согласно [7], должны выполняться следующие условия:

• Виртуализация PID'ob (PID virtualization) [13] - чтобы гарантированно иметь возможность присвоить каждому процессу тот PID, который у него был до заморозки. Например, наличие в ОС возможности создавать для каждого контейнера отдельный PID namespace [39] . Эта функциональность влияет на создание математической модели и будет более подробно рассмотрена далее, в главе про формализацию операций.

что отношения родитель-ребенок не выйдут за рамки контейнера.

ров были изолированы друг от друга.

ность перезапустить процессы на другой машине.

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

аллоцированные ресурсы, сетевые соединения, и другие данные, относящиеся к данному процессу. [7]

Заморозка и восстановление включают в себя: При сохранении:

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

2. Сохраняются состояние всех процессов в контейнере и самого контейнера в файл дампа.

3. Останавливается контейнер - уничтожаются все процессы и отмоптирует-ся его файловая система.

При восстановлении:

1. Запускается контейнер - создается контейнер в состоянии, которое описано в файле дампа.

2. Создаются все необходимые процессы внутри контейнера (они будут в приостановленном состоянии) и восстанавливаются все их ресурсы в соответствии с файлом дампа.

3. Запускается исполнение всех процессов контейнера из приостановленного состояния.

1.3.4 Сохраняемые параметры

При сохранении (checkpoint) / восстановлении (restore, или restart в некоторых англоязычных источниках) набора взаимодействующих процессов необходимо, собрать консистентное состояние всего набора процессов. При этом должны сохраниться все зависимости между процессами: иерархия процессов (от-

ношения родитель-ребенок), взаимосвязи между процессами (принадлежность процессов группам процессов или сессиям), разделяемые ресурсы, и т.д. [25]

При восстановлении - процессы должны создаваться таким образом, чтобы все зависимости были в точности такими же, при сохранении. [25]

Когда нужно смигрировать контейнер, определяют список всех его процессов, то есть процессы, принадлежащие его cgroup'e. Для каждого процесса сохраняется не только связанные с ним файлы, но информация, о его текущем состоянии/исполнении его память и параметры, характеризующие ядерные объекты, например, process id (pid), session id (sid), parent id (ppid).

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

Зависимости: иерархия процессов, идентификаторы (PPID, SID, PGID, TGID), разделяемые ресурсы (открытые файлы).

1.3.5 Восстановление из пространства пользователя

Существуют два основных подхода к созданию систем для миграции процессов: из пространства ядра (kernel space) или из пространства пользователя (userspace).

Наиболее перспективным представляется подход, где система целиком работает в пространстве пользователя.

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

Использование стандартных системных вызовов ядра ОС при восстановле-

нии:

• позволяет максимально использовать существующие интерфейсы и функциональные возможности операционной системы; [7]

напрямую из kernelspace'a (так как при неудаче, упадет вся система, а не только переносимый контейнер);

внесении производителем ОС каких-либо изменений в ядро ОС;

Так как, большая часть ресурсов процесса должна быть обработана из контекста процесса, в стек каждого процесса вставляется (code injection) специальная функция обработчик, которая выполнится первой, сразу после того, как процесс продолжит свое исполнение, и которая и восстановит все необходимые ресурсы. Например, для процесса init контейнера такая функция восстановит состояние контейнера (например, точки монтирования контейнера, сеть (таблицы маршрутизации, iptables rules), IPC объекты) и инициирует построение дерева процессов. [7]

Использование стандартных системных вызовов ядра ОС при восстановлении - упрощает процесс восстановления. Но системные вызовы - не позволяют произвольно изменить состояние процесса после его создания. [25]

1.3.6 Когда мигрируем

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

Например, если на данную машину в данный момент нагрузка (например, процессорная или сетевая) высокая, то это отрицательно сказывается на ее производительности. В таком случае разумно мигрировать некоторые контейнеры на другие, не столь загруженные, машины.

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

В работе "CPU Utilization Prediction Methods Overview"(2.) автором рассматривалась возможность предсказания процессорной нагрузки, и алгоритмы и подходы, которые могут использоваться для расчетов того, когда имеет смысл смигрировать контейнер с точки зрения балансировки нагрузки и динамического перераспределения ресурсов.

Распространение облачных систем, как публичных, так и внутрикорпоративных, увеличение числа физических машин, находящихся под управлением облачного ПО, вызывает пристальное внимание к системам управления ресурсами - DRS (dynamic resource scheduling). Для оптимального распределения нагрузки DRS должен ориентироваться не только на текущие показатели потребления ресурсов, но и заглядывать в будущее. Прогноз способен ответить на два ключевых вопроса: является ли текущее переиспользование ресурсов кратковременным (пиком) и какова средняя ожидаемая нагрузка на хост при заданном горизонте планирование. Ответы на эти вопросы помогают принять решение о необходимости миграции, с одной стороны, и выбрать принимающий,

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

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

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

В первую очередь следует определиться с желаемым горизонтом прогнозирования, поскольку точность разных методов по-разному убывает с ростом интервала прогнозирования. Методы, ориентированные на предсказание на один шаг (управление обратной связью [28], модели Box-Jenkins [29]), хорошо работают только для краткосрочных прогнозов. Другие методы (байесовский классификатор [30]) подходят для долгосрочных прогнозов, но могут быть менее эффективными на ближайших прогнозах. При горизонтах планирования порядка суток появляется возможность учитывать ежедневно повторяющиеся особенности ряда, наподобие всплесков в начале рабочего дня определённой часовой зоны.

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

При выборе модели, многое зависит от общих свойств системы, для которой предстоит строить прогноз. Вот несколько важных вопросов, касающихся самой системы:

• Предполагается лп связь между потреблением процессора и другими параметрами системы (например, счетчиками производительности)?

•

компонентов, функция распределения шума и т.д.)?

онной функций для продифференцированного и исходного ряда нагрузки?

Если потребление процессора связано со значениями других наблюдаемых параметров системы, то в этом случае эти параметры следует попробовать включить в число предикторов. То же касается потребления других компонент приложения (например, расположенных в других ВМ), если они коррелируют с потреблением CPU данной компоненты.

Список литературы диссертационного исследования кандидат наук Кудинова Марина Викторовна, 2019 год

6 Список литературы

1. Беклемишев Д.В., Курс аналитической геометрии и линейной алгебры. Москва: Наука, 2001.

2. М. Kerrisk, The Linux programming interface: a Linux and Unix system programming handbook.San Francisco: No Starch Press, 2010.

3. Aho, Sethi, UHman, Compilers: Principles, Techniques, and Tools. Addison-Wesley, 1986.

4. Лав Роберт. Ядро Linux. Описание процесса разработки. Третье издание. Москва: Вильяме, 2013.

5. М.Г.Иванов, Введение в тензоры в теории поля, Москва 2011

6. litf.ps: /habr.com/ru/post/195330/

7. Andrey Mirkin, Alexey Kuznetsov, Kir Kolyshkin, Containers checkpointing and live migration. 2010. https://www.semanticscholar.org/paper/Containers-checkpointing-and-live-migration-Mirkin/c0fccaee409159dbbbdf005c5a3fc92ee6621

8. Тормасов А.Г., Белоусов C.M., Протасов С.С. Патент US 7,461,144. Virtual private server with enhanced security. 2008

9. Тормасов А.Г., Белоусов C.M., Протасов С.С. Патент US 7,461,148. Virtual private server with isolation of system components. 2008

10. Тормасов А.Г., Белоусов C.M., Протасов С.С. Патент US 8,694,637. Virtual private server with CPU time scheduler and isolation of system components. 2014

11. http://habrahabr.ru/company/parallels/blog/245533/

12. https://infoboxcloud.ru/community/blog/iaas/220.html

13. https://wiki.openvz.org/Checkpointing_internals

14. https://criu.org/Main_Page

15. 0.0. Sudakov, Yu.V. Boyko, O.V. Tretyak, T.P. Korotkova, E.S. Meshcheryakov, Process checkpointing and restart system for Linux, Mathematical Machines and Systems, 2003.

16. Eduardo Pinheiro, Truly-Transparent Checkpointing of Parallel Applications, Federal University of Rio de Janeiro UFRJ.

17. Werner Almesberger, TCP Connection Passing, In Proceedings of the Linux Symposium (Ottawa, Ontario, Canada, July, 2004).

18. Jason Duell, The Design and Implementation of Berkeley Lab's Linux Checkpoint/I Lawrence Berkeley National Laboratory.

19. Hua Zhong, Jason Nieh, CRAK: Linux Checkpoint/Restart As a Kernel Module, Department of Computer Science, Columbia University, Technical Report CUCS-014-01, November 2001.

20. https://systems.cs.columbia.edu/projects/zap/

21. Steven Osman, Dinesh Subhraveti, Gong Su, Jason Nieh, The Design and Implementation of Zap: A System for Migrating Computing Environments. In Proceedings of the Fifth Symposium on Operating Systems Design and Implementation (OSDI 2002), Boston, MA, December 9-11, 2002.

22. The Sprite Operating System, http: //www.eecs.berkeley.edu/Research/ Projects (

23. http://dmtcp.sourceforge.net/

24. https://www.redhat.com/en/blog/checkpointrestore-container-migration

25. Oren Laadan, Jason Nieh. Transparent Checkpoint-Restart of Multiple Processes on Commodity Operating Systems. Proceedings of the 2007 USENIX Annual Technical Conference (USENIX 2007). Santa Clara, CA, June 2007. https://www.ui

26. Dhiman, G. n^p. 2010. A system for online power prediction in virtualized environments using gaussian mixture models. Design Automation Conference (DAC), 2010 47th ACM/IEEE. 3 (2010), 807-812.

27. Meisner, D. h ßp. 2009. PowerNap: eliminating server idle power. Analysis. 44, (2009), 205-216.

28. Kalyvianaki, E. n^p. 2014. Adaptive Resource Provisioning for Virtualized Servers. ACM Transactions on Autonomous and Adaptive Systems. 9, 2 (2014).

29. Dinda, P.A. 1998. The Statistical Properties of Host Load The Statistical Properties of Host Load. 7, July (1998), 211-229.

30. Di, S. H^p. 2014. Google hostload prediction based on Bayesian model with optimized feature combination. Journal of Parallel and Distributed Computing. 74, 1 (2014), 1820-1832.

31. Andrea Arcangeli, Izik Eidus, Chris Wright, Increasing memory density by using KSM. https://www.kernel.org/doc/ols/2009/ols2009-pages-19-28.pdf

32. http://www.linux-kvm.org/page/KSM

33. https://www.kernel.org/doc/Documentation/vm/ksm.txt

34. https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6 KSM.html

35. http://www.vmware.com/files/pdf/mem_mgmt_perf_vsphere5.pdf

36. https://wiki.compscicenter.ru/images/l/13/Gorbunov_master2017.pdf

37. http://www.andy-pearce.com/blog/posts/2013/Aug/process-groups-and-sessions/

38. http://man7.org/linux/man-pages/man7/credentials.7.html

39. http://man7.org/linux/man-pages/man7/pid_namespaces.7.html

40. http://man7.org/linux/man-pages/man2/syscalls.2.html

41. http://man7.org/linux/man-pages/man2/fork.2.html

42. http://man7.org/linux/man-pages/man2/setsid.2.html

43. http://man7.org/linux/man-pages/man2/exit.2.html

44. http://man7.org/linux/man-pages/man2/setpgid.2.html

45. https://www.kernel.org/doc/man-pages/

46. Ю.И.Журавлёв, Ю.А.Флёров, Дискретный анализ Часть 1. Москва 1999