Размещено на http://www.allbest.ru/

На правах рукописи

Специальность 05.13.18 - Математическое моделирование, численные методы и комплексы программ

АВТОРЕФЕРАТ

диссертации на соискание учёной степени кандидата физико-математических наук

МАТЕМАТИЧЕСКОЕ МОДЕЛИРОВАНИЕ ПРОЦЕССОВ МИГРАЦИИ ГРУППЫ НЕПРЕРЫВНО РАБОТАЮЩИХ СЕРВЕРОВ

Миркин Андрей Леонидович

Москва - 2008

Работа выполнена на кафедре информатики Московского физико-технического института (государственного университета).

Научный руководитель:

кандидат физико-математических наук ТОРМАСОВ Александр Геннадьевич

Официальные оппоненты:

доктор физико-математических наук, профессор РЯЗАНОВ Владимир Васильевич кандидат физико-математических наук ЕВДОКИМОВ Алексей Витальевич

Ведущая организация:

Институт автоматизации проектирования РАН

Защита состоится « 19 » декабря 2008 года в 9.00 час. на заседании диссертационного совета Д 212.156.05 при Московском физико-техническом институте (государственном университете) по адресу: 141700, г. Долгопрудный Московской обл., Институтский пер. д.9, ауд. 903 КПМ.

С диссертацией можно ознакомиться в библиотеке МФТИ (ГУ).

Автореферат разослан « 18 » ноября 2008 г.

Ученый секретарь

диссертационного совета Федько О.С.

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

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

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

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

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

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

· обеспечения отказоустойчивости;

· отладки приложений;

· обеспечения возможности возвращения к контрольной точке.

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

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

Цель работы, задачи исследования

Целью данного исследования является разработка математической модели и алгоритма сохранения и восстановления состояния группы процессов и исследование свойств модели при ее конкретизации для операционной системы Linux с использованием функциональности проекта OpenVZ. Кроме этого, работа направлена на разработку математических моделей миграции группы процессов с одного компьютера на другой для оценки паузы в обслуживании во время миграции и накладных расходов, связанных с процедурой миграции. Также целью исследования является разработка математической модели и алгоритма балансировки нагрузки, основанного на моделях и алгоритмах миграции без перерыва в обслуживании конечных пользователей, между объединенными в кластер компьютерами. В данной работе ставится также задача исследования зависимости скорости миграции от различных внешних параметров, таких как загруженность сетевого канала, загруженность компьютеров и их характеристик.

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

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

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

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

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

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

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

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

Практическая значимость

Математические модели и алгоритмы сохранения и восстановления состояния групп процессов и различных ресурсов предлагались в нескольких проектах: CHPOX (Checkpointing for Linux), EPCKPT (Eduardo Pinheiro checkpointing project), TCPCP (TCP connection passing), CRAK (Checkpointing/restart as a kernel module), ZAP, BLCR (Berkeley lab checkpointing/restart). Отличительная черта настоящего исследования состоит в том, что во всех предыдущих проектах присутствовал ряд ограничений, не позволяющий сохранять и восстанавливать любые приложения, что существенно сужает область применимости существующих систем, в то время как в настоящей работе внимание концентрируется на сохранении полного состояния исполняемых программ.

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

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

Апробация и реализация результатов работы

По выполненным диссертационным исследованиям опубликовано 9 работ, в том числе две [8, 9] - в ведущих научных журналах, рекомендованных ВАК РФ.

Результаты диссертационного исследования докладывались, обсуждались и получили одобрение специалистов на научных конференциях и семинарах: 48-51 научных конференциях МФТИ, Москва-Долгопрудный, 2005-2008 гг.; XXXIV международной молодежной научной конференции «Гагаринские чтения», Москва, 2008 г.; международной конференции «South California Linux Expo 6x», Los Angeles, USA, 2008 г.; международной конференции «Linux Symposium 2008», Ottawa, Canada, 2008 г.; научных семинарах кафедры информатики МФТИ, 2004-2008 гг.

Конкретизация разрабатываемых моделей и алгоритмов делалась для UNIX/Linux-подобных операционных систем, так как эти системы свободно распространяются и их исходный код доступен для изучения и модификации. В данной работе не рассматривалась возможность конкретизации моделей для коммерческих операционных систем с закрытым исходным кодом, хотя некоторые из предложенных математических моделей могут быть реализованы и в них.

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

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

На защиту выносятся следующие основные положения:

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

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

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

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

Диссертация состоит из введения, четырех глав, заключения, списка использованных источников и одного приложения. Работа изложена на 105 страницах, список использованных источников содержит 96 наименований.

2. Содержание работы

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

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

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

Выявлены основные требования к системе сохранения и восстановления состояния групп процессов:

· возможность сохранения и восстановления всех ресурсов, выделяемых процессам;

· гарантия успешного восстановления, несмотря на возможное совпадение идентификаторов ресурсов

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

Во второй главе предлагается алгоритм сохранения и восстановления группы процессов с учетом специфики операционной системы Linux.

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

