Software & Systems

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

Одной из причин нарушения работы ИС является эффект старения ПО [1], который выражается в деградации производительности приложений в процессе их работы и в увеличении количества их отказов с ростом времени непрерывной работы. Примерами такого эффекта являются утечка памяти и файловых дескрипторов, накопление ошибок округления. Борьба с эффектом старения ПО заключается в снижении его негативного воздействия на работу приложения на основе методики, получившей название «восстановление рабочего состояния ПО» [1]. Ее суть состоит в регулярном переводе приложения в рабочее состояние, близкое к первоначальному, за счет проведения некой очистки, которая может включать в себя сбор мусора и повторную инициализацию внутренних структур приложения.

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

Кроме того, возникают сложности применения существующих методов восстановления к ИС, построенной на основе одной из популярных и перспективных технологий – технологии виртуальных машин (ВМ). Особенность подхода, реализуемого в данной технологии, – размещение нескольких серверов на одном аппаратном обеспечении – приводит к росту зависимости эффективности их работы от аппаратного обеспечения и ПО управляющей ВМ (УВМ). В результате применение существующих методов восстановления рабочего состояния для восстановления УВМ в большинстве случаев становится неприемлемым, например, временная остановка УВМ в процессе восстановления при применении метода перезагрузки ведет к остановке всех серверов, находящихся под ее управлением. Методы, ориентированные сугубо на восстановление УВМ, разрабатывались ранее, в частности, метод, предложенный в [3], позволяет существенно снизить время остановки УВМ в процессе восстановления, однако требует внесения изменений в ее исходный код. Хороший обзор технологии ВМ приведен в работе Т. Джонса (http://www.ibm.com/developerworks/ru/ library/l-linuxvirt/index.html). ВМ представляет собой программный контейнер, в котором установлена ОС со всеми необходимыми службами и приложениями, а хост – ЭВМ, состоящую из реально существующих компонент аппаратного обеспечения с запущенной на нее платформой виртуализации.

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

В данной работе предложены новые методы восстановления рабочего состояния приложения в ИС, построенной на основе технологии ВМ.

Методы восстановления рабочего состояния приложений

При разработке данных методов прежде всего уделялось внимание наиболее распространенным и уязвимым с точки зрения эффекта старения ПО элементам ИС, построенной на основе технологии ВМ, от которых требуется длительное время непрерывной работы, часто по 24 часа и по 7 дней в неделю. Это:

–      логический сервер (объект № 1); в данном случае некоторое приложение, размещенное внутри ВМ и предоставляющее услуги пользователям через сеть;

–      УВМ (объект № 2), от которой зависит работа всех ВМ, находящихся под ее управлением; нарушение ее работы может приводить к нарушению работы всех ВМ, которыми она управляет.

Данные объекты существенно отличаются по своей природе, в связи с чем для каждого из них разработан свой метод восстановления. Так, для восстановления объекта № 1 – метод подмены ВМ (Virtual Machine Substitution, VMS), суть которого в замене логического сервера на новый с восстановленным рабочим состоянием в процессе обслуживания пользователей. Для объекта № 2 разработан метод перезагрузки ОС УВМ с перемещением ВМ и определением схемы их размещения (Virtual Machine Monitor Rejuvenation, VMMR). Суть данного метода в освобождении УВМ от управления ВМ на время ее восстановления.

Метод подмены ВМ

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

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

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

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

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

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

–      модуль управления процессом восстановления (модуль № 1), отвечающий за начальную и заключительную конфигурации ВМ и координацию процесса восстановления;

–      модуль управления процессом переноса обслуживания пользователей (модуль № 2), отвечающий за перераспределение запросов между серверами.

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

Метод перезагрузки ОС УВМ с перемещением ВМ и определением схемы их размещения

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

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

1)    определение схемы размещения ВМ, находящихся под управлением УВМ;

2)    перемещение ВМ на основе технологии горячей миграции;

3)    перезапуск УВМ после перемещения всех машин;

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

Цель определения схемы размещения ВМ состоит в сохранении активности наибольшего количества ВМ. Для ее достижения разработан алгоритм поиска хостов, пригодных для размещения машин: 1-й этап – определение порядка разме- щения ВМ; 2-й этап – определение хоста для каждой ВМ.

Определение порядка размещения выполняется на основе жадного алгоритма [4], который позволяет получить решение, близкое к оптимальному, за приемлемое время и практически не привносит дополнительной вычислительной нагрузки. ВМ располагаются в порядке возрастания их требований к ресурсам. При размещении ВМ обычно учитываются их требования по нескольким типам ресурсов. Таким образом, данная за- дача является задачей многокритериальной оп- тимизации. Существует несколько подходов к решению многокритериальных задач [4]. Для объединения различных типов ресурсов в данной работе выбран метод линейной свертки векторного критерия в одну функцию – обобщенный (агрегированный) критерий:  где  – требование ВМ i к ресурсу типа j;  – обобщенная оценка требований ВМ i к ресурсам; cj – положительное число, характеризующее относительную важность ресурса типа j.

