В этом году компания VMware в рамках анонсов конференции Explore 2022 выпустила новые версии платформ vSphere 8 и vSAN 8. Главным нововведением новой версии vSAN стало решение Express Storage Architecture. Это новая архитектура гиперконвергентной инфраструктуры, которая позволяет достичь максимальных показателей производительности и эффективности на базе высокопроизводительных систем хранения.

За счет использования флэш-памяти TLC на основе технологии NVMe, архитектура ESA имеет множество преимуществ по сравнению со стандартной vSAN Original Storage Architecture (OSA), которая также продолжает поддерживаться для стандартного на текущий момент оборудования (устройства SATA/SAS).

Традиционно, в vSAN одним из фундаментальных понятий были дисковые группы. Это объединения дисков на хостах ESXi, которые используются для функций хранения (Capacity tier) и кэширования (Caching tier). Необходимо было это для того, чтобы пользователи могли гибко управлять ресурсами HDD и SSD дисков с точки зрения емкостей (дешевле использовать HDD) и производительности кэша (лучше использовать SSD).

Так как архитектура ESA предназначена для высокопроизводительных хранилищ на SSD/NVMe носителях, то необходимость использования дисковых групп отпала - вместо них появился объект Storage Pool. Теперь пользователю не нужно указывать, какие диски будут использоваться для кэширования, а какие для хранения - все они вносят вклад, как в подсистему хранения, так и в подсистему кэширования на паритетной основе (операции ввода-вывода распределяются между устройствами равномерно, не создавая бутылочного горла).

Идея vSAN в том, чтобы обеспечивать скорость чтения на уровне RAID-1, а эффективность использования дискового пространства на уровне RAID-5 / RAID-6. Подсистема работы с хранилищами оптимизирована таким образом, что сейчас поддерживается память TLC, но и сделаны оптимизации для будущих устройств QLC. Об этом рассказал Дункан Эппинг.

Ключевые элементы новой архитектуры - это файловая система log-structured filesystem и специальный durable log. Давайте посмотрим на картинку:

Все данные, которые отправляются на запись в log-structured file system, сначала попадают в durable log. Это позволяет убедиться в том, что данные сохранятся персистентно. Этот durable log является частью блока Performance Leg, который спроектирован для того, чтобы операции записи сохранялись быстро и в первую очередь.

Performance Leg представляет собой конфигурацию уровня RAID-1, принимающую операции записи, которые мгновенно подтверждаются со стороны хранилища, а потом на нижнем уровне данные распределяются уже как избыточный страйп (RAID 5/6) на Capacity Leg. Для этого Performance Leg собирает stripe write размером 512 КБ и отсылает эти блоки на Capacity Leg, ну а для подстраховки этих процессов на случай сбоев у нас всегда есть durable log. Такая схема позволяет достичь наилучшего баланса с точки зрения производительность/доступная емкость в VMware vSAN 8.

Ну и посмотрите интересное видео от Дункана на эту тему:

Многие из вас знают компанию StarWind Software, лидера в сфере поставки программных и программно-аппаратных решений для создания отказоустойчивых хранилищ. Помимо решений непосредственно для организации хранилищ, у компании есть и виртуальный модуль StarWind Backup Appliance, который предназначен для резервного копирования виртуальных машин на хранилищах StarWind. Это программно-аппаратный комплекс на базе оборудования NVMe, который позволяет избавиться от проблемы производительности хранилищ резервных копий и забыть о задаче планирования окна резервного копирования.

Модуль StarWind Backup Appliance поставляется в виде настроенного и готового к работе сервера резервного копирования, построенного на базе StarWind HyperConverged Appliance (HCA). Работа с продуктом происходит через удобный веб-интерфейс StraWind Web UI, есть также плагин StarWind для vCenter.

В апреле компания StarWind объявила, что StarWind Backup Appliance теперь включает в себя оборудование GRAID SupremeRAID - первую в мире карточку NVMe-oF RAID, которая обеспечивает высочайший уровень защиты данных в рамках технологии NVMe RAID на рынке.

Традиционные RAID-контроллеры не были разработаны изначально для технологии NVMe, а программные RAID работают недостаточно эффективно, потребляя при этом большое число циклов CPU, что мешает рабочим нагрузкам сервера. Поэтому с теперь помощью карточек GRAID комплексы StarWind Backup Appliance обеспечат максимальную производительность и защиту данных на базе дисков NVMe SSD.

Вот так выглядят результаты тестов технологии GRAID по сравнению с текущими реализациями аппаратных RAID для NVMe:

Более подробно об этом нововведении можно узнать из пресс-релиза StarWind. Скачать пробную версию StarWind Backup Appliance можно по этой ссылке.

Недавно компания VMware провела тестирование баз данных PostgreSQL в качестве рабочей нагрузки в виртуальных машинах vSphere 7.0 U2 с использованием памяти Intel Optane DC persistent memory (PMem). Напомним, что именно на этот тип памяти компания VMware ориентируется при разработке технологии Project Capitola.

Память Intel Optane DC persistent memory (DCPMM она же PMEM) не такая быстрая как DRAM и имеет бОльшие задержки, но они все равно измеряются наносекундами. При этом данная память позволяет иметь ее большой объем на сервере, что существенно повышает плотность ВМ на одном хосте.

В качестве тестового стенда использовалась следующая конфигурация хоста ESXi и виртуальных машин:

Память PMEM была презентована виртуальным машинам как очень быстрое устройство хранения (NVDIMM). Конфигурация PostgreSQL была следующей:

VMware использовала 3 различных конфигурации для тестирования:

• 2 устройства NVME SSD (это базовый уровень) - оба раздела, WAL и база данных, были на двух разных быстрых SSD
• WAL на базе PMEM - раздел WAL поместили на 200-гигабайтное устройство PMem NVDIMM
• WAL и база данных на PMem - все разделы были размещены на устройствах PMem NVDIMM

В виртуальной машине запускали стресс-тест базы данных со значительной нагрузкой на диск, средней нагрузкой на систему и интегрированными транзакциями. Пропускная способность (throughput) измерялась в количестве транзакций в секунду (TPS).

Вот что из этого вышло:

По итогу теста для полной нагрузки на PMEM по сравнению с SSD пропускная способность выросла на 44.6%, а задержка (latency) упала на 30.8% (при перенесении только WAL на PMEM эти показатели составили 13.4% и 11.8%, соответственно).

Те же самые параметры для read-only транзакций:

Тут уже разница более, чем в 3 раза. Также VMware попробовала машину с 1 ГБ оперативной памяти вместо 200 ГБ - там улучшение было еще больше, а среднем PMEM дает улучшение производительности по сравнению с SSD в районе 4.5x.

Полное описание процедуры тестирования находится тут.

Вильям Ламм написал интересную статью про USB-устройства на хосте VMware ESXi, когда нужно использовать некоторые устройства как хранилища, а некоторые - для проброса в виртуальные машины. При этом, в рамках данной методики, не нужно останавливать USB Arbitrator Service на хосте.

Итак, для начала выводим список доступных USB-интерфейсов на сервере:

esxcli hardware usb passthrough device list

У Вильяма в списке 2 USB-хранилища (их пары VendorId:ProductId имеют значения 90c:2000 и 90c:1000):

Для второго устройства можно отключить именно функции проброса USB (passthrough), чтобы устройство не могло быть презентовано виртуальной машине. Для этого выполняем такую команду:

esxcli hardware usb passthrough device disable -d 2:7:90c:1000

После этого будет вот такая картина:

Далее уже можно подключить это устройство хранения к хосту ESXi, чтобы использовать его для создания VMFS-томов. Процедура описана вот тут, посмотрим на нее вкратце.

Сначала добавляем расширенную настройку (Advanced Setting) на хосте ESXi, чтобы он принимал SSD-диски, подключенные к USB:

esxcli system settings advanced set -o /Disk/AllowUsbClaimedAsSSD -i 1

Теперь нужно создать SATP-правило, которое помечает наше USB-устройство как SSD-диск. Для этого нужно получить имя устройства с помощью команды:

vdq -q

Затем создаем переменную с именем устройства, например:

DEVICE_NAME="t10.JMicron_Generic_________0123456789ABCDEF"

Затем выполняем следующие команды для создания SATP-правила и перезагрузки устройства, которое подцепится как SSD-хранилище:

esxcli storage nmp satp rule add -s VMW_SATP_LOCAL --device=${DEVICE_NAME} --option=enable_ssd

esxcli storage core claiming unclaim --type device --device=${DEVICE_NAME}

esxcli storage core claimrule load

esxcli storage core claimrule run

Теперь устройство можно использовать как SSD-диск для vSAN или VMFS. Если хотите использовать его для vSAN, то нужно включить соответствующую расширенную настройку командой:

esxcli system settings advanced set -o /VSAN/AllowUsbDisks -i 1

После этого вы сможете увидеть данное устройство в выводе команды vdq -q как совместимое для vSAN, на котором можно создавать дисковые группы:

Если же вы хотите использовать этот SSD-диск как хранилище VMFS, то нужно сначала создать том, чтобы он был виден в интерфейсе vSphere Client.

Создаем переменную с полным путем к устройству:

DEVICE_PATH="/vmfs/devices/disks/t10.JMicron_Generic_________0123456789ABCDEF"

Далее выполняем команду, которая разметит наш том как VMFS:

partedUtil mklabel ${DEVICE_PATH} msdos

END_SECTOR=$(eval expr $(partedUtil getptbl ${DEVICE_PATH} | tail -1 | awk '{print $1 " \\* " $2 " \\* " $3}') - 1)

/sbin/partedUtil "setptbl" "${DEVICE_PATH}" "gpt" "1 2048 ${END_SECTOR} AA31E02A400F11DB9590000C2911D1B8 0"

/sbin/vmkfstools -C vmfs6 -b 1m -S $(hostname -s)-local-usb-ssd-datastore ${DEVICE_PATH}:1

Если все в порядке, вы увидите новый том в списке VMFS-томов в vSphere Client:

Многие администраторы VMware vSAN задаются вопросом - а сколько прослужат диски в кластере хранилищ? Сегодня для vSAN уже имеет смысл использовать только SSD-диски, так как их стоимость уже вполне стала приемлемой для построения All-Flash хранилищ.

Как известно, в кластере vSAN есть 2 типа дисков - Cache (кэширование данных перед записью на постоянное хранение) и Capacity (постоянное хранилище). В первом случае, конечно же, использование ресурса диска идет в разы быстрее, чем для Capacity Tier.

Florian Grehl в своем блоге провел замер использования дисков обоих ярусов в плане записанных гигабайт в сутки в тестовой лаборатории. Вы сами сможете сделать это с помощью его PowerCLI-сценария, а также визуализовав данные в Graphite.

У него получилась вот такая картина:

В день у него получилось:

• 300 ГБ на диски Caching tier
• 20 ГБ на диски Capacity tier

Надо понимать, что объем записанных данных на каждый диск зависит от числа дисков в группе, а также развернутого типа RAID и политики FTT.

Когда вы покупаете SSD-диск, гарантия на него идет как на машину: время (обычно 5 лет), либо пробег (а в случае с диском это "TBW" = Terabytes Written, то есть записанный объем в ТБ) - в зависимости от того, что наступит раньше.

Как правило, для Capacity tier ресурс TBW за 5 лет на практике выработать не получится, а вот для Caching tier неплохо бы этот параметр замерить и сопоставить с характеристиками дисков. Например, 300 ГБ в день дает 535 ТБ за 5 лет.

Ну а вот параметры TBW, например, для устройств Samsung:

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

Многие из вас знают, что в решении для организации отказоустойчивых кластеров хранилищ VMware vSAN есть функции дедупликации и сжатия данных (deduplication and compression, DD&C). С помощью этих функций можно более эффективно использовать ярус хранения данных виртуальных машин (Capacity Tier). О некоторых аспектах применения дедупликации и сжатия данных в vSAN мы рассказывали вот тут, а сегодня поговорим об их общем влиянии на производительность дисковой подсистемы.

Как знают администраторы vSAN, это решение использует двухъярусную архитектуру, создающую оптимальное соотношение цена/качество для хранилищ ВМ - на Cache Tier, собранном из дорогих SSD-дисков (быстро работающих на дисках), размещается Write Buffer и Read Cache, а на дешевых SSD/HDD-дисках - постоянные данные виртуальных машин.

Механизм DD&C работает так - если он включен, то как только из Cache Tier виртуальной машине отправляется квитанция о записи данных, то может начаться процесс дестейджинга данных на Capacity Tier, во время которого сам механизм и вступает в действие. Сначала с помощью механики дедупликации в рамках дисковой группы (deduplication domain) находятся идентичные блоки размером 4 КБ и дедуплицируются, а затем блоки сжимаются. При этом, если блок сжимается менее, чем на 50%, то целевое хранилище записывается оригинал блока в целях быстрого доступа при чтении (без декомпрессии).

Получается, что механизм DD&C - оппортунистический, то есть он работает не всегда, а по мере возможности и не гарантирует конкретных результатов по эффективности сжатия данных на целевом хранилище.

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

Очевидно, что дедупликация с компрессией могут влиять на производительность, так как требуют ресурсов процессора на обработку потока ввода-вывода. Давайте посмотрим, как именно.

При высоком входящем потоке операций чтения и записи vSAN старается обеспечить наименьшую задержку (latency) при прохождении команд. При этом vSAN сам решает, в какой именно момент начать процесс дестейджинга данных, поэтому буфер на запись заполняется разные моменты по-разному.

Такая двухъярусная система vSAN имеет 2 теоретических максимума:

• Max burst rate - возможность Cache Tier сбрасывать обработанные пакеты данных в сторону Capacity Tier
• Max steady state rate - установившаяся максимальная скорость записи данных на приемнике Capacity Tier

Реальная скорость обмена данными между ярусами лежит где-то между этими значениями. Если вы будете использовать бенчмарк HCIBench на длительном отрезке времени, то сможете практическим путем определить эти значения из соответствующих графиков замера производительности хранилища.

Если у вас идет дестейджинг данных с включенным DD&C, это потенциально может повлиять на производительность записи данных на Capacity Tier. При использовании DD&C снижается максимальная скорость записи данных на ярус постоянного хранения, так как перед этой записью должны быть выполнены операции дедупликации и сжатия.

Иными словами, кластер с включенным DD&C может давать такие же показатели качества обслуживания, как и кластер с более медленными устройствами в Capacity Tier, но с выключенным DD&C.

Логично ожидать, что при включенном DD&C буффер Write Buffer будет заполняться скорее, так как будут возникать задержки ожидания отработки DD&C. Но пока буффер полностью не заполнен - заметных просадок в производительности не будет. Очищаться также Write Buffer будет медленнее при включенном DD&C.

Также может измениться и время отсылки квитанции о записи (acknowledgment time, оно же write latency), которое увеличит latency для виртуальной машины. Это произойдет, если уже начался дестейджинг данных, а машина запрашивает ACK и ждет ответа с уровня буффера. Хотя в целом vSAN построен таким образом, чтобы как можно быстрее такой ответ дать.

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

Если вы также используете RAID 5/6 для кластеров vSAN, то совместно с техниками DD&C могут возникнуть серьезные эффекты с влиянием на производительность. Об этих аспектах подробно рассказано вот тут - обязательно ознакомьтесь с ними (см. также комментарий к статье).

По итогу можно сделать следующие выводы из этой схемы:

• Если вам хочется использовать DD&C, и вы видите, что у ВМ высокая latency - попробуйте более быстрые диски на Capacity Tier.
• Используйте больше дисковых групп, так как Buffer и его пространство hot working set используется на уровне дисковой группы. Две группы на хосте нужно минимум, а лучше три.
• Альтернативой DD&C могут стать устройства большой емкости - там просто все поместится).
• Используйте последнюю версию vSAN - алгоритмы работы с данными все время совершенствуются.
• Также помните, что RAID 5/6 также экономит место по сравнению с RAID1, что может стать альтернативой DD&C.

Ну и главный вывод он как всегда один: производительность - это всегда компромисс между требованиями рабочих нагрузок и деньгами, которые вы готовы потратить на обеспечение этих требований.

Мы много писали о возможностях новой версии платформы VMware vSphere 7 (например, тут и тут), но нововведений там столько, что это не уместить и в десять статей. Сегодня мы поговорим об изменениях в структуре разделов (Partition Layout), которые произошли в VMware ESXi 7.

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

Поэтому в vSphere 7 были увеличены размеры загрузочных областей, а системные разделы, которые стали расширяемыми, были консолидированы в один большой раздел.

В VMware vSphere 6.x структура разделов выглядела следующим образом:

Как мы видим, размеры разделов были фиксированы, кроме раздела Scratch и опционального VMFS datastore. Они зависят от типа загрузочного диска (boot media) и его емкости.

В VMware vSphere 7 произошла консолидация системных разделов в область ESX-OSData:

Теперь в ESXi 7 есть следующие 4 раздела:

• System boot - хранит boot loader и модули EFI. Формат: FAT16.
• Boot-banks (2 штуки) - системное пространство для хранения загрузочных модулей ESXi. Формат: FAT16.
• ESX-OSData - унифицированное хранилище дополнительных модулей, которые не необходимы для загрузки. К ним относятся средства конфигурации и сохранения состояния, а также системные виртуальные машины. Формат: VMFS-L. Для этой области нужно использовать долговременные хранилища на базе надежных устройств.

Как вы видите, ESX-OSData разделен на две части: ROM-data и RAM-data. Часто записываемые данные, например, логи, трассировка томов VMFS и vSAN EPD, глобальные трассировки, горячие базы данных - хранятся в RAM-data. В области ROM-data хранятся нечасто используемые данные, например, ISO-образы VMware Tools, конфигурации, а также дампы core dumps.

В зависимости от размера устройства, куда устанавливается ESXi, меняется и размер всех областей, кроме system boot:

Если размер устройства больше 128 ГБ, то ESXi 7 автоматически создает VMFS-тома.

Когда вы используете для запуска ESXi устройства USB или карточки SD, то раздел ESX-OSData создается на долговременном хранилище, таком как HDD или SSD. Когда HDD/SSD недоступны, то ESX-OSData будет создан на USB-устройстве, но он будет содержать только ROM-data, при этом RAM-data будет храниться на RAM-диске (и не сохранять состояние при перезагрузках).

Для подсистем ESXi, которым требуется доступ к содержимому разделов, используются символьные ссылки, например, /bootbank и /altbootbank. А по адресу /var/core лежат дампы core dumps:

В VMware vSphere Client можно посмотреть информацию о разделах на вкладке Partition Details:

Ту же самую информацию можно получить и через интерфейс командной строки ESXi (команда vdf):

Обратите внимание, что соответствующие разделы смонтированы в BOOTBANK1 и 2, а также OSDATA-xxx.

Кстати, вы видите, что OSDATA имеет тип файловой системы Virtual Flash File System (VFFS). Когда OSDATA размещается на устройствах SDD или NVMe, тома VMFS-L помечаются как VFSS.

ESXi поддерживает множество устройств USB/SD, локальных дисков HDD/SSD, устройств NVMe, а также загрузку с тома SAN LUN. Чтобы установить ESXi 7 вам нужно выполнить следующие требования:

• Boot media размером минимум 8 ГБ для устройств USB или SD
• 32 ГБ для других типов устройств, таких как жесткие диски, SSD или NVMe
• Boot device не может быть расшарен между хостами ESXi

Если вы используете для установки ESXi такие хранилища, как M.2 или другие не-USB девайсы, учитывайте, что такие устройства могут быстро износиться и выйти из строя, например, если вы используете хранилища VMFS на этих устройствах. Поэтому удалите тома VMFS с таких устройств, если они были созданы установщиком по умолчанию.

На днях пришла пара важных новостей о продуктах компании StarWind Software, которая является одним из лидеров в сфере производства программных и программно-аппаратных хранилищ для виртуальной инфраструктуры.

StarWind HCA All-Flash

Первая важная новость - это выпуск программно-аппаратного комплекса StarWind HyperConverged Appliance (HCA) All-Flash, полностью построенного на SSD-накопителях. Обновленные аппаратные конфигурации StarWind HCA, выполненные в форм-факторе 1 или 2 юнита, позволяют добиться максимальной производительности хранилищ в рамках разумной ценовой политики. Да, All-Flash постепенно становится доступен, скоро это смогут себе позволить не только большие и богатые компании.

Решение StarWind HCA - это множество возможностей по созданию высокопроизводительной и отказоустойчивой инфраструктуры хранилищ "все-в-одном" под системы виртуализации VMware vSphere и Microsoft Hyper-V. Вот основные высокоуровневые возможности платформы:

• Поддержка гибридного облака: кластеризация хранилищ и active-active репликация между вашим датацентром и любым публичным облаком, таким как AWS или Azure
• Функции непрерывной (Fault Tolerance) и высокой доступности (High Availability)
• Безопасное резервное копирование виртуальных машин
• Катастрофоустойчивость на уровне площадок
• Максимизация производительности за счет RDMA
• Распределенное кэширование
• Проактивная поддержка вашей инфраструктуры специалистами StarWind
• И многое, многое другое

Сейчас спецификация на программно-аппаратные модули StarWind HCA All-Flash выглядит так:

После развертывания гиперконвергентной платформы StarWind HCA она управляется с помощью единой консоли StarWind Command Center.

Ну и самое главное - программно-аппаратные комплексы StarWind HCA All-Flash полностью на SSD-дисках продаются сегодня, по-сути, по цене гибридных хранилищ (HDD+SSD). Если хотите узнать больше - обращайтесь в StarWind за деталями на специальной странице. Посмотрите также и даташит HCA.

Новый StarWind Virtual SAN V8 для Hyper-V

Второй важный релиз - это обновленная версия продукта StarWind Virtual SAN V8 for Hyper-V (билд 13481 от 25 февраля 2020 года).

Давайте посмотрим, что нового появилось в StarWind Virtual SAN V8 for Hyper-V:

Ядро продукта

• Добавлен мастер для настройки StarWind Log Collector. Теперь можно использовать для этого соответствующее контекстное меню сервера в Management Console. Там можно подготовить архив с логами и скачать их на машину, где запущена Management Console.
• Исправлена ошибка с заголовочным файлом, который брал настройки из конфига, но не существовал на диске, что приводило с падению сервиса.
• Улучшен вывод событий в файлы журнала, когда в системе происходят изменения.
• Улучшена обработка ответов на команды UNMAP/TRIM от аппаратного хранилища.
• Добавлена реализация процессинга заголовка и блога данных дайждестов iSCSI на процессорах с набором команд SSE4.2.
• Максимальное число лог-файлов в ротации увеличено с 5 до 20.

• Процедура полной синхронизации была переработана, чтобы избежать перемещения данных, которые уже есть на хранилище назначения. Делается это путем поблочного сравнения CRC и копирования только отличающихся блоков.
• Исправлена ошибка падения сервиса в случае выхода в офлайн партнерского узла при большой нагрузке на HA-устройство.
• Значение по умолчанию пинга партнерского узла (iScsiPingCmdSendCmdTimeoutInSec) увеличено с 1 до 3 секунд.
• Исправлена ошибка с утечкой памяти для состояния, когда один из узлов был настроен с RDMA и пытался использовать iSER для соединения с партнером, который не принимал соединений iSER.

• Реализована поддержка SMTP-соединений через SSL/STARTTLS.
• Добавлена возможность аутентификации на SMTP.
• Добавлена возможность проверки настроек SMTP путем отправки тестового сообщения.

• Список регионов для всех репликаций помещен во внешний файл JSON, который можно просто обновлять в случае изменений на стороне провайдера.
• Исправлена обработка баркодов с длиной, отличающейся от дефолтной (8 символов).
• Исправлена ошибка падения сервиса при загрузке tape split из большого числа частей (тысячи).
• Исправлены ошибки в настройках CloudReplicator Settings.

• Обновился скрипт AddVirtualTape.ps1, был добавлен учет параметров, чувствительных к регистру.
• Для команды Remove-Device были добавлены опциональные параметры принудительного отсоединения, сохранения сервисных данных и удаления хранимых данных на устройстве.
• Добавлен метод IDevice::EnableCache для включения и отключения кэша (смотрите примеры FlashCache.ps1 и FlushCacheAll.ps1).
• VTLReplicationSettings.ps1 — для назначения репликации используется число, кодирующее его тип.
• Свойство "Valid" добавлено к HA channel.
• Сценарий MaintenanceMode.ps1 — улучшенная обработка булевых параметров при исполнении сценария из командной строки.
• Тип устройства LSFS — удален параметр AutoDefrag (он теперь всегда true).

• Небольшие улучшения и исправления ошибок.

Скачать полнофункциональную пробную версию StarWind Virtual SAN for Hyper-V можно по этой прямой ссылке. Release Notes доступны тут.

На блогах VMware появилась интересная статья о том, как работает связка кэширующего яруса (Cache tier) с ярусом хранения данных (Capacity tier) на хостах кластера VMware vSAN в контексте производительности. Многие пользователи задаются вопросом - а стоит ли ставить более быстрые устройства на хосты ESXi в Capacity tier и стоит ли увеличивать их объем? Насколько это важно для производительности?

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

В кластере vSAN это выглядит вот так:

Второе преимущество двухъярусной архитектуры заключается в возможности манипуляции данными не на лету (чтобы не затормаживать поток чтения-записи), а уже при их сбрасывании на Capacity tier. Например, так работают сервисы компрессии и дедупликации в VMware vSAN - эти процессы происходят уже на уровне яруса хранения, что позволяет виртуальной машине не испытывать просадок производительности на уровне яруса кэширования.

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

С точки зрения производительности это можно представить так (слева система с ярусом кэширования и хранения, справа - только с ярусом хранения):

Оказывается, в реальном мире большинство профилей нагрузки выглядят именно как на картинке слева, то есть система принимает большую нагрузку пачками (burst), после чего наступает некоторый перерыв, который устройства кэширования кластера vSAN используют для сброса данных на постоянные диски (drain).

Если вы поставите более производительное устройство кэширования и большего объема, то оно сможет в течение большего времени и быстрее "впитывать" в себя пачки операций ввода-вывода, которые возникают в результате всплесков нагрузки:

Но более быстрое устройство при равном объеме будет "наполняться" быстрее при большом потоке ввода-вывода, что уменьшит время, в течение которого оно сможет обслуживать такие всплески на пиковой скорости (зато во время них не будет проблем производительности). Здесь нужно подбирать устройства кэширования именно под ваш профиль нагрузки.

С точки зрения устройств кэширования и хранения, кластер VMware vSAN представлен дисковыми группами, в каждой из которых есть как минимум одно устройство кэширования и несколько дисков хранения:

Для устройств кэширования на уровне одной дисковой группы установлен лимит в 600 ГБ. Однако это не значит, что нельзя использовать ярус большего объема. Мало того, некоторые пользователи vSAN как раз используют больший объем, так как в этом случае запись происходит во все доступные ячейки SSD (но суммарный объем буфера все равно не превышает лимит), что приводит к меньшему изнашиванию устройств в целом. Например, так происходит в кластере All-flash - там все доступная свободная емкость (но до 600 ГБ) резервируется для кэша.

Надо еще понимать, что если вы поставите очень быстрые устройства кэширования, но небольшого объема - они будут быстро заполняться на пиковой скорости, а потом брать "паузу" на сброс данных на ярус хранения. Таким образом, здесь нужен компромисс между объемом и производительностью кэша.

На базе сказанного выше можно дать следующие рекомендации по оптимизации производительности двухъярусной системы хранения в кластерах VMware vSAN:

• Старайтесь использовать устройства кэширования большего объема, чтобы они могли впитывать большой поток ввода-вывода в течение большего времени. Производительность устройств уже рассматривайте во вторую очередь, только если у вас уж очень большой поток во время всплесков, который нужно обслуживать очень быстро.
• Добавляйте больше дисковых групп, каждую из которых может обслуживать свое устройство кэширования. На уровне дисковой группы установлен лимит в 600 ГБ, но всего на хосте может быть до 3 ТБ буфера, поделенного на 5 дисковых групп.
• Используйте более производительные устройства в ярусе хранения - так сброс данных буфера (destage rate) на них будет происходить быстрее, что приведет к более быстрой готовности оного обслуживать пиковую нагрузку.
• Увеличивайте число устройств хранения в дисковой группе - это увеличит скорость дестейджинга данных на них в параллельном режиме.
• Отслеживайте производительность кластера с помощью vSAN Performance Service, чтобы увидеть моменты, когда ярус кэширования захлебывается по производительности. Это позволит соотнести поведение буфера и профиля нагрузки и принять решения по сайзингу яруса кэширования и яруса хранения.
• Используйте самые последнии версии VMware vSAN. Например, в vSAN 6.7 Update 3 было сделано множество программных оптимизаций производительности, особенно в плане компрессии и дедупликации данных. Всегда имеет смысл быть в курсе, что нового появилось в апдейте и накатывать его своевременно.

Это гостевой пост нашего спонсора - сервис-провайдера ИТ-ГРАД, предоставляющего услугу аренды виртуальных машин из облака. В MIT предложили систему, которая в два раза уменьшит объем электричества, потребляемого «твердотельниками» в ЦОД. Рассказываем, как она устроена.

Проблема энергопотребления

Приблизительно через десять лет на вычислительные системы (в целом) будет приходиться40% потребляемой электроэнергии. За пятую часть этого объема будут «ответственны» центры обработки данных.

Системы хранения данных — один из основных «потребителей» электроэнергии в ЦОД. Чтобы сократить расходы на содержание СХД, операторы дата-центров заменяют жесткие диски на твердотельные накопители. Последние более производительны и энергоэффективны: известны случаи, когда SSD уменьшали объем потребляемого стойками СХД электричества на 60%.

Но ситуация все равно далека от идеальной. В машинном зале крупного дата-центра могут находиться сотни стоек с накопителями, и счета за электроэнергию остаются большими. Поэтому сегодня разрабатываются новые технологии, чтобы еще сильнее сократить энергопотребление SSD. Одну из таких технологий представили в MIT. Специалисты вуза спроектировали архитектуру системы хранения данных на базе твердотельных накопителей, которая снижает расходы операторов ЦОД на электричество в два раза. Ее назвали LightStore.

Как устроена система

LightStore представляет собой хранилище типа «ключ — значение» (KV-хранилище). Ключом считаются пользовательские запросы к СХД, а значением — сами данные. Систему разворачивают на специальном аппаратном узле в сети ЦОД. Его подключают напрямую, в обход серверов хранения данных (дополнительно потребляющих электроэнергию).

Узел построен на базе энергоэффективного CPU, а также NAND- и DRAM-памяти. Управляет им контроллер и специализированное ПО. Первый компонент отвечает за обмен данными с массивами NAND, а второй — за хранение ключей и их обработку. В основе программной архитектуры LightStore лежат так называемые LSM-деревья — структуры данных, используемые во всех современных СУБД.

Кластер LightStore масштабируется линейно путем подключения дополнительных узлов к сети. Для этих целей применяются специальные адаптеры. Они формализуют пользовательские запросы к СХД и трансформируют их в понятные для нее команды. Обработка запросов производится с использованием согласованного хеширования — при добавлении новой пары ключ-значение, хеш рассчитывается только для нее, а не для всех пар. Аналогичный подход применяют системы Redis и Swift.

В общем случае архитектуру LightStore и схему ее подключений в ЦОД можно представить вот так:

По словам разработчиков, пропускная способность LightStore при работе в 10GbE-сети дата-центра превышает 600 Мбит/с. При этом один ее узел потребляет на 10 Вт меньше, чем узел «классических» SSD-систем — для них этот показатель равен 20 Вт. Также оборудование занимает в два раза меньше места, отчасти из-за того, что LightStore не требуются серверы хранения.

Сейчас инженеры из MIT занимаются исправлением недостатков LightStore и расширением функциональности системы. Например, ее «учат» работать с атомарными запросами и запросами по диапазону. Также в планах разработчиков добавить поддержку SQL-запросов. Авторы убеждены, что в будущем LightStore может стать отраслевым стандартом для SSD-хранилищ в центрах обработки данных.

Аналоги решения

В прошлом году компания Marvell, которая занимается разработкой СХД, анонсировала SSD-контроллеры с интеллектуальными функциями. Они построены на базе систем ИИ, которые оптимизируют энергопотребление SSD в ЦОД. Ожидается, что решение найдет применение в машинных залах организаций, занимающихся аналитикой больших данных.

Еще один пример — накопитель WD Blue SSD с повышенной производительностью и энергоэффективностью. Устройство использует спецификацию NVMe для подключения дисков к шине PCI Express. Такой подход позволил повысить эффективность накопителя при работе с большим числом параллельных запросов. Устройство имеет скорость чтения в 545 МБ/с и скорость записи в 525 МБ/с. NVMe может стать стандартом ИТ-индустрии для SSD-интерфейсов. Производителям аппаратного обеспечения больше не придется расходовать ресурсы на разработку уникальных драйверов и разъемов.

В будущем можно ожидать появления большего числа решений, повышающих энергоэффективность СХД, подобных системам из MIT, Marvell и WD.

Оригинал статьи в блоге ИТ-ГРАД.

Компания VMware выпустила документ, касающийся работы баз данных Oracle Database 12c на платформе VMware vSAN - Oracle Database on VMware vSAN 6.7. Основная тема дока - тестирование числа операций ввода-вывода (IOPS) и latency операций СУБД на хостах в All-Flash конфигурации, когда и ярус кэширования, и ярус хранения реализован на SSD-дисках:

В документе рассматривается 4 ключевых аспекта для реализации тяжелых баз данных:

• Производительность OLTP-нагрузок в кластере all-flash vSAN.
• Политики Storage Policy Based Management (SPBM) для управления хранилищами.
• Построение платформы для бизнес-критичных задач уровня Tier-1.
• Валидация архитектуры для уменьшения времени развертывания и операционных рисков.

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

В тестах использовалось два типа рабочих нагрузок (R1 и R15), отличающихся конфигурацией ВМ, а также включенными или выключенными технологиями дедупликации и компрессии на стороне vSAN:

Описание рабочей нагрузки:

Базовые результаты по IOPS и latency для операций чтения и записи:

После результатов тестирования в документе есть секция с рекомендациями по исполнению Oracle на хранилищах vSAN, которые будет полезно почитать администратору БД и vSphere (большая их часть приведена в vSAN Design and Sizing Guide).

С появлением таких решений, как VMware Virtual SAN и StarWind Virtual SAN, многие пользователи стали проявлять интерес к хранилищам на базе серверных систем, построенным полностью на флэш-накопителях. Само собой, это все работает очень быстро, но стоит приличных денег. Кроме того, предприятия используют и отдельные системы хранения данных All-Flash, что дает отличные результаты по IOPS, но для многих пока это стоит космических денег.

Вот, кстати, последний магический квадрант Gartner о производителях систем хранения на базе накопителей SSD:

Jerome Wendt, аналитик компании DCIG, написал интересную классификацию хранилищ данных All-Flash с примерами. Вот какие основные группы он выделяет:

1. Elastic all-flash arrays. Это дисковые массивы, которые изначально были запроектированы под флэш-хранилища. Это множество включает в себя такие модели, как Dell EMC XtremIO, Kaminario, Nimbus Data и Pure Storage, а аналитическая компания DCIG также включает туда массивы HPE Nimble и Dell EMC Isilon. Главная характеристика этой группы - это возможность горизонтального масштабирования, которое подразумевает рабочий процесс "set-it-and-forget-it" (то есть настроил и забыл).
2. Enterprise all-flash arrays. Это массивы корпоративного класса, которые, как правило, стоят весьма немалых денег. Эта группа представлена массивами Dell EMC VMAX, HPE 3PAR, Huawei OceanStor, NetApp AFF и Western Digital Tegile. В этих моделях есть как вертикальное (scale-up), так и горизонтальное (scale-out) масштабирование, а сами массивы заточены под выдачу максимальной производительности (1+ million IOPS). Самое главное - что эти массивы хорошо обрабатывают смешанные нагрузки (а не просто последовательное чтение или запись) по вводу-выводу в больших корпоративных окружениях (Enterprise-админы поймут, почему это самая важная характеристика).
3. General purpose all-flash arrays. Это множество представлено такими продуктами, как Dell EMC Unity, FUJITSU Storage ETERNUS AF Series, Hitachi Vantara VSP F series, Nexsan Unity и NEC Storage M Series. Это традиционные дисковые массивы с двумя контроллерами, которые были обновлены, чтобы обслуживать флэш-накопители. Главное преимущество этих систем - развитые системы управления, так как они прошли большой путь эволюции.
4. High performance all-flash arrays. Это отдельный класс дорогостоящих систем на базе флэш-памяти, которые только приходят на рынок. В качестве примера сейчас можно привести СХД E8 Storage, а позднее в этом году выйдет система от Kaminario. В этом классе количественная мера производительности уже на порядок выше - это 10+ миллионов IOPS, получаемых за счет использования технологии NVMe-oF на фронтенд-интерфейсах для хостов. Отметим, что внедрение этих хранилищ на практике пока затруднено, ввиду высокой цены и общей неготовностью инфраструктуры к обслуживанию таких хранилищ.
5. Utility all-flash arrays. Эта группа включает в себя такие СХД, как серию хранилищ HPE MSA, IBM FlashSystem 900, серию NetApp E-series и SanDisk Infiniflash. Это системы для организаций, которым необходимо посадить на дисковый массив только несколько приложений, которым необходим высокий уровень производительности и надежности. Эти хранилища продаются по привлекательной цене, но заточены под вполне определенные задачи и не подходят для сред с большим числом нагрузок. Кроме того, в этих СХД средства управления не позволяют делать многого.

Автор говорит еще о том, что в течение 5-10 лет появятся еще так называемые Composable Flash Arrays, которые заменят собой описанные пять типов массивов, но пока ситуация остается такой, какой она описана выше.

Многие администраторы больших виртуальных инфраструктур VMware vSphere, в которых работают кластеры отказоустойчивых хранилищ VMware vSAN, часто задаются вопросом, какой дисковый контроллер выбрать для организации хранения на хостах ESXi.

Дункан Эппинг дает простую рекомендацию - надо брать один из самых недорогих поддерживаемых контроллеров, который имеет большую глубину очереди (Queue Depth). Например, часто в рекомендациях для vSAN можно встретить контроллер Dell H730, который является весьма дорогим устройством, если брать его на каждый сервер.

Но его не обязательно покупать, достаточно будет дискового контроллера Dell HBA 330, который и стоит дешевле, и глубину очереди имеет в 10 раз больше, чем H730 (хотя оба они соответствуют требованиям vSAN). Да, у H730 есть кэш на контроллере, но он в данном случае не требуется. Лучше использовать интерфейс NVMe для подключения отдельного SSD-кэша, не затрагивающего RAID-контроллеры (его нужно размещать как можно ближе к CPU).

Поэтому итоговая рекомендация по выбору дискового контроллера для кластеров vSAN проста - берите любое недорогое устройство из списка совместимости vSAN Compatibility Guide, но с хорошей глубиной очереди (например, HP H240), а на сэкономленные деньги отдельно организуйте кэш на базе NVMe.

Производительность, готовность и большой объем дискового пространства! Компания ИТ-ГРАД представляет вашему вниманию систему, способную удовлетворить современные требования: All-Flash массив FAS2552A.

Надежная конфигурация

• Двухузловой кластер FAS2552A (НА-пара) с 12 твердотельными накопителями по 400 ГБ

Множество преимуществ

• Значительное ускорение работы приложений.
• Использование флеш-дисков со всеми протоколами (FCP, ISCSI, NFS, CIFS).
• Больше никаких простоев! Все задачи технического обслуживания (включая техническое обновление и перенос) можно выполнять без отключения системы.
• Гибкая конфигурация. СХД может быть увеличена до 8 узлов с объемом дискового пространства 3 ПБ3. Возможно перемещение данных без отключения системы.
• Эффективность хранения данных для всех протоколов.
• Дедупликация, компрессия и гибкое выделение ресурсов для всех протоколов (FCP, ISCSI, NFS, CIFS).
• Удобное резервное копирование и аварийное восстановление.
• Функция резервного копирования Snapshot с интеграцией приложений и гибкие возможности аварийного восстановления в других ЦОД.
• Корпоративная система хранения данных, проверенная в реальных условиях эксплуатации тысяч установленных систем. Стабильная работа с помощью Data ONTAP, лучшей в мире операционной системы для СХД, а также широкий спектр сервисов технической поддержки (например, AutoSupport).

Для запроса стоимости FAS2552A обращайтесь в компанию ИТ-ГРАД.

Компания VMware еще с выходом VMware vSphere 5.1 объявила о нескольких новых начинаниях в сфере хранения данных виртуальных машин, включая возможность использования распределенного кеш на SSD-накопителях локальных дисков серверов ESXi. Данная технология имела рабочее название vFlash и находилась в стадии Tech Preview, превратившись позднее в полноценную функцию vSphere Flash Read Cache (vFRC) платформы VMware vSphere 5.5. И это вполне рабочий инструмент, который можно использовать в задачах различного уровня.

Недавно мы опубликовали статью компании ИТ-ГРАД об SSD-кэшировании средствами гипервизора - vSphere Flash Read Cache (vFRC). Производитель решений #1 в сфере программных хранилищ под виртуализацию, компания StarWind Software, также решила затронуть тему кэширования на стороне сервера в бесплатном вебинаре "Server-Side Caching as an Alternative to All-Flash Arrays", который пройдет 25 февраля.

Вебинар пройдет 25 февраля в 19-00 по московскому времени.

На вебинаре Макс Коломейцев и Крис Эванс расскажут о новейших подходах к организации кэширования данных виртуальных машин на стороне сервера за счет использования Flash-накопителей и оперативной памяти, что вполне может быть альтернативой дорогостоящих All-Flash массивов с точки зрения производительности ввода-вывода.

На вебинаре будут рассмотрены следующие вопросы:

• Принцип Парето (80/20) при распределении данных в областях памяти
• Как работает кэширование на стороне сервера
• Плюсы и минусы такого кэширования
• Реализация кэширования в виртуальных средах (как в гостевой ОС, так и в хостовой)
• Реализация кэширования в физических средах
• Выбор правильного аппаратного обеспечения для хостов
• Обзор возможностей программных продуктов различных вендоров

Вебинар, безусловно, получится очень интересным, особенно для тех, кто интересуется темой производительности виртуальной инфраструктуры.

РЕГИСТРАЦИЯ

Как вы знаете, недавно компания VMware сняла эмбарго на освещение новых возможностей платформы виртуализации VMware vSphere 6.0, о которых мы писали вот тут (и тут). На блогах, посвященных технологиям виртуализации, появилось много разных статей о новых возможностях продукта, и мы уже писали о технологии непрерывной доступности VMware Fault Tolerance 6.0.

Сегодня мы хотим рассказать об отказоустойчивых кластерах VMware Virtual SAN 6.0, для которых версия программного обеспечения продвинулась с 1.0 сразу до 6.0 (поэтому пользователи, все же, не должны заблуждаться насчет зрелости продукта - это его вторая версия).

Итак, что нового появилось в VMware Virtual SAN 6.0:

1. Поддержка архитектуры All Flash для создания кластера хранилищ.

Теперь доступны два варианта развертывания VSAN:

• Hybrid – Virtual SAN, как и раньше, использует SSD-диски для кэширования, а для хранения ВМ используются обычные HDD-диски. Максимально возможные конфигурации этой архитектуры стали выше (например, стало 64 хоста в кластере).
• All Flash – Virtual SAN использует имеющиеся Flash-накопители как для кэширования, так для хранения ВМ.

Отличия между данными архитектурами:

В конфигурации All Flash девайсы, ответственные за кэширование, будут производить только кэширование записи и не будут делать кэширование на чтение (это очевидно почему). В гибридной конфигурации, как и раньше, 30% емкости SSD-кэшей используется для Write Buffer, а 70% - для кэша на чтение.

В целом, утверждается, что решение Virtual SAN теперь готово к полноценной промышленной эксплуатации.

2. Возможность High Density Direct Attached Storage (HDDAS).

Теперь кластеры Virtual SAN удобно использовать в окружениях с блейд-системами. Для них поддерживаются как SDD, так и HDD-устройства, включая flash-хранилища блейд-серверов.

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

3. Новая файловая система и формат On-Disk.

Virtual SAN в VMware vSphere 5.5 использовал модифицированный формат файловой системы VMFS с измененным механизмом блокировок, которая называлась VMFS-L. Теперь же в VSAN 6.0 используется файловая система VSAN FS, специально предназначенная для кластеров хранилищ.

Старый формат VMFS-L поддерживается и в новой версии, но VMware предлагает провести миграцию хранилищ, тем более что это делается без простоя сервисов.

4. Функции Proactive Rebalance.

В Virtual SAN 6.0 появилась возможность ребаланса объектов по виртуальным дискам в случае, если подключается новый узел vSphere или если диски заполнены на 80% и более. Делается это через Ruby Console.

5. VSAN Fault Domains (группы отказа).

Теперь в VSAN можно определять домены отказа, то есть группы хостов у которых может произойти одновременный сбой (например, отказ питания на стойке), чтобы все их объекты были задублированы в других доменах:

Теперь реплики объектов происходят не на уровне хостов, а на уровне Fault Domains (в данном случае инфраструктура хранения переживет отказ одной стойки):

6. Новые функции для дисков (Serviceability Functions).

• Light LED on failures – включение LED-индикатора при отказе.
• Turn on disk LED manually - включение LED-индикатора вручную для диска, чтобы его можно было найти на массиве.
• Marking a disk as local – если диск не обнаружился как локальный, его можно пометить вручную из GUI.
• Marking a disk as SSD - теперь эта опция есть в GUI, нужна если диск автоматически не распознается как SSD.

7. Улучшения сетевого взаимодействия.

Теперь Virtual SAN 6 поддерживает конфигурации на уровне Layer 3. Кроме того, теперь доступна конфигурация с Jumbo Frames. Ну и добавлена поддержка возможностей vDS и Network IO Control (NetIOC).

8. Новый тип виртуального диска VMDK - vsanSparse.

Ранее использовались стандартные Redo-диски, но они не были приспособлены под кэширование и другие функции VSAN FS, поэтому сделали новый тип диска vsanSparse.

9. Улучшенные функции Disk/Disk Group Evacuation.

Возможность эвакуации данных с отдельного диска или группы перед тем, как вы его хотите вывести из эксплуатации физически. Ранее приходилось переводить весь хост в Maintenance Mode, чтобы было очень неудобно при поломке лишь одного диска.

10. Новое представление Resynchronization Dashboard.

Это представление показывает статус объектов, которые по тем или иным причинам находятся в состоянии ресинхронизации. Также показывается примерное время окончании синхронизации:

11. Новые службы 3rd Party File Services.

Сторонние вендоры теперь могут надстраивать свои решения над VMware Virtual SAN. Например, мы писали о таком решении совсем недавно - это NexentaConnect.

12. Полноценная поддержка командлетов PowerCLI.

Ранее интерфейс PowerCLI поддерживался неофициально, теперь же командлеты задокументированы и поддерживаются:

13. Службы мониторинга жизнедеятельности (VSAN Health Services).

Теперь для компонентов Virtual SAN доступна информация об их состоянии:

14. Storage Consumption Models.

Возможность визуализовать использование ресурсов хранения Virtual SAN 6.0 при создании или изменении VM Storage Policy.

О доступности VMware Virtual SAN 6.0 будет объявлено отдельно.

Некоторое время назад мы писали о технологии VMware vFlash (она же Virtual Flash), которая позволяет использовать высокопроизводительные накопители SSD (вот тут - о производительности) для решения двух важных задач:

• Предоставление виртуальным машинам дополнительного места, в которое будут свопиться страницы памяти в случае недостатка ресурсов на хосте (это намного более производительно, чем свопить на обычный HDD-диск). Эта техника называется Virtual Flash Host Swap и пришла на смену механизму Swap to SSD.
• Прозрачное встраивание в поток ввода-вывода на хосте между виртуальными машинами и хранилищами, что позволяет существенно ускорить операции чтения данных виртуальных дисков. Называется это VMware Flash Read Cache (vFRC).