Оценим время, которое тратится на заморозку процессов. Пусть n - количество процессов, которое надо заморозить, t - квант времени, который выдается процессам планировщиком задач, tmem - время обращения скорость обращения к памяти, Vcpu - производительность процессора. Так как после выставления специального флага процессы еще могут находиться в состоянии исполнения в течение выделенного им кванта времени, то общее время заморозки можно оценить следующей формулой:

Вторая фаза - сохранение состояния виртуального сервера в файл. На этом этапе происходит сохранение состояний процессов и виртуального сервера: сохраняется информация о процессах, о сетевом интерфейсе, об открытых файлах, о сигналах, о виртуальной памяти, о структурах UNIX System V IPC, о сетевых соединениях. В отличие от других подобных систем в нашей системе реализована поддержка всех структур данных, что позволяет сохранять состояние любых приложений.

Этап сохранения состояния занимает гораздо больше времени, так как в этот момент происходит запись данных на диск, а скорость записи на жесткий диск в несколько раз меньше скорости записи в память. Пусть каждый процесс имеет k страниц памяти, которые надо сохранить, trmem - время, которое требуется, чтобы считать страницу данных из оперативной памяти, trswap - время, которое требуется, чтобы считать страницу данных из файла подкачки, U - загруженность оперативной памяти компьютера, f(U, k) - функция распределения количества страниц, находящихся в файле подкачки, twdisk - время, которое тратится на запись одной страницы данных на диск. Тогда общее время сохранения состояния будет оцениваться следующей формулой: миграция компьютер загруженность сетевой

После небольшого преобразования оценочную формулу можно упростить до следующего вида:

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

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

Более интересным для рассмотрения является процесс восстановления виртуального сервера. Он состоит из двух фаз. Первая - восстановление данных и перевод всех процессов в специальное состояние. Вторая - перевод процессов из специального состояния в состояние исполнения. Остановимся на первой фазе более подробно.

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

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

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

После небольшого упрощения оценочная формула принимает следующий вид:

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

В третьей главе рассматриваются математические модели миграции контейнера.

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

1. Перенос файловой системы контейнера. Это может быть сделано при помощи обычной утилиты rsync.

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

3. Сохранение состояния контейнера в файл.

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

5. Перенос файла с состоянием контейнера на компьютер назначения.

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

7. Разморозка контейнера и включение внутри него сетевого интерфейса на компьютере назначения.

8. Остановка контейнера на исходном компьютере.

9. Удаление файловой системы и конфигурационных файлов контейнера на исходном компьютере.

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

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

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

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

Пусть Vnet - пропускная способность сетевого интерфейса, Unet - загруженность сетевого канала, Sdisk - размер файловой системы контейнера. Размер файла с состоянием контейнера может быть оценен следующей формулой:

где Spage - размер одной страницы данных.

Тогда время необходимое на вторую синхронизацию можно оценить следующей формулой:

Время необходимое на копирование файла с состоянием:

или

Обозначим через tnet время передачи одной страницы данных по сети и получим следующую оценку:

так как Unet ? 1.

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

Опытным путем было подтверждено, что вторая синхронизация файловой системы и перенос файла с состоянием контейнера занимают около 95% всей паузы. Именно поэтому рассматриваются варианты оптимизации этих стадий:

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

2. Уменьшение размера файла с состоянием:

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

б) Итеративная миграция - страницы, используемые процессами, в основном передаются до миграции.

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

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

так как вероятность того, что за время первого переноса файловой системы изменятся все файлы, очень мала.

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

Пусть B - активность изменения одним процессом страниц памяти (количество страниц изменяемое в единицу времени), Дt - время между выставлением на страницах специального флага и заморозкой контейнера, l - количество служебных страниц процесса, которые надо сохранять в любом случае. Тогда время копирования файла состояния в данном случае будет оцениваться следующей формулой:

так как Дt очень мало и l<<k.

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

Во время восстановления контейнера на компьютере назначения все не сохраненные в файле с состоянием страницы памяти помечаются как страницы находящиеся в файле подкачки. Если после разморозки контейнера процессы попытаются обратиться к такой странице памяти, то будет создан специальный запрос к нашему файлу подкачки. Этот «page-in» файл представляет собой не обычный файл на диске, а специальную программу, которая может принимать запросы на страницы от процессов и пересылать их на исходный компьютер. Приложение «page-out», находящееся на исходном компьютере, принимает запросы и отправляет в ответ страницы памяти. После этого страница поступает на компьютер назначения и возвращается процессу, который ее запросил (рис. 1). В течение нескольких первых минут после разморозки контейнера страницы передаются с исходного компьютера по запросу процессов. После этого активируется принудительная перекачка страниц, и вся оставшаяся память контейнера передается на компьютер назначения.

Рис. 1. Миграция памяти контейнера при помощи сетевого файла подкачки

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

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



Рис. 2. Итеративная миграция памяти контейнера

