Отказоустойчивость в облачных системах реального - HPC-UA

Міжнародна конференція "Високопродуктивні обчислення"
HPC-UA’2012 (Україна, Київ, 8-10 жовтня 2012 року)
________________________________________________________________________________________________________________________
Отказоустойчивость в облачных системах
реального времени
Волокита А.Н.1 , Иванов Д.Г.1 , Сниховский В. Л.1 , Костенко В. А.1 , Бондур В.С.1
1
Национальный технический университет Украины «Киевский политехнический институт»,
Киев, Украина
artem.volokita@kpi.ua, dmytro.ivanov@mail.ru, snikhovsky@gmail.com,
vovakostenko@gmail.com, bondvladserg@mail.ru
Аннотация.
В работе рассматриваются основные подходы к обеспечению отказоустойчивости облачных
систем, в частности систем реального времени. Показаны особенности методов восстановления системы
после отказов на основе сохранения состояний процессов. Рассмотрена модель облачной отказоустойчивой
системы реального времени на основе согласованного сохранения состояний.
Ключевые слова
Распределенные вычисления, cloud computing, системы реального времени, отказоустойчивость.
1 Вступление
Современные высокопродуктивные вычислительные системы, к которым относится и cloud computing, состоят
из множества компонент; задачи разделяются на подзадачи, которые распределяются по виртуальным
машинам. Процессам и пользователям для доступа к удаленным ресурсам приходится использовать сеть
Интернет, что может привести к увеличению потерь данных.
Для обеспечения отказоустойчивости распределенных систем используются методы сохранения
состояний процесса на основе контрольных точек. Данные методы характеризуется способностью
восстанавливать состояние процессов в случае отказа, при этом процессы обмениваются сообщениями для
контроля состояний друг друга.
Пользователи пока отказываются использовать системы реального времени на основе облачной
инфраструктуры, в то же время предлагается достаточно большое количество теоретических решений,
касающихся отказоустойчивости распределенных систем [1].
Поддержка облачными технологиями приложений реального времени достаточно востребована – сегодня
приложения реального времени широко применяются на производственных предприятиях, в военной
аппаратуре, научном оборудовании и даже мобильных устройствах. Для большинства приложений реального
времени критически важна безопасность и надежность, не менее важным фактором является время выполнения.
Использование облачной инфраструктуры для приложений, работающих в реальном времени, повышает
вероятность возникновения ошибок и отказов. Сбои в работе данных систем могут привести к значительным
финансовым потерям, поэтому необходимо обеспечить отказоустойчивость распределенных систем,
работающих в облаке.
2 Теоретическая часть
Рассмотрим методы отказоустойчивости распределенных систем на основе сохранения состояний процессов. В
методах несогласованного сохранения состояний каждый процесс самостоятельно создает контрольные точки.
В методах согласованного сохранения состояний контрольные точки процессов формируют глобальную
целостную структуру [2].
-132-
Міжнародна конференція "Високопродуктивні обчислення"
HPC-UA’2012 (Україна, Київ, 8-10 жовтня 2012 року)
________________________________________________________________________________________________________________________
2.1 Методы несогласованного сохранения состояний
Методы несогласованного сохранения состояний процессов основываются на не координируемом создании
контрольных точек и хранении истории обмена данными с другими процессами. При этом различают
пессимистические и оптимистические алгоритмы.
В пессимистических алгоритмах процесс не отправляет новые сообщения другим процессам, пока не
получит соответствующего подтверждения о получении сообщения, или даже выполнении задания [3].
Данный подход позволяет значительно упростить откат отказавших процессов по сравнению с
оптимистическими методами, в которых процесс не ждет подтверждения о доставке (выполнении)
предыдущего сообщения перед отправкой следующего.
Пессимистическое сохранение сообщений отправителем
При пессимистическом сохранении сообщений отправителем [4] каждое сообщение записывается во
временную память машины отправителя асинхронно без остановки процессов вычисления. Это позволяет
восстанавливать систему после ошибок без избыточного синхронного сохранения сообщений в постоянной
памяти.
Процесс-получатель возвращает отправителю порядковый номер получения (ПНП), который
записывается в лог сообщений отправителя и может быть объединен с подтверждающим сообщением
протокола сети.
Процесс-отправитель продолжает нормальное выполнение сразу после отправки сообщения, при этом
он обязан повторять рассылку до тех пор, пока ПНП всех сообщений не будут получены. После отправления
ПНП, процесс-получатель продолжает вычисления, однако не должен отправлять другие сообщения до тех пор,
пока все процессы-отправители не подтвердят получение ПНП.
Процессы, отправляющие сообщения неисправному процессу, не получат ответ, содержащий ПНП, и,
соответственно, ПНП не будут сохранены в логах отправителей. В случае выхода из строя процесс-получатель
перезапускается с последней контрольной точки, сообщения восстанавливаются из лога соответственно ПНП.
После восстановления отказавшего процесса ему будут повторно в любом порядке отправлены все сообщения,
не получившие ПНП.
Пессимистическое сохранение сообщений получателем
При пессимистическом сохранении сообщений получателем каждое полученное сообщение синхронно
сохраняется с приостановкой процесса-получателя.
При восстановлении системы выполняется откат к контрольной точке только для неисправного
процесса, при этом все сообщения, полученные в промежуток времени между контрольной точкой и отказом
процесса, восстанавливаются из лога в постоянной памяти и повторно обрабатываются в порядке получения.
В связи с этим, после восстановления процесс повторно генерирует сообщения, являющиеся копиями
сообщений, отправленных до отказа.
Оптимистическое сохранение сообщений получателем
При оптимистическом сохранении сообщений получателем сообщения записываются в постоянную память
асинхронно для избегания блокировки системы и для минимизации избыточности хранимых данных [5]. При
этом сохранение сообщений выполняется или за одну операцию, или когда система незанята.
Главным недостатком оптимистического сохранения сообщений являются сообщения-сироты,
потерянные по причине отказа до записи в постоянную память.
2.2 Модель отказоустойчивой СРВ на основе согласованного сохранения состояний
В методах согласованного сохранения состояний процессы имеют одну контрольную точку для уменьшения
расхода памяти и предотвращения накопления мусора. Методы согласованного сохранения состояний
упрощают восстановление и не являются восприимчивыми к эффекту домино.
Рассмотрим одну из реализаций данного метода для обеспечения отказоустойчивости систем реального
времени в облачной инфраструктуре. Отказоустойчивость основывается на надёжности каждого
вычислительного узла, т.е. виртуальная машина выбирается на основе надёжности и может быть удалена, если
не справляется с выполнением задач в реальном времени.
На рис. 1. показана модель отказоустойчивой системы реального времени на основе согласованного
сохранения состояний. В отказоустойчивой системе реального времени выполняются множество виртуальных
машин, находящихся в облачной инфраструктуре, а также функционирует узел принятия решений – арбитр.
-133-
Міжнародна конференція "Високопродуктивні обчислення"
HPC-UA’2012 (Україна, Київ, 8-10 жовтня 2012 року)
________________________________________________________________________________________________________________________
Виртуальная машина выполняет алгоритм приложения реального времени, после чего запускается
модуль проверки, отвечающий за корректность работы виртуальной машины. Арбитр содержит три модуля:
проверки времени, оценки надёжности и принятия решений. В зависимости от типа приложения реального
времени арбитр может быть расположен на стороне облака или пользователя, но, как правило, находится возле
датчиков или механизмов управления.
Рис. 1. Модель отказоустойчивой СРВ в облачной инфраструктуре
В рассмотренной модели каждому алгоритму соответствует своя виртуальная машина. Модуль проверки
результатов работы виртуальной машины передает результаты выполнения задачи модулю проверки времени,
который сверяет с установленными ограничениями время выполнения.
Модуль оценки надёжности, в свою очередь, рассчитывает и задаёт значение надёжности для каждой
виртуальной машины. Затем, информация передается в модуль принятия решений, который выбирает
выходные данные узла с наивысшей надежностью, и создается контрольная точка восстановления.
В таблице 1 показаны результаты сравнения четырёх методов, рассмотренных в докладе.
Факторы
откаты процессов
глубина отката
процессы-сироты
Табл.1. Сравнительная характеристика методов обеспечения
отказоустойчивости в облачных системах.
Пессимистическое Пессимистическое Оптимистическое
Согласованное
сохранение
сохранение
сохранение
сохранение
сообщений
сообщений
сообщений
состояний
отправителем
получателем
получателем
все
последняя
контрольная точка
нет
выборочно
последняя
контрольная точка
нет
локальный
последняя
контрольная точка
нет
выборочно
несколько
контрольных точек
возможны
недоступно
асинхронно
синхронно
асинхронно
недоступно
временная память
постоянная память
постоянная память
простой
сложный
простой
сложный
средняя
высокая
высокая
высокая
сохранение сообщений
размещение лога в
памяти
сбор мусора
сложность реализации
в СРВ
Как видно из таблицы, при выборе метода восстановления процесса посредством отката к контрольным точкам
необходимо заранее учитывать количество ошибок, к которым процесс должен быть устойчив, количество
необходимых контрольных точек, простоту восстановления, защиту от процессов-сирот, избыточность затрат.
3 Заключение
Показаны особенности методов создания контрольных точек, рассмотрена модель облачной отказоустойчивой
системы реального времени. Выполнено сравнение методов сохранения состояний процессов.
Список литературы
[1] S. Malik, F. Huet, Adaptive Fault Tolerance in Real Time Cloud Computing, July 2011.
-134-
Міжнародна конференція "Високопродуктивні обчислення"
HPC-UA’2012 (Україна, Київ, 8-10 жовтня 2012 року)
________________________________________________________________________________________________________________________
[2] Y.M. Teo, B.L. Luong, Y. Song, T. Nam, Cost-Performance of Fault Tolerance in Cloud Computing, October
2011.
[3] R. E. Strom, D. F. Bacon, S. Yemini, Volatile Logging in n-fault-tolerant Distributed Systems, Proc. of 18th
Annual International Symposium on Fault-Tolerant Computing, 1988.
[4] D. B. Johnson, W. Zwaenepoel, Sender-based Message Logging, Proc. of 17th Annual International Symposium
on Fault-Tolerant Computing, 1987.
[5] R. E. Strom, S. Yemini, Optimistic Recovery in Distributed Systems, ACM Transactions on Computer System,
Vol. 3, No. 3, 1985.
-135-