Особенности VAAI в vSphere 5.0

Сегодня новый пересказ статьи про улучшения в механизме VAAI. Также рекомендую ознакомиться с «What’s New in VMware vSphere 5.0 Storage».

Как упоминалось в предыдущей статье,  одной из главных целей нововведений в vSphere 5.0 является упрощение управления хранением данных. Для реализации этой идеи VMware стимулирует клиентов к уменьшению количества и увеличению размеров СХД.

Одним из средств достижения этой цели является технология Thin Provisioning. Однако существуют две особенности данной технологии, которые вызывают сомнения у клиентов относительно целесообразности использования данной технологии:

  • Когда ВМы удалены или мигрированы с хранилища, то массив не информируется о том, что используемые ими ранее блоки освобождены. Это приводит тому, что управляющие инструменты массивов сообщают о большем использовании дискового пространства, чем есть на самом деле.
  • Что произойдет, если место закончится? Раньше, нехватка места приводила к тому, что все ВМы на хранилище могли пострадать.

Для решения данных проблем был произведен ряд улучшений в примитивах vSphere Storage APIs for Array Integration (VAAI) для  Thin Provisioning:

  1. Если хранилище, использующее Thin Provisioning  задействует 100% дискового пространства, то будут остановлены только те ВМы, которым требуются  дополнительные блоки данных, а те, которым не нужно дополнительное место, продолжат работать.
  2. Новый примитив, использующий SCSI-команду UNMAP, позволяет ESXi сообщать массиву об освобождении  места, которое занимала ВМ(будь то она удалена или мигрирована на другое хранилище). Это позволяет массиву корректно отчитываться о занятом пространстве хранилищ с  Thin Provisioning, а потребителям корректно мониторить и успешно прогнозировать требования к системам хранения.
  3. Теперь предупреждения всплывают в vCenter, если занято 75% на хранилище с Thin Provisioning, это позволяет администратору превентивно добавить больше места, расширить диск или смигрировать ВМ с хранилища на другие.

Поддержка NAS

До этой версии VMware поддерживала аппаратное ускорение только на блочных системах хранения. С версии 5.0 добавлен ряд примитивов для NAS. Аппаратное ускорение для NAS даёт возможность быстрого предоставления и использования «толстых» виртуальных дисков с помощью новых примитивов VAAI:

  • Full File Clone. Аналогичен примитиву “Full Copy” для блочных массивов, позволяет клонировать виртуальные диски NAS-устройством.
  • Native Snapshot Support. Нативная поддержка снимков позволяет массиву  создавать снапшоты.
  • Extended Statistics. Расширенная статистика показывает размер использования места на NAS-хранилищах, особенно полезна для Thin Provisioning.
  • Reserve Space. Резервирование места даёт возможность создать «толстый» виртуальный диск на NAS, тогда как ранее на NAS поддерживались только «тонкие». Теперь можно выбрать тип диска lazy-zero или eager-zero.

Если говорить о примитивах для блочных систем хранения, то улучшения произведены в примитиве Atomic Test & Set (ATS). ATS используется для блокировки файлов на VMFS-хранилищах и намного превосходит метод блокировки SCSI Reservation. Теперь от ATS на блочных массивах больше пользы. Например, в предыдущей версии ATS при попытке заблокировать файл одновременно двумя хостами, VMkernel возвращалась к использованию механизма SCSI reservation, сейчас же используется механизм ATS retry.

Для интересующихся статусами VAAI в пользовательском интерфейсе предлагается следующий алгоритм:

if (ATS==supported)
 VAAI = SUPPORTED
else if (ATS==notsupported && ZERO==notsupported && CLONE==notsupported)
 VAAI = UNSUPPORTED
else
 VAAI = UNKNOWN
Запись опубликована в рубрике 5.0, VMware, vSphere с метками , . Добавьте в закладки постоянную ссылку.

2 комментария: Особенности VAAI в vSphere 5.0

  1. Vitaliy говорит:

    >Новый примитив, использующий SCSI-команду UNMAP, позволяет ESXi сообщать массиву об освобождении места, которое занимала ВМ

    Как я уже писал, вот за это vmware отдельное спасибо. Сейчас мои СХД поддерживают thin LUN’ы и при удалении или перемещении ВМ размер занимаемый LUN не уменьшался — приходилось вручную запускать процесс оптимизации блоков, который на моей СХД мог длиться до 7 дней. Сейчас же занимаемое место удалённых ВМ будет просто вычитаться из пула и освобождать дополнительное пространсвто на СХД сразу же — это прекрасно)

  2. Vitaliy говорит:

    Оо, вспомнил! По-умолчанию, при выполнении UNMAP vSphere вернёт массиву не всё пространство, занятое ВМ, а только 60%! Это максимальное рекомендованное значение, но это ограничение можно обойти вручную выполнив следующую команду:
    vmkfstools -y < значение>, гже < значение> — это число от 0 до 100.
    Эта команда указывает vSphere освободить %% блоков на СХД от освободившегося пространства на виртуальном хранилище VMFS.

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

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