Введен следующий критерий остановки 1: итеративный процесс завершается в любом из трех случаев: не остается измененных страниц; количество оставшихся после данной итерации страниц стало больше чем после предыдущей итерации; количество измененных страниц становится больше чем , где N - количество всех страниц в контейнере, i - номер итерации.

В работе формулируются и доказываются следующие теоремы:

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

Теорема 2. При использовании критерия остановки 1 для итерационного процесса передачи памяти для времени передачи файла состояния Titer справедлива следующая оценка:

Из этой оценки видно, что после 4-5 итераций время передачи файла состояния уменьшается на порядок. После проведения ряда тестов оказалось, что для не очень сильно загруженного контейнера достаточно всего 3-4 итерации, чтобы осталось около 100 страниц, которые необходимо сохранять в файл состояния, при общем количестве около 1500 страниц (около 6 мегабайт).

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

Рассмотрим кластер, состоящий из нескольких компьютеров, на каждом из которых запущено несколько виртуальных серверов, предоставляющих некоторые сервисы пользователям. Каждый из компьютеров кластера характеризуется несколькими параметрами: M - размер оперативной памяти, C - количество и производительность процессоров, H - объем жесткого диска, N - пропускная способность сетевого интерфейса.

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

Предлагаемая модель балансировки использует множество параметров, которые необходимо периодически проверять на каждом компьютере в кластере, поэтому в первую очередь необходимо определить интервал времени t, который будет использоваться для обновления нужных параметров. На каждом компьютере кроме исходных параметров должны определяться следующие величины: Ucpu - загруженность процессора, Umem - заполнение оперативной памяти, Uhdd - занятость пространства на жестком диске, Unet - загруженность сетевого канала.

После получения всех необходимых данных для каждого компьютера в кластере считается характеристика h(Ucpu, C, Umem, M, Uhdd, H, Unet, N):



где kcpu, kmem, khdd и knet - коэффициенты важности соответствующих параметров, которые устанавливаются администратором априори.

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

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

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

Рис. 3. Вычисление характеристик в кластере, как совокупность характеристик контейнеров CTi.

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

В рамках сформулированной модели предлагается критерий балансировки: Виртуальный сервер i переносится с компьютера 1 на простаивающий компьютер 2, если

и

где hнакл - характеристика, связанная с накладными расходами, вычисляемая по формуле (14).

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

В приложении приведены основные компоненты реализованного программного комплекса.

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

1. Разработаны математическая модель и алгоритм сохранения и восстановления состояния группы процессов. Они реализованы в виде комплекса программ для операционной системы Linux.

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

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

Список публикаций по теме диссертации

Миркин А.Л. Миграция виртуальных серверов в режиме реального времени // Современные проблемы фундаментальных и прикладных наук. Часть VII. Управление и прикладная математика: Труды XLVIII научной конференции - М. - Долгопрудный: МФТИ, 2005. - С. 70-71.

Миркин А.Л. Модель миграции виртуальных серверов в режиме реального времени с переносом памяти по требованию процесса // Современные проблемы фундаментальных и прикладных наук. Часть VII. Управление и прикладная математика: Труды XLIX научной конференции. - М. - Долгопрудный: МФТИ, 2006. - С. 77-78.

Миркин А.Л. Модель миграции виртуальных серверов в режиме реального времени с предварительной итерационной передачей памяти // Современные проблемы фундаментальных и прикладных наук. Часть VII. Управление и прикладная математика: Труды 50-й научной конференции. - М. - Долгопрудный: МФТИ, 2007. - С. 55-57.

Миркин А.Л. Система сохранения и восстановления состояния процессов для операционной системы Linux // Моделирование и обработка информации: Сборник научных трудов - М.: МФТИ, 2008. - С. 203-206.

Миркин А.Л. Виртуальные серверы и их миграция в режиме реального времени // XXXIV Международная молодежная научная конференция Гагаринские чтения, секция Информационные системы и прикладные информационные технологии в социально-экономической сфере - М.: Московский авиационный технологический институт, 2008 - С. 200-201.

Andrey Mirkin, Alexey Kuznetsov, Kir Kolyshkin Containers checkpointing and live migration // Proceedings of the Linux Symposium. V. 2. - Ottawa, 2008. - Pp. 85-90.

Миркин А.Л. Балансировка нагрузки между несколькими компьютерами при помощи миграции виртуальных серверов в режиме реального времени // Современные проблемы фундаментальных и прикладных наук. Часть VII. Управление и прикладная математика: Труды 51-й научной конференции. - М. - Долгопрудный: МФТИ, 2008. - Т. 2 - С. 38-40.

Миркин А.Л., Петров В.А. Система миграции виртуальных серверов в режиме реального времени // Вестник НГУ. Серия: Информационные технологии - Новосибирск, 2008 - Т. 6, вып. 3 - С. 16-27.

Петров В.А., Тормасов А.Г., Миркин А.Л. Длительность миграции виртуальных серверов в распределенной системе // Вестник НГУ. Серия: Информационные технологии - Новосибирск, 2008 - Т. 6, вып. 3 - С. 38-57.

Размещено на Allbest.ru