С выходом FVP версии 1.0 на этой неделе вопросы к архитектуре хостов начали раздаваться все громче. Все больше людей начинают тестировать FVP, и они хотят создать максимально оптимальную тестовую среду. И я их не осуждаю за это. В моих входящих и твиттере доминируют следующие вопросы: "Должен я использовать один или несколько дисков?", "Какой уровень RAID выбрать?", "SSD или PCIe?". Отвечать всем и каждому по отдельности не верно, так что пришло время опубликовать статью, освещающую вопросы дизайна локальной архитектуры хоста.
Отбросить все лишнее
FVP предназначен для интеграции в ядро и минимизации всех возможных оверхедов. Добавление любых вариантов "умных" слоев между ядром и флеш-устройством отрицательно влияет на эффективность FVP. Как заядлый автолюбитель я вижу значительное сходство в мыслях инженеров PernixData при разработке FVP и девизом Колина Чепмена (основатель Lotus Cars) на момент разработки его машин - "Упростить и потом облегчить" - и я думаю, что разработка окружения FVP в чем-то похожа. Поддерживайте окружение настолько простым, насколько возможно. Сокращайте расстояние между приложением и устройством для получения самого короткого и быстрого соединения. Дополнительные слои только добавляют проблемы, и мы все знаем, что самый короткий путь между двумя точками - это непрерывная прямая линия. Следовательно, при разработке архитектуры хоста нужно использовать минимальное число частей и удалить максимальное количество слоев. Как эта ментальная установка превращается в архитектуру хоста? Давайте поближе взглянем на уровни RAID, использование множества флеш-устройств и выбор между PCIe и SSD.
Уровни RAID
Не так давно был написан ряд статей об эффекте RAID на производительность и срок работы флеш-устройств. Марк Говард опубликовал "SSD vs. RAID? Fix RAID", Грег Шульц написал "Can RAID extend nand flash SSD life?". Отличные материалы, но в контексте флеш-устройств под управлением FVP мы пытаемся избежать использования RAID. RAID разработан для жестких дисков и несомненный факт в том, что SSD работают иначе, чем жесткие диски. FVP записывает ввод-вывод в последовательном виде на уровне флеш-устройства и разработан так, чтобы минимизировать число циклов записи и стирания ячеек. RAID-система оказывает влияние на этот дизайн и не только приводит к появлению произвольных записей, за счет использвоания уровней RAID с распределенной четностью вы увеличиваете количество циклов записи-стирания за счет их природы операций чтение-модификация-запись - то, чего нужно максимально избегать при работе с флеш-устройствами. Дополнительная информация об эффекте произвольных записей доступна в статье "Базовые элементы Flash Virtualization Platform (FVP), часть 2. Использование собственной платформы или файловой системы".
Что насчет защиты данных?
Но разве вам не нужно защищаться от потери данных? Прежде всего, надо понимать, что FVP не является постоянным хранилищем. Задача FVP - ускорять рабочий процесс. Но это не означает, что мы не принимаем во внимание целостность и доступность данных. Напротив, мы просто иначе подходим к этой задаче. FVP использует различные политики записи. При выборе политики сквозной записи данные всегда сохраняются на системе хранения до подтверждения ввода-вывода приложению. при использовании политики отложенной записи мы обеспечиваем отказоустойчивость, сохраняя копию данных на соседних флеш-устройствах кластера. Дополнительная информация о политиках записи доступна с статье "Работа FVP с удаленным флеш-устройством (FVP, часть 4)".
Рекомендация
В итоге, рекомендуется использовать не RAID-, а JBOD-конфигурации при конфигурировании локальных SSD. Если вариант JBOD не доступен, то выберите RAID 0. Если в хосте используются несколько SSD, то сконфигурируйте каждый диск в отдельности и не объединяйте диски в RAID-массив. Это подводит меня к следующему постулату, который Джош Коэн написал в своей статье "Changing of the Guard: PernixData goes GA with FVP 1.0": "Хотя FVP легко масштабируется, при добавлении новых хостов мне интересно, как PernixData будет решать задачу масштабирования, когда требуется большая пропускная способность, но не требуется увеличение вычислительной мощности? В голову приходит старый добрый RAID. Установите три SSD в хост, объедините их в RAID 5. Бах! Пропускная способность стала больше. Я не имею в виду использование RAID на уровне контроллера. Я допускаю, что FVP разберется с тем, как создать больше ввода-вывода при использовании нескольких SSD на хосте, будет ли это RAID-подобная технология или что-то принципиально другое." На всякий случай поясню, я не критикую Джоша - напротив, я получаю много вопросов об использовании нескольких SSD и RAID-уровнях ежедневно, но Джош просто поднял большой шум в своей статье.
Множество SSD-дисков
Позже я опубликую статью с детальным изображением принципов балансировки нагрузки FVP, но пока важно понимать, что объединение нескольких дисков или добавление множества дисков не ускоряет единичную виртуальную машину. Причина в простоте. Жизненно важно понимать, что одно флеш-устройство ответственно за весь рабочий набор данных виртуальной машины. Использование множества дисков может помочь при работе множества виртуальных машин, но все это сильно зависит от архитектуры дискового контроллера. Пока, без углубления в детали балансировки нагрузки, алгоритмы первичного размещения данных и архитектуру дисковых контроллеров, мы рекомендуем сохранять дизайн максимально простым и начать с одного большого диска при тестировании продукта.
SSD или PCIe флеш-устройства
С точки зрения простоты, архитектура PCIe флеш-устройств побеждает архитектуру контроллера дисков и SSD. Нет необходимости определять RAID-уровень или любую другую настройку контроллера. Одной из главных причин для выбора PCIe флеш-устройства является доступность полосы пропускания современной PCIe шины. 4-полосная PCIe шина 3-го поколения (самый типичный современный вариант) может обеспечить полосу пропускания в 4 ГБ/с, тогда как максимальная полоса SAS-архитектуры - 600 МБ/с. Есть ли недостатки? Бюджетное ограничение на первом месте. Если бюджет не преграда, то что еще может склонить к использованию SSD? Большинство PCIe-устройств требуют специализированных драйверов или особых сборок ESXi с включенными драйверами. Это может быть проблемой, если состав инфраструктуры сертифицирован в соответствии с ограничениями регуляторов. Необходимость разбора хоста может быть другой проблемой: вам потребуется отключить и открыть сервер, в сравнении с установкой диска с передней панели. Некоторые компании имеют строгие правила обслуживания оборудования.
Беспроигрышная ситуация
Однако давайте не сходить с пути при обсуждении преимуществ, которые привносят SSD и PCIe-устройства. При обсуждении преимуществ PCIe над SSD вы переходите в зону высокопроизводительных вычислений. Запомним, что архитектура FVP построена вокруг идеи масштабирования. Мы должны обсуждать операции ввода-вывода и полосу пропускания в контексте разделяемого устройства, т.е. подключения множества ESXi-хостов к единой системе хранения данных. При обсуждении кластеризованного флеша на стороне серверов мы говорим о субмилисекундных задержках и постоянном потоке тысяч операций ввода-вывода на каждый хост (очень близко к приложениям)! В силу кластерной природы, при миграции на другой хост он может обеспечивать аналогичный прирост производительности. Вы увеличиваете производительность добавляя хосты, а не размазываете или уменьшаете доступный пул производительности для каждой из виртуальных машин. Огромная разница!
Заключение
Постарайтесь поддерживать локальную архитектуру хоста максимально простой и убрать максимум лишних частей. Избегайте использования виртуальных дисков. Выбор между одним или несколькими дисками мы оставим для следующей статьи. В целях тестирования я рекомендую начать с одного SSD-диска и постепенно добавлять дополнительные SSD-диски.
Материал для дополнительного чтения
Ищите детальную информацию о взаимодействии RAID И SSD? Отличный материал для пляжного чтения - Stochastic Analysis on RAID Reliability for Solid-State Drives.
Оригинальная статья.
С 2016 года FVP снят с продажи.
