Базовые элементы Flash Virtualization Platform (FVP), часть 1

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

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

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

Виртуальное устройство может получить недостаточно тактов процессора, как результат операции ввода-вывода будут ожидать внутри виртуального устройства (3) или в модуле vmkernel (2), до поступления в модуль ядра, отвечающий за хранение данных, где снова попадает в очереди ввода-вывода. Схожая проблема возникает при подтверждении ввода-вывода. От флеша ввод-вывод подтверждается (5) виртуальному устройству, устройство должно получить такты ЦП для обработки подтверждения. Затем устройство должно передать подтверждение (6) виртуальной машине (7) через модуль vmkernel и виртуальная машина должна получить такты ЦП для приема подтверждения (8). На системах с низкой загрузкой проблема не будет видна, но по мере роста нагрузки и добавления все большего числа виртуальных машин ускорение ввода-вывода будет быстро убывать.

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

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

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

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

FVP использует модуль ядра
Вместо виртуального устройства был разработан модуль ядра. FVP расширяет гипервизор, устанавливая модуль ядра внутрь VMkernel. Как он работает: модуль ядра "взламывает" путь ввода-вывода по дороге от виртуальной машины к гипервизору. До передачи в подсистему хранения FVP определяет должна ли быть данная операция ввода-вывода обработана с использованием локального флеш-устройства или передана на внешнюю систему хранения данных. Будучи частью гипервизора FVP столь же быстр в обработке ввода-вывода виртуальной машины. Так как FVP реализован в виде модуля ядра, то нет необходимости заниматься тонкой подстройкой конфигурации ЦП и ОЗУ, кроме того, нет опасности случайно отключить виртуальное устройство.

Виртуальное устройство = плохо?
Не всегда. Однако когда вы работаете с флешем в пути ввода-вывода и получаете к нему доступ в оперативной памяти проблема в том, что каждый оверхед, который вы добавляете в путь данных, очень быстро начинает оказывать значимое влияние. Оперативная память имеет наносекундные задержки, латентность флеш-устройств изменяется микросекундами, тогда как жесткие диски и виртуальные устройства работают в миллисекундном мире. Следовательно, если ваша задача отделить уровень производительности от уровня хранения данных, имеет смысл использовать архитектуру, подходящую для каждого из уровней. Отличная архитектура объединит оба решения. Используйте FVP для уровня производительности и виртуальные устройства для уровня хранения данных.