Миф о неограниченном размещении ВМ на VMFS-хранилище с VAAI

Оригинал этой статьи написан Jason’ом Boche.

Два года назад, в октябре 2010 года, увидел свет vSphere 4.1, и мы радовались потрясающим нововведениям и повышению масштабируемости инфраструктуры. Два года спустя у нас есть vSphere 5.0 и vSphere 5.1, а также куча других продуктов, сформировавших vCloud Suite.

Я намеренно начал рассказ с vSphere 4.1. В vSphere 4.1 Enterprise Edition появилась такая функция как vSphere API for Array Integration (VAAI). Кстати, это произносится как ‘vee double-ehh eye’. 🙂

Эти API предлагают три различных механизма (примитива) для блочных СХД, позволяющих отдавать отдельные операции на выполнение СХД. Один из этих механизмов мы с вами сегодня и рассмотрим.

Одним из старейших споров является “сколько ВМ VMware можно разместить на одном хранилище VMFS”? Проверенный временем ответ – 10/15/20. Наиболее аккуратный – “столько, сколько вам подходит”, обычно переводящийся в “это зависит от…”

С появлением VAAI я отметил пугающий тренд, что механизм Atomic Test and Set (ATS) или Hardware Assisted Locking раз и навсегда дал ответ на этот вопрос. Якобы вы можете запускать любое количество виртуальных машин на одном LUN’е, так как SCSI-блокировок больше нет.

С появлением vSphere 5.0 VAAI стал поддерживаться большим количеством СХД, и были добавлены новые механизмы как в СХД с блочным типом доступа, так и в NFS-СХД. Также VMware добавила поддержку VMFS-хранилищ размером до 64Тб без использования экстентов. Эта поддержка прекрасно объединяется с мифом о волшебстве ATS. Соответственно, мы не должны были иметь проблем с размещением сотен (если не тысяч) ВМ на одном большом блочном (VMFS) хранилище, как если бы это был NFS, и мы были свободны от ограничений SCSI.

ATS был разработан для устранения задержек LUN, связанных со SCSI-блокировками. Эти блокировки устанавливались при выполнении таких операций как создание/удаление файлов и т.п. Мы сталкиваемся с этими операциями при включении ВМ, создании снимков или разворачивании ВМ из шаблона. Эти операции имеют общую черту – им требуется изменить метаданные VMFS-раздела, для чего требуется его блокировка (SCSI-блокировка) хостом, выполняющим эту операцию. Эта блокировка, хоть она и достаточно короткая по времени, приводит к заметным задержкам операций ввода/вывода, если на одном VMFS-хранилище находится много ВМ, и к нему подключено много хостов. ATS передает механизм блокировки на откуп СХД, которая блокирует только изменяемые данные вместо блокировки целого LUN. Любое окружение, которое ранее оперировало этими задачами, получит от VAAI выигрыш за счет снижения задержек.

Теперь, после этого лирического отступления, вернемся к нашему мифу: “благодаря VAAI мы можем разместить неограниченное количество ВМ на одном VMFS-хранилище без экстентов”. Если наши ВМ часто подвержены описанным выше операциям, то, без сомнения, ATS позволит устранить бутылочное горлышко блокировок и снизить общую задержку СХД. Следовательно, вы сможете разместить на LUN больше ВМ, пока не упретесь в следующее бутылочное горлышко. Неограниченным количеством ВМ тут и близко не пахнет. Например, я могу использовать снапшоты на уровне СХД, либо снимки виртуальных машин. А может, я не использую VDI, и мне не страшна проблема одновременного включения нескольких ВМ.

Давайте проведем тесты. Возьмем vSphere 5.1 и разместим на ней несколько “толстых” ВМ с различными СУБД.

Встречайте администратора БД Майка. Он обслуживает 32 ВМ с различными СУБД, размещенными на 8 VMFS-хранилищах. Снапшоты Майк не использует, тип виртуальных дисков – eager-zeroed.

Хранилище Майка поддерживает VAAI, но в текущие лицензии этот функционал не включен.

Решив поверить маркетингу, Майк приобретает новые лицензии, чтобы внедрить VAAI и перенести все ВМ на единый LUN, находящийся на этих же дисках.

В понедельник после переноса ВМ на новый большой LUN, на Майка посыпались заявки о медленной работе приложений и сбоях при проведении транзакций. Майк проанализировал работу всех СУБД и не нашел никаких проблем. Тогда он решил взглянуть на статистику.

Майк был сбит с толку – он не ожидал такой деградации производительности. Как это возможно, ведь изменилось только соотношение количества ВМ на хранилище? Ведь у нас есть VAAI?

Нюанс заключался в глубине очереди. Может выполняться определенное количество запросов от хоста к LUN в один момент времени. Когда множество ВМ с одного хоста находятся на одном LUN, они используют общую очередь этого LUN. И глубина очереди определяет, сколько запросов с одного хоста на один LUN будет обрабатываться, а сколько уйдет в буфер (увеличив задержку). Если мы не используем Storage IO Control, то значение по умолчанию (vSphere DSNRO) равно 32.

У Майка 2 хоста, это означает, что ранее его ВМ получали в среднем (hosts*datastores*DSNRO/VM) 2*8*32/32=16 запросов на одну ВМ.

Теперь же стали получать 2*1*32/32=2 запроса на одну ВМ.

Таким образом, старое правило остается в силе – 10/15/20 ВМ на одно хранилище:

  • 10 “тяжелых” ВМ;
  • 15 “средних” ВМ;
  • 20 “легких” ВМ.

Таким образом, ATS ни в коей мере не разрешает вам хранить неограниченное количество ВМ на одном хранилище. Он лишь убирает SCSI-блокировки, устраняя таким образом одно из бутылочных горлышек. Остальные нюансы блочных хранилищ (такие как количество дисков, тип рейда, размер очереди, режим владения контроллера LUN’ами, используемая фабрика и т.д.) остаются в силе.

Миф развенчан 😉

Leave a Reply

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