Особенности 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:

~ # vmkfstools -Pv 10  /vmfs/volumes/newly-created-vmfs5/
VMFS-5.54 file system spanning 1  partitions.
File  system label (if any): newly-created-vmfs5
Mode: public
Capacity 3298534883328 (3145728 file  blocks * 1048576),
3297500987392 (3144742 blocks) avail
Volume Creation Time: Tue Jun 14  14:35:53 2011
Files  (max/free): 130000/129992
Ptr Blocks (max/free):  64512/64496
Sub Blocks  (max/free): 32000/32000
Secondary Ptr Blocks (max/free):  256/256
File Blocks  (overcommit/used/overcommit %): 0/986/0
Ptr Blocks   (overcommit/used/overcommit %): 0/16/0
Sub Blocks   (overcommit/used/overcommit %): 0/0/0
UUID:  4df771c9-f6419df2-81bc-0019b9f1ecf6
Partitions spanned (on  "lvm"):
 naa.60a98000572d54724a34642d71325763:1
DISKLIB-LIB   : Getting VAAI support  status for /vmfs/volumes/newly-created-vmfs5/
Is Native Snapshot Capable:  NO
~ #

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

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

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

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

~ # vmkfstools -Pv 10  /vmfs/volumes/upgrade-testvol
VMFS-5.54 file system spanning 1  partitions.
File  system label (if any): upgrade-testvol
Mode: public
Capacity 3298534883328 (3145728 file  blocks * 1048576),
3297916223488 (3145138 blocks) avail
Volume Creation Time: Mon Jun 13  13:03:04 2011
Files  (max/free): 30720/30713
Ptr Blocks (max/free):  64512/64496
Sub Blocks  (max/free): 3968/3968
Secondary Ptr Blocks (max/free):  256/256
File Blocks  (overcommit/used/overcommit %): 0/590/0
Ptr Blocks   (overcommit/used/overcommit %): 0/16/0
Sub Blocks   (overcommit/used/overcommit %): 0/0/0
UUID:  4df60a88-8eaa51ea-3108-0019b9f1ecf6
Partitions spanned (on  "lvm"):
 naa.60a98000572d54724a34642d71325763:1
DISKLIB-LIB   : Getting VAAI support  status for /vmfs/volumes/upgrade-testvol
Is Native Snapshot Capable:  NO
~ #

Различия между созданным с нуля и обновленным хранилищем на 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.

Запись опубликована в рубрике 5.0, VMware, vSphere с метками . Добавьте в закладки постоянную ссылку.

14 комментариев: Особенности VMFS-5

  1. Admin говорит:

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

  2. Mister Nobody говорит:

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

  3. Vitaliy говорит:

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

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

  4. Mister Nobody говорит:

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

  5. Vitaliy говорит:

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

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

  6. Dim-soft говорит:

    то есть одним куском в VM как и прежде только 2Тб ?? 🙁

  7. Vitaliy говорит:

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

  8. romx говорит:

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

  9. romx говорит:

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

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

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

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

  10. philzy говорит:

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

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

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

  11. Михаил говорит:

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

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

  12. Vitaliy говорит:

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

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

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

  13. Dim-soft говорит:

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

  14. EGarbuzov говорит:

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

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *