На днях компания VMware выпустила документ "Performance of VMware vCenter Server 6.7 in Remote Offices and Branch Offices", в котором рассказывается о производительности сервера vCenter в инфраструктуре небольших офисов и филиалов, где развернуто всего несколько хостов VMware ESXi.

Инфраструктура remote offices and branch offices (ROBO), как правило, удалена от основного датацентра компании, что вызывает влияние на сетевые характеристики, такие как полоса пропускания, задержки в сети и ошибки в доставке пакетов. На эту тему в документе есть интересная табличка:

Авторы документа отмечают, что больше всего на производительность операций vCenter влияет не полоса пропускания, а latency между сервером vCenter (который может быть в головном офисе) и хостами ESXi (которые могут быть на удаленной площадке). В случае больших задержек для прохождения команд от vCenter, время выполнения операций с виртуальными машинами также возрастает:

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

На сайте проекта VMware Labs за последние дни появилась пара интересных обновлений полезных утилит. Первое - это апдейт средства vSAN Performance Monitor 1.2, предназначенного для мониторинга и визуализации (в Grafana) метрик в среде отказоустойчивых кластеров VMware vSAN.

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

В версии vSAN Performance Monitor 1.2 появились следующие улучшения:

• Исправлена проблема с настройкой CA-сертификатов
• Некоторые доработки агента, собирающиего данные
• Убран анонимный сбор статистики от influxdb

Скачать vSAN Performance Monitor 1.2 можно по этой ссылке.

Второе существенное обновление в Labs - это апдейт утилиты vRealize Operations REST Notifications Helper 1.3. О прошлой версии 1.2 этого средства мы писали вот тут. Напомним, что эта штука позволяет администратору vROPs изменять свойства алерта перед его отправкой на сторону.

В данном обновлении появились следующие новые функции:

• Добавлена конфигурация предпочитаемого HTTP-запроса
• Добавлена конфигурация маппинга критичности алерта
• Добавлены черные списки с полем resourceName
• Добавлена настройка структуры конечного устройства (endpoint) для обработки разного поведения на базе состояний сработавшего/несработавшего триггера
• Добавлено описание симптомов в одну строку как и для рекомендаций.
• Различные исправления ошибок

Обновленный vRealize Operations REST Notifications Helper 1.3 можно скачать по этой ссылке.

На блогах 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 было сделано множество программных оптимизаций производительности, особенно в плане компрессии и дедупликации данных. Всегда имеет смысл быть в курсе, что нового появилось в апдейте и накатывать его своевременно.

На портале VMware Labs очередное обновление - вышла новая версия полезной утилиты VMware OS Optimization Tool, которая позволяет подготовить гостевые ОС к развертыванию и проводить тюнинг реестра в целях оптимизации производительности, а также отключение ненужных сервисов и запланированных задач.

Последний раз мы писали про эту утилиту в апреле прошлого года, давайте же посмотрим, что нового появилось в VMware OS Optimization Tool b1110:

• Новая кнопка Common Options - позволяет быстро выбрать и настроить параметры для управления общей функциональностью. Теперь в интерфейсе можно с помощью данного блока выбрать нужный вариант тюнинга, не заглядывая в различные индивидуальные настройки в разных разделах.
• Разделение Windows 10 на 2 шаблона, чтобы лучше обрабатывать различия между этими двумя версиями. Один шаблон для версий 1507-1803, а второй - для 1809-1909.
• Улучшенные оптимизации для Windows 10, особенно для версий 1809 - 1909.
• Исправлены многочисленные ошибки: сброс настроек при сохранении кастомизированных шаблонов, недоступные ссылки на вкладке Reference, недоступность Windows Store после оптимизации и многое другое.

Для новых версий Windows 10 была добавлена следующая функциональность для шаблонов:

• Перемещение элементов между mandatory user и current user к default user.
• Добавлено 34 новых элемента групповых политик, относящихся к OneDrive, Microsoft Edge, приватности, Windows Update, нотификациям и диагностике.
• Добавлено 6 элементов в группу Disable Services.
• Добавлен 1 элемент в группу Disable Scheduled Tasks.
• Добавлен 1 элемент в группу HKEY_USERS\temp настроек реестра.
• Добавлен 2 элемента в группу настроек HKLM.
• Упрощено удаление встроенных приложений Windows (кроме Windows Store).

Скачать VMware OS Optimization Tool b1110 можно по этой ссылке.

Продолжаем рассказывать (пока еще есть что!) о новых продуктах и технологиях, анонсированных на конференции VMworld 2019, которая закончилась уже почти 3 недели назад. Одна из самых интересных и перспективных технологий - это, конечно же, техника VMware Cluster Memory, которая действительно может поменять архитектуру датацентров в будущем.

Об этой технологии хорошо написал Дункан Эппинг. Как известно некоторым из вас, еще 20 лет назад скорость доступа к оперативной памяти серверов была примерно в 1000 раз выше, чем доступ к данным другого хоста по локальной сети. Шли годы, сетевой стек и оборудование улучшались - и в итоге на сегодняшний день доступ по сети всего в 10 раз медленнее, чем локальный доступ к RAM. Достигается это различными способами, в том числе технологией удалённого прямого доступа к памяти (remote direct memory access, RDMA).

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

Поэтому VMware в рамках сессии VMworld "Big Memory with VMware Cluster Memory" рассказала о том, как можно строить кластеры с помощью так называемых "серверов памяти", которые обеспечивают работу хостов ESXi и их виртуальных машин, которым нужно дополнительное пространство памяти по требованию.

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

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

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

Если страницы долгое время остаются невостребованными - они перемещаются обратно на Memory Server. По-сути, эта технология представляет собой оптимизацию механизма паджинации. В то же время, здесь пока существуют следующие проблемы:

• Сбои, связанные с доступом к Cluster Memory
• Безопасность и сохранность данных
• Управление ресурсами в распределенной среде
• Увеличение потребления межсерверного канала
• Управление жизненным циклом страниц
• Производительность механизма в целом

В рамках демо на VMworld 2019 была показана технология Cluster Memory в действии для виртуальной машины, использующей 3 ГБ такой памяти.

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

Обратите внимание, и это здесь четко видно, что Cluster Memory всегда работает быстрее, чем локальный SSD-Swap. Второй важный момент тут, что даже при 70% использовании удаленной памяти виртуальная машина, с точки зрения производительности, чувствует себя вполне хорошо.

Понятно, что технология VMware Cluster Memory еще дело будущего, но пока вы можете посмотреть интересную запись упомянутой сессии на VMworld.

На прошедшей конференции VMworld 2019 было сделано немало интересных анонсов (о самых интересных из них мы рассказываем тут), один из них - это определенно технологическое превью Project Magna (год назад мы рассказывали о начале разработки этого продукта). Это облачное решение VMware, которое предназначено для постоянной непрерывной оптимизации инфраструктуры отказоустойчивых хранилищ VMware vSAN.

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

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

В качестве ML-алгоритма используется так называемый Reinforcement Learning, который анализирует заданные вами KPI по производительности и сравнивает их с аналогичными конфигурациями для похожих нагрузок. Этот алгоритм постоянно проверяет тысячи различных сценариев конфигурации, чтобы найти оптимальный именно для вашей инфраструктуры. Само испытание производится методом проб и ошибок:

Также продукт vRealize Operations можно будет интегрировать с Project Magna таким образом, чтобы первый мог получить от последнего нужные конфигурации, а пользователь может поставить настройку селф-тюнинга, которая будет следовать заданной вами цели.

Цели (KPI) могу быть заданы в виде следующих вариантов:

