Особенности VMFS-5

В новой vSphere стала доступна файловая система VMFS-5. Для быстрого понимания особенностей её приведу краткий пересказ статьи из официального блога.

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

Улучшения VMFS-5:

  • Унификация размера  файлового блока в 1МБ. Предыдущая версия VMFS использует блоки размеро 1, 2, 4 или 8МБ. Большие размеры блоков нужны для создания файлов свыше 256GB. В VMFS-5 больше нет потребности в таких больших блоках – очень большие файлы можно создавать используя 1МБ блок.
  • Большие одиночные экстенты. Размер одиночного экстента увеличен до 60ТБ.
  • Меньше размер субблоков. В VMFS-5 реализован субблок меньшего размера. Субблоки уменьшены с 64 до 8КБ. Файлы размером от 1 до 8КБ теперь занимают 8КБ места.
  • Поддержка маленьких файлов. Новая файловая система поддерживает очень маленькие файлы. Для файлов размером менее 1КБ используется участок описания файла в метаданных. При превышении размера в 1КБ начинает использоваться 8-килобайтный файловый субблок.
  • Поддержка большего количества файлов. Теперь поддерживается более 100 000 файлов.
  • Расширенная поддержка ATS. Примитив с аппаратной аккселерацией, Atomic Test & Set (ATS), теперь используется для повышения проивзодительности блокировок файлов.

Улучшена утилита vmkfstools:

Переход с VMFS-3 на VMFS-5

Операция перехода с VMFS-3 на VMFS-5 бесшовна: производится вживую, без останова, во время операции ВМ продолжают работать.

Хранилища, обновленные до VMFS-5, могут использовать: функцию поддержки 1-килобайтных файлов,  тома до 60ТБ, все улучшения в функционале VAAI ATS.

Пример вывода vmkfstools на обновленном томе:

Различия между созданным с нуля и обновленным хранилищем на VMFS-5

Хранилища, обновленные до VMFS-5:

  • продолжают использовать прежний размер файлового блока, а не унифицированный 1-мегабайтный блок;
  • продолжают использовать 64-килобайтный субблоки, а не новый 8-килобайтный;
  • имеют ограничение в 30720 файлов, а созданные с нуля поддерживают свыше 100000 файлов;
  • продолжают использовать партиции с MBR (Master Boot Record), при превышении размера в 2 ТБ происходит бесшовное переключение с MBR на GPT (GUID Partition Table);
  • имеют начало разделов с сектора 128;у созданных изначально разделы начинаются с сектора 2048.

RDM – Raw Device Mappings

  • Максимальный размер для passthru RDM 60ТБ.
  • Максимальный размер для non-passthru(virtual) RDM 2ТБ – 512 байт.
  • Обновленный до VMFS-5 хранилища также поддеживают большие passthru RDM.

Хочется напомнить об оставших ограничениях:

Максимальный размер VMDK-файла равен  2ТБ – 512 байт.

Максимальное количество LUN равно 256.

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

Рекомендуется  создавать VMFS-5 тома с нуля для получения максимального эффекта, миграцию с VMFS-3 оcуществлять посредством Storage vMotion.

14 thoughts on “Особенности VMFS-5”

  1. “Меньше размер субблоков. В VMFS-5 реализован субблок меньшего размера. Субблоки уменьшены с 64 до 8КБ. Файлы размером от 1 до 8КБ теперь занимают 8КБ места.
    Поддержка маленьких файлов. Новая файловая система поддерживает очень маленькие файлы. Для файлов размером менее 1КБ используется участок описания файла в метаданных. При превышении размера в 1КБ начинает использоваться 8-килобайтный файловый субблок.
    Поддержка большего количества файлов. Теперь поддерживается более 100 000 файлов.”
    Можно узнать, что эти улучшения дадут на практике? Если рост производительности, то на сколько процентов?

    Reply

  2. Я думаю, что по этим пунктам не будет роста производительности. У VMFS есть серьёзная проблема с дефрагментацией, подозреваю такие улучшения её слегка сглаживают.

    Reply

  3. Андрей, ты не правильно перевёл эту часть:
    Большие сборные тома(экстенты). Размер сборных томов(экстентов) увеличен до 60ТБ.

    В оригинале написано: “Large Single Extent Volumes”, что означает размер одиночного! экстента. Раньше максимальный размер сборных томов был 64 ТБ, а размер одного экстента не более 2ТБ, теперь же размер одного экстента может быть ~60Тб

    Reply

  4. >Андрей, ты не правильно перевёл эту часть:
    Это не Андрей, это Виктор 😉
    Я исправлял текст, какой-то косяк видать перед публикацией, может из-за кросспостинга.
    Либо исправленная версия была переписана косячной.

    Reply

  5. Оу, прошу прощения, не посмотрел на авторство поста 🙂

    А по поводу размера блока в 8КБ – это шаг навстречу производителям СХД, которые знают о существовании лунов с VMFS, например EMC и NetApp, которые будут делать более эффективную дедупликацию. Хотя это лишь моё предположение и реального выигрыша от такого размера блока я тоже пока не вижу. Проверю, когда приедет мой NetApp 🙂

    Reply

  7. Да, лимит в 2ТБ на VMDK файл остался. Но хотя бы есть возможность RDM большего размера делать – это уже шаг вперёд

    Reply

  8. Уменьшение субблоков это хорошо для повышеня эффективности использования пространства (меньше распределенного, но неспользованного места), но увеличивает объемы метаданных, и, скорее всего, негативно сказывается на производтельности.
    Так что, скорее всего, роста производительности не будет, но, надеюсь, что, при современном железе и процессорах, и особого падения удастся избежать.

    Reply

  9. “роста производительности именно по этой причине” имелось ввиду выше.
    Хотя может быть рост по какой-то другой причине.

    > Да, лимит в 2ТБ на VMDK файл остался. Но хотя бы есть возможность RDM большего размера делать – это уже шаг вперёд

    Если нужен датастор большего, чем 2TB размера, то пользуйтесь NFS.

    ЗЫ. RDM это аццкое зло, на самом деле. :-/

    Reply

  10. RDM это аццкое зло, на самом деле. :-/

    Ага, у вас просто не бились в хлам VMFS-тома с vmdk-файлами 🙂
    Или вы их не стерли (руками нового админа).

    Но в философском аспекте – согласен на 100%

    Reply

  11. а что такого аццкого?

    я вижу только одну проблему – больше LUN’ов проще что-то не туда презентовать.

    Reply

  12. >Если нужен датастор большего, чем 2TB размера, то пользуйтесь NFS.

    Не всегда есть возможность использовать NFS, например у меня ethernet 1Gbit, а нужно больше. Да, я могу объединить до 8 линков в port-channel и получить примерно 8Гбит на корзину, но это бессмысленно, если у меня уже развернута 8Gbit FC SAN. Тем более, что на серверах у меня всего по 2 Ethernet порта, которые уже заняты, а докупать новые адаптеры уже не выгодно. Но это ограничения моей инфраструктуры

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

    Reply

  13. а если прокинуть полностью весь контроллер в VM под соляркой и вернуть как NFS или iscsi ?
    будет больше 2Тб ?

    Reply

  14. > а если прокинуть полностью весь контроллер в VM под соляркой и вернуть как NFS или iscsi ?
    Не уверен насчёт именно солярки, но вообще если создать iSCSI-инициатор внутри VM, то ещё с незапамятных времён ей можно было отдавать разделы >2 TB

    Reply

Leave a Reply

Your email address will not be published. Required fields are marked *