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

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

МИРКИН Андрей Леонидович .

МАТЕМАТИЧЕСКОЕ МОДЕЛИРОВАНИЕ

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

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

АВТОРЕФЕРАТ

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

ии345605Б

Москва-2008

003456056

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

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

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

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

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

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

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

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

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

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

Автореферат разослан « Ц» Н0АКР& 2008 г.

Ученый секретарь диссертационного совета

Федько О.С.

Общая характеристика работы Актуальность темы

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

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

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

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

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

3

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

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

Миграция группы процессов с одного компьютера на другой открывает

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

6

функциональность, позволяющая создавать изолированные группы процессов. В данный момент идет активное обсуждение с разработчиками со всего мира возможности включения уже созданной системы в очередную версию ядра 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. Результаты, полученные на тестовых данных, подтверждают возможность практического применения алгоритмов, разработанных в данном исследовании.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Т__nJ— m

V -v к

сри mem

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

Этап сохранения состояния занимает гораздо больше времени, так как в этот момент происходит запись данных на диск, а скорость записи на жесткий диск в несколько раз меньше скорости записи в память. Пусть каждый процесс имеет к страниц памяти, которые надо сохранить, trmem - время, которое требуется, чтобы считать страницу данных из оперативной памяти, trswap - время, которое требуется, чтобы считать страницу данных из файла подкачки, U -загруженность оперативной памяти компьютера,/^ к) — функция распределения

10

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

T^P~t{f(u'k.y-w+(*, -frn)\tmim+к, ) (2)

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

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

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

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

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

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

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

+к, -t^+k,-t„) (4)

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

вид:

T„stan ('tos/t + к, ■ (trcll,k + twmem )) (5)

1

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

I

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

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

9 .и

т "" (7)

sync »г V /

ПС1

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

С ,TJ

rp dump net /о\

С0РУ~ у '

'net

или

л

'Spoge ' ^net

Т--!--(9)

сору у V /

net

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

TcPy~ikrt„e,-Une,>±krtM (10)

I 1

так как Unet - 1 ■

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

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

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

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

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

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

Задача подсистемы контроля изменяемых файлов заключается в том, чтобы

сохранять имена изменяемых за время ее работы файлов. Эта подсистема должна

включаться перед первым переносом файловой системы контейнера и

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

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

значительно ускорит этот этап. Основная проблема состоит в реализации

подобной подсистемы, так как для этого потребуются большие изменения в самом

ядре операционной системы.

Пусть А - средняя активность работы с диском одного процесса (количество

изменяемых файлов за единицу времени), - средний размер одного файла на

15

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

r A-n-Tsy„c-Sf„e.Uml A-n-S^Uj, SM-U„e, y ~ V2 V

Ht'/ Y net net

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

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

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

T„a^p~n-{B-At+l)-tna!«Tapy (12)

так как At очень мало и 1«к.

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

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

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

1. Запрос страницы из файла подкачки.

2. Пересылка запроса на исходный сервер.

3. Поиск нужной страницы.

4. Передача страницы на сервер назначения.

5. Загрузка страницы в память.

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

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

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

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

Исходный компьютер Компьютер назначения

1-я итерация

2-я итерация

Память контейнера

все страницы

измененные

И Ш8 Р1 страницы г-1 щу ОН

I IIИН1 -!

Страницы, измененные во время 1-й итерации 3-я итерация

Р

измененные страницы

II

Страницы, измененные во время 2-й итерации

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

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

18

предыдущей итерации; количество измененных страниц становится больше чем Л/

2' , где N - количество всех страниц в контейнере, г - номер итерации.

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

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

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

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

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

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

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

(13)

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

Предлагаемая модель балансировки использует множество параметров, которые необходимо периодически проверять на каждом компьютере в кластере, поэтому в первую очередь необходимо определить интервал времени !, который будет использоваться для обновления нужных параметров. На каждом компьютере кроме исходных параметров должны определяться следующие величины: исри - загруженность процессора, итет - заполнение оперативной памяти, С//„а - занятость пространства на жестком диске, 11„е, - загруженность сетевого канала.

После получения всех необходимых данных для каждого компьютера в кластере считается характеристика к(исри, С, итет, М, Д ипеь Ы):

и{исри,с,иша,м,иш,н,ит,м) - + (14)

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

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

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

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

Компьютер 1

Компьютер 2

Компьютер 3

Компьютер 4

Сеть

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

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

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

Н+Ка»<\к Ц<Ц (15)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[6], [8] - разработка математической модели и алгоритма сохранения и восстановления группы процессов, разработка математических моделей и алгоритмов миграции группы процессов с одного компьютера на другой без прерывания обслуживания конечных пользователей;

[9] - проведение численных экспериментов с помощью комплекса программ и анализ результатов.

о-

о

МИРКИН Андрей Леонидович

МАТЕМАТИЧЕСКОЕ МОДЕЛИРОВАНИЕ

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

Автореферат

Подписано в печать 12.11.2008. Формат 60x90 1/16. Усл. печ. л. 1,0. Тираж 80 экз. Заказ № Московский физико-технический институт (государственный университет)

Печать на аппарате Rex-Rotary Copy Printer 1280. НИЧ МФТИ.

141700, г Долгопрудный Московской обл., Институтский пер., 9 тел.: (495) 4088430, факс (495) 5766582

Введение.

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

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

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

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

5. Краткое содержание работы.

Глава 1. Обзор существующих систем.

1.1. Системы сохранения и восстановления.

1.1.1. СНРОХ.

1.1.2. ЕРСКРТ.

1.1.3. TCP Connection Passing.

1.1.4. CRAK.

1.1.5. ZAP.

1.1.6. BLCR.

1.2. Системы виртуализации VMware и Xen.

1.3. Система виртуализации OpenVZ.

1.4. Требования к системе сохранения и восстановления.

1.5. Системы балансировки нагрузки.

1.5.1. Network Load Balancing.

1.5.2. Cisco Load Balancing.

1.5.3. Распределение нагрузки на WEB приложения.

1.5.4. Технология адаптивного распределения нагрузки (ALB).

1.6. Системы кластеризации.

1.6.1. Red Hat Cluster Suite.

1.6.2. SuSE Cluster.

Глава 2. Сохранение и восстановление состояния процессов.

2.1. Математическая модель.

2.2. Алгоритм сохранения процессов.

2.3. Алгоритм восстановления процессов.

2.4. Оценка времени работы алгоритма.

2.5. Программная реализация алгоритма.

2.6. Методика проведения экспериментов.

2.7. Результаты.

Глава 3. Миграция контейнеров.

3.1. Математическая модель.

3.2. Миграция контейнеров с остановкой.

3.3. Миграция контейнеров в режиме непрерывного обслуживания.

3.4. Оптимизация синхронизации файловой системы.

3.5. Миграция с использованием сетевого файла подкачки.

3.6. Итеративная миграция.

3.7. Программная реализация алгоритмов.

3.8. Методика проведения экспериментов.

3.9. Результаты.

Глава 4. Балансировка нагрузки.

4.1. Математическая модель.

4.2. Алгоритм и критерий балансировки.

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

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

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

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

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

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

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

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

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

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

Приведем в заключение основные результаты и выводы работы:

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

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

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

1. Mary Baker Fast Crash Recover}' in Distributed File Systems, ps. (ftp://ftp.cs.berkeley.edu/ucb/spritc/papers/thcsis-Baker.ps).

2. Douglis F. Transparent Process Migration in the Sprite Operating System, ps. (ftp://ftp.cs.berkeley.cdu/ucb/sprite/papers/thesis-Douglis.ps).

3. Pinheiro E. Truly-Transparent Checkpointing of Parallel Applications, html. (http://www.rcscarch.rutgers.edu/~edpin/epckpt/paperhtml).

4. Sudakov 0.0., Boyko Yu.V., Tretyak O.V., Korotkova T.P., Meshcheryakov E.S. Process checkpointing and restart system for Linux // Mathematical Machines and Systems 2003 - N.2 - P. 146-153.

5. Werner Almesberger TCP Connection Passing, pdf. (http://www.finux.org/Reprints/Reprint-Almesberger-OLS2004.pdf).

6. TCP Connection Passing, html. (http://tcpcp.sourceforge.net/).

7. Transmission Control Protocol, html. (http://en.wikipedia.org/wiki/TransmissionControlProtocol).

8. Hua Zhong, Jason Nieh CRAK: Linux Checkpoint/Restart As a Kernel Module // Department of Computer Science, Columbia University, html. (http://www.ncl.cs.columbia.edu/research/migrate/crak.html).

9. Oren Laadcm, Dan Phung, Jason Nieh Transparent Checkpoint-Restart of Distributed Applications on Commodity Clusters // Proceedings of the 2005 IEEE International Conference on Cluster Computing (Cluster 2005) -Boston, MA September 27-30, 2005.

10. Mozilla Firefox web browser, html. (http://www.mozilla.com/firefox/).

11. Oracle Database, html. (http://www.oracle.com/index.html).

12. Duell J., Hargrove P., and Roman E. The Design and Implementation of Berkeley Lab's Linux Checkpoint/Restart // Berkeley Lab Technical Report (publication LBNL-54941), December 2002, pdi. (http://ftg.lbl.gov/CheckpointRestart/Pubs/blcr.pdi).

13. Roman E. A Survey of Chcckpoint/Restart Implementations // Berkeley Lab Technical Report (publication LBNL-54942), July 2002, pdf. (http://ftg.lbl.gov/CheckpointRestart/Pubs/checkpointSurvey-020724b.pdi).

14. Paul H. Hargrove and Jason C. Duell Berkeley Lab Checkpoint/Restart (BLCR) for Linux Clusters // In Proceedings of SciDAC 2006, June 2006, pdf. (http://ftg.lbl.gov/CheckpointRestart/Pubs/LBNL-60520.pdf).

15. VMware: Virtualization via Hypervisor, Virtual Machine & Server Consolidation, html. (http://www.vmware.com).

16. Система виртуальных машин фирмы VMware, html. (http://www.linuxcenter.ru/lib/books/vmware/).

17. Storage Area Network (SAN), html. (http :// en. wikipedia. org/wiki/ Storageareanetwork).

18. IBM Redbooks, Introduction to Storage Area Network, html. (http://www.redbooks.ibm.com/abstracts/sg245470.html70pen).

19. Xen, html. (http://www.xen.org).

20. Citrix XenServer: Efficient Virtual Server Software, html. (http://citrix.com/English/ps2/products/product.asp?contentID;=683148).

21. OpenVZ Server Virtualization Open Source Project, html. (http://www.openvz.org).

22. MPI: The Message Passing Interface, html. (http://parallel.ru/tech/techdev/mpi.html).

23. The Message Passing Interface (MPI) standard, html. (http://www-unix.mcs.anl.gov/mpi/).

24. System call, html. (http://en.wikipedia.org/wiki/Systemcall).

25. Robert Love Linux Kernel Development. Second Edition. USA: Novell Press, 2005.

26. Signal Handling The GNU С Library, html. (http://www.gnu.org/software/libtool/manual/libc/Signal-Handling.html).

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

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

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

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

31. Дональд Э. Кнут Искусство программирования, том 1. Основные алгоритмы. 3-е изд. - М.: «Вильяме», 2006. — 720 с.

32. Ананий В. Левитин Алгоритмы: введение в разработку и анализ. М.: «Вильяме», 2006. - С. 212-215.

33. Кормен Т., Лейзерсон Ч., Ривест Р. Алгоритмы: построение и анализ (второе издание). М.: «Вильяме», 2005. - С. 622-632.

34. TCP Protocol Overview, html. (http://www.lincoln.edu/math/rmyrick/ComputerNetworks/InetReference/83. htm).

35. RFC 793 Transmission Control Protocol, html. (http://www.faqs.org/rfcs/rfc793.html).

36. RFC768 User Datagram Protocol, html. (http://www .faqs .org/rfcs/rfc768.html).

37. Intel Pentium 4 processor, html. (http://ru.wikipedia.org/wiki/Pentium4).

38. Streaming SIMD Extensions 2 (SSE2), html. (http://softpixel.com/~cwright/programming/simd/sse2.php).

39. Карпов B.E., Коньков K.A. Основы операционных систем. М.: Изд-во "Интернет-университет информационных технологий — ИНТУИТ.ру", 2004. - 632 с.

40. Linux Test Project, html. (http://ltp.sourceforge.net/).

41. В. Dragovic, К. Fraser, S. Hand Xen and the art of virtualization // Proceedings of the ACM Symposium on Operating Systems Principles. -2003.-Pp. 164-177.

42. The Xen virtual machine monitor, html.http://vvww.cl.cam.ac.uk/research/srg/netos/xen/).

43. Andrew Tanenbaum Modern Operating Systems, 2nd edition. Prentice Hall, 2001.

44. Kolyshkin K., Korotaev K. OpenYZ Project OS Server Virtualization // Proceedings of the LinuxTag conference. - 2006, html. (http://www.linuxtag.org/2006/de/besucher/material.html).

45. Виртуальная память // Материал из Википедии, html. (http://ru.wikipedia.org/wiki/%D0%92%D0%B8%D 1 %80%D 1 %82%D 1 %83 %D0%B0%D0%BB%D 1 %8C%D0%BD%D0%B0%D 1 %8F%D0%BF%D0 %B0%D0%BC%D 1 %8F%D 1 %82%D 1 %8C).

46. ВахалияЮ. UNIX изнутри. СПб.: Питер, 2003. - 844 с.

47. Иртегов Д. Введение в операционные системы. СПб.: Питер, 2002.

48. Tar GNU Project - Free Software Foundation (FSF), html. (http://www.gnu.org/sofitvvare/tar/).

49. Rsync Open Source Utility, html. (http://rsync.samba.org/).

50. RFC 4251 The Secure Shell (SSH) Protocol Architecture, html. (http://tools.ietf.org/html/rfc4251).

51. Secure Shell (SSH), html. (http://ru.wikipedia.org/wiki/SSH).100

52. OpenSSH project, html. (http://www.openssh.org/).

53. Network Load Balancing Technical Overview, html. (http://technet.microsoft.com/en-us/libraiy/bb742455.aspx).

54. Implementing Microsoft Network Load Balancing in a Virtualized Environment, VMware Infrastructure 3 // Technical Note, pdf. (http://www.vmware.com/files/pdf/implmentingmsnetworkloadbalancin g.pdf).

55. W. Richard Stevens ТСРЯР Illustrated, Volume 1: The Protocols. Addison-Wesley, 1994. - 576 p.

56. RFC 791 Internet Protocol Specification, html. (http://www.freesofl.org/CIE/RFC/791/index.htm).

57. RFC 1794 DNS Support for Load Balancing, html. (http://tools.ietf.org/html/rfc 1794).

58. BGP протокол (перевод на русский), html. (http://www.opennet.ru/docs/RUS/bgprus/index.html).

59. How Does Load Balancing Work? Cisco Systems, pdf. (http://www.cisco.com/application/pdf/paws/5212/46.pdf).

60. Виджэй Боллапрагада, Кэртис Мэрфи, Расе Уайт Структура операционной системы Cisco IOS. -М.: «Вильяме», 2002. 208 с.

61. Джо Брокмайер, Ди-Анн Лебланк, Рональд Маккарти, мл. Маршрутизация в Linux. M.: «Вильяме», 2002. - С. 240.

62. WEB farm Load Balancing in Asp.net, html. (http://www.c-sharpcorner.com/UploadFile/gopenath/Page 107182007032219AM/Page 1 .asp x).

63. Network File System (NFS), html. (http://www.redhat.com/docs/manuals/linux/RHL-9-ManuaI/ref-guide/ch-nfs.html).

64. RFC 3530 Network File System (NFS) version 4 Protocol, html. (http://tools.ietf.org/html/rfc3530).

65. Сетевая модель OSI, html. (http://ru.wikipedia.org/wiki/%D0%A1 %D0%B5%D1 %82%DO%B5%DO%B 2%D0%B0%D1%8F%D0%BC%D0%BE%D0%B4%D0%B5%D0%BB%D l%8COSI).

66. Модель OSI, html. (http://www.citforum.ru/nets/switche/osi.shtml).

67. Standard Group MAC Addresses Tutorial, html. (http://standards.ieee.org/regauth/groupmac/tutorial.html).

68. Что такое port mapping? (прокси FAQ), html. (http ://www. freeproxy .ru/ru/ freeproxy/faq/whatisportmapping. htm).

69. NAT (Network Address Translation), html.http ://ru. wikipedia.org/wiki/NAT).102

70. HTTP (HyperText Transfer Protocol), html.http://ru.wikipedia.org/wiki/HTTP).

71. Solving Server Bottlenecks with Intel Server Adaptors, pdf. (http://developer.intel.ru/download/network/pdf/serverbottlenecks.pdf).

72. Sven Goldt, Sven van der Meer, Scott Burkett, Matt Welsh The Linux Programmer's Guide. Chapter 6. Linux Interprocess Communications, html. (http://tldp.Org/LDP/lpg/node7.html#SECTION00700000000000000000).

73. SCSI (Small Computer System Interface), html. (http://ru.wikipedia.org/wiki/SCSI).

74. RAID (Redundant Array of Independent/Inexpensive Disks), html. (http://ru.wikipedia.org/wiki/RAID).

75. Redhat Cluster Suite, html. (http://www.redhat.com/clustersuite/).

76. Matthew O'Keefe, John Ha Open source high-availability clustering, html. (https://www.redhat.com/magazine/009jul05/features/cluster/).

77. Red Hat Enterprise Linux Open Source Applications for Servers and Desktops built on Linux, html. (http://www.redhat.com/rhel/).

78. Red Hat Cluster Suite for Red Hat Enterprise Linux 5.2. May 2008, pdf. (http://www.redhat.com/docs/en

79. US/RedHatEnterpriscLinux/ 5.2/pdf C lusterSuite0 verview/C lusterSuit eOverview.pdf).

80. Distributed Lock Manager, html. (http://en.wikipedia.org/wiki/Distributedlockmanager).

81. Resource Group Manager Cluster Wiki, html. (http://sources.redhat.com/cluster/wiki/RGManager).

82. The OpenAIS Standards Based Cluster Framework, html. (http: //www. op cnai s. org/).

83. Ajay Kaalvanshi and Timo Jokiaho Using OpenAIS for Building Highly Available Session Initiation Protocol (SIP) Registrar // ISAS 2006, pdf. (http://www.springerlink.com/content/g381x5113456r051/fulltext.pdf).

84. Steven C. Dake The Corosync Cluster Engine // Proceedings of the Linux Symposium. V. 1. Ottawa, 2008. - Pp. 85-99.

85. Linux Server: SUSE Linux Enterprise Server by Novel, html. (http ://wvvw.novell. com/products/server/).

86. Distributed Replicated Block Device (DRBD), html. (http://xgu.ru/wiki/DRBD).

87. Heartbeat: Linux-HA (High-Availability Linux) project, html. (http: //www. 1 i nux-ha.org/Heartbeat).

88. High-Availability cluster with DRBD and Heartbeat, html. (http://wiki.openvz.org/HAclusterwithDRBDandHeartbeat).

89. File system consistency check utility, html. (http://ru.wikipedia.org/wiki/Fsck).

90. Philipp Reisner Rapid resynchronization for replicated storage. Activity-logging for DRBD. 27th January 2004, pdf. (http://www.drbd.org/fileadmin/drbd/publications/drbd-activity-loggingv6.pdf).

91. Гнеденко Б.В. Курс теории вероятностей, М.: Наука, 1988 - 448 с.