• Read Performance - все настраивается для наименьших задержек на чтение (latency), увеличения пропускной способности (максимум для этого будет использоваться до 10% памяти хоста).
• Write Performance - конфигурация стремится уменьшить задержки и увеличить производительность на запись (пренебрегая скоростью чтения).
• Balanced - оптимизация сбалансированного режима чтения-записи, в зависимости от требований рабочей нагрузки.

Также полученные целевые KPI можно будет сравнить со средними по отрасли (эти данные будут агрегироваться от клиентов VMware). Для глубокого понимания происходящего в консоли Magna будет доступен график производительности, который в ключевых точках будет показывать, какие изменения были сделаны:

Например, на этом скриншоте мы видим, что Magna увеличила размер кэша на чтение до 50 ГБ 23 июля - и это благотворно повлияло на performance index.

Больше о решении Project Magna можно узнать из следующих сессий VMworld 2019:

• HCI1620BU – Artificial Intelligence and Machine Learning for Hyperconverged Infrastructure
• MLA2021BU – Realize your Self-Aware Hybrid Cloud with Machine Learning
• HCI1650BU – Optimize vSAN performance using vRealize Operations and Reinforcement Learning

Доступность Project Magna ожидается в следующем году.

Год назад компания StarWind Software анонсировала собственный таргет и инициатор NVMe-oF для Hyper-V, с помощью которых можно организовать высокопроизводительный доступ к хранилищам на базе дисков NVMe (подключенных через шину PCI Express) из виртуальных машин. За прошедший год StarWind достаточно сильно улучшила и оптимизировала этот продукт и представила публично результаты его тестирования.

Для проведения теста в StarWind собрали стенд из 12 программно-апаратных модулей (Hyperconverged Appliances, HCA) на базе оборудования Intel, Mellanox и SuperMicro, составляющий высокопроизводительный вычислительный кластер и кластер хранилищ, где подсистема хранения реализована с помощью продукта Virtual SAN, а доступ к дискам происходит средствами инициатора NVMe-oF от StarWind. Между хостами был настроен 100 Гбит Ethernet, а диски SSD были на базе технологии NVMe (P4800X). Более подробно о конфигурации и сценарии тестирования с технологией NVMe-oF написано тут.

Аппаратная спецификация кластера выглядела так:

• Platform: Supermicro SuperServer 2029UZ-TR4+
• CPU: 2x Intel® Xeon® Platinum 8268 Processor 2.90 GHz. Intel® Turbo Boost ON, Intel® Hyper-Threading ON
• RAM: 96GB
• Boot Storage: 2x Intel® SSD D3-S4510 Series (240GB, M.2 80mm SATA 6Gb/s, 3D2, TLC)
• Storage Capacity: 2x Intel® Optane™ SSD DC P4800X Series (375GB, 1/2 Height PCIe x4, 3D XPoint™). The latest available firmware installed.
• RAW capacity: 9TB 
• Usable capacity: 8.38TB 
• Working set capacity: 4.08TB 
• Networking: 2x Mellanox ConnectX-5 MCX516A-CCAT 100GbE Dual-Port NIC
• Switch: 2x Mellanox SN2700 32 Spectrum ports 100GbE Ethernet Switch

Схема соединений тестового стенда:

Для оптимизации потока ввода-вывода и балансировки с точки зрения CPU использовался StarWind iSCSI Accelerator, для уменьшения latency применялся StarWind Loopback Accelerator (часть решения Virtual SAN), для синхронизации данных и метаданных - StarWind iSER initiator.

Как итог, ввод-вывод оптимизировался такими технологиями, как RDMA, DMA in loopback и TCP Acceleration.

С точки зрения размещения узлов NUMA было также сделано немало оптимизаций (кликните для увеличения):

Более подробно о механике самого теста, а также программных и аппаратных компонентах и технологиях, рассказано здесь. Сначала тест проводился на чистом HCA-кластере без кэширования.

Результаты для 4К Random reads были такими - 6,709,997 IOPS при теоретически достижимом значении 13,200,000 IOPS (подробнее вот в этом видео).

Далее результаты по IOPS были следующими:

• 90% random reads и 10% writes = 5,139,741 IOPS
• 70% random reads и 30% writes = 3,434,870 IOPS

Полная табличка выглядит так:

Потом на каждом хосте Hyper-V установили еще по 2 диска Optane NVMe SSD и запустили 100% random reads, что дало еще большую пропускную способность - 108.38 GBps (это 96% от теоретической в 112.5 GBps.

Для 100% sequential 2M block writes получили 100.29 GBps.

Полные результаты с учетом добавления двух дисков:

А потом на этой же конфигурации включили Write-Back cache на уровне дисков Intel Optane NVMe SSD для каждой из ВМ и для 100% reads получили 26,834,060 IOPS.

Полная таблица результатов со включенным кэшированием выглядит так:

Да-да, 26.8 миллионов IOPS в кластере из 12 хостов - это уже реальность (10 лет назад выжимали что-то около 1-2 миллионов в подобных тестах). Это, кстати, 101.5% от теоретического максимального значения в 26.4М IOPS (12 хостов, в каждом из которых 4 диска по 550 тысяч IOPS).

Для тестов, когда хранилища были презентованы посредством технологии NVMe-oF (Linux SPDK NVMe-oF Target + StarWind NVMe-oF Initiator), было получено значение 22,239,158 IOPS для 100% reads (что составляет 84% от теоретически расчетной производительности 26,400,000 IOPS). Более подробно об этом тестировании рассказано в отдельной статье.

Полные результаты этого теста:

Все остальное можно посмотреть на этой странице компании StarWind, которая ведет учет результатов. Зал славы сейчас выглядит так :)

Недавно на сайте проекта VMware Labs обновилась одна из самых полезных утилит для администраторов хранилищ VMware vSphere – IOBlazer. Она позволяет сгенерировать нагрузку на хранилища с любых платформ - Linux, Windows и Mac OS, при этом администратор может задавать паттерн нагрузки с высокой степенью кастомизации, что очень важно для реального тестирования подсистемы хранения для виртуальных машин.

На сайте проекта VMware Labs появилась очередная интересная утилита - виртуальный модуль vSAN Performance Monitor, предназначенный для мониторинга метрик в среде отказоустойчивых кластеров VMware vSAN и их визуализации.

С помощью vSAN Performance Monitor администратор может на регулярной основе собирать метрики производительности в кластерах vSAN, которые потом визуализуются на уже преднастроенных дэшбордах, встроенных в продукт.

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

Напомним, что 5 лет назад была выпущена похожая утилита - vSAN Observer, ну а создатели vSAN Performance Monitor открыто пишут, что при разработке вдохновлялись именно ей.

Само средство поставляется в виде виртуального модуля (Virtual Appliance), который реализует 3 основных компонента:

• Коллектор Telegraf - это агент, который собирает метрики в кластере и сохраняет их в базе данных InfluxDB.
• InfluxDB - собственно, сама база данных, хранящая метрики.
• Grafana - это фреймворк, который используется для визуализации метрик из базы.

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

В качестве платформы и целевой машины для vSAN Performance Monitor поддерживаются vSphere 6.0 и VM hardware 11  (или более поздние). Для работы утилиты вам потребуется включить службу Virtual SAN Performance Service (о том, как это сделать, написано вот тут).

Скачать vSAN Performance Monitor можно по этой ссылке.

Многие из администраторов VMware vSphere знают про механизм Storage I/O Control (SIOC) в платформе VMware vSphere (см. также наш пост здесь). Он позволяет приоритезировать ввод-вывод для виртуальных машин в рамках хоста, а также обмен данными хостов ESXi с хранилищами, к которым они подключены.

