vSphere Storage (часть 1) — введение в VAAI

Опубликовано: 20 Апреля, 2023

Введение

Хранилище обеспечивает критически важную базовую поддержку среды vSphere. Кроме того, это одна из самых дорогих инвестиций в инфраструктуру, сделанных организацией. Таким образом, обеспечение того, чтобы эти инвестиции были максимально использованы для достижения их максимального потенциала, как правило, представляет значительный интерес для организации. В то же время большая часть вычислительной мощности хранилища остается неиспользованной.

Чтобы помочь компаниям максимизировать свои инвестиции в системы хранения и позволить им переложить некоторые задачи обработки, связанные с хранением, с хост-серверов, в выпуске ESX/ESXi 4.1 VMware добавила функцию под названием VAAI (ранее VAAI была частью vStorage API). что означает API-интерфейсы vStorage для интеграции массивов. Эта функция была значительно улучшена в vSphere 5.0.

VAAI переносит некоторые ресурсоемкие задачи с хостов на массивы хранения с поддержкой VAAI. Такая разгрузка может иметь ряд положительных преимуществ для организации:

  • Улучшена производительность хост-серверов.
  • Потенциальная возможность увеличить плотность виртуальных машин хост-серверов, поскольку высвобождается больше вычислительной мощности.
  • Значительно улучшена производительность для определенных операций хранения. Это связано с тем, что VAAI может указать системе хранения выполнять определенные задачи напрямую, без необходимости привлечения сети или хоста, и, таким образом, может избежать любых проблем с задержкой, которые могут присутствовать на этих ресурсах.

VAAI предлагает широкий набор возможностей, а поставщики систем хранения данных обеспечивают различные уровни поддержки различных функций. Таким образом, не все массивы одинаковы, когда речь идет о поддержке VAAI.

Итак, какую функциональность на самом деле предлагает VAAI? Это то, что мы собираемся обсудить сейчас, с разбивкой по версиям vSphere. Кстати, различные возможности, включенные в VAAI, известны как . Вы часто будете встречать эту терминологию, когда будете читать о VAAI.

СМОТРЕТЬ ограничения

Прежде чем мы обсудим различные примитивы, составляющие VAAI, давайте обсудим некоторые ограничения технологии:

  • Исходный и целевой тома VMFS должны иметь одинаковый размер блока.
  • Исходный файл VMDK и целевой файл VMDK должны использовать один и тот же тип подготовки (толстый, тонкий).
  • Исходная виртуальная машина не может иметь моментальных снимков.
  • Исходная VMFS не может иметь экстенты, которые все находятся в разных массивах.

В этой статье мы сосредоточимся на функциях VAAI, включенных в vSphere 4.1. Во второй части мы перейдем к обсуждению функций, включенных в vSphere 5.

всфера 4.1

Для своего первоначального полного набега на мир прямой интеграции на основе массивов VMware включила поддержку трех примитивов. Эти функции оказывают наибольшее влияние на администраторов.

Полная копия

Представьте себе такой сценарий: вам нужно скопировать массивный многотерабайтный файл (возможно, полный виртуальный диск) из одного места на вашем массиве хранения без поддержки VAAI в другое место на том же массиве. Это может быть результатом операции клонирования виртуальной машины или результатом операции Storage vMotion. В этом традиционном сценарии будет происходить следующее:

  • Гипервизор инициирует операцию копирования.
  • Гипервизор начинает операцию копирования файла.
  • Файл копируется по сети на хост, а затем обратно по сети в массив хранения. Гипервизор должен читать и записывать каждый блок во время передачи.
  • По завершении гипервизор завершает операцию копирования файла.

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

Кроме того, эта операция копирования оказывает значительное влияние на сеть на протяжении всего процесса копирования. Это может оказать негативное влияние на остальную часть окружающей среды.

Теперь предположим, что у вас есть массив с поддержкой VAAI, поддерживающий примитив Full Copy. При такой поддержке гипервизор просто отправляет одну команду SCSI XCOPY массиву хранения, предписывая ему скопировать файл из исходного местоположения в назначенное второе местоположение. И это вся роль гипервизора в операции.

Это имеет много преимуществ:

  • Меньшая нагрузка на гипервизор.
  • Более быстрая операция копирования.
  • Практически не влияет на сеть, так как вся операция копирования выполняется внутри массива.

Блок обнуления

Когда виртуальная машина копируется из одного места в другое, копируется весь файл, включая пустое место. vSphere копирует части файлов, фактически содержащие данные, а также отдельные блоки, составляющие пустое пространство. Например, файл может иметь размер 250 ГБ, но содержать только 50 ГБ данных. Это означает, что необходимо скопировать 50 ГБ данных, но время и циклы будут потрачены впустую на копирование пустого пространства.

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

Аппаратная блокировка

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

С введением аппаратной блокировки через VAAI использование резервирования SCSI может быть в основном исключено, что также устраняет случаи конфликтов резервирования SCSI. Конфликты резервирования SCSI могут привести к серьезным проблемам с производительностью, поскольку хосты вынуждены ждать снятия блокировки, прежде чем они смогут выполнять определенные операции.

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

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

С более новыми версиями vSphere, которые изначально более эффективны, и с поддержкой VAAI администраторам не нужно так сильно беспокоиться о количестве виртуальных машин, хранящихся в VMFS, поскольку меньше вероятность того, что весь том будет заблокирован. Это может помочь администраторам более эффективно использовать свое время и хранилище.

Вот некоторые другие действия, которые приводят к блокировке метаданных:

  • Создание файла или шаблона.
  • Удаление файла.
  • Создание хранилища данных VMFS.
  • Создание новой виртуальной машины.
  • Расширение хранилища данных VMFS.
  • vMotion.
  • Создание шаблона.

Резюме

Имея только эти три примитива, доступные в vSphere 4.1, администраторы, у которых есть хранилище с поддержкой VAAI, могут по-настоящему довести свои инвестиции в хранилище до предела и использовать его таким образом, чтобы повысить эффективность всей виртуальной среды. мы обсудим VAAI и vSphere 5.