Отказоустойчивое ускорение записи (FVP, часть 6)
Для обеспечения наилучшей производительности критически важным является ускорение операций как чтения, так и записи. Однако есть фундаментальные различия при проектировании платформы, которая обеспечивает ускорение как чтения, так и записи по сравнению с платформой, ускоряющей только чтение.
Ускорение операций чтения - относительно "простой" процесс. Копируй данные, считанные из датастора, в флеш-устройство и обслуживай последующие запросы чтения из этого же устройства. Нет необходимости поддерживать отказоустойчивость. Данные на флеш-устройстве - скопированная версия данных на датасторе. Изменения всегда производятся для данных, расположенных на датасторе. Следовательно, отказ флеш-устройства не окажет на приложение никакого влияния, кроме уменьшения производительности. Однако это не так в случае ускорения операций записи. При ускорении операций записи данные сначала записываются на флеш-устройство и потом в фоне копируются на систему хранения данных. В этом временном интервале есть шанс потери неперенесенных данных в случае отказа флеш-устройства или хоста целиком.
Потери данных недопустимы, поэтому FVP спроектирован с нуля для обеспечения консистентности и доступности данных. Реплицируя данные операций записи на соседние хосты, платформа предотвращает потерю данных в случае отказа флеш-устройства или хоста. В силу кластерной природы FVP способен поддерживать консистентность данных записи между хостом-источником и репликами и требует минимальный объем пространства хранения без значительной нагрузки на сетевое соединение. Давайте внимательно посмотрим, как FVP обеспечивает отказоустойчивое ускорение записи.
Интеграция FVP расширением гипервизора
Основы отказоустойчивого ускорения записи обеспечиваются путем расширения VMkernel. В силу глубокой интеграции FVP с чрезвычайно стабильным ядром ESXi, FVP защищен и получает достаточно тактов ЦП и ресурсов для работы. Модуль ядра FVP расширяет код ядра, это означает, что в нем отсутствуют сервисы, работающие в виртуальной машине или виртуальном устройстве, которые могут быть неожиданно остановлены или выключены. Это также значит, что подобно VMkernel, FVP может исполняться на любом ЦП и, следовательно, масштабироваться соответственно нагрузке; до тех пор пока работает ядро, работает и FVP. Дополнительная информация о принципе выбора архитектуры модуля ядра вместо виртуального устройства доступна в статье "Базовые элементы Flash Virtualization Platform (FVP), часть 1".
Избыточность записи
При добавлении виртуальной машины во флеш-кластер вы можете выбрать подходящую политику записей. Дополнительная информация о различиях между политиками сквозной и отложенной записей доступна в статье "Политики кэширования Write-Back и Write-Throuhg в FVP". Политика отложенной записи (Write-back) имеет три опции: "Только локальное флеш-устройство" (Local flash only), "Локальное флеш-устройство и 1 сетевое флеш-устройство" (Local flash and 1 network flash device) и "Локальное флеш-устройство и 2 сетевых флеш-устройства" (Local flash with 2 network flash devices).
Только локальное флеш-устройство
Эта опция политики отложенной записи создана для обеспечения максимальной производительности для приложений, которые не требуют дополнительной целостности данных, таких как регенерируемые VDI рабочие столы или виртуальные киоски. Обратите внимание, что по причине использования флеш-устройств (являющихся энергонезависимым ресурсом) данные остаются доступными на устройстве до тех пор, пока не наступил отказ самого устройства. К примеру, если произошли отказ и перезагрузка хоста, данные по-прежнему располагаются на флеш-устройстве. Если на уровне хоста произошла значительная поломка, то флеш-устройство может быть установлено в другом хосте, являющемся частью флеш-кластера, и FVP определит данное устройство и произведет копирование данных на датастор при необходимости.
Локальное флеш-устройство с сетевыми флеш-устройствами
Выбор политики отложенной записи с опцией одного или двух сетевых флеш-устройств приведет к тому, что операции записи будут реплицироваться на указанное количество соседних сетевых флеш-устройств. Процесс записи данных работает по алгоритму синхронной репликации, это означает, что как источник, так и сетевые флеш-устройства должны подтвердить операцию записи до передачи подтверждения виртуальной машине.
1. Виртуальная машина генерирует операцию записи.
2. FVP отправляет данные одновременно на локальное и сетевое флеш-устройства.
3. Сетевое и локальное флеш-устройства подтверждают выполнение записи.
4. FVP подтверждает выполнение записи виртуальной машине.
На данном этапе ввод-вывод для приложения завершается и приложение может продолжать работу. FVP асинхронно переносит данные на систему хранения. Этот процесс полностью прозрачен для приложения.
5. FVP копирует данные на систему хранения.
Частота копирования данных на систему хранения
Хотя данные безопасно хранятся на нескольких устройствах, FVP старается как можно быстрее скопировать их на систему хранения. После подтверждения операции записи от флеш-устройств FVP копирует данные на систему хранения как можно быстрее, не перегружая при этом систему хранения. FVP синхронно уведомляет хосты источника и реплики о статусе данных, после записи данных на систему хранения FVP уведомляет хосты с репликами о возможности сброса данных в режиме минимальной загрузки. По такому алгоритму хост с репликой может повторно использовать место для хранения данных без принудительной сборки мусора в кэше и очистки ячеек флеш-устройства. Этот метод позволяет поддерживать расходы на дополнительный флеш-кэш на минимальном уровне.
Интерфейс показывает флэш-кэш виртуальной машины на каждом устройстве. В этом сценарии виртуальная машина Machine 1 сконфигурирована с политикой отложенной записи с опцией "Локальное флеш-устройство и 1 сетевое флеш-устройство". Локальный флеш-кэш machine 1 - 208.5 МБ, тогда как реплицированные данные записей занимают только 512 КБ.
Обработка отказов
Что произойдет, если откажет один из компонентов архитектуры? Компоненты могут отказать как на хосте, на котором работает виртуальная машина, так и на хосте, содержащем реплику записанных данных. ПО FVP разработано для обработки отказа как хоста-источника, так и хоста-реплики.
Отказ хоста-источника
В момент, когда на хосте-источнике возникает проблема, FVP назначает один из хостов-реплик, содержащих записываемые данные, ответственным за запись данных на систему хранения данных. Такой ошибкой может быть отказ флеш-устройства или полный отказ хоста. Если на хосте-источнике отказывает флеш-устройство, то виртуальная машина остается активной, ее ввод-вывод не ускоряется. Это означает, что отказ флеш-устройства оказывает влияние на производительность, но не на доступность самого приложения. Хост, содержащий реплику данных, становится ответственным за копирование оставшихся ускоренных записей на систему хранения.
Аналогичный алгоритм срабатывает в случае отказа хоста-источника. Один из хостов с репликой копирует оставшиеся ускоренные записи на систему хранения. HA перезапускает виртуальную машину на доступном хосте, и приложение может продолжить работу без потери данных.
Отказ хоста реплики
Что произойдет при отказе флеш-устройства или хоста с репликой данных? В этом случае FVP запускает два отдельных процесса. В первую очередь, политика записи виртуальной машины динамически переключается в режим сквозной записи. Как я писал выше, главной задачей FVP является обеспечение доступности данных. В силу отказа хоста-реплики текущий набор хостов перестает соответствовать выбранному требованию отказоустойчивости записей.
Во время переключения политики с режима отложенной записи в режим сквозной записи хост-источник принудительно копирует все отложенные записи на систему хранения данных.
Менеджер распределенных ресурсов PernixData выбирает другой хост во флеш-кластере на замену отказавшему хосту-реплике. После завершения выбора политика записей виртуальной машины переключается обратно в режим отложенной записи. Этот процесс выполняется автоматически без необходимости ручного вмешательства администратора. FVP, в первую очередь, обеспечивает защиту данных и переключается в режим затребованного ускорения в случае, если инфраструктура может его поддерживать.
Отказ датастора на хосте-реплике приводит к тому, что менеджер распределенных ресурсов PernixData удаляет хост из списка хостов реплик и переключает политику отложенной записи на политику прямой записи.
Отказ сети vMotion
В случае отказа сети vMotion между хостом-источником и хостом-репликой FVP работает по алгоритму, аналогичному отказу хоста-реплики.
Политика записи виртуальной машины переключается в режим сквозной записи, и менеджер распределенных ресурсов PernixData выбирает новый хост-реплику для хоста-источника. После назначения нового хоста-реплики политика записей переключается обратно в установленный ранее режим.
Отказоустойчивое ускорение записей
vSphere имеет заслуженную репутацию чрезвычайно стабильного гипервизора и глубокая интеграция FVP с ядром ESXi обеспечивает прочное основание для ускорения операций записи. Благодаря использованию кластерных технологий FVP реплицирует данные на соседние флеш-устройства и тем устраняет единую точку отказа. Основное внимание при проектировании платформы было направлено на исключение рисков и максимальное снижение накладных расходов; скорость копирования данных на систему хранения из флеш-кэша и управления репликами - два ключевых примера, демонстрирующих, что эта технология обеспечивает решения высшего уровня для производительных хранилищ данных.
С 2016 года FVP снят с продажи.