Материал из Xgu.ru

Remus Fault Tolerance

Перевод статьи: http://www.usenix.org/events/nsdi/tech/full_papers/cully/cully_html/ выполнен ilia_2s@mail.ru

Remus: Высокая доступность посредством асинхронной репликации виртуальных машин
Brendan Cully, Geoffrey Lefebvre, Dutch Meyer, Mike Feeley, Norm Hutchinson, and Andrew Warfield*

Отдел Информационных технологий Университета Британской Колумбии

Контакты:

• brendan@cs.ubc.ca
• geoffrey@cs.ubc.ca
• dmeyer@cs.ubc.ca
• feeley@cs.ubc.ca
• norm@cs.ubc.ca
• andy@cs.ubc.ca

Содержание 1 Аннотация 2 1 Введение 2.1 1.1 Показатели 2.2 1.2 Подход 2.3 2 Проектирование и Реализация 2.4 2.1 Описание модели сбоя 2.5 2.2 Расстановка контрольных точек 2.6 2.3 Память и CPU 2.7 2.4 Буферизация сети 2.8 2.5 Буферизация диска 2.9 2.6 Детектирование сбоя 3 3 Оценка 3.1 3.1 Тестовое оборудование 3.2 3.2 Проверка корректности 3.3 3.3 Измерения производительности 3.4 3.4 Возможности оптимизации 4 4 Аналогичные системы 5 5 Предстоящая работа 6 6 Заключение 7 Благодарности 8 9

[править] Аннотация

Наделить приложение, способностью устойчиво функционировать при отказах оборудования — сложная задача, в основном, достигаемая ре-инжинирингом программного обеспечения (включение в исходный код отказоустойчивой логики), либо, развёртыванием специального дополнительного оборудования. Это создает серьезный барьер в повышении уровня надежности уже написанных (проприетарных) приложений, либо программ, требовательных к аппаратным ресурсам. Здесь описывается прозрачная система высокой доступности, доступная каждому, позволяющая функционировать существующему программному обеспечению в не изменном виде. Но при этом, такое программное обеспечение, становится защищенным от аппаратных сбоев ЭВМ, на которых оно запущено. Remus предоставляет непревзойденную степень защиты от сбоев, в плоть до того, что запущенная система продолжит прозрачно выполняться на альтернативной физической ЭВМ в случае сбоя основного узла, "подвиснув" всего на долю секунды, для того, чтобы резервный узел полностью подхватил все параметры отказавшего узла, например, такие, как активные сетевые соединения. Наш подход объединяет защиту приложений в виртуальной машине с асинхронным переносом его меняющегося состояния на резервный узел, с частотой более 40 раз в секунду! И использует высокопроизводительное исполнение запущенных VMs c опережением состояния на реплицируемой системе.

[править] 1 Введение

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

