Удаленный доступ FVP к флеш-устройству (FVP, часть 7)

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

Что такое удаленный доступ к флеш-устройству?
Удаленный доступ к флеш-устройству позволяет виртуальной машине обращаться к текущему и предыдущим состояниям флеш-кэша в флеш-кластере вне зависимости от расположения виртуальной машины или флеш-кэша. То есть, если виртуальная машина мигрирует с хоста A на хост B, FVP будет обращаться к данным, расположенным на флеш-устройстве хоста A, если виртуальная машина запросит эти данные.

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

Как было ранее описано в статье "Базовые элементы Flash Virtualization Platform (FVP), часть 2. Использование собственной платформы или файловой системы", работа с флеш-устройствами сложна. Я кратко рассказывал о методе избежания прожигания флеш-устройств избыточными циклами перезаписи и очистки ячеек для сохранения работоспособности флеш-устройства с предсказуемой и стабильной производительностью. Это значит, что множество версий одних и тех же данных, могут одновременно располагаться на флеш-устройстве. Одна версия данных будет действующей, тогда как остальные - некорректными и устаревшими; отслеживать историю данных на локальном флеш-устройстве - сложная задача сама по себе, а теперь подумаете о задаче масштабирования! DRS может управлять 32 хостами в кластере и произвольно перемещать виртуальную машину с хоста на хост.

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

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

После миграции локальный флеш-кэш виртуальной машины составляет 1 ГБ, тогда как кэш на удаленном флеш-устройстве содержит почти 90 ГБ. Нужно ли копировать эти данные на новый хост или это будет пустой тратой ресурсов? Пересылка такого объема данных по сети не только загружает ее, но и ускоряет износ флеш-устройств, загружает ЦП хостов.

Износ флеш-устройств
Для уменьшения износа флеш-устройств данные не удаляются из кэша до возникновения необходимости. Это значит, что FVP не будет удалять устаревшие данные просто для высвобождения пространства. До возникновения необходимости в очистке пространства FVP не удаляет данные, операция очистки уменьшает срок работы флеш-ячеек. Подробности доступны в статье "Базовые элементы Flash Virtualization Platform (FVP), часть 2. Использование собственной платформы или файловой системы". Это значит, что данные хоть и являются действительными, приложение не использует их в своих текущих или будущих операциях. Если бы данные копировались при миграции виртуальной машины на другой хост, это привело бы к утилизации значительного объема флеш-ресурсов. В первую очередь, данные потребовалось бы записать на локальное флеш-устройство, что привело бы к множеству циклов стирания записи. Кроме того, могла бы возникнуть ситуация, когда важные данные другой виртуальной машины были бы вытеснены неважными данными мигрируемой машины.

Накладные расходы сети и ЦП
Подумайте о непроизводительной загрузке сети и увеличивающемся по этой причине времени миграции виртуальных машин. Это может вас не заботить, если речь идет о миграции одной виртуальной машины за раз, но DRS производит ребалансировку раз в 5 минут. Что если миграция будет настолько большой, что не уложится в отведенное время? Какое влияние это окажет на балансировку нагрузки на коротком и долгом промежутках времени? Что будет с редимом обслуживания хоста? Я знаю компании с крайне ограниченным окном обслуживания; с увеличенным временем миграции некоторые компании едва смогут перевести хосты в режим обслуживания и включить их обратно до завершения окна обслуживания. Откладывать перевод хоста в режим обслуживания на неделю для обновления ПО или изменить настройку на неделю позже только из-за того, что вы потеряли время при миграции устаревших данных не соответствует моему представлению об рациональном и эффективном использовании ресурсов.

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

После 30 минут мы снова проверили сервер SharePoint, чтобы увидеть сколько данных было передано. Выяснилось, что локальный флеш-кэш увеличился с 1.15 до 2.97 ГБ. Мы измеряли приложение во время его активного рабочего периода, это дополнительно подтверждает, что передача 90 ГБ данных была бы пустой тратой ресурсов обоих хостов ESXi.

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

Оригинальная статья.

С 2016 года FVP снят с продажи.