Сегодня мы поговорим о SIOC версии 2 и о том, как он взаимодействует с политиками Storage Policy Based Management (SPBM). Начать надо с того, что SIOC v2 полностью основан на политиках SPBM, а точнее является их частью. Он позволяет контролировать поток ввода-вывода на уровне виртуальных машин.

SIOC первой версии работает только с томами VMFS и NFS, тома VVol и RDM пока не поддерживаются. Он доступен только на уровне датасторов для регулирования потребления его ресурсов со стороны ВМ, настраиваемого на базе шар (shares). Там можно настроить SIOC на базе ограничения от пиковой пропускной способности (throughput) или заданного значения задержки (latency):

На базе выделенных shares виртуальным машинам, механизм SIOC распределит пропускную способность конкретного хранилища между ними. Их можно изменять в любой момент, перераспределяя ресурсы, а также выставлять нужные лимиты по IOPS:

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

Если же мы посмотрим на SIOC v2, который появился в VMware vSphere 6.5 в дополнение к первой версии, то увидим, что теперь это часть SPBM, и выделение ресурсов работает на уровне виртуальных машин, а не датасторов. SIOC v2 использует механизм vSphere APIs for I/O Filtering (VAIO), который получает прямой доступ к потоку ввода-вывода конкретной ВМ, вне зависимости от того, на каком хранилище она находится.

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

Поэтому важно понимать, что SIOC v1 и SIOC v2 можно использовать одновременно, так как они касаются разных аспектов обработки потока ввода-вывода от виртуальных машин к хранилищам и обратно.

SIOC v2 включается в разделе политик SPBM, в секции Host-based rules:

На вкладке Storage I/O Control можно выбрать предопределенный шаблон выделения ресурсов I/O, либо кастомно задать его:

Для выбранной политики можно установить кастомные значения limit, reservation и shares. Если говорить о предопределенных шаблонах, то вот так они выглядят для варианта Low:

Так для Normal:

А так для High:

Если выберите вариант Custom, то дефолтно там будут такие значения:

Лимит можно задать, например, для тестовых машин, где ведется разработка, резервирование - когда вы точно знаете, какое минимальное число IOPS нужно приложению для работы, а shares можете регулировать долями от 1000. Например, если у вас 5 машин, то вы можете распределить shares как 300, 200, 100, 100 и 100. Это значит, что первая машина будет выжимать в три раза больше IOPS, чем последняя.

Еще один плюс такого назначения параметров SIOC на уровне ВМ - это возможность определить политики для отдельных дисков VMDK, на которых может происходить работа с данными разной степени интенсивности:

После того, как вы настроили политики SIOC v2, вы можете увидеть все текущие назначения в разделе Monitor -> Resource Allocation -> Storage:

Дункан написал полезный пост о том, влияет ли установка лимитов по вводу-выводу в кластере VMware vSAN (I/O Limit) на производительность операций ресинхронизации кластера и перемещение машин между хранилищами Storage vMotion (SVMotion).

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

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

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

Июнь оказался весьма богат на новые релизы на сайте проекта VMware Labs - недавно мы писали про обновление Horizon DaaS Migration Tool 2.1 для миграции облака DaaS, новое средство Flowgate для агрегации метрик, обновления HCIBench и USB Network Native Driver for ESXi.

Но на этом релизы не остановились - на днях VMware выпустила обновленную утилиту IOBlazer, которая позволяет сгенерировать нагрузку на хранилища с любых платформ - Linux, Windows и OSX. Утилита была выпущена еще в 2011 году, но с тех пор не дорабатывалась, а вот на днях мы увидели ее версию 1.01.

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

IOBlazer также может "проигрывать" записанные логи VSCSI, которые были получены за счет использования утилиты vscsiStats. В качестве метрик производительности можно получить пропускную способность в IOPS и в мегабайтах в секунду, а также задержки ввода-вывода (IO latency). Это дает возможность IOBlazer сгенерировать синтетическую нагрузку на диск виртуальной машины, которая соответствует реальной нагрузке, с возможностью ее повторения в любой момент.

IOBlazer вырос из минималистичного эмулятора MS SQL Server, который бы сфокусирован на эмуляции только нагрузки по вводу-выводу. Ранее утилита имела очень ограниченные возможности по генерации нагрузки по модели MS SQL Server IO (Асинхронность, небуфферизованные IO, параметры Gather/Scatter), теперь же все стало существенно лучше. Но 2 ограничения все еще остаются:

1. Выравнивание доступа к памяти по 4 КБ (страница памяти).

2. Выравнивание операций доступа к диску по 512 байт (дисовый сектор).

Утилиту не надо устанавливать - она запускается из дистрибутива. Инструкции можно найти в файле README. Скачать IOBlazer 1.01 можно по этой ссылке. В комплекте также идет исходник на C, который вы можете собрать самостоятельно.

На сайте VMware Labs обновилась утилита HCIBench до версии 2.1.

Напомним, что о версии HCIBench 2.0 мы писали вот тут, а здесь мы рассматривали использование этой утилиты для замеров производительности кластеров VMware vSAN. Напомним, что это средство позволяет провести комплексный тест производительности отказоустойчивых кластеров хранилищ Virtual SAN, а также других конфигураций виртуальной инфраструктуры.

Проект HCIbecnh ("Hyper-converged Infrastructure Benchmark") является оберткой для известного open source теста VDbench, он позволяет организовать автоматизированное тестирование гиперконвергентного кластера (HCI-кластера). Гиперконвергентный кластер - это когда все его вычислительные ресурсы, системы хранения и сети виртуализованы и собраны в единую интегрированную сущность и управляются из одной точки.

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

Что нового появилось в HCIBench 2.1:

• Интерфейс переключили на темную тему.
• Переработанная технология подготовки VMDK, которая теперь работает гораздо быстрее за счет использования рандомизации на дедуплицированных хранилищах.
• Добавлена возможность обновления процесса подготовки VMDK.
• Добавлена проверка портов базы данных Graphite в процесс превалидации.
• Пароли vCenter и хостов ESXi затемняются при сохранении
• Добавлена кнопка удаления гостевой ВМ ("Delete Guest VM").
• Пофикшены проблемы с дисплеями для Grafana.
• Пофикшена проблема с пустыми результатами при отработки модели нагрузки FIO (Flexible I/O).
• Множество мелких исправлений ошибок.

Скачать HCIBench 2.1 можно по этой ссылке. Документация пока доступна только для версии 2.0.

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

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

Основные моменты траблшутинга по такому воркфлоу рассказаны в документе "Troubleshooting vSAN Performance". Самый очевидный симптом проблем - это задержки (Latency) на уровне гостевой ОС (то есть время, затраченное на выполнение транзакции ввода-вывода), которые приводят к медленной работе приложений.

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

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

После того, как администратор выяснил основные признаки проблемы и локализовал ее на уровне приложений, можно приступать к анализу метрик. Алгоритм действий приведен в документе "Troubleshooting vSAN Performance":

Тут рекомендуется делать следующее:

• Шаг 1 - просматриваем метрики в гостевой ОС проблемной ВМ, чтобы убедиться, что проблемы с производительностью хранилища ощущаются на уровне приложений.
• Шаг 2 - просматриваем метрики на уровне кластера vSAN, чтобы в целом понять масштаб проблемы - нет ли других аномалий в кластере. Это позволяет идентифицировать потенциальные "наводки" от других компонентов виртуальной инфраструктуры.
• Шаг 3 - просматриваем метрики на уровне хоста ESXi, чтобы соотнести метрики внутри гостевой ОС и всего хоста в целом с точки зрения latency.
• Шаг 4 - смотрим на хосте метрики дисковой группы, чтобы найти источник повышенной latency.
• Шаг 5 - если не нашли проблему на шаге 4, то смотрим на сеть хоста и метрики VMkernel, чтобы убедиться, что сеть функционирует штатно.

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

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