Ниже мы вкратце расскажем о настройке этих двух механизмов через VMware vSphere Web Client (в обычном C#-клиенте этого, к сожалению, нет). Если что, более подробно о технике vFRC можно почитать по этой ссылке.

Итак, в vSphere Web Client переходим на вкладку "Manage" для нужного хоста, далее в разделе "Settings" выбираем пункт "Virtual Flash Resource Management". Это кэш, который мы добавляем для того, чтобы в случае нехватки места, его могли использовать виртуальные машины, чтобы не свопить данные на медленный магнитный диск, кроме того он же будет использоваться для целей vFRC.

Нажимаем Add Capacity:

Выбираем диски, которые мы будем использовать как Host Swap и нажимаем "Ок" (все данные на них будут стерты):

Всего под нужды Virtual Flash может быть выделено до 8 дисков суммарной емкостью до 32 ТБ. Видим, что ресурс добавлен как Virtual Flash Resource (его емкость отдельно учитывается для vFRC и Host Cache):

Настройка Virtual Flash Host Swap

Первым делом рекомендуется настроить именно этот кэш, а остаток уже распределять по виртуальным машинам для vFRC.

Выбираем пункт "Virtual Flash Host Swap Cache Configuration" в левом меню, а далее в правой части мы нажимаем кнопку "Edit":

Указываем необходимый объем, который планируется использовать, и нажимаем "Ок":

После того, как мы настроили нужное значение - в случае недостатка ресурсов на хосте виртуальные машины будут использовать высокоскоростные диски SDD для своих нужд внутри гостевой ОС (файлы подкачки прочее).

Настройка VMware Flash Read Cache (vFRC)

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

Сам кэш vFRC можно настроить на уровне отдельных виртуальных машин на хосте VMware ESXi, а также на уровне отдельных виртуальных дисков VMDK.

Чтобы выставить использование нужного объема vFRC для отдельной виртуальной машины, нужно выбрать пункт "Edit Settings" из контекстного меню ВМ и на вкладке "Virtual Hardware" в разделе "Virtual Flash Read Cache" установить нужное значение для соответствующего виртуального диска:

Если этого пункта у вас нет, то значит у вас версия виртуального "железа" (Virtual Machine Hardware) ниже, чем 10, и ее нужно обновить.

По ссылке "Advanced" можно настроить размер блока для кэша (значение Reservation, установленное тут, обновит значение на предыдущем скрине):

Чтобы понять, какие значения SSD-кэша можно и нужно выставлять для виртуальных машин, рекомендуется почитать документ "Performance of vSphere Flash Read Cache in VMware vSphere 5.5".

Как знают те из вас, кто следит за развитием технологий VMware, есть такой механизм как vFRC (vSphere Flash Read Cache), представляющий собой распределенный кэш на SSD-накопителях локальных дисков серверов ESXi (ранее он имел рабочее название vFlash). Не так давно мы писали про обзорный документ "What’s New in VMware vSphere Flash Read Cache", а на днях вышел более глубокий технический документ "Performance of vSphere Flash Read Cache in VMware vSphere 5.5", посвященный производительности vFRC.

Помимо всего прочего, в документе рассматривается способ получения информации о структуре и содержимом кэша vFRC. Сделать это можно с помощью команды:

~ # esxcli storage vflash cache list

Эта команда выведет список идентификаторов кэша для VMDK-дисков, для которых включена vFRC. Далее с помощью следующей команды можно узнать детали конкретного ID кэша:

 # esxcli storage vflash cache get –c <cache-identifier>

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

~ # cacheID='vsish -e ls /vmkModules/vflash/module/vfc/cache/'
~ # vsish -e get /vmkModules/vflash/module/vfc/cache/${cacheID}stats

В результате будет выведено что-то подобное:

vFlash per cache instance statistics {
cacheBlockSize:8192
numBlocks:1270976
numBlocksCurrentlyCached:222255
numFailedPrimaryIOs:0
numFailedCacheIOs:0
avgNumBlocksOnCache:172494
read:vFlash per I/O type Statistics {
numIOs:168016
avgNumIOPs:61
maxNumIOPs:1969
avgNumKBs:42143
maxNumKBs:227891
avgLatencyUS:16201
maxLatencyUS:41070
numPrimaryIOs:11442
numCacheIOs:156574
avgCacheLatencyUS:17130
avgPrimaryLatencyUS:239961
cacheHitPercentage:94
}
write:vFlash per I/O type Statistics {
numIOs:102264
avgNumIOPs:307
maxNumIOPs:3982
avgNumKBs:10424
maxNumKBs:12106
avgLatencyUS:3248
maxLatencyUS:31798
numPrimaryIOs:102264
numCacheIOs:0
avgCacheLatencyUS:0
avgPrimaryLatencyUS:3248
cacheHitPercentage:0
}
rwTotal:vFlash per I/O type Statistics {
numIOs:270280
avgNumIOPs:88
maxNumIOPs:2027
avgNumKBs:52568
maxNumKBs:233584
avgLatencyUS:11300
maxLatencyUS:40029
numPrimaryIOs:113706
numCacheIOs:156574
avgCacheLatencyUS:17130
avgPrimaryLatencyUS:27068
cacheHitPercentage:58
}
flush:vFlash per operation type statistics {
lastOpTimeUS:0
numBlocksLastOp:0
nextOpTimeUS:0
numBlocksNextOp:0
avgNumBlocksPerOp:0
}
evict:vFlash per operation type statistics {
lastOpTimeUS:0
numBlocksLastOp:0
nextOpTimeUS:0
numBlocksNextOp:0
avgNumBlocksPerOp:0
}
}

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

Одна из самых популярных статей на VM Guru - это статья про типы дисков виртуальных машин на платформе VMware vSphere. Там рассказано про все имеющиеся виды виртуальных дисков, среди которых можно выделить три основных:

• Lazy zeroed thick disks - все пространство диска выделяется в момент создания, при этом блоки не очищаются от данных, которые находились там ранее. Но при первом обращении ВМ к этому блоку он обнуляется.
• Eager zeroed thick disks - все пространство такого диска выделяется в момент создания, при этом блоки очищаются от данных, которые находились там ранее. Далее происходит обычная работа с блоками без очистки.
• Thin disks ("тонкие диски") - эти диски создаются минимального размера и растут по мере их наполнения данными до выделенного объема. При выделении нового блока - он предварительно очищается. Эти диски экономят пространство на массиве, так как не забивают его нулями и не требуют аллокации заданного объема.

Между администраторами VMware vSphere очень часто возникает дискуссия: диски какого типа нужно создавать, особенно если дело касается высоких нагрузок ВМ на дисковую подсистему? Сейчас это становится актуальным и для флэш-массивов, которые начинают появляться в организациях различного масштаба и предназначены как раз для высоких нагрузок ВМ на диски.

Специально для таких пользователей компания VMware провела тесты для последовательных и случайных операций при работе с виртуальными дисками различного типа, используя для этого дисковые массивы с SSD-накопителями.

Результаты оказались интересны - диски типа Thin и Lazy zeroed серьезно уступают в производительности дискам Eager zeroed, когда дело касается нагрузок случайного типа.

Использованная тестовая конфигурация:

• Сервер Dell R910 с 40 ядрами и 256 ГБ оперативной памяти.
• Дисковый массив Pure FA-420 FlashArray с двумя полками, на которых 44 флэш-диска по 238 ГБ каждый (суммарно 8.2 ТБ полезной емкости).
• Виртуальная машина Windows 2008 R2 Virtual Machine следующей конфигурации: 4 vCPU, 8 GB RAM, 40 GB OS/Boot Disk, 500 GB Data Disk.
• Инициатор SW iSCSI для карточки 10 Gb.

Таблица результатов тестов, сделанных с помощью IOMETER для различных размеров блоков:

Из таблицы видно, что все диски на последовательных нагрузках показывают примерно одинаковый результат, а вот на Random-нагрузках уже совершенно другая картина. Все это более наглядно можно увидеть графиков, где диски Thin и Lazy zeroed существенно проседают по производительности:

Вывод - не все йогурты одинаково полезны. Для высокопроизводительных нагрузок желательно использовать диски типа Eager zeroed - хуже точно не будет. Единственный их минус - требуется существенное время на их создание, поскольку происходит обнуление блоков. Но если ваш дисковый массив поддерживает примитивы VAAI, то много времени не понадобится: например, в том же тесте диск Eager zeroed размером 500 ГБ создался менее чем за одну минуту.

Достаточно давно мы писали о технологии VMware vFlash (теперь она называется vSphere Flash Read Cache), которая пришла на смену технологии Swap-to-SSD - она позволяет использовать локальные SSD-диски хостов VMware ESXi для задач кэширования. Напомним, что Flash Read Cache позволяет использовать кэширование данных только на чтение для дисков VMDK виртуальных машин, работает она на уровне гипервизора и существенно улучшает производительность виртуальных машин, которые интенсивно используют подсистему ввода-вывода для операций на чтение.

Очевидно, что SSD-кэш, который по производительности находится между оперативной памятью и обычными дисками, существенно повышает быстродействие в системах, где периодически наблюдается недостаток ресурсов RAM. Все это дело работает в кластере до 32 хостов ESXi.

Однако, иногда вам может понадобиться вернуть SSD-накопитель хосту ESXi, чтобы использовать его для других задач. Можно попробовать отключить использование ресурсов vFlash для всех виртуальных машин хоста, затем пойти в раздел "Virtual Flash Resource Management" и выбрать опцию "Remove All" - но это не сработает. Появятся следующие ошибки:

Host’s virtual flash resource is inaccessible.
The object or item referred to could not be found.

Чтобы вернуть диск SSD снова в строй понадобится удалить специальный раздел - vFlash File System partition. Для этого нужно сначала его найти. Выполняем команду:

ls /vmfs/devices/disks

Тут мы видим нашу SSD-партицию (видим в середине буквы "SSD" - не ошибитесь - нам нужен раздел без ":1"):

disk ID “t10.ATA_____M42DCT032M4SSD3__________________________00000000121903600F1F”

Сносим эту партицию с помощью утилиты partedutil, используя найденный Disk ID:

partedutil delete "/vmfs/devices/disks/t10.ATA_____M42DCT032M4SSD3__________________________00000000121903600F1F" 1

Что-то вроде этого:

После чего мы видим, что диск SSD освободился и его можно использовать на хосте VMware ESXi:

Источник.

Мы уже писали о технологии VMware Virtual SAN, которая сейчас находится в режиме бета-тестирования. Кроме того, мы затрагивали тему производительности виртуальных ПК VMware Horizon View на хранилищах Virtual SAN (там про то, что VSAN масштабируется почти без потерь производительности).

Сегодня мы хотим рассказать еще о двух вещах. Во-первых, компания VMware выпустила обновление беты Virtual SAN, которое получило следующие новые возможности:

• AHCI fix - как писала VMware ранее, была проблема с контроллерами AHCI, которая приводила к потере данных на устройствах VSAN (см. PDL, Permanent Device Loss). Теперь эту проблему исправили, и можно продолжать тестирование на этих контроллерах.

• New RVC Commands - теперь в Ruby Virtual Console, которая входит в состав VMware vCenter 5.5, есть команды по управлению хранилищами в пространстве имен spbm (Storage Policy Based Management). Существующие политики можно найти в папке "~/storage/vmprofiles".

• PowerCLI fling - многим пользователям интересна автоматизация задач в VMware vCloud Suite. Теперь и для VSAN есть набор командлетов PowerCLI, которые позволяют управлять хранилищами VSAN. Более подробно об этом здесь.

• Limit Changes - в первой бета-версии дисковая группа могла иметь 1 SSD-Накопитель и до 6 HDD-дисков, но поскольку есть серверы, в которых восемь слотов, то HDD-дисков теперь поддерживается до 7 штук (SSD по-прежнему один).

Во-вторых появилась третья статья в серии про Virtual SAN - "VDI Benchmarking Using View Planner on VMware Virtual SAN – Part 3" из цикла статей, где делаются всяческие замеры производительности хранилищ VSAN.

В этот раз сравнивалось некий дисковый массив "all flash storage array", который работает на SSD-накопителях, и 7-ми и 8-ми узловые кластеры Virtual SAN. Результаты в очках, поставленных VDImark (View Planner QoS), поставленные кластеру из хостовых хранилищ и дисковому массиву:

Напомним, что очки VDImark - это число виртуальных машин, которое может быть запущено на данной аппаратной конфигурации с соблюдением определенного порогового значения для операций (на самом деле минимум 95% операций должны попасть в эти трешхолды для ВМ, чтобы их засчитали).

Результаты тестов оказались весьма неплохими. Картинка для тестов по времени отклика операций группы А (интерактивные операции пользователя):

Группа B:

Вывод: Virtual SAN - очень неплох в сравнении с нативной производительностью какого-то SSD-массива (VMware, что это за массив-то??).

Ну и ссылки на все статьи цикла:

• VDI Benchmarking Using View Planner on VMware Virtual SAN – Part 1
• VDI Benchmarking Using View Planner on VMware Virtual SAN – Part 2
• VDI Benchmarking Using View Planner on VMware Virtual SAN – Part 3

Сразу после релиза обновленной версии платформы vSphere 5.5 компания VMware выпустила очень интересный и полезный документ Performance Best Practices for VMware vSphere 5.5, в котором рассматриваются аспекты производительности серверов VMware ESXi и виртуальных машин уже с учетом функциональности новой версии.

Например, теперь в документе описаны следующие фичи в контексте производительности:

• Функции кэширования на SSD-накопителях vSphere Flash Read Cache, о которых мы писали вот тут. Они увеличивают производительность за счет применения кэша на чтение для операций ввода-вывода виртуальных машин.
• Возможность VMware Virtual SAN (VSAN), о которой мы писали тут. Она позволяет использовать локальные ресурсы хостов ESXi для построения распределенной инфраструктуры хранения виртуальных машин.
• База данных VMware vFabric Postgres database (vPostgres).

Кроме того, были обновлены и дополнены следующие темы в документе (который уже можно смело называть книгой, так как занимает он 90 страниц):

• Использование нагрузок в ВМ, чувствительных к скорости подсистемы ввода-вывода и сетевому взаимодействию (интересна также статья в тему)
• Техники NUMA и Virtual NUMA (vNUMA)
• Техники экономии памяти хоста (Memory overcommit)
• Технология Large memory pages
• Техника Receive-side scaling (RSS), как в гостевых ОС, так и для адаптеров 10 Gigabit Ethernet
• Средства миграции VMware vMotion, Storage vMotion, а также Cross-host Storage vMotion
• Техники балансировки нагрузки VMware Distributed Resource Scheduler (DRS) и экономии электропитания Distributed Power Management (DPM)
• Обновленный (а точнее полностью переписанный) VMware Single Sign-On Server (об этом у нас тут)

Как многие знают, с выходом VMware vSphere 5.1 компания VMware объявила о нескольких новых начинаниях в сфере хранения данных виртуальных машин, таких как концепция vVOL для хранилищ vSphere и сервисы распределенного хранения VMware Distributed Storage (концепция vSAN).

Кроме того, не так давно были воплощены в жизнь такие полезные службы vSphere для работы с SSD-накопителями, как SSD Monitoring (реализуется демоном smartd) и Swap to SSD (использование локальных дисков для файлов подкачки виртуальных машин). Однако функции кэширования на SSD реализованы пока совсем в базовом варианте, поэтому сегодня вам будет интересно узнать о новой технологии Virtual Flash (vFlash) для SSD-накопителей в VMware vSphere, которая была анонсирована совсем недавно.

Эта технология, находящаяся в стадии Tech Preview, направлена на дальнейшую интеграцию SSD-накопителей и других flash-устройств в инфраструктуру хранения VMware vSphere. Прежде всего, vFlash - это средство, позволяющее объединить SSD-ресурсы хост-серверов VMware ESXi в единый пул, используемый для задач кэширования, чтобы повысить быстродействие виртуальных машин. vFlash - это фреймворк, позволяющий сторонним вендорам SSD-накопителей и кэш-устройств использовать собственные алгоритмы для создания модулей обработки кэшей виртуальных машин (плагины vFlash Cache Modules). Будет реализован и собственный базовый алгоритм VMware для работы с кэшем.

Основная мысль VMware - предоставить партнерам некий API для их flash-устройств, за счет которого виртуальные машины будут "умно" использовать алгоритмы кэширования. Для этого можно будет использовать 2 подхода к кэшированию: VM-aware caching и VM-transparent caching:

VM-aware Caching (vFlash Memory)

В этом режиме обработки кэширования флэш-ресурс доступен напрямую для виртуальной машины, которая может использовать его на уровне блоков. В этом случае на уровне виртуального аппаратного обеспечения у виртуальной машины есть ресурс vFlash Memory определенного объема, который она может использовать как обычный диск в гостевой ОС. То есть, приложение или операционная система должны сами думать, как этот высокопроизводительный ресурс использовать. Можно вообще использовать его не как кэш, а как обычный диск, хотя идея, конечно же, не в этом.

VM-transparent Caching (vFlash Cache)

В этом случае виртуальная машина и ее гостевая ОС не знают, что на пути команд ввода-вывода находится прослойка в виде flash-устройств, оптимизирующих производительность за счет кэширования. В этом случае задача специализированного ПО (в том числе от партнеров) - предоставить оптимальный алгоритм кэширования. В этом случае будет доступна настройка следующих параметров кэша:

• Гарантированный объем (Reservation size)
• Выбор программного модуля-обработчика (vFlash Cache Module)
• Режим работы кэша (write-back или write-thru)
• Размер блока (настраивается в зависимости от гостевой ОС)
• Что делать с кэшем при перемещении виртуальной машины посредством vMotion (перенести вместе с ней или удалить)

При vMotion сервер vCenter будет проверять наличие необходимых ресурсов кэширования для виртуальной машины на целевом хосте ESXi. Для совместимости с технологией VMware HA, виртуальная машина должна будет иметь доступные vFlash-ресурсы на хранилищах хостов в случае сбоя (соответственно, потребуется эти ресурсы гарантировать).

В целом vFlash в VMware vSphere обещает быть очень перспективной технологией, что особенно актуально на волне роста потребления SSD-накопителей, постепенно дешевеющих и входящих в повсеместное употребление.

Мы уже писали о некоторых функциях утилиты esxcli в VMware vSphere, которая работает с различными пространствами имен, такими как network, storage, hardware и прочими. Сегодня мы хотим остановиться на новых функциях по управлению устройствами ввода-вывода I/O Device Management (IODM), пространство имен для которых появилось в VMware vSphere 5.1. Цель этих новых инструментов - дать администратору инструменты для понимания уровня, на котором происходят проблемы с хранилищем в сети SAN (см. тут).

Это новое пространство имен выглядит вот так:

esxcli storage san

Например, мы хотим сделать Reset для FC-адаптера:

esxcli storage san fc reset -A vmhba3

А потом посмотреть его лог, который включает в себя информацию о таких событиях, как разрыв соединения:

esxcli storage san fc events get

Можно собрать статистику по iscsi-адаптеру командой:

esxcli storage san iscsi stats get

Кроме того, в VMware vSphere 5.1 появились функции мониторинга твердотельных накопителей - SSD Monitoring, реализуемые метриками, которые собирает каждые полчаса демон S.M.A.R.T. (Self-Monitoring, Analysis and Reporting Technology). Находятся стандартные плагины в /usr/lib/VMware/smart_plugins (кстати, вендоры дисковых устройств могут добавлять туда свои плагины вместо имеющихся generic-плагинов). Надо также отметить, что эти метрики не передаются в vCenter и доступны только через esxcli.

Посмотреть статистики SSD-дисков можно командой:

esxcli storage core device smart get -d naa.xxxxxx

Жирным выделены метрики, которые могут оказаться полезными. Параметр Reallocated Sector Count не должен сильно увеличиваться со временем для исправных дисков. Когда дисковая подсистема получает ошибку read/write/verification для сектора, она перемещает его данные в специально зарезервированную область (spare area), а данный счетчик увеличивается.

Media Wearout Indicator - это уровень "жизни" вашего SSD-диска (для новых дисков он должен отображаться как 100). По мере прохождения циклов перезаписи диск "изнашивается" и данный счетчик уменьшается, соответственно, когда он перейдет в значение 0 - его жизнь формально закончится, исходя из рассчитанного для него ресурса. Кстати, этот счетчик может временно уменьшаться при интенсивных нагрузках диска, а потом восстанавливаться со временем, если средняя нагрузка на диск снизилась.

Не так давно мы уже писали о технологии виртуальных томов vVOL, представленной на VMworld 2012, которая позволит дисковым массивам и хостам оперировать с отдельными виртуальными машинами на уровне логического дискового устройства, реализующего их хранилище, что повысит производительность и эффективность операций с ВМ.

Там же, на VMworld 2012, компания VMware представила технологию vSAN, реализующую распределенное хранение данных ВМ на локальных хранилищах хост-серверов VMware ESXi (Distributed Storage):

Концепция vSAN, включающая в себя Distributed Storage, является продолжением существующего подхода к организации общих хранилищ виртуальных машин на базе локальных дисков серверов - VMware vStorage Appliance. Работает это средство обеспечения отказоустойчивости хранилищ за счет полного дублирования хранилищ одного из узлов кластера, а также репликации данных между ними:

Теперь же, в скором времени в гипервизор VMware ESXi будет включена технология Distributed Storage, которая позволит агрегировать вручную или автоматически дисковые емкости (HDD и SSD) хост-серверов в единый пул хранения с функциями отказоустойчивости и кэширования:

Разрабатывается эта концепция на волне распространения SSD-накопителей в серверном оборудовании и СХД. Единый пул хранения кластера Distributed Storage будет не только объединять диски серверов (туда добавляются диски без созданных разделов с определенным администратором вкладом емкости в общий пул) и предоставлять пространство хранения виртуальным машинам на любом из хостов, но и будет управляем средствами политик механизма Policy-Based Storage Management. Интересно то, что размер кластера хранилища для Distributed Storage будет равен размеру кластера хостов (сейчас 32), в рамках которого все хосты имеют возможность использовать агрегированную емкость пула, даже те серверы, что не имеют дисков вовсе.

Все это будет интегрировано с механизмами HA, vMotion и DRS в целях обеспечения отказоустойчивости и балансировки нагрузки на хост-серверы. Кроме этого, агрегированный пул хранилищ будет поддерживать все основные технологии VMware для работы с хранилищами: снапшоты ВМ, связанные клоны, vSphere Replication (vR) и vStorage APIs for Data Protection (vADP).

С точки зрения политик хранения, Distributed Storage будет предоставлять следующие варианты для каждой виртуальной машины:

• Доступная емкость и объем ее резервирования.
• Уровень отказоустойчивости (степень дублирования данных на узлах = количество реплик).
• Уровень производительности (какое количество SSD-кэша выделить для обслуживания реплик, а также число страйпов для диска ВМ, если необходимо).

Данные в кластере VMware Distributed Storage хранятся на локальных дисках узлов по схеме RAID-1, так как это дает максимальный экономический эффект с точки зрения затрат на 1 IOPS при условии комбинирования HDD-хранилищ данных и SSD-хранилищ кэша и данных (подробнее тут). SSD-кэш работает как фронтэнд для HDD-дисков, обрабатывая кэширование чтений и буферизацию записи для операций кластера, при этом сделано множество оптимизаций кэша для увеличения вероятности попаданий в кэш при чтении данных ВМ с дисков различных узлов.

Ну а на практике vSAN уже работает в лабораториях VMware, где инженеры демонстрируют возможности Distributed Storage:

Информации о времени доступности технологии VMware Distributed Storage пока нет. Возможно, базовые функции vSAN будут реализованы в VMware vSphere 6.0.