Эта статьяБумага об отказоустойчивой виртуальной машинечтение заметок. В этой статье реализуется отказоустойчивая виртуальная машина, которая резервирует работу основной виртуальной машины на другом сервере. Есть две идеи реализации:
- Резервное копирование всех изменений состояния на резервную виртуальную машину(включая ЦП, память, устройства ввода/вывода). Однако таким образом объем данных, которые необходимо передать и обработать, будет огромным.
- Рассматривайте виртуальные машины как детерминированные конечные автоматы, который является методом этой статьи. Требуется только начальное состояние и детерминированный ввод, а для завершения резервного копирования записываются некоторые неопределенные события.
VMware реализовала механизм резервного копирования виртуальных машин, описанный в этой статье, в vSphere, что позволяет без проблем создавать резервные копии виртуальных машин после сбоя основной виртуальной машины. В настоящее время эта технология поддерживает только одноядерные процессоры, поскольку выборка инструкций многоядерного процессора также является неопределенным событием. Конечно, предпосылка того, что механизм резервного копирования, реализованный в этой статье, работает, заключается в том, что неисправность может быть обнаружена до того, как она будет обнаружена извне.
Базовая отказоустойчивая конструкция
Отказоустойчивая конфигурация показана ниже для виртуальной машины (главная виртуальная машина), мы запускаемРезервное копирование виртуальных машин, два хоста находятся ввиртуальное состояние блокировки. они будут подключены к одномуобщий диск. Среди них весь ввод (включая сеть, мышь, клавиатуру и т.д.) будет отдаваться только на основную виртуальную машину, и то черезлог каналОтправлено на резервную виртуальную машину.
Определить реализацию воспроизведения
При запуске реплицированной виртуальной машины возникают три основные проблемы:
- Правильно фиксировать все входные данные и неопределенные события, необходимые для обеспечения детерминированной работы резервной виртуальной машины,
- Правильно применяйте ввод и неопределенность для резервного копирования виртуальных машин
- Гарантированно не снижает производительность
Однако VMware vSphere уже предоставляетVMware OK Воспроизвести[2] Функция.
протокол отказоустойчивости
输出要求：如果备份虚拟机在故障之后替代了主虚拟机，备份虚拟机运行期间要保证外界得到的输出是完全一致的。
только доволенвыходные требования, сбой не будет замечен внешним миром, и это требование требует задержки внешнего вывода до тех пор, пока резервная виртуальная машина не получит достаточно информации для воспроизведения операции вывода. Необходимое условие — резервная виртуальная машина должна получить все логи перед операцией вывода. Резервная виртуальная машина не может подключиться к сети до операции экспорта, так как в основной виртуальной машине могут быть неопределенные события, которые отменяют последующий экспорт.
输出规则：主虚拟机不会将输出发送给外界，直到收到了来自备份虚拟机收到产生输出的操作的日志的确认。
Протокол отказоустойчивости показан на рисунке ниже: асинхронные события, операции ввода и вывода отправляются на резервную виртуальную машину, а основная виртуальная машина выводит только после того, как резервная виртуальная машина подтвердит получение операции вывода.
Однако протокол не может гарантировать повторяющиеся выходные данные, поскольку резервная ВМ не имеет возможности узнать, произошел ли сбой основной ВМ до или после вывода, и пакеты, отправленные на основную ВМ в случае сбоя, также будут потеряны. К счастью, сетевая инфраструктура, операционные системы и приложения обычно могут справляться с потерей или дублированием пакетов.
Обнаружение неисправностей и реагирование
Все журналы необходимо применить до того, как резервная виртуальная машина заменит основную виртуальную машину. Основная виртуальная машина и резервная виртуальная машина в основном используют пакеты пульса и журналы связи, чтобы определить, не неисправны ли друг друга. Чтобы решить проблему разделения мозгов, две виртуальные машины должны знать, неисправны ли друг друга через общий диск. Если основная виртуальная машина выходит из строя, резервная виртуальная машина заменяет основную виртуальную машину и создается новая резервная виртуальная машина; если резервная виртуальная машина выходит из строя, создается новая резервная виртуальная машина.
Практики реализации отказоустойчивости
- Запускать и перезапускать отказоустойчивые виртуальные машины
После запуска основной виртуальной машины или отказа резервной виртуальной машины необходимо создать резервную виртуальную машину в том же состоянии, что и основная виртуальная машина, и работа основной виртуальной машины не может быть прервана. Специально реализованная с помощью VMware VMotion, VMotion копирует виртуальную машину на другой физический сервер, используя исходную виртуальную машину в качестве основной виртуальной машины, а целевую виртуальную машину в качестве резервной виртуальной машины.
Резервная виртуальная машина обычно находится на другом сервере в кластере, выбранном для размещения по расписанию vSphere, и эти серверы имеют доступ к общему диску.
- Управление каналами журналов:
Канал журнала может быть реализован с помощью большого буфера, а необходимое время может контролировать скорость работы основной виртуальной машины, чтобы гарантировать, что резервная виртуальная машина сможет догнать ее.
- Эксплуатация отказоустойчивых виртуальных машин
Виртуальные машины имеют различные операции управления, такие как отключение и изменение выделения ресурсов, которые фактически могут быть реализованы с помощью специальных журналов операций управления.
Отказоустойчивость представляет собой проблему для VMotion, которая используется для беспрепятственной миграции виртуальных машин, требуя приостановки всех дисковых операций ввода-вывода во время переключения. Основная виртуальная машина может приостановить дисковый ввод-вывод, но если резервная виртуальная машина дублирует основную виртуальную машину, вам необходимо запросить основную виртуальную машину приостановить дисковый ввод-вывод через канал журнала.
- Проблемы в реализации дискового ввода/вывода:
Реализация дискового ввода-вывода столкнется со следующими проблемами.
- Дисковые операции не блокируются, поэтому возможна параллельная запись, но это вносит недетерминированность. Решение состоит в том, чтобы принудительно выполнять дисковые операции последовательно.
- Дисковые операции (DMA) и приложения работают с одним и тем же блоком памяти параллельно, вызывая гонки данных. Решение состоит в том, чтобы использовать дополнительный буфер, сначала считывать данные в дополнительный буфер при чтении с диска и копировать данные в дополнительный буфер при записи на диск.
- Когда основная виртуальная машина выходит из строя, а резервная виртуальная машина вступает во владение, дисковый ввод-вывод может не завершиться. Решение состоит в том, чтобы повторить дисковую операцию, так как первые две схемы уже избегают гонок данных, поэтому дисковая операция является реентерабельной.
- Проблемы реализации сетевого ввода/вывода:
vSphere реализует некоторые сетевые оптимизации, такие как получение данных напрямую из сетевого буфера без прохождения ловушки, но это внесет неопределенность, поэтому эту оптимизацию необходимо отключить. Кроме того, были сделаны следующие оптимизации:
- Уменьшите ловушки и простои виртуальных машин с помощью массовых операций.
- Уменьшите задержку передачи пакетов данных: зарегистрируйте операции отправки и получения в стеке протокола TCP, чтобы обеспечить немедленную отправку и получение журналов.
выбор в дизайне
Делиться ли диском
Основная виртуальная машина и резервная виртуальная машина могут фактически использовать независимые диски.Диск является внутренним хранилищем, поэтому нет необходимости соблюдатьвыходные требования, но два диска необходимо синхронизировать в начале отказоустойчивости. Однако это проблема разделения мозгов, которая не может быть решена с помощью диска и требует наличия стороннего сервера координации.
Выполните операцию чтения с диска в резервной виртуальной машине.
Виртуальные машины резервного копирования также могут рассматривать возможность чтения данных напрямую с диска, минуя канал журнала. Но это может привести к тому, что виртуальная машина резервного копирования будет работать медленно, поскольку ей нужно ждать чтения с диска, обрабатывать ошибки чтения и откладывать запись, чтобы убедиться, что предыдущие операции чтения успешно выполняются сервером резервного копирования.
использованная литература
- Scales, Daniel J., Mike Nelson, and Ganesh Venkitachalam. "The design of a practical system for fault-tolerant virtual machines." ACM SIGOPS Operating Systems Review 44.4 (2010): 30-39.
- Sheldon, M. X. V. M. J., and Ganesh Venkitachalam Boris Weissman. "Retrace: Collecting execution trace with virtual machine deterministic replay." Proceedings of the Third Annual Workshop on Modeling, Benchmarking and Simulation (MoBS 2007). 2007.