Вчера мы писали об ограничениях технологии Persistent Memory в vSphere 6.7, которая еще только изучается пользователями виртуальных инфраструктур на предмет эксплуатации в производственной среде. Преимущество такой памяти - это, конечно же, ее быстродействие и энергонезависимость, что позволяет применять ее в высокопроизводительных вычислениях (High Performance Computing, HPC).

Ну а пока все это изучается, сейчас самое время для проведения всякого рода тестирований.

На днях VMware выпустила документ "Persistent Memory Performance in vSphere 6.7 with Intel Optane DC persistent memory", где как раз тестируется память PMEM. Сейчас на рынке представлено всего 2 таких решения:

• NVDIMM-N от компаний DELL EMC и HPE. NVDIMM-N - это такой тип устройств DIMM, который содержит модули DRAM и NANDflash на самом DIMM. Данные перемещаются между двумя этими модулями при запуске или выключении машины, а также во время внезапной потери питания (на этот случай есть батарейки на плате). На текущий момент есть модули 16 GB NVDIMM-Ns.
• Intel Optane DC persistent memory (DCPMM) - эта память не такая быстрая как DRAM и имеет бОльшие задержки, но они измеряются наносекундами. Модули DCPMM изготавливаются под разъем DDR4 и доступны планками по 128, 256 и 512 ГБ. В одной системе может быть до 6 ТБ памяти DCPMM.

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

При тестировании производительности ввода-вывода были сделаны следующие заключения:

• Накладные расходы на поддержку PMEM составляют менее 4%.

• Конфигурация vPMEM-aware (когда приложение знает о vPMEM устройстве) может дать до 3x и более прироста пропускной способности в смешанном потоке чтения-записи в сравнении с традиционными устройствами vNVMe SSD (они использовались в качестве базового уровня).

• Задержки (latency) на уровне приложений для конфигураций vPMEM составили менее 1 микросекунды.

Также тестировалась производительность баз данных Oracle, и там были сделаны такие выводы:

• Улучшение на 28% в производительности приложения (количество транзакций HammerDB в минуту) с vPMEM по сравнению с vNVME SSD.

• Увеличение 1.25x DB reads, 2.24x DB writes и до 16.6x в числе записей в DB log.

• До 66 раз больше уменьшение задержек при выполнении операций в Oracle DB.

В MySQL тоже весьма существенное улучшение производительности:

Для PMEM-aware приложений тоже хорошие результаты:

Ну а остальные детали процесса проведения тестирования производительности устройств PMEM вы найдете в документе VMware.

Компания StarWind Software известна пользователям как производитель лучшего в отрасли программного решения Virtual SAN для создания отказоустойчивых хранилищ на базе хост-серверов виртуализации VMware vSphere и Microsoft Hyper-V. StarWind иногда выпускает бесплатные утилиты для администраторов виртуальных инфраструктур, и сегодня мы поговорим об очередной новинке - StarWind iSCSI Accelerator...

Недавно мы писали об обновлении продукта для комплексного управления и мониторинга виртуальной инфраструктуры VMware vRealize Operations 7.5. Ранее для этого решения был запущен маркетплейс Dashboard Sample Exchange, где пользователи сообщества vROPs могут публиковать собственные полезные дэшборды (их уже почти 130 штук), которые помогают в ежедневных операциях по управлению платформой VMware vSphere.

Совсем недавно VMware запустила еще один маркетплейс - Super Metric Sample Exchange. В инфраструктуре vROPs суперметрики (super metrics) - это те, которые образованы путем каких-либо комбинаций обычных метрик через математическую формулу (например, какой процент CPU виртуальная машина отъедает от всего хоста ESXi). Для редактирования таких метрик используется super metric editor (подробнее тут):

Чтобы начать работу с маркетплейсом, нужно перейти на сайт vRealize и нажать кнопку View Samples:

В качестве фильтра для языка программирования выберите "vRealize Ops Super Metrics":

Еще один способ найти суперметрики - это пойти на https://code.vmware.com/samples и также выбрать там в фильтре "vRealize Ops Super Metrics":

На выходе будут сэмплы кода для суперметрик (пока их совсем немного):

Можно скачать их в формате JSON, после чего импортировать в разделе vRealize Operations > Administration > Configuration > Super Metrics:

Также вы можете добавлять и собственные суперметрики на маркетплейс. Для этого на картинке выше есть пункт "Export Selected Super Metric". Метрика также будет экспортирована в формате JSON. Для ее загрузки на маркетплейс нужно использовать портал VMware {code}, где вам потребуется завести аккаунт.

Там у вас будет кнопка "Add New Sample":

После этого запустится мастер добавления нового сэмпла, где вы можете выбрать ваш JSON:

Далее нужно добавить максимально понятное и подробное описание созданной вами суперметрики:

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

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

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

А зачем вообще проводить тестирование кластера vSAN? Тут, как правило, есть следующие причины:

• Понимание возможностей инфраструктуры хранения и возможность убедиться в том, что в ней нет аномалий.
• Валидировать дизайн кластера vSAN с точки зрения приемо-сдаточных испытаний (User Acceptance Testing, UAT).
• Получить референсные значения, с которыми можно будет сверяться при внесении существенных изменений в архитектуру vSAN.
• Проведение тестов перед внедрением (PoC-проекты).
• Установление базового уровня пользовательских ожиданий после развертывания приложений.

По итогу тестирования производительности хранилищ vSAN вы должны получить ответы на следующие вопросы:

• Какого наибольшего числа операций ввода-вывода в секунду (IOPS) можно добиться?
• Какая ожидаемая задержка выполнения операций (latency) при требуемом числе IOPS для рабочей нагрузки?
• Какая максимальная пропускная способность операций чтения-записи (throughput)?

То есть результаты тестирования держатся на трех китах - IOPS, latency и throughput.

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

IOPS

Число выдаваемых IOPS зависит как от используемого оборудования для хостов и сетевых компонентов, так и от архитектуры системы. Актуальное число IOPS также зависит от уровня RAID в кластере vSAN, числа сетевых соединений между хостами, их загрузки и прочих факторов.

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

Latency

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

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

Throughput

Пропускная способность важна при выполнении больших операций ввода-вывода, а также при различных паттернах чтения записи (последовательный/случайный). Чем больше размер I/O, тем очевидно больше пропускная способность. С точки зрения объема передаваемых данных одна операция I/O размером 256К равна 64 операциям ввода-вывода по 4К, но вот с точки зрения throughput это будут совершенно разные значения, так как займут разное время.

Методология тестирования хорошо описана в документации по HCIBench, а также вот в этой статье на русском языке. Работа с утилитой начинается по ссылке https://<HCIBench IP address>:8443.

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

Очень важно при тестировании также задать правильный профиль рабочей нагрузки (4 варианта на картинке выше).

После выполнения теста Easy Run вы получите выходной файл с результатами вроде vdb-8vmdk-100ws-4k-70rdpct-100randompct-4threads-xxxxxxxxxx-res.txt. Из имени файла можно понять использованную тестовую конфигурацию (она также будет в самом файле):

Block size : 4k
Read/Write (%) : 70/30
Random (%) : 100
OIO (per vmdk) : 4

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

Если открыть один их этих файлов, мы увидим детальные параметры производительности различных компонентов среды vSAN:

Полученные параметры можно считать базовым уровнем для тестирования производительности кластера. Теперь нужно увеличивать параллелизм, то есть число тредов Outstanding I/O (OIO), для выжимки оптимальной производительности. Увеличение этого параметра будет увеличивать число IOPS, а также, как следствие, будет расти Latency. Так вы сможете понять, как инфраструктура хранения ведет себя в динамике, реагируя на изменение профиля нагрузки.

