VMFS vs NFS in vSphere

Как-то Diz задал вопрос: “правда ли, что NFS гораздо лучше, чем SCSI для хранилищ в случае одного большого хранилища? Как ситуация изменилась в 6.x?”

Наше путешествие будет включать в себя следующие пункты:

• SCSI-очереди.
• А что там с NFS?
• Решает ли скорость протокола?
• vSphere 6.x?
• Рекомендации.

SCSI-очереди

Отлично тема очередей раскрыта тут.

Очередь – это глубина постоянно выполняющихся SCSI-команд.

Допустим, есть команда “прочитай блок №1”. Пока блок №1 не будет прочитан, а его содержимое возвращено, данная команда занимает “буфер”.

Соответственно, с каждого хоста vSphere до каждого LUN (дискового устройства СХД) есть буфер глубиной 32 команды (может отличаться в разных версиях vSphere у разных HBA).

Поэтому, короткий ответ будет “да” – у одного LUN для виртуализации есть шансы упереться в эту очередь.

Хочу сразу уточнить, что это глубина очереди с одного хоста до одного LUN. Если LUN несколько, и нагрузка на них равномерная, то хост может выполнить большее количество команд без их приостановки.

Типичный вариант “затыкания” в очереди – это очень большой ввод вывод с одного хоста в один LUN (например, несколько тысяч операций ввода-вывода), и не справляющиеся с этим выводом диски.

А что там с NFS

На первый взгляд, NFS-хранилище решает главную проблему SCSI – убирает глубину очереди в 32 на один LUN. Снаружи от хоста до NFS-хранилища подобного “затыка” нет, внутри у сервера глубина очереди сопоставима с SCSI-хранилищами (например, 1024 у HPE’шного рейд-контроллера).

С другой стороны, с балансированием доступа до NFS все несколько неоднозначно. До появления vSphere 6.0 и NFS 4.1 единственным вариантом балансировки нагрузки являлся EtherChannel/LACP, а это, в свою очередь, означало, что от гипервизора до СХД утилизировался один линк.

Также стоит отметить, что NFS-хранилища не предоставляют функционал RDM-дисков.

Если у вас NFS без поддержки функционала VAAI, то вы не сможете создавать толстые VMDK-диски на таком хранилище.

Решает ли скорость протокола?

И да, и нет. Разумеется, обогнать NFS поверх 1Гбит/с сможет даже “черепаший” FC4Gb, который уже давно устарел.

Текущие “топовые” коммутаторы FC поддерживают до 128Гбит/с, Ethernet – до 100Гбит/с. 10Гб/с Ethernet и 8Гб/с FC уже давно стали легкодоступной попсой.

Учтите, что полоса утилизируется только в случае последовательных операций (а это как правило бэкап или восстановление).

Возьмем данные из технической спецификации на массив начального уровня HPE MSA 2050:

• 72 SAS15k, организованные в кучу Raid5, дают в сумме 5,29ГБ/c на последовательное чтение;
• 8 SSD, объединенные в кучу Raid1, выдают на чтение 220,8 тысяч IOPS по 8КБ или 1,68ГБ/c на случайное чтение.

Естественно, это цифры, полученные из максимально допустимого распараллеливания ввода вывода. В реальной жизни на аналогичном железе результаты будут скромнее .

Если подытожить, то скорости близкие или превышающие 10Гбит/с вы можете получить либо с SSD, либо с огромной кучи HDD с последовательными операциями ввода-вывода.

С другой стороны, есть ряд исследований, показывающих, что Fiber Channel лучше чем Ethernet (раз, два), если речь идет о достаточно высокой утилизации канала.

vSphere 6.x

В vSphere при использовании одного хранилища VMFS каждый хост будет иметь пресловутую глубину очереди и сможет в нее упереться. Это SCSI и ничего тут не поделаешь.

Так как VMFS кластерная система, она добавляет свои накладные расходы для того, чтобы ее нельзя было повредить одновременной записью.

Соответственно, VMware направляло свои силы в двух направлениях:

1. Оптимизация VMFS. Это VMFS5&VAAI ATS Locking (желательно иметь поддержку этого функционала со стороны СХД). А также дальнейшее улучшение VAAI ATS в VMFS6 (поддерживается в vSphere 6.5). Кроме того, VMFS6 позволяет выполнять несколько операций с тонкими VMDK-дисками с одного хоста. В предыдущих версиях VMFS хост был обязан выполнять операции с тонкими дисками последовательно по одной.
2. Появление функционала VVoL, который позволяет фактически “эмулировать” создание дискового устройства (LUN) для каждого VMDK-диска виртуальной машины.

Файловая система VMFS поддерживает ее “растягивание” на 32 дисковых устройства (так называемые VMFS-экстенты).

Частично это может помочь, однако управлять размещением ВМ по разным лунам нельзя, так как каждый хост “старается писать” в свою область данных на растянутом VMFS-разделе.

Рекомендации

Начиная эту статью, я хотел яростно обругать NFS-хранилища и сказать, что место им в SoHo.

Но, по большому счету, если вы:

• хотите использовать одно хранилище, а не несколько;
• размер единого хранилища ВМ превышает 62ТБ;
• не нуждаетесь в Raw Device Mapping;
• развернули Ethernet 10G (а лучше больше).

То вам может подойти NFS. Рекомендую иметь NFS с поддержкой VAAI.

Бонусом получите экономию на отсутствии у вас FC-инфраструктуры.

Если же вы хотите остаться на VMFS, то у меня есть ряд общих рекомендаций:

• количество хранилищ должно быть кратно количеству контроллеров вашего массива. Он может быть “ALUA” – и тогда обслуживает половину LUN только один контроллер с его кэшем. Еще лучше, если количество LUN кратно количеству путей до СХД;
• ВМ должны быть сбалансированы по этим хранилищам;
• тип балансировки доступа до хранилища должен быть приведен в соответствие с рекомендациями вендора. Скорее всего, это будет Round Robin, возможно, с переключением путей на каждый 1 iops;
• лучше использовать наиболее свежую версию vSphere и VMFS. Помимо явных упоминаний могут быть и улучшения, о которых VMware промолчало (например, в каком-то гайде производительности я встречал упоминание о том, что “пенальти” гипервизора на свежих процессорах и vSphere 6.x в два раза ниже, чем на более старых и vSphere 5.x);
• также лучше использовать наиболее свежее железо (касается хоста, СХД и коммутации). СХД лучше с поддержкой VAAI;
• желательно изредка анализировать ввод-вывод на VMFS-разделы. Если туда прилетает несколько тысяч IOPS, возможно, проклятие SCSI-очередей тут как тут.

Как в принципе избавиться от этого:

• VVol.

Дополнительные материалы:

• UNDERSTANDING VMWARE ESXI QUEUING AND THE FLASHARRAY
• IO queues within ESXi
• VMFS Extents

P.S. Коллеги, приглашаю Вас высказать своё мнение в комментариях, поделиться своим опытом.