К сожалению, HA - сложная сфера, она требует, проектирования систем с избыточностью компонентов, совместно с поддержкой переключения на резерв при сбоях. Коммерческие системы высокой доступности, цель которых — защитить современные серверы, главным образом используют специализированное железо, изменённое программное обеспечение (ПО), или и то и другое, одновременно! (См. HP. NonStop Computing. http://h20223.www2.hp.com/non-stopcomputing/cache/76385-0-0-0-121.aspx). В каждом случае, возможность обеспечить прозрачную безотказность при сбоях — это комплекс достаточно дорогих мер, препятствующих внедрению на широкораспространенные серверы.

Этот документ описывает Remus, программную систему, которая предоставляет отказоустойчивость, независимо от используемой ОС и приложений, на доступном в продаже оборудовании. Наш подход состоит в обеспечении возможности мигрирации запущенной виртуальной машины между физическими узлами (Clark, C., Fraser, K., Hand, S., Hansen, J. G., Jul, E., Limpach, C., Pratt, I., and Warfield, A. Live migration of virtual machines. In Proceedings of the 2nd conference on Symposium on Networked Systems Design & Implementation (Berkeley, CA, USA, 2005), USENIX Association.), расширенной техники репликации снепшотов, выполняющейся не модифицированной гостевой ОС, с очень высокой частотой (каждые 25ms). Используя данную технику, наша система делит выполнение VM на серию реплицированных снимков (снепшотов). Сетевые пакеты, такой виртуальной машины, передаются определенным образом и не будут выпущены, до момента, пока состояние основной системы системы не реплицировано.

Виртуализация дает возможность делать копии выполняемой VM, но успешный результат создания копии не будет гарантирован. Синхронная передача состояния при каждом изменении - это не практично: она снижает эффективность пропускной способности памяти до уровня производительности репликации через сетевое устройство. Предпочтительнее, создание на двух функционирующих узлах режима lock-step (Bressoud, T. C., and Schneider, F. B. Hypervisor-based fault-tolerance. In Proceedings of the Fifteenth ACM Symposium on Operating System Principles (December 1995), pp. 1–11.). Данный режим позволит одному узлу выполняться с опережением и после сверять и реплицировать его состояние асинхронно. Внутреннее состояние системы никаким образом не пройдет через систему ввода/вывод и будет не видно снаружи, до того момента, пока контрольная точка не пройдена — мы достигли высокой скорости и эффективно реплицировали запущенную систему за десяток миллисекунд.

Данный документ ориентируется на практику. Полная репликация системы - это хорошо известный подход для предоставления высокой доступности. Тем не менее, обычно применение такого подхода становится значительно дороже, чем приложение-зависимая техника расстановки контрольных точек, которая реплицирует только релевантные данные (Marques, D., Bronevetsky, G., Fernandes, R., Pingali, K., and Stodghill, P. Optimizing checkpoint sizes in the c3 system. In 19th International Parallel and Distributed Processing Symposium (IPDPS 2005) (April 2005)). Наш подход может использоваться для создания HA “в массы”, как сервисная платформа для виртуальных машин. Не смотря на аппаратные и программные ограничения под которыми эта система функционирует, она предоставляет защиту аналогичную или лучшую, чем дорогие коммерческие предложения. Многие существующие системы всего-лишь активно зеркалят обновляющееся хранилище, позволяя приложениям произвести восстановление из неконсистентного состояния. Напротив, Remus, несмотря ни на что, в моменты отказа обеспечивает, не заметное снаружи состояние, при котором ничего не теряется.

[править] 1.1 Показатели

Цели Remus'a создание отказоустойчивости уровня “mission-critical” доступной для систем mid- и low-end. Упрощая подготовку к работе и позволяя нескольким серверам быть консолидированными в небольшое число физических узлов, виртуализация делает такие системы более популярными, в отличии от других. Тем не менее, выгоды консолидации оборачиваются скрытыми затратами в увеличении воздействия аппаратных отказов. Remus нацелен на HA высокого уровня, как сервис предоставляемый платформой виртуализации, поставляемый администраторам индивидуальных VMs, в качестве инструмента смягчающего риски, связанные с виртуализацией.

Дизайн системы Remus основан на следующих показателях высокого уровня:

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

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

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

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

[править] 1.2 Подход

Remus запускается на паре серверов в конфигурации “active-passive”. Мы используем три главных механизма в целях преодоления сложностей, которые обычно связаны с этим подходом. Во-первых, мы основываем свою систему на виртуализованной инфраструктуре, способствуя полной репликации ОС. Во вторых, мы расширяем производительность системы посредством опережающего выполнения, которое отделяет внешний вывод от точек синхронизации. Это позволяет основному серверу сохранять производительность, пока происходит асинхронная синхронизация с реплицирующим сервером. Основные этапы работы Remus приведены на Схеме 1.

Схема 1: Опережающее выполнение и асинхронная репликация.

Основанная на VM репликация целой системы. Гипервизоры применялись для создания систем HA и раньше (Bressoud, T. C., and Schneider, F. B. Hypervisor-based fault-tolerance. In Proceedings of the Fifteenth ACM Symposium on Operating System Principles (December 1995), pp. 1–11.). В этом качестве, виртуализация использована для запуска пары систем в режиме “lock-step”, и в добавок была добавлена поддержка, которая обеспечивает, чтобы VMs на паре физических узлов выполнялись детерминированным путем: внешние события осторожно вводятся в основную и резервную Vms, таким образом они обе приобретают идентичные состояния. Две фундаментальные проблемы влияют на обеспечение такого детерминированного выполнения. Во-первых, это высоко-архитектурная основа, требующая, чтобы система имела всестороннюю согласованность выполняемых инструкций и внешних событий. Во-вторых, в много-процессорных системах, где скрытая память разделяется между процессами, результатом является появление издержек, и обязательна тщательная передача и размножение (Dunlap, G. Execution Replay for Intrusion Analysis. PhD thesis, University of Michigan, 2006.).

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

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

[править] 2 Проектирование и Реализация

Схема 2: Remus: Архитектура высокого уровня

Схема 2 показывает высокоуровневое представление системы. Мы начали с выделения ЭВМ в самостоятельный элемент, чтобы она могла быть защищена в виде VM. Наша реализация основана на гипервизоре виртуальных машин Xen (Barham, P., Dragovic, B., Fraser, K., Hand, S., Harris, T., Ho, A., Neugebauer, R., Pratt, I., and Warfield, A. Xen and the art of virtualization. In SOSP '03: Proceedings of the nineteenth ACM symposium on Operating systems principles (New York, NY, USA, 2003), ACM Press, pp. 164–177.), и расширяет поддержку живой миграции в Xen'е для предоставления контрольных точек, расставленных с низкими интервалами. Начальная часть нашего принципа расстановки контрольных точек была принята для включения в основной код Xen.

Remus достигает HA путем частого распространения контрольных точек с активной VM на резервный физический узел. На резервном узле, образ VM загружен в память и может начать выполняться немедленно, в случае обнаружения ошибки активной системы. Так как резервный узел только периодически консистентен с основным, весь сетевой вывод необходимо буферизировать до момента полной синхранизации с резервным узлом. По завершению, получения консистентнного образа узла, буфер может быть отправлен клиентам снаружи. Контрольная точка, буфер и реализация цикла проходит очень часто – в контрольных тестах мы показателей - до сорока раз в секунду, воспроизводя расстановку контрольных точек для всей ЭВМ включая сеть и для дисковых состояний каждые 25 миллисекунд.

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

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

[править] 2.1 Описание модели сбоя

Remus предполагает следующее развитие событий:

• Защита от останова, если хотя бы один из узлов функционирует.

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

• Отсутствие внешнего вывода, до момента пока состояние взаимодействия систем не подтверждено копией.

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

Мы не стремимся защититься от ошибок ПО или достичь безошибочных состояний. Как рассмотрено в (Chandra, S., and Chen, P. M. The impact of recovery mechanisms on the likelihood of saving corrupted state. In ISSRE '02: Proceedings of the 13th International Symposium on Software Reliability Engineering (ISSRE'02) (Washington, DC, USA, 2002), IEEE Computer Society, p. 91.), подход этой категории предоставляет полный снимок состояния системы и его копирование, и в такой ситуации каждая ошибка в приложении распространиться на резервный узел.

Наше описание модели сбоя повторяет коммерческие продукты HA, которые сегодня позволяют достичь защиты для VM (Symantec Corporation. Veritas Cluster Server for VMware ESX. http://eval.symantec.com/mktginfo/products/Datasheets /High_Availability/vcs22vmware_datasheet.pdf, 2006.); (VMware, Inc. Vmware high availability (ha). http://www.vmware.com/products/vi/vc/ha.html, 2007.). Тем не менее, степень защиты предлагаемая данными продуктами в значительной степени меньше, чем предоставленная Remus: существующие коммерческие продукты реагируют на сбой физического узла простой перезагрузкой VM на другом узле из консистентного дискового состояния. Наш подход выдерживает сбои с течением времени, аналогично живой миграции, запущенная VM продолжает выполняться и сетевые соединения не рвутся. Текущее состояние не теряется и диски не повреждаются.

[править] 2.2 Расстановка контрольных точек

Расстановка контрольных точек в запущенной VM множество раз в секунду накладывает высокие требования на систему. Remus решает эту проблему активно конвейерезируя операцию расстановки контрольных точек. Мы используем систему, основанную на периодах дискретизации, которые прерывают выполнение активной VM, небольшими паузами автоматически регистрируя ее состояния, и открывая внешний вывод, в момент когда состояние сохранено. Возвращаясь к Схеме 1, эту процедуру можно разделить на четыре этапа: (1) Первый этап, пауза VM и копирование всего измененного состояния в буфер. Эта процедура фактически этап “остановка и копирование” живой миграции (Clark, C., Fraser, K., Hand, S., Hansen, J. G., Jul, E., Limpach, C., Pratt, I., and Warfield, A. Live migration of virtual machines. In Proceedings of the 2nd conference on Symposium on Networked Systems Design & Implementation (Berkeley, CA, USA, 2005), USENIX Association.), но как описывается позже в этом разделе, это позволяет значительно оптимизировать частую расстановку контрольных точек. С изменением состояния сохраненного в буфере, VM запускается и возобновляет опережающее выполнение. (2) Буферезированное состояние передается и сохраняется в памяти резервного узла. (3) Контрольная точка, в момент окончания передачи параметров состояния, передается основному узлу. (4) В завершении, открывается внешний вывод сетевого буфера.

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

[править] 2.3 Память и CPU

Расстановка контрольных точек осуществляется над существующими механизмами Xen, для реализации возможности живой миграции (Clark, C., Fraser, K., Hand, S., Hansen, J. G., Jul, E., Limpach, C., Pratt, I., and Warfield, A. Live migration of virtual machines. In Proceedings of the 2nd conference on Symposium on Networked Systems Design & Implementation (Berkeley, CA, USA, 2005), USENIX Association.). Живая миграция это способ, с помощью которого VM перемещается на другой физический узел с едва заметным подтормаживанием сервисов. Для достижения этого, память копируется в новое расположение пока VM продолжает исполняться в старом. В процессе миграции, записи в память перехватываются и изменяемые страницы копируются в новое местоположение в процессе. Миграция делается, после заданного количества интервалов или когда все передано, так как VM обращается к памяти несколько быстрее, чем процесс миграции может переносить ее, гостевой домен приостанавливается и остальная изменяемая память переносится совместно с текущими состояниями CPU. В этот момент активируется образ, находящийся в новом местоположении. Общее время простоя зависит от количества памяти остающегося для копирования при приостановке гостевого домена, но обычно это менее 100ms. Общее время миграции это функция от всего количества памяти используемой в гостевом домене и используемой в момент операции(Clark, C., Fraser, K., Hand, S., Hansen, J. G., Jul, E., Limpach, C., Pratt, I., and Warfield, A. Live migration of virtual machines. In Proceedings of the 2nd conference on Symposium on Networked Systems Design & Implementation (Berkeley, CA, USA, 2005), USENIX Association.), которая неоднократно меняется в процессе работы гостевой ОС.

Xen предоставляет возможность перемещать записи гостевой ОС в память, используя механизм названый “shadow page tables”. Когда данный режим включен, VMM сохраняет a скрытую (“shadow”) версию страниц памяти гостевой ОС и открывает их для аппаратного MMU. Защита страниц используется для получения гостевой ОС доступа к внутренней версии страниц памяти, позволяя гипервизору производить обновления, пока происходит приведение скрытой версии в соответствующий вид.

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

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

Изменения в миграции. В процессе живой миграции, память гостевой ОС многократно копируется в каждом цикле, на выполнение которых могут потребоваться минуты; небольшая задержка в обслуживании вызывается на этапе “остановка и копирование”, длящемся не долго. Это не касается частых расстановок контрольных точек VM: каждая контрольная точка это итог этапа миграции “остановка и копирование”, таким образом это позволяет избегать критической точки оптимизации и сокращать издержки, вызываемые расстановкой контрольных точек. При внедрении контрольных точек в код Xen, выяснилось, что основное время расходуется в момент нахождения гостевой ОС в приостановленном состоянии и расходуется, в значительной степени из-за недостатков демона хранилища Xen (xenstore), который предоставляет административную связь между гостевой VM и доменом 0.

Remus оптимизирует связь контрольных точек двумя путями: Во первых, он уменьшает число внутри-процессовых запросов необходимых для приостановки и запуска гостевого домена. Во-вторых, он полностью заменяет xenstore в процессах приостановки/запуска. В оригинальных исходниках, когда процессу миграции необходимо приостановить VM, он посылает сообщение xend, демону аправления VM. Xend в свою очередь послал сообщение xenstore, извещенному гостевой ОС по каналу сообщений (виртуальное прерывание), что необходимо начать приостановку. В конце гостевая ОС, перед приостановкой создает гипервызов2 (hypercall2), который отменяет выполнение гостевой ОС и сообщает об этом xenstore, который после этого посылает прерывание xend, который в конечном итоге возвращает управление процессу миграции. Этот запутанный процесс может занимать какое угодно время — обычно измеряемая задержка находится в пределах от 30 до 40ms, но мы наблюдали задержки длительностью до 500ms в некоторых случаях.

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

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

Поддержка контрольных точек. Возможность установки контрольных точек в Xen потребовала двух основных изменений в исходниках “suspend-to-disk” и живой миграции. Во первых, добавлена поддержка возврата выполнения домена после приостанавливания; сначала Xen не позволял “использование контрольных точек на ходу” и VM падала после возврата к исходному состоянию. Во вторых программа приостановки была преобразовано из однократной процедуры в демон. Это позволило зациклить дальнейшую расстановку контрольных точек, только для новой измененной памяти.

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

Асинхронная передача. Чтобы дать возможность гостевой ОС быстро восстановить работу, процесс миграции был изменен на копирование затронутых страниц в растущий буфер, в отличии от прямой доставки их по сети, пока домен приостановлен. Это приводит к значительному увеличению скорости функционирования: время необходимое для компиляции ядра в тесте, описанном в Разделе 3.3 было уменьшено на ~10%, при скорости 20 контрольных точек в секунду.

Изменения гостевой ОС. Как говорилось ранее, паравиртуальные системы в Xen включают обработчик приостановления, очищающий состояние устройств при получении запроса на приостановку. В дополнение к оптимизации уведомлений, описанной ранее в этом разделе, обработчик приостановления также был изменен, для уменьшения объема работы, проделываемой до приостановки. В оригинальных исходниках, приостановление влечет отключение всех устройств и всего остального, кроме одного CPU. Эта работа выполняется в момент восстановления домена на другой ЭВМ. Эти изменения доступны в Xen с версией 3.1.0.

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

[править] 2.4 Буферизация сети

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

Схема 3: буферизация сети в Remus

Схема 3 показывает механизм, с помощью которого мы избегаем высвобождения опережающего состояния сети. Входящий трафик доставляется в защищенный узел незамедлительно, но исходящие пакеты созданные в момент прохождения предыдущей контрольной точки, ставятся в очередь, пока обрабатывается текущая контрольная точка и о ее завершении не будет информирована резервирующая сторона. Мы применили этот буфер в качестве обслуживания linux, применяемого к гостевой ОС, взаимодействующей с сетевым устройством домена 0, которое отвечает на два сообщения RTnetlink. До того, как гостевой ОС будет разрешено возобновить исполнение после прохождения контрольной точки, сетевой буфер принимает сообщение CHECKPOINT, которое вынуждает его ограничить исходящую очередь, предотвращая выход любых дальнейших пакетов, пока не получено соответствующее открывающее сообщение. Когда гостевая контрольная точка получено резервирующим узлом, буфер получает открывающее сообщение, и в этот момент начинается раздача трафика, до следующего ограничения.

У такого подхода есть 2 мелких затруднения. Во первых, так как это linux, приоритезация возможна только для исходящего трафика. Под Xen, гостевые сетевые интерфейсы состоят из ответной части в гостевой ОС и соответствующего устройства в домене 0. Исходящий трафик из гостевой ОС рассматривается как входящий трафик на ответное устройство в домене 0. Поэтому, чтобы планировать трафик, мы преобразовали входящий трафик в исходящий, с помощью маршрутизации через специальное устройство, названное “устройство незамедлительной приоретизации” (McHardy, P. Linux imq. http://www.linuximq.net/.). Этот модуль разработан для работы на уровне IP через iptables (Russell, R. Netfilter. http://www.netfilter.org/.), но было не сложно расширить его работу до уровня моста, который мы используем для предоставления сетевого доступа к VM, при нашем подходе.

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

[править] 2.5 Буферизация диска

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

Также как описано про подсистему репликации памяти в разделе 2.3, записи на диск от активной VM используют “write-through”: они немедленно применяются к основному диску и асинхронно зеркалятся в буфер в памяти резервного узла. Этот подход дает две прямые выгоды: Первая, он обеспечивает чтобы образ активного диска всегда оставался консистентным; даже при падении обоих узлов, активный диск будет отражать состояние сбоя видимой из вне VM на момент сбоя (отражаемое снаружи состояние VM располагается на первичном узле если он не упал, или если резервный также упал, перед тем как был активирован, оно располагается на резервном). Вторая, прямая запись на диск точно рассчитывает задержку и пропускную способность физического диска. Эта кажущаяся очевидной возможность имеет большое значение: точная характеристика реакций диска сложная проблема, как мы сами проверили в ранней версии дискового буфера, который замораживал в памяти запросы записи основной VM, до прохождения контрольной точки. С подходом записи каждого буфера, недостаточно рассчитать время необходимое для передачи данных на диск и наделить VM возможностью выполняться с опережением или консервативно переоценить задержки записи и в результате потерять производительность. Моделирование времени доступа к диску, как известно сложно (Schindler, J., and Ganger, G. Automated disk drive characterization. Tech. Rep. CMU SCS Technical Report CMU-CS-99-176, Carnegie Mellon University, December 1999.), но наш подход искореняет проблему путем резервирования прямой обратной связи от диска до клиентской VM.

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

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

Буфер диска использован в модуле “block tap” в Xen (Warfield, A. Virtual Devices for Virtual Machines. PhD thesis, University of Cambridge, 2006.). “Block tap” это устройство, позволяющее процессу в привилегированном домене эффективно посредничать самому с интерфейсом дискового устройства находящемуся в гостевой VM и оконечным устройством, который обслуживает запросы. Модуль буферизации логирует запросы записи на диск от защищенной VM и зеркалит их на соответствующий модуль на резервном узле, обрабатывающем протокол контрольной точки, описанный ранее и затем сам себя убирает из дискового запроса, до того как резервный узел начнет выполнение, в случае сбоя основного.

Схема 4: Буферизация записи на диск в Remus.

[править] 2.6 Детектирование сбоя

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

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

[править] 3 Оценка

Главная цель создания Remus – достижение типичной и прозрачной HA, которая может быть развернута сегодня на широкораспространенном оборудовании. В этом разделе, мы описываем конечные достижения нашего подхода, при испытаниях под нагрузками, для ответа на 2 вопроса: (1) Эта система применима на практике? (2) Для каких приложений наиболее применим наш подход?

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

Затем мы оценили издержки, вносимые системой в производительность приложений, при самых различных нагрузках. Мы обнаружили, что задача общего характера, такая как компиляция ядра теряет ~ 50%, при расстановки контрольных точек 20 раз в секунду, при нагрузке на сеть, реализованной с помощью “SPECweb”, производительность находится в районе ¼ от родной. Дополнительная издержка в такой ситуации это высокая задержка исходящего трафика на сетевом интерфейсе.

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

[править] 3.1 Тестовое оборудование

Если не указано иное, все тесты запускались на серверах IBM eServer x306, в конфигурации: 3.2 GHz Pentium 4 CPU с включенной технологией “hyperthreading”, 1 GB RAM, 3 Intel e1000 GbE NIC, 80 GB SATA HDD. Гипервизор Xen 3.1.2, измененный как описано в Разделе Section 2.3, и ОС для всех VM linux 2.6.18, поставляемый в Xen 3.1.2, с изменениями описанными в Разделе 2.3. Защищенная VM размещалась на 512 MB от всей RAM. Для снижения “эффекта планирования” в VMM, VCPU домена 0 был привязан к первому hyperthread'у. Один физический сетевой интерфейс был привязан к виртуальному интерфейсу гостевой ОС, и задействован для трафика приложений, один был использован для административного доступа, и остальные были использованы для репликации (мы не связывали интерфейсы для репликации, так как это не важно для тестирования). Образы виртуальных дисков разместились на SATA HDD, экспортированные в гостевой домен с использованием драйвера “tapdisk AIO”.

[править] 3.2 Проверка корректности

Как обсуждалось в разделе 2.2, Протокол репликации Remus функционирует в 4 раздельных этапа: (1) Состояние измененной контрольной точки и шаг цикла, в котором передаются сетевой и десковый запрос; (2) реплицирование состояния системы, (3) когда завершена контрольная точка для памяти и соответствующее дисковое состояние принято, резервный узел уведомляет и (4) в момент принятия информации, осуществляется внешний сетевой вывод очереди предыдущего цикла. Для подтверждения, что наша система функционирует, мы сознательно протестировали ее, искусственно вызывая сетевые ошибки на каждом этапе. Для каждого теста, защищена система выполняла компиляцию ядра, с целью нагрузить диск, память и CPU. Для проверки сетевого буфера, мы одновременно запустили требовательный к графике клиент X11 (glxgears) соединенный с внешним сервером X11. Remus был настроен на постоянное создание контрольных точек каждые 25. Каждый индивидуальный тест был повторен дважды.

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

[править] 3.3 Измерения производительности

В данном разделе, мы оценили производительность при использовании нашей системы с помощью различных крупномасштабных тестов показателей, которые считаются репрезентативными в различных вариантах нагрузки во всем мире. В первом нагрузочном тесте мы запустили тест компиляции ядра, тест “SPECweb2005” и тест диска “Postmark”. Компиляция ядра является распределенной нагрузкой, для виртуальной памяти системы, диска и CPU, “SPECweb” во-первых тестит сетевую производительность и пропускную способность памяти и “Postmark” нацелен на производительность диска.

Схема 5: Зависимость времени прохождения контрольной точки от изменений памяти.

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

Компиляция ядра. В тесте компиляции ядра измерялось общее время необходимое для компиляции ядра linux 2.6.18 с использованием дефолтной конфигурации и получения bzImage. При компиляции использовался GCC 4.1.2 и make 3.81. Это распределяет нагрузку и тестирует производительность CPU, памяти и диска.

Схема 6 показывает потери в защите при установке интервалов контрольных точек 10, 20, 30, 40 раз в секунду, в сравнении с обычной компиляцией на незащищенной VM. Общая измеренная потеря для каждой из частот была 31%, 52%, 89%, 103% соответственно. Потери росли линейно с увеличением частоты контрольных точек, во время наших измерений. Этот набор тестов убедил нас, что разумные потери при основном использовании системы, соответствуют частоте контрольных точек 40 раз в секунду.

Схема 6: Время компиляции ядра от частоты контрольных точек.

SPECweb2005. Тест производительности “SPECweb” написан из трех отдельных частей: веб-сервер, сервер приложений и один или более симуляторов web-клиентов. Мы настроили 3 VM на отдельных физических машинах. Сервер приложений и клиент используют 640 MB из 1024 MB всей доступной RAM. Web-серверу и резервному узлу доступно 2048 MB RAM, из которых 1024 выделено на VM веб-сервера, на тестируемой системе. Достижения “SPECweb”, были побиты, при использовании “SPECweb” “e-commerce” мы достигли до 95% “хорошего” и 99% “удовлетворительного” времени.

Схема 7 отражает производительность “SPECweb” при различных частотах расстановки контрольных в сравнении с незащищенным сервером. Эти значения в основном определяются зависимостью вносимой сетевым буфером между сервером и клиентом. Несмотря на их настройку на различные частоты, "SPECweb" использует память достаточно быстро, настолько,что время требуемое на передачу изменившейся памяти между контрольными точками иногда превышает 100ms, независимо от частоты контрольных точек. Так как сетевой буфер не может быть открыт до момента информирования о состоянии контрольной точки, полная сетевая задержка может быть больше чем настроенный интервал контрольных точек. Remus обеспечивает чтобы VM была приостановлена к началу каждого периода, но не обеспечивает чтобы чтобы все состояние было реплицировано за период без превышения пропускной способности, доступной на момент настройки длины интервалов расстановки контрольных точек. Так как реальная частота контрольной точки ниже чем, заданная и сетевая задержка преобладает, посчитанная "SPECweb" производительность на самом деле плавает в интервале около настроенной частоты. При настройке на 10, 20, 30, 40 контрольных точек в секунду средние частоты контрольной точки составляют 9.98, 16.38, 20.25, 23.34 соответственно или средней задержки 100ms, 61ms, 49ms, 43ms соответственно.

Схема 7: Значения "SPECweb" от частоты контрольных точек (исходное значение: 305)

"SPECweb" это требовательный к RAM тестировщик, который также чувствителен к сетевой задержке. Это делает его слвбо подходящим под наше текущее применение, которое порождает сетевую задержку при обмене с памятью. Схема 8 ярко демонстрирует эффект задержки между клиентской VM и веб-сервером "SPECweb". Мы использовали планировщик Linux netem (netem. http://linux-net.osdl.org/index.php/Netem) для создания некоторой задержки на исходящем соединении веб-сервера (виртуализованного но не запущенного под Remu). Для сравнения, Схема 7 также отражает потери из-за защиты, когда отключена сетевая буферизация, для лучшей нейтрализации сетевой задержки из-за других форм потерь в контрольных точках (еще раз, плавающий профиль связан с интервалом контрольных точек, более коротких, чем настроено). Ограничения планирования и сжатие страниц, описанные в Разделе 3.4, являются двумя возможными механизмами снижения задержек в контрольных точках и времени передачи. При сокращении задержек контрольных точек на одном или обоих узлах, производительность "SPECweb" скорее всего значительно возрастет.

Схема 8: Влияние сетевой задержки на производительность "SPECweb".

Postmark. Предыдущий раздел характеризует производительность сети и памяти, при защите, но использованные тесты создают только небольшую нагрузку на дисковую подсистему. Для того, чтобы лучше понять эффект, даваемый механизмом буферизации диска мы запускали "Postmark" - дисковый тестировщик (version 1.51). Этот тест производительности чувствителен к пропускной способности и времени ответа диска. Для снижения затрат на репликацию диска мы не задействовали защиту памяти или сети в процессе этого теста. Конфигурация была идентична незащищенной системе, с исключением в виртуальном диске, для которого был использован модуль репликации "tapdisk". Схема 9 отображает общее необходимое время для совершения 10000 транзакций "postmark" без дисковой репликации и с дисковой репликацией соответствующей частоте 10, 20, 30, 40 раз в секунду. Результаты показывают, что такая репликация не оказывает существенного влияния на производительность диска.

Схема 9: Влияние репликации диска на производительность "Postmark".

[править] 3.4 Возможности оптимизации

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

Планирование по сроку завершения. Общее количество времени необходимое для прохождения контрольной точки варьируется, в зависимости от количества копируемой памяти. Но, даже не смотря на это, Remus дает гарантирует защищенной VM приостановку в начале каждого периода, в настоящее время нет попыток проконтролировать количество состояний которые могут меняться между периодами. Для создания четких плановых гарантий, скорость работы гостевой ОС может быть намеренно замедлена (Gupta, D., Yocum, K., McNett, M., Snoeren, A. C., Vahdat, A., and Voelker, G. M. To infinity and beyond: time warped network emulation. In SOSP '05: Proceedings of the twentieth ACM symposium on Operating systems principles (2005).) между контрольными точками, в зависимости от количества измененных страниц памяти. Приложения, которые приоритезируют задержки по пропускной способности, такие как те что моделирует тест “SPECweb”, обсуждаемый в Разделе 3.3, могут регулировать их для увеличения производительности. Для каждой операции, контейнер таблиц страниц скрытой памяти может быть увеличен, в ожидании вызова, пока кол-во измененых страниц превышает некоторую максимальную отметку, или он может напрямую поставить VM на паузу.

Сжатие страниц. Уже было рассмотрено, как диск обычно записывает только 5–20% всего блока данных (Yang, Q., Xiao, W., and Ren, J. Trap-array: A disk array architecture providing timely recovery to any point-in-time. In ISCA '06: Proceedings of the 33rd annual international symposium on Computer Architecture (Washington, DC, USA, 2006), IEEE Computer Society, pp. 289–301.). Если аналогичную особенность применить для RAM, мы используем его, чтобы уменьшить количество состояний, требующих репликации, петем пересылки только изменений от предыдущий передачи этой же страницы.

Для получения возможной выгоды от сжатия потока репликации мы разработали образец базового механизма сжатия. Перед передачей страницы, система проверяет ее наличие в адресно-индексирующем кеше LRU, хранящим предыдущие переданные страницы. Если она в кеше, страница обрабатывается функцией XOR к предыдущей версии и различия кодируются RLE. Это позволяет значительно сжать не сильно измененные записываемые страницы. Хотя это и так на протяжении большей части потока данных, по-прежнему есть значительная часть страниц, которые были изменены, для которых XOR сжатие не является эффективным. В таких случаях, алгоритмы общего назначения, как например, использование GZIP поможет достичь более высокой степени сжатия.

Мы обнаружили это используя совмещенный подход, в котором каждая страница предварительно сжатая XOR, передавалась обратно для сжатия gzip, если степень XOR-сжатия была менее 5:1 или если предыдущая страница не была кеширована, мы смогли достичь обычного сжатия 10:1 в потоке репликации. Схема 10 показывает пропускную способность в MBps для 60-секундного периода теста с компиляцией ядра, описанного в Разделе 3.3. Размер кеша был 8192 страниц и средняя вероятность попадания в кеш составила 99%.

Схема 10: Сравнение требуемой пропускной способности с использованием различных схем компрессии.

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

Контрольные точки копирования при записи. Текущая реализация приостанавливает домен в каждой контрольной точке, на время, линейно зависящее от количества измененных страниц, за время прошедшее с момента последней контрольной точки. Это ограничение можно смягчить путем "копирования при записи" измененных страниц и немедленного запуска домена. Это помогает снизить время, за которое домен должен быть приостановлен, до небольшого фиксированного значения, пропорционального общему количеству доступной для гостевой ОС RAM. Мы намерены реализовать "копирование при записи" путем предоставления системы теневых страниц Xen с промапленным в пользовательское окружение буфером в который оно будет копировать измененные страницы до восстановления доступа на чтение-запись. Затем процесс репликации может извлечь какие либо страницы из буфера, с пометкой "извлечены из буфера COW", вместо прямого чтения их из гостевой ОС. Когда завершиться репликация страниц, занимаемое ими пространство в буфере может быть помечено для повторного использования модулем Xen COW. Если образовался пустой буфер, гостевая ОС может просто приостановиться, в результате изящного уменьшения масштаба сервиса от COW до операции "остановка и копирование".

[править] 4 Аналогичные системы

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

Миграция виртуальной машины. Как описано ранее, Remus в основном создан на основе поддержки живой миграции Xen (Clark, C., Fraser, K., Hand, S., Hansen, J. G., Jul, E., Limpach, C., Pratt, I., and Warfield, A. Live migration of virtual machines. In Proceedings of the 2nd conference on Symposium on Networked Systems Design & Implementation (Berkeley, CA, USA, 2005), USENIX Association.), значительно расширенной для поддержки частых репликации на удаленный узел. Bradford и другие, расширяли живую миграцию Xen's в другом направлении: миграция не измененного состояния, совместно с миграцией гостевой ОС, которая может быть перезапущена на удаленном узле, который не имеет совместного с основной системой общего доступа к сетевому хранилищу (Bradford, R., Kotsovinos, E., Feldmann, A., and Schiöberg, H. Live wide-area migration of virtual machines including local persistent state. In VEE '07: Proceedings of the 3rd international conference on Virtual execution environments (New York, NY, USA, 2007), ACM Press, pp. 169–179.).

Также как и Remus, другие проекты использовали виртуальные машины для реализации HA. Наиболее похожа на нашу работу работу Bressoud and Schneider's (Bressoud, T. C., and Schneider, F. B. Hypervisor-based fault-tolerance. In Proceedings of the Fifteenth ACM Symposium on Operating System Principles (December 1995), pp. 1–11.). Они использовали монитор вирт. машин для перенаправления приходящих событи от основной системы на резервную, где они воспроизводились независимо до повторения состояния основной системы. Независимое выполнение накладывает более строгие ограничения на архитектуру удаленного узла, нежели простая виртуализация, которая зависит только от архитектуры использованного VMM.

Другим существенном недостатком независимого исполнения, проанализированным в работе Bressoud and Schneider является то, что его нельзя легко расширить для много-ядерных CPU. Проблема заключается в том, что необходимо, но сложно определить, какое из ядер осуществляет доступ к общей памяти. Было сделано несколько попыток для решения этой проблемы. К примеру, Flight Data Recorder (Xu, M., Bodik, R., and Hill, M. D. A "flight data recorder" for enabling full-system multiprocessor deterministic replay. In ISCA '03: Proceedings of the 30th annual international symposium on Computer architecture (New York, NY, USA, 2003), ACM Press, pp. 122–135.) это аппаратный модуль, который перехватывает когерентный кеш трафик, с целью регистрации порядка, в котором несколько процессоров осуществляют доступ к памяти. Кроме того, Dunlap ввел программый подход с помощью протокола CREW (совместное чтение, единоличная запись), являющейся надстройкой над общей памятью через защиту страниц (Dunlap, G. Execution Replay for Intrusion Analysis. PhD thesis, University of Michigan, 2006.). Пока эти подходы дали возможность сделать SMP-детерминистированное выполнение, это не имеет смысла, так как несет высокие издержки, которые возрастают линейно с ростом параллелизма. Наша работа полностью обходит эту проблему, так как не требует детерминированного выполнения.

Логгирование и выполнение VM. Логгирование VM использовалось для других целей нежели HA. К примеру, в ReVirt (Dunlap, G. W., King, S. T., Cinar, S., Basrai, M. A., and Chen, P. M. Revirt: Enabling intrusion analysis through virtual-machine logging and replay. In Proceedings of the 5th Symposium on Operating Systems Design & Implementation (OSDI 2002) (2002).), виртуализация использовалась для предоставления уровня безопасности для логгирования изменений состояния на получаемой системе, в целях обеспечения улучшения показателей для систем обнаружения вторжений. Перевыполняемая система, это копия, оригинальной системы, доступная для чтения , которая не предназначена для запуска в целях воссоздания событий рождаемых в заимосвязанной системе. Логгирование также может быть использована для создания отладчика с перемещением по времени (King, S. T., Dunlap, G. W., and Chen, P. M. Debugging operating systems with time-traveling virtual machines. In ATEC'05: Proceedings of the USENIX Annual Technical Conference 2005 on USENIX Annual Technical Conference (Berkeley, CA, USA, 2005), USENIX Association.) который, также как и ReVirt, воспроизведет систему только для анализа.

Репликация ОС. Есть множество ОС, таких как Accent (Rashid, R. F., and Robertson, G. G. Accent: A communication oriented network operating system kernel. In SOSP '81: Proceedings of the eighth ACM symposium on Operating systems principles (New York, NY, USA, 1981), ACM Press, pp. 64–75.), Amoeba (Mullender, S. J., van Rossum, G., Tanenbaum, A. S., van Renesse, R., and van Staveren, H. Amoeba: A distributed operating system for the 1990s. Computer 23, 5 (1990), 44–53.), MOSIX (Barak, A., and Wheeler, R. Mosix: an integrated multiprocessor unix. 41–53.) и Sprite (Ousterhout, J. K., Cherenson, A. R., Douglis, F., Nelson, M. N., and Welch, B. B. The sprite network operating system. Computer 21, 2 (1988), 23–36.), которые поддерживают миграцию процессов, толька для балансировки нагрузки. Основная цель при использовании процесса миграции для защиты от сбоев, наличие мигрировавшего процесса, который имеет необходимые связи с системой, из которой он был перенесен. Отключение этих зависимостей должно произойти при отказе основной системы, но решение нетревиально, из-за сложной структуры таких связей.

Были и попытки создания реплицируемых приложений на уровне ОС. Zap (Osman, S., Subhraveti, D., Su, G., and Nieh, J. The design and implementation of zap: a system for migrating computing environments. SIGOPS Oper. Syst. Rev. 36, SI (2002), 361–376.) пытался внедрить слой виртуализации в ядро linux. Этот подход заставляет изменять каждую ОС и требует тщательного контроля при обновлениях.

При помощи библиотек. Некоторые библиотеки приложений имеют поддержку миграции процессов и расстановки контрольных точек. Это обычно помогает для структур параллельных приложений, таких как CoCheck (Stellner, G. CoCheck: Checkpointing and Process Migration for MPI. In Proceedings of the 10th International Parallel Processing Symposium (IPPS '96) (Honolulu, Hawaii, 1996).). Обычно, миграция процессов используется для балансировки нагрузки и контрольных точек, используемых для восстановления в случае выхода из строя всего распределенного приложения.

Реплицироемое хранилище. В этом направлении также существует большой объем работ, для создания хранилища контролируемого контрольными точками, на случаи восстановления при сбоях. Linux Logical Volume Manager (Lvm2. http://sources.redhat.com/lvm2/.) предоставляет ограниченную форму копирования на лету снапшотов блочного хранилища. Parallax (Warfield, A., Ross, R., Fraser, K., Limpach, C., and Hand, S. Parallax: managing storage for a million machines. In HOTOS'05: Proceedings of the 10th conference on Hot Topics in Operating Systems (Berkeley, CA, USA, 2005), USENIX Association.) значительно улучшает этот проект снимая ограничения создания снапшотов блочного хранилища на лету. Andrew File System (Howard, J. H., Kazar, M. L., Menees, S. G., Nichols, D. A., Satyanarayanan, M., Sidebotham, R. N., and West, M. J. Scale and performance in a distributed file system. ACM Transactions on Computer Systems 6, 1 (1988), 51–81.) позволяет создавать один снапшот одновременно, для заданного тома. Другие подходы, включая RSnapshot, являющиеся надстройками над файловой системой позволяют создавать снепшоты через серию жестких ссылок и внедрены в широкий спектор ПО для резервного копирования. DRBD (Reisner, P., and Ellenberg, L. Drbd v8 – replicated storage with shared disk semantics. In Proceedings of the 12th International Linux System Technology Conference (October 2005).) это программная надстройка над блочным устройством, которая прозрачно его реплицирует на другой сервер.

Опережающее выполнение. Использование опережающего выполнения с целью изолирования I/O процессов от вычилений было открыто и другими системами. В частности, SpecNFS (Nightingale, E. B., Chen, P. M., and Flinn, J. Speculative execution in a distributed file system. In SOSP '05: Proceedings of the twentieth ACM symposium on Operating systems principles (New York, NY, USA, 2005), ACM Press, pp. 191–205.) и Rethink the Sync (ightingale, E. B., Veeraraghavan, K., Chen, P. M., and Flinn, J. Rethink the sync. In USENIX'06: Proceedings of the 7th conference on USENIX Symposium on Operating Systems Design and Implementation (Berkeley, CA, USA, 2006), USENIX Association.) используют опережение, аналогично нам, с целью создания асинхронности в I/O процесах. Remus отличается от таких систем, в том, что смысл блочного ввода-вывода из гостевой ОС остается неизменным полностью: он немедленно применяется к локальному физическому диску. Напротив, наша система буферизации сгенерированного сетевого трафика делает невидимым извне эффект опережающего выполнения, до тех пор, пока состояние не реплицировано полностью.

[править] 5 Предстоящая работа

В этом разделе кратко описан ряд направлений, необходимые для улучшения и расширения Remus. Как мы продемонстрировали в предыдущем разделе, издержки, накладываемые сервисом HA не являются безосновательными. Тем не менее, описанное в этом документе применение слабо развито. Некоторые потенциальные области оптимизации остались не изучены. После полной реализации оптимизаций, описанной в Разделе 3.4, мы намерены исследовать более важные дополнение, которые описаны далее.

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

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

Кластерная репликация. Может быть полезным - расширить систему для защиты множества соединенных между собой узлов. Пока каждый узел можно защитить независимо, While each host can be protected independently, согласованная защита может дать возможность установить сетевое соединения, для работы без буферизации. В этом есть потенциал для резкого повышения пропускной способности в используемых приложениях, включая 3х уровневые конфигурации веб-приложений, распространенных в сфере хостинга. Поддержка кластерной репликации можно реализовать с помощью распределенного протокола контрольных точек, аналогичного тому, который был описан нашим коллегой Gang Peng в магисторской диссертации (Peng, G. Distributed checkpointing. Master's thesis, University of British Columbia, 2007.), который использует раннюю версию инфраструктуры контрольных точек Remus.

Восстановление после сбоя. Remus это продукт проекта "SecondSite" (Cully, B., and Warfield, A. Secondsite: disaster protection for the common server. In HOTDEP'06: Proceedings of the 2nd conference on Hot Topics in System Dependability (Berkeley, CA, USA, 2006), USENIX Association.), целью которого являлось создание географически разнесенного зеркала функционирующих систем с целью защиты от форсмажора. Мы планируем размещать Remus в нескольких точках, в целях эксперимента с конфигурацией такого рода. При развертывании на больших дистанциях, сетевая задержка будет влиять еще больше. К тому же, потребуется переконфигурировать сеть для соответствующего перенаправления Интернет трафика.

Датацентры организованные логически. Мы расширяем Remus для полного логгирования и сохранения истории выполнения защищааемых VM, а не только самых важных контрольных точек. Путем промапливания памяти гостевой ОС в Parallax (Meyer, D., Aggarwal, G., Cully, B., Lefebvre, G., Hutchinson, N., Feeley, M., and Warfield, A. Parallax: Virtual disks for virtual machines. In EuroSys '08: Proceedings of the ACM SIGOPS/EuroSys European Conference on Computer Systems 2008 (New York, NY, USA, 2008), ACM.), наше хранилище виртуальных блоков, разработанное для получение снепшотов с большой частотой, мы надеемся что удастся эффективно сохранять большие объемы неизменных и переходных состояний с очень хорошей детализацией. Такие данные должны стать очень полезными, при разработке расширенного дебаггинга и экспертных тулзов. Это также может дать удобный механизм для восстановления из поврежденного состояния, внесенного ошибкой оператора или путем воздействия вредоносного ПО (вирусы и т. д.).

[править] 6 Заключение

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

Предоставляя HA это сложная задача, требующая в случае традиционного подхода значительных затрат и инженерных усилий. Remus создает HA путем предоставления ее как сервиса на уровне платформы виртуализации: HA можно легко включить для определенных VM. Как и с любой системой, защиты не бувает без потерь: Сетевая буферезаци требует гарантий констистентности репликации, что налагает издержки производительности на приложения, требующие очень низкой задержки. Администраторы должны также развертывать доп. оборудование, которое может использоваться в конфигурации многие-к-одному, с единственным резервным узлом защищающем несколько активных узлов. В замен этих издержек, Remus полностью освобождает от задачи изменения каждого приложения для предоставления способностей HA и еще он не требует использования специально предназначенного оборудования.

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

[править] Благодарности

Авторы хотели бы поблагодарить своих вдохновителей, Arunа Venkataramani, и анонимных обозревателей за их содержательные и одобряющие отзывы. Мы также в долгу у Anoop Karollil за его помощь в оценках. Эту работу спонсировали "Intel Research" и "The National Science and Engineering Research Council of Canada".

[править]

Тоже что Citrix Systems, Inc.

1

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

2

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

[править]

Данный документ перевел HEVEA из LATEX. Bold text