Чтобы изменить параметр OIO, нужно отключить Easy Run и в профиле рабочей нагрузки нажать Add:

Также для измерения пропускной способности вы можете поэкспериментировать с размером операции ввода-вывода. Современные ОС поддерживают размер I/O в диапазоне 32K - 1 MB, но для тестирования лучше использовать I/O в диапазоне 32K – 256K.

Еще какие моменты надо учитывать при тестировании:

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

Некоторое время назад мы писали о новых возможностях недавно вышедшего обновления платформы виртуализации VMware vSphere Platinum 6.7 Update 2. Cреди новых возможностей гипервизора там есть фича "Новые возможности планировщика CPU помогают бороться с уязвимостями типа L1TF".

Оказывается, это довольно серьезное улучшение. Надо сказать, что планировщик гипервизора side-channel aware scheduler (SCA) появился еще в прошлой версии платформы. Он закрывал уязвимость L1TF (L1 Terminal Fault) в процессорах Intel за счет того, что процессы виртуальных машин запускались только в одном треде одного физического ядра. Это позволяло нивелировать вектор атаки данного типа, но приводило к существенному снижению производительности.

Особенно это чувствовалось, когда сервер ESXi был загружен по CPU полностью, и SCA первой версии в этом случае давал до 30% хуже результат, чем без него. Если же сервер был загружен, например, на 75%, то в производительность оставалась примерно той же, но без SCA нагрузка на CPU была существенно ниже.

Обо всем этом подробно описано в документе "Performance of vSphere 6.7 Scheduling Options":

Давайте вкратце посмотрим, о чем там говорится.

Итак, начиная с VMware vSphere 6.7 Update 2, появился обновленный планировщик SCAv2, который был существенно доработан по сравнению со своей предыдущей версией. Он позволяет исполнять контексты vCPU одной машины в разных гипертредах одного физического ядра процессора хоста. В этом случае атаке L1TF не подвержены взаимодействия типа VM/VM и VM/ESXi (чувствительная информация между ними не шарится в общем кэше).

В документе описано 2 типа тестов, которые проводились для планировщиков SCAv1 и SCAv2: работа хоста под максимальной нагрузкой по процессорам и под нагрузкой на уровне 75% от максимальной мощности всех CPU хоста ESXi (reduced load). В качестве базового уровня использовался планировщик без SCA (он же на картинке ниже обозначен как Default):

Если верить графикам, отражающим результаты тестирования различными бенчмарками, то планировщик SCAv2 работает существенно лучше во всех случаях, кроме очень большой (по выделенным ресурсам) виртуальной машины - Monster VM с базой Oracle и 192 vCPU, но такой кейс в реальной жизни случается весьма редко. Так что, в целом, улучшения были проведены весьма существенные (как минимум, на 11% планировщик стал более производительным по результатам тестов).

Помимо документа выше, информация об улучшениях планировщика приведена еще в KB 55806.

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

Архитектура vSAN включает в себя два яруса - кэш (cache tier) и пространство постоянного хранения (capacity tier). Такая структура дает возможность достичь максимальной производительности по вводу-выводу, которая абсолютно необходима в кластере хранилищ на базе хостов.

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

У дисковых групп есть следующие особенности:

• Каждый хост, который дает емкость кластеру vSAN, должен содержать как минимум одну дисковую группу.
• Дисковая группа содержит как минимум одно устройство для кэша и от 1 до 7 устройств хранения.
• Каждый хост ESXi в кластере vSAN может иметь до 5 групп, а каждая группа - до 7 устройств хранения. То есть на хосте может быть до 35 устройств хранения, чего вполне достаточно для подавляющего большинства вариантов использования.
• Неважно, используете ли вы гибридную конфигурацию (SSD и HDD диски) или All-Flash, устройство кэширования должно быть Flash-устройством.
• В гибридной конфигурации устройства кэша на 70% используются как кэш на чтение (read cache) и на 30% как кэш на запись (write buffer).
• В конфигурации All-Flash 100% устройства кэша выделено под write buffer.

Write buffer и capacity tier

В принципе, всем понятно, что гибридная конфигурация хостов ESXi в кластере vSAN более дешевая (HDD стоит меньше SSD), но менее производительная, чем All-Flash. Но когда-то наступит время, и все будет All-Flash (в них, кстати, еще и нет нужды организовывать кэш на чтение, так как все читается с SSD с той же скоростью). Поэтому и выделяется 100% под write buffer.

При этом если операция чтения в All-Flash хосте находит блок в кэше - то он читается именно оттуда, чтобы не искать его в capacity tier. Максимальный размер write buffer на одной дисковой группе хоста ESXi - 600 ГБ. При этом если сам диск более 600 ГБ, то его емкость будет использоваться с пользой (см. комментарий к этой статье).

Для гибридных конфигураций 70% емкости кэша выделяется под кэш на чтение, чтобы быстро получать данные с производительных SSD-устройств, при этом vSAN старается поддерживать коэффициент попадания в кэш на чтение (cache hit rate) на уровне 90%.

Write buffer (он же write-back buffer) подтверждает запись на устройство хранения еще до актуальной записи блоков на сapacity tier. Такой подход дает время и возможность организовать операции записи наиболее эффективно и записать их на сapacity tier уже пачкой и более эффективно. Это дает существенный выигрыш в производительности.

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

Вот сравнительная таблица этих классов (колонка TBW - это terabytes written, то есть перезапись скольких ТБ они переживут):

Помните, что нужно всегда сверяться с VMware Compatibility Guide, когда выбираете устройства PCIe flash, SSD или NVMe.

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

Организация дисковых групп

При планировании хостов ESXi в кластере vSAN можно делать на нем одну или более дисковых групп. Несколько дисковых групп использовать предпочтительнее. Давайте рассмотрим пример:

• Одна дисковая группа с одним кэшем и 6 устройств хранения в ней.
• Две дисковых группы с двумя устройствами кэша, в каждой по 3 устройства хранения.

Если в первом случае ломается SSD-устройство кэша, то в офлайн уходит вся дисковая группа из 6 дисков, а во втором случае поломка одного девайса приведет к выходу из строя только трех дисков.

Надо понимать, что этот кейс не имеет прямого отношения к доступности данных виртуальных машин, которая определяется политикой FTT (Failures to tolerate) - о ней мы подробно рассказывали тут, а также политиками хранилищ SPBM. Между тем, размер домена отказа (failure domain) во втором случае меньше, а значит и создает меньше рисков для функционирования кластера. Также восстановление и ребилд данных на три диска займет в два раза меньше времени, чем на шесть.

Кстати, некоторые думают, что в случае отказа дисковой группы, кластер vSAN будет ждать 60 минут (настройка Object Repair Timer) до начала восстановления данных на другие диски согласно политике FTT (ребилд), но это неверно. Если вы посмотрите наш пост тут, то поймете, что 60 минут vSAN ждет в случае APD (All Paths Down - например, временное выпадение из сети), а вот в случае PDL (Physical Device Loss) восстановление данных на другие дисковые группы начнется немедленно.

С точки зрения производительности, иметь 2 дисковые группы также выгоднее, чем одну, особенно если разнести их по разным контроллерам хранилищ (storage controllers). Ну и это более гибко в обслуживании и размещении данных на физических устройствах (например, замена диска во втором примере пройдет быстрее).

Работа операций ввода-вывода (I/O)

Как уже было сказано, в гибридной конфигурации есть кэши на чтение и на запись, а в All-Flash - только на запись:

При этом хост ESXi работает так, чтобы операции чтения с дисков попадали в кэш на чтение в 90% случаев. Остальные 10% операций чтения затрагивают HDD-диски и вытаскивают блоки с них. Но и тут применяются оптимизации - например, одновременно с вытаскиванием запрошенного блока, vSAN подтягивает в кэш еще 1 МБ данных вокруг него, чтобы последовательное чтение проходило быстрее.

Для All-Flash конфигурации кэш на чтение не нужен - все данные вытаскиваются с примерно одинаковой скоростью, зато все 100% кэша используются под write buffer, что дает преимущество в скорости обработки большого входящего потока операций ввода-вывода.

Ну и напоследок отметим, что vSAN при записи на флэш-диски распределяет операции записи равномерно между ячейками независимо от размера диска. Это позволяет диску изнашиваться равномерно и иметь бОльшую наработку на отказ.

Недавно мы писали о нативной поддержке Microsoft SQL Server в кластерах хранилищ VMware vSAN, а сегодня раскроем эту тему еще несколько глубже. Недавно VMware опубликовала полезный материал, содержащий основные рекомендации по исполнению нагрузок SQL Server в кластерах хранилищ VMware vSAN.

Надо понимать, что важно не только настроить серверы SQL, но и саму среду vSAN, в зависимости от характера ваших нагрузок (какие-то базы данных требуют высокой производительности, какие-то большой дисковой емкости и т.п.).

Давайте посмотрим, что это за базовые рекомендации:

1. Общие рекомендации.

• Включайте дополнительный хост ESXi к результатам сайзинга по схеме n+1 на случай отказа диска, дисковой группы или всего хоста в целом.
• Имейте хороший запас по пропускной способности сети для трафика vSAN, рекомендуется использовать 10G сеть с выделенной полосой для трафика синхронизации. Для All-Flash vSAN это обязательное требование. И не забывайте о резервировании каналов.
• Имейте как минимум 2 дисковых группы на хост - это может увеличить полосу пропускания во многих случаях, а также обеспечивает лучшую отказоустойчивость.
• Службы vSAN на уровне кластера:
  • vSAN Performance service (включен по умолчанию в vSAN 6.7) предоставляет метрики производительности в сторонние системы, такие как vRealize Operations, что позволяет эффективно мониторить и решать проблемы.
  • Вы можете использовать шифрование data at rest (FIPS 140-2 compliant), это не влияет на производительность по IOPS, но дает нагрузку на CPU, поэтому лучше использовать процессоры с поддержкой возможности AES-NI. Для end-to-end шифрования используйте туннели IPSEC. Если нужно зашифровать только отдельную БД, используйте SQL Server native encryption.
  • vSAN 6.7 поддерживает SCSI-3 persistent reservations для общих дисков при использовании SQL Server FCI. Для этого на уровне кластера надо включить службу vSAN iSCSI Target.

Настройте политики SPBM для данных SQL Server:

• Политика Failures to tolerate (FTT): убедитесь, что выставлено как минимум значение 1, не используйте опцию "No data redundancy".
• Политика Number of disk stripes per object: используйте значение по умолчанию (1) и подумайте о разделении данных между разными дисками VMDK, привязанными к разным контроллерам vSCSI.
• Политика IOPS limit per object: vSAN 6.2 и более поздние версии имеют возможности QoS, которые могут ограничить IOPS, потребляемые дисковым объектам. Не используйте эту политику для задач, требовательных к нагрузкам. Эта фича используется, как правило, для операций резервного копирования и восстановления, чтобы предотвратить забитие полосы пропускания этими задачами.

2. Рекомендации для нагрузок Tier-1 (высоконагруженные OLTP-базы).

Как правило, такие нагрузки по вводу-выводу включают запросы с множественным позиционированием точек записи в базе данных, активность по сбросу грязных страниц кэша на диск, а также запись транзакционного лога. Размер операции ввода-вывода небольшой - в диапазоне 8K - 64K. Можно использовать бенчмарки TPC-E для воспроизведения паттернов OLTP-подобных нагрузок.

• Рассмотрите возможность использования All-flash vSAN.
• Используйте как минимум диски SAS SSD (а не SATA SSD) - у них больше глубина очереди. Также подумайте о технологии NVMe.
• Отключайте дедупликацию и компрессию данных, которые включены в vSAN по умолчанию. Лучше использовать компрессию таблиц на уровне базы данных.
• Для object space reservation установите "Thick provisioning" для всех VMDK с данными SQL Server и логами. Это позволит не натолкнуться на проблему нехватки места при использовании тонких дисков. Также в опциях SQL Server лучше установить настройку Perform maintenance tasks, чтобы инициализировать файлы с данными сразу же. Также выделите сразу место под лог БД, чтобы не натолкнуться на недостаток места в гостевой ОС, либо установите настройку его роста в ГБ, а не в процентах.
• Не используйте IOPS limit for object.
• Используйте RAID-1 mirroring и как минимум FTT=1 для для VMDK-дисков с данными и логом.
• Если вы используете дополнительные методы отказоустойчивости, такие как Always On Availability Groups, то вам может потребоваться увеличить FTT. Делайте это не только с точки зрения доступности, но и с точки зрения производительности. Вы можете комбинировать отказоустойчивость Availability Groups на уровне приложения с отказоустойчивостью на уровне дисковой подсистемы.
• Если вам требуется доступность SQL между площадками, можно использовать архитектуру растянутых кластеров (vSAN Stretched Cluster).
• Подумайте о коммутаторах для трафика vSAN. Оптимально использовать кластеры all-NVMe vSAN, тогда операции ввода вывода будут быстро передаваться между дисковыми устройствами без участия физических контроллеров. Также лучше использовать 10G-коммутаторы Enterprise-уровня с большими размерами буфера (non-shared), чтобы обеспечить работу с плотным потоком ввода-вывода.

2. Рекомендации для нагрузок Tier-2 (высоконагруженные OLTP-базы).

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

Для гибридной среды vSAN (микс HDD+SSD) рекомендуется следующее:

• Используйте несколько дисковых групп для увеличения пропускной способности.
• Имейте как минимум 10% от емкости данных для пространства кэширования на SSD. Также рекомендуется использовать объем SSD-емкости как минимум в два раза больший, чем рабочий набор данных (working data set).
• Используйте, по возможности, устройства SAS SSD вместо SATA SSD.

Если вы используете конфигурацию All-flash vSAN, то:

• Используйте дедупликацию и компрессию, если у приложений нет высоких требований по операциям записи.
• Если хотите экономить место и не требуется большой производительности, то используйте конфигурацию RAID 5/6 erasure coding, но для транзакционных логов используйте VMDK-диски, размещенные на RAID 1.
• Для object space reservation установите "Thick provisioning" для всех VMDK с данными SQL Server и логами.

3. Нагрузки типа Data Warehouse и серверов отчетов (Reporting).

Для таких нагрузок характерен большой размер операции ввода-вывода, так как происходит запрос большого объема данных из БД. Критичной метрикой здесь является не IOPS, а пропускная способность (MB/s). Для генерации таких нагрузок могут быть использованы бенчмарки TPC-H.

Тут приводятся следующие рекомендации:

• Для конфигураций All-flash лучше использовать NVMe SSD для хранилищ данных, это даст хорошую производительность по большим операциям чтения.
• Для конфигураций All-flash в целях экономии места используйте RAID 5/6 для VMDK с данными БД.
• Преаллоцируйте пространство для логов SQL Server, чтобы не натолкнуться на проблему нехватки места.
• Не используйте IOPS limit for object, это может ограничить полосу пропускания.
• Лучше использовать 10G-коммутаторы Enterprise-уровня с большими размерами буфера (non-shared), чтобы обеспечить работу с плотным потоком ввода-вывода и выдать хорошую пропускную способность.

Мы часто писали о решении VMware vRealize Network Insight (vRNI), которое позволяет системным и сетевым администраторам, а также администраторам информационной безопасности, смотреть за сетевым взаимодействием в рамках виртуальной инфраструктуры и предпринимать действия по ее защите.

Также с помощью vRNI можно найти 3 типа отклонений для виртуальных машин, работающих непрерывно в виртуальной инфраструктуре:

• Outliers - девианты по трафику в рамках группы ВМ по сравнению с остальными членами группы.
• Thresholds - машины, которые превысили пороговые значения по трафику или сбросу пакетов.
• Top Talkers - самые потребляющие сетевые ресурсы машины в каком-то аспекте мониторинга.

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

Если один из серверов начинает существенно отклоняться (например, отдавать трафика намного больше чем остальные), то это может говорить либо об ошибке в конфигурации балансировщика, либо о каких-то проблемах на этом веб-сервере. Также к таким сервисам можно отнести серверы DNS, Active Directory, кластеры серверов SQL и другие масштабируемые сервисы.

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

Здесь мы видим, что виртуальная машина cmbu-sc2dc-01 на порту 53 имеет большой поток трафика, гораздо больше, чем остальные, поэтому и попала в категорию "Outliers" на панели справа.

Для мониторинга такого поведения вы можете выбрать один или несколько портов, а также направление трафика (входящий/исходящий), так как есть сервисы, которые в основном принимают данные (например, обработчики), а есть, которые преимущественно отдают (веб-серверы, DNS и т.п.).

Чтобы создать группу Outliers для мониторинга, нужно в консоли vRNI пойти в меню Analytics и там открыть раздел Outliers:

Далее вы увидите список всех настроенных групп Outliers. Там вы увидите, сколько девиантов в каждой группе было обнаружено, какие связанные с ними события произошли, а также информацию о группе (сколько ВМ, их IP и т.п.), также вы увидите, когда были обнаружены эти отклонения.

Для создания новой группы, в правом верхнем углу надо нажать ADD и установить все необходимые настройки:

Здесь они означают следующее:

1. Имя группы.
2. Масштаб наблюдения (application tier, NSX Security tag и т.п.).
3. Для уровня приложения (application tier) нужно выбрать само приложение и его ярус (tier).
4. Метрика - total traffic (MB, GB и т.п.), число пакетов или сессий, либо объем трафика в секунду.
5. Направление обнаруживаемого трафика (incoming, outgoing, both).
6. Направление трафика в датацентре: north-south (интернет-трафик), east-west (внутренний трафик датацентра), либо оба направления.
7. Порты назначения - можно мониторить все используемые порты, либо выбранные. Но пока есть лимит 20 портов, если он будет превышен, то их надо будет вводить вручную.
8. Чувствительность алгоритма обнаружения (low, medium, high).
9. Когда все установлено, vRNI сгенерирует превьюшку результатов на графике, включающем в себя настроенные сетевые потоки.

Если превью вас устроило, то просто нажимаете Submit и добавляете новую группу в систему мониторинга.

Как только обнаруживается Outlier, для него создается открытое событие (Event), оно продолжает висеть в открытых, пока отклонение продолжает существовать. Как только все возвращается в норму, событие закрывается, однако остается в архиве, чтобы администратор знал о происходящем.

В общем, vRNI, хотя бы только с этой стороны - полезная штука!

Источник.

Политика ограничения виртуальных машин по операциям ввода-вывода (IOPS limits storage policy rule) позволяет ограничить виртуальную машину в кластере VMware vSAN в плане потребления ресурсов хранилища. Она применяется для VMDK дисков машин и, как правило, используется в ситуациях, когда нужно изолировать "прожорливого соседа" - то есть виртуальную машину, которая может начать потреблять несоразмерно много ресурсов хранилища по вводу-выводу на хосте ESXi, вызывая большие задержки (latency) у других машин этого хоста. При этом такая машина на данном хосте может быть далеко не самой важной.

Ограничение машины по IOPS имеет некоторые особенности. Размер операции ввода-вывода может варьироваться в диапазоне от 4 КБ до 1 МБ. Это означает, что самая большая операция может быть в 256 больше по объему самой маленькой. Поэтому при применении ограничения по IOPS решение vSAN использует так называемые "взвешенные IOPS", определяемые квантами по 32 КБ (об этом мы писали вот тут). При размере операции до 32 КБ планировщик vSAN считает ее как одну операцию, 32-64 КБ - как две, и так далее.

Это позволяет при визуализации метрик производительности нормализовать поток данных к хранилищу и управлять им при импорте настроек из механизма SIOC, который применяется к виртуальным машинам не в кластере vSAN. Надо отметить, что vSAN имеет собственную механику регуляции I/O и собственный планировщик, поэтому механизм SIOC не применяется к таким хранилищам.

Соответственно, давайте взглянем на графики операций ввода-вывода на вкладке Monitor->vSAN->Performance:

На нижнем графике (Virtual SCSI IOPS) мы видим число реальных операций ввода-вывода, независимо от их размера, а на верхнем - уже нормализованные IOPS и лимиты, применяемые к ВМ.

IOPS limit применяется только ко всему потоку ввода-вывода гостевой ОС машины (то есть ярус хранения, ярус кэширования), но не затрагивает операции с самим диском VMDK и его swap-файлами, например, репликация машины, SVmotion (миграция хранилища), XVmotion (миграция машин без общего хранилища) и клонирование ВМ.

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

Здесь мы видим, что при достижении лимита 200 IOPS latency возросла до 580 мс, а при достижении 400 мс - где-то до 230-290 мс. Эти задержки, возникающие на уровне виртуальной машины, проявляют себя также и на уровне всего хоста, кластера и даже приложений, таких как vRealize Operations.

Этот важный фактор надо учитывать, когда вы ищете причину высокой latency, потому что механизм vSAN Performance Service не делает различий, возникли ли задержки из-за проблем с производительностью, или они являются результатом применения IOPS limits.

Интересно также, что применение IOPS limits storage policy rule к одной виртуальной машине может повлиять и на другую ВМ, к которой не применяется этого правила. Например, вы копируете файлы одной ВМ на вторую (и обратно), у которой есть IOPS limit. При достижении этого лимита, очевидно, происходит уменьшение числа IOPS не только у целевой ВМ, но и у источника, так как происходит уменьшение совокупного числа операций ввода-вывода на передачу файлов.

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

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

Компания StarWind Software, известная своим лидирующим решением Virtual SAN для создания отказоустойчивых хранилищ для виртуальных машин VMware vSphere и Microsoft Hyper-V, продолжает выпускать полезные бесплатные утилиты. Например, напомним, что ранее мы писали о StarWind Deduplication Analyzer.

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

Для тестирования RDMA-соединений есть различные утилиты, но они разработаны для различных операционных систем, и их трудно сопрягать между собой. Также они показывают либо задержки (latency), либо пропускную способность (bandwidth), а rPerf выводит обе этих метрики. Ну и, конечно же, ее можно использовать для Windows и Linux одновременно.

Давайте посмотрим, как это работает. Для тестирования вам понадобятся системы Windows 7 / Windows Server 2012 или более поздние, а если вы хотите использовать Linux - то CentOS 7 или Ubuntu.

Сетевой адаптер (NIC) должен иметь настроенные механизмы Network Direct Provider v1 и lossless RDMA. Для адаптеров нужны последние версии драйверов, так как стандартный драйвер Windows не поддерживает ND API. Для систем Linux нужны драйвера с поддержкой RDMA и RoCE.

1. Скачиваем утилиту StarWind rPerf по ссылке:

https://www.starwindsoftware.com/starwind-rperf#download

Далее на Linux системе выполняем chmod +x rperf.

2. Выполняем следующую команду для выставления хоста Windows Server в качестве сервера (полный список команд и флагов утилиты приведен вот тут):

nd_rperf.exe -s -a 10.1.2.11

3. Выполняем такую команду для запуска теста производительности соединения из системы Linux (со стороны клиента):

./rperf -c -a 10.1.2.11 -C 100000 -S 4096 -q 16 -o W

Эта команда сгенерирует 100 тысяч операций записи с размером буфера 4096 и глубиной очереди (queue depth) размером 16:

В результатах вывода мы увидим значения throughput и latency (см. скриншот). Также можно сделать и Linux сервером:

./rperf -s -a 10.1.2.12

а Windows - клиентом:

nd_rperf.exe -c -a 10.1.2.12 -C 10000 -S 4096 -q 16 -o R

Скачать утилиту StarWind rPerf можно по этой ссылке.

Весной 2018 года Selectel запустил услугу резервного копирования для Облака на базе VMware посредством Veeam® Backup&Replication™ (далее VBR). К реализации проекта мы подошли основательно, спланировали и выполнили следующий перечень работ:

• Изучение документации и лучших практик по продуктам Veeam
• Разработку архитектуры VBR уровня сервис-провайдера
• Развертывание инфраструктуры VBR

Еще 8 лет назад мы писали о кэшировании в решении StarWind Virtual SAN, которое является лучшим на сегодняшний день программным средством создания отказоустойчивых хранилищ для виртуальных машин. У кэширования на запись write-back есть недостаток - возможность потери данных в случае отключения электропитания. Поэтому сегодня мы расскажем о том, что такое новый Log-structured Write Cache (LWC), и для чего он нужен...

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

Но долго ждать тоже не стоит, так как можно недополучить преимущества новых версий. Например, всегда от релиза к релизу у платформы vSphere растет производительность в различных аспектах. В частности, давайте посмотрим, как выросла производительность технологии миграции хранилищ Storage DRS в VMware vSphere 6.7 по сравнению с версией 6.5.

VMware провела тестирование двух версий платформы и посмотрела, как быстро происходит генерация рекомендаций DRS в разрезе следующих операций в кластере:

• CreateVM
• CloneVM
• ReconfigureVM (добавление дополнительного диска)
• RelocateVM (перемещение на другой датастор)
• Datastore Enter Maintenance (перевод датастора в режим обслуживания)

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

Для 16 одновременных операций:

Отдельно представлен график для операций Datastore Enter Maintenance:

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

Несколько недель назад компания Login VSI, известная своими бенчмарками для виртуальных сред, выпустила обновленную версию своего средства для генерации и тестирования нагрузки приложений в виртуальных ПК - Login PI Release 3. Напомним, что о прошлой версии этого продукта мы писали вот тут.

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

Давайте посмотрим, что нового появилось в Login PI Release 3:

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

• Воркфлоу можно создавать с помощью функций автодополнения (intellisense) и подсветки синтаксиса. Их можно редактировать без соединения с бэкендом Login PI, то есть на клиенте без задержек.
• Более гранулярные действия в рабочих процессах и возможность более детального планирования событий, что позволяет точнее настраивать симулированных пользователей и удобнее оркестрировать их поведение.
• Расширенная поддержка сторонних приложений (EPIC, Cerner, AllScripts и т.п.), приложений пользователей (Microsoft Office), а также тесно интегрированных сторонних плагинов, рабочих процессов и скриптов.

2. Новая архитектура Login PI Release 3.

Здесь появились следующие улучшения:

• Теперь поставляется как виртуальный модуль (virtual appliance) и развертывается за несколько минут.
• За счет использования REST API теперь можно интегрировать Login PI с традиционными решениями для мониторинга, такими как SCOM, или системами управления инцидентами, например, ServiceNow, а также big-data анализаторами (например, Splunk).
• Login PI R3 поддерживает соединения через RDP, PCoIP, Blast Extreme, Citrix ICA/HDX, NetScaler и любые другие.
• Повышенная безопасность продукта.

3. Новый интерфейс.

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

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

4. Проактивный мониторинг.

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

Компания 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).

Мы много писали о рещениях NVIDIA GRID / Quadro vDWS  (они используют технологии virtual GPU или vGPU), например здесь, здесь и здесь. Ранее эта технология предполагала только применение vGPU для нагрузок в виртуальных машинах, которые требовательны к графике, поэтому используют ресурсы графического адаптера в разделенном режиме.

Между тем, начиная с недавнего времени (а именно с выпуска архитектуры Pascal GPU), VMware и NVIDIA предлагают использование vGPU для задач машинного обучения (CUDA / Machine Learning / Deep Learning), которые в последнее время становятся все более актуальными, особенно для крупных компаний. С помощью этой технологии виртуальная машина с vGPU на борту может эффективно использовать библиотеки TensorFlow, Keras, Caffe, Theano, Torch и прочие.

Например, можно создать использовать профиль P40-1q vGPU для архитектуры Pascal P40 GPU, что позволит иметь до 24 виртуальных машин на одном физическом адаптере (поскольку на устройстве 24 ГБ видеопамяти).

Зачем же использовать vGPU для ML/DL-задач, ведь при исполнении тяжелой нагрузки (например, тренировка сложной нейронной сети) загружается все устройство? Дело в том, что пользователи не используют на своих машинах 100% времени на исполнение ML/DL-задач. Большинство времени они собирают данные и подготавливают их, а после исполнения задачи интерпретируют результаты и составляют отчеты. Соответственно, лишь часть времени идет большая нагрузка на GPU от одного или нескольких пользователей. В этом случае использование vGPU дает максимальный эффект.

Например, у нас есть 3 виртуальных машины, при этом тяжелая нагрузка у VM1 и VM2 пересекается только 25% времени. Нагрузка VM3 не пересекается с VM1 и VM2 во времени:

Компания VMware проводила тест для такого случая, используя виртуальные машины CentOS с профилями P40-1q vGPU, которые имели 12 vCPU, 60 ГБ памяти и 96 ГБ диска. Там запускались задачи обучения TensorFlow, включая комплексное моделирование для рекуррентной нейронной сети (recurrent neural network, RNN), а также задача распознавания рукописного текста с помощью сверточной нейронной сети (convolution neural network, CNN). Эксперимент проводился на серверах Dell PowerEdge R740 с 18-ядерным процессором Intel Xeon Gold 6140 и карточками NVIDIA Pascal P40 GPU. 

Результаты для первого теста оказались таковы: 

Время обучения из-за наложения окон нагрузки в среднем увеличилось на 16-23%, что в целом приемлемо для пользователей, разделяющих ресурсы на одном сервере. Для второго теста было получено что-то подобное:

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

Несмотря на то, что число загруженных ML/DL-нагрузкой виртуальных машин увеличилось до 24, время тренировки нейронной сети увеличилось лишь в 17 раз, то есть даже в случае полного наложения временных окон рабочих нагрузок есть некоторый позитивный эффект:

Интересны также результаты с изменением политики использования vGPU. Некоторые знают, что у планировщика vGPU есть три режима работы:

• Best Effort (это исполнение задач на вычислительных ядрах по алгоритму round-robin).
• Equal Share (всем дается одинаковое количество времени GPU - это позволяет избежать влияния тяжелых нагрузок на легкие машины, например).
• Fixed Share (планировщик дает фиксированное время GPU на основе профиля нагрузки vGPU).

VMware поэкспериментировала с настройками Best Effort и Equal Share для тех же тестов, и вот что получилось:

С точки зрения времени исполнения задач, настройка Best Effort оказалась лучшим выбором, а вот с точки зрения использования GPU - Equal Sharing меньше грузила графический процессор:

Некоторые остальные детали вы можете почитать в оригинальной статье VMware.