Для объединения различных типов ресурсов необходимо привести их к общей единице измерения. Такое приведение строится на основе максимального базового объема по каждому типу ресурсов среди всех хостов , где j=1, …, K. Затем выбираются такие коэффициенты zj для них, что zj*=1 000 в абсолютных безразмерных единицах. Коэффициенты относительной важности приняты одинаковыми и равны 1/K, поскольку ни одному из типов ресурсов не отдается предпочтение.

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

Эксперименты

С целью оценки разработанных методов восстановления проведена серия экспериментов. Для этого была выбрана платформа виртуализации Citrix XenServer (http://citrix.com), широко ис- пользуемая как в академических кругах для выполнения исследовательских работ, так и в промышленности при построении ИТ-инфра­структуры. Тестовый стенд состоял из пяти компьютеров с установленной платформой виртуализации и двух компьютеров, из которых один – для хранения дисков ВМ, другой – для запуска, эмулирующего работу пользователей с сервером. Конфигурация ВМ: 1 процессор, 512 Мб оперативной памяти.

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

–      для сервера – перезапуск приложения (Re- start) и перезагрузка ОС (Reboot);

–      для УВМ – перезагрузка ОС УВМ (Vmm Reboot, VR).

Метод VMS был реализован для ОС семейства Linux на базе встроенного в ядро файрвола netfilter (http://www.netfilter.org). Netfilter является одним из основных инструментов обработки трафика в ОС Linux и обладает высокой гибкостью настройки и скоростью обработки. Метод VMMR реализован на основе программных интерфейсов, встроенных в Citrix XenServer.

Тестирование методов восстановления сервера проводилось на популярном сервере приложений Apache Tomcat (http://tomcat.apache.org). При тестировании использовались характеристики web-нагрузки, полученные на основе реальных данных, но скорректированные в соответствии с техникой ускорения процесса старения [5] для сокращения времени тестирования. Параметры нагрузки были следующие: время между сессиями рассчитывалось как сумма 280 мс и значения, выбранного на основе гамма-распределения с параметрами масштаба 2046,5634 и формы 0,6452; количество запросов в сессии выбиралось в соответствии с распределением Вейбула с параметрами масштаба 10,6819 и формы 0,9124, но не более 30 запросов; время (единица измерения – мс) между запросами выбиралось в соответствии с распределением Вейбула с параметрами масштаба 53,2432 и формы 0,8569; количество связных запросов определялось в соответствии с логнормальным распределением с математическим ожиданием 2,155 и среднеквадратическим отклонением 1,377, но не более 50 запросов.

Тестирование методов восстановления УВМ проводилось на машине, под управлением которой находилось 3 ВМ. В качестве источника эффекта старения ПО внутри УВМ была выбрана известная проблема утечки памяти в программах на языке Perl [6]. Для исключения влияния эффекта старения Apache Tomcat сервера на результаты оценки методов восстановления УВМ вместо него был использован сервер Apache httpd (http://httpd.apache.org). Исследование httpd-серве­ра показало отсутствие эффекта старения ПО при заданных в тесте параметрах нагрузки. Эти параметры были такие же, как и в предшествующем эксперименте. Интенсивность вызова функции в приложении на языке Perl, ответственной за старение УВМ, составляла 100 мс.

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

Результаты тестирования набора методов восстановления

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

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

–      возможность сохранения запросов пользователей в процессе восстановления;

–      восстановление вне зависимости от источника эффекта старения ПО;

–      отсутствие необходимости модификации исходного кода ПО;

–      отсутствие необходимости внесения изменений в конфигурацию ИС.

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

Литература

1.     Huang Y., Kintala C., Kolettis N., Fulton N. Software rejuvenation: Analysis, module and applications // The Proceedings of Fault-Tolerant Computing Symposium. 1995. Vol. 25, pp. 381–390.

2.     Удовиченко А.О. Проблема «старения» программного обеспечения и пути ее решения // Информатизация и связь. 2012. № 1. С. 17–20.

3.     Kourai K., Chiba S. A fast rejuvenation technique for server consolidation with virtual machines // Proceeding of International Conference on Dependable Systems and Networks. 2007. Vol. 37, pp. 245–255.

4.     Коган Д.И. Задачи и методы конечномерной оптимизации: учеб. пособие. Ч. 3. Динамическое программирование и дискретная многокритериальная оптимизация. Н. Новгород: НГУ, 2004. 157 с.

5.     Matias R., Barbetta P., Trivedi K., Filho P. Accelerated Degradation Tests Applied to Software Aging Experiments // IEEE Transactions on Reliability. 2010. Vol. 59. № 1, pp. 102–114.

6.     Мичурин А. Утечки памяти в программах на Perl // Системный администратор. № 5 (18). 2004. URL: http://sa­mag.ru/archive/article/286 (дата обращения: 22.03.2012).