Некоторое время назад мы писали о новых возможностях решения для создания отказоустойчивых хранилищ на базе хост-серверов VMware vSAN 6.7 Update 3. Среди прочего там появилось пара расширенных настроек, на которые обратил внимание Cormac Hogan. Давайте посмотрим, чем управляют эти Advanced Options в кластере.

Чтобы увидеть новые опции, надо в vSphere Client пойти в Cluster > Configure > vSAN > Services > Advanced Options, где можно увидеть параметры Large Cluster Support и Automatic Rebalance:

Первая настройка, как понятно из названия, регулирует возможность создания кластеров, которые имеют более 32 узлов. Ранее, чтобы расширить кластер, нужно было выставить параметр TcpipHeapMax на всех его хост-серверах ESXi. Теперь это удобно сделано в Advanced Options и применяется на уровне всего кластера.

Настройка Large Cluster Support требует перезагрузки каждого из хост-серверов:

Если вы не перезагрузите хосты, что в разделе статуса "vSAN extended configuration in sync" будут отображаться ошибки:

Вторая настройка, Automatic Rebalance, относится к дисковым объектам кластера vSAN, которые распределяются по дисковым группам разных хостов. Если данная настройка включена, то кластер vSAN автоматически наблюдает за балансом распределения дисковых объектов по хостам ESXi и выравнивает нагрузку на дисковые устройства. По умолчанию пороговое значение составляет 30%, что означает, что когда разница нагрузки между двумя дисковыми устройствами достигнет этого значения - начнется перебалансировка и перемещение дисковых объектов. Она будет продолжаться, пока это значение не снизится до 15% или меньшей величины.

Также в разделе vSAN Disk Balance вы найдете информацию по использованию дисковой подсистемы кластера:

В случае, если у вас включена настройка Automatic Rebalance, кластер vSAN будет стараться поддерживать этот хэлсчек всегда зеленым. Если же отключена - то в случае возникновения дисбаланса загорится алерт, и администратору нужно будет вручную запустить задачу Rebalance Disks.

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

Год назад компания 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 vSphere 6.7 Update 3 стала доступной для загрузки. Одновременно с этим компания VMware сделала доступной для скачивания и развертывания систему отказоустойчивых кластеров хранилищ VMware vSAN 6.7 Update 3. В обоих этих решениях появилась встроенная поддержка технологии Cloud Native Storage (CNS), о которой мы сегодня расскажем.

Итак, Cloud Native Storage (CNS) - это функциональность VMware vSphere и платформы оркестрации Kubernetes (K8s), которая позволяет по запросу развертывать и обслуживать хранилища для виртуальных машин, содержащих внутри себя контейнеры. По-сути, это платформа для управления жизненным циклом хранения для контейнеризованных приложений.

При этом для такого управления сделано специальное представление в интерфейсе vCenter, которое вы видите на картинке выше.

Основная задача CNS - это обеспечивать развертывание, мониторинг и управление хранилищами для Cloud Native Applications (CNA), то есть современных приложений, исполняемых в контейнерах Docker под управлением Kubernetes (но, кстати, в будущем возможна поддержка и таких платформ, как Mesos и Docker Swarm).

Архитектура CNS реализована двумя компонентами:

• Интерфейс Container Storage Interface (CSI), представляющий собой плагин для K8s.
• Консоль управления CNS Control Plane на сервере vCenter, доступная через vSphere Client.

Через консоль управления CNS администратор может получить представление об имеющихся хранилищах в среде K8s (и видеть маппинги хранилищ на виртуальные диски VMDK), а также управлять ими в большом масштабе, что очень сложно при оперировании на уровне отдельных контейнеров, так как их могут быть сотни на одном хосте ESXi.

Кстати, про оперирование CNS есть интересное видео от VMware:

Надо понимать, что технология CNS появилась не впервые. Ранее подобные функции реализовывал механизм vSphere Storage for Kubernetes (он же vSphere Cloud Provider, VCP). Проект VCP появился как результат внутреннего хакатона VMware, когда требовалось быстро сделать драйвер для кластеров Kubernetes.

До этого приходилось вручную монтировать хранилища контейнеров на виртуальные диски VMDK, что было крайне неудобно, а при большом количестве контейнеров - практически нереально.

Сейчас архитектура VCP реализуется такими решениями Kubernetes as a Service (KaaS), как VMware PKS, RedHat OpenShift, Google Cloud Anthos и Rancher. Для этой архитектуры было возможно 2 режима развертывания - "in-tree" и "out-of-tree". В первом случае VCP был интегрирован в дистрибутив Kubernetes и развертывался одновременно с ним, а во втором - подразумевал последующую интеграцию после развертывания K8s.

Ввиду того, что обновлять VCP при первом варианте развертывания можно было только одновременно с K8s, вариант "in-tree" был исключен из конфигурации развертывания Kubernetes. VMware использовала эту ситуацию для того, чтобы полностью переписать код VCP (который, скорее всего, был не самым оптимальным еще с хакатона) и получить новую архитектуру - CNS.

Также кстати оказалась и покупка компании Heptio (об этом мы упоминали вот тут) - в итоге VMware интегрировала решение CNS прямо в платформу vSphere, без необходимости что-либо развертывать дополнительно. Мало того, архитектура CNS поддерживает любой оркестратор контейнеров, построенный на базе спецификации CSI.

Таким образом, CNS Control Plane на сервере vCenter брокеризует соединение с плагином (на данный момент только для K8s), который уже взаимодействует на уровне Kubernetes.

Частью решения CNS являются First Class Disks (FCDs), о которых мы рассказывали вот тут. Они были придуманы для того, чтобы управлять сервисами, заключенными в VMDK-диски, но не требующими виртуальных машин для своего постоянного существования. Это очень удобно для контейнеров, так как их можно динамически привязывать и отвязывать, не оставляя после себя "осиротевших" VMDK.

Кроме всего этого, CNS полностью подчиняется политикам Storage Policy-Based Management (SPBM), а это значит, что инфраструктура таких хранилищ отлично согласуется с пространством ярусного хранения VMware vSAN и концепцией K8s StorageClass. Также CNS, конечно же, работает и с классическими хранилищами VMFS и NFS, что позволяет использовать политики SPBM на базе тэгов.

Надо отметить, что технология CNS доступна для всех пользователей VMware vSphere, начиная с издания Standard, поэтому платить отдельно за нее не придется. Ну и в заключение обзорное видео о том, что такое и как работает Cloud Native Storage:

Скачать VMware vSphere 6.7 Update 3 с интегрированной технологией CNS можно по этой ссылке.

Недавно на сайте проекта 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:

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

Один из известных производителей, поддерживающих технологию VVols - это компания Pure Storage. Недавно Cody Hosterman написал статью о том, как подключить тома VVols в VMware vSphere через PowerCLI для хранилищ Pure Storage. Коди развивает свой модуль PowerShell, который называется PureStorage.FlashArray.VMware.

Давайте посмотрим, как он работает. Сначала можно почитать о доступных опциях командлета Mount-PfaVvolDatastore, с помощью которого можно сделать монтирование датастора VVol:

Командлет может делать следующее:

• Проверяет, презентован ли protocol endpoint (PE) указанного массива кластеру. Если нет, то с его помощью можно сделать это.
• Ресканирует кластер, чтобы убедиться, что PE виден хостам.
• Монтирует VVol в кластере.
• Возвращает датастор хранилищу.

Пример 1 - имеется прямой доступ к массиву

Соединяемся с vCenter и создаем соединение с FlashArray:

connect-viserver -Server <vCenter FQDN>
$flasharray = new-pfaConnection -endpoint <FlashArray FQDN> -credentials (get-credential) -ignoreCertificateError -nonDefaultArray

В интерфейсе vSphere Client датастор VVol еще не будет смонтирован:

Со стороны Pure Storage protocol endpoint также не подключен:

Запускаем Mount-PfaVvolDatastore:

Mount-PfaVvolDatastore -flasharray $flasharray -cluster (get-cluster <cluster name>) -datastoreName <datastore name>

После этого PE будет подключен к Pure Storage:

А датастор VVol будет смонтирован к кластеру:

Пример 2 - нет доступа к массиву

Значит тут мы полагаем, что администратор хранилищ уже настроил PE, и вам нужно только смонтировать том VVol:

Так как датастор VVol ранее не монтировался, нельзя просто создать array connection (нет доступа к массиву). В этом случае подойдет командлет Get-VasaStorageArray:

Передав в командлет монтирования массив FA-m50, имя кластера и имя датастора, можно смонтировать том VVol:

$vasaArrays = Get-VasaStorageArray
Mount-PfaVvolDatastore -vasaArray $vasaArrays[<desired index>] -cluster (get-cluster <cluster name>) -datastoreName <datastore name>

Если обобщить, то процесс монтирования датастора VVol с самого начала выглядит так:

• Установка модуля PowerShell
• Соединение с массивом
• Соединение с vCenter
• Создание хостовой группы (в случае с iSCSI нужно еще настроить iSCSI-таргеты)
• Зарегистрировать VASA-провайдер
• Смонтировать датастор VVol

Полный сценарий PowerShell приведен ниже:

install-module PureStorage.FlashArray.VMware

$flasharray = new-pfaConnection -endpoint flasharray-m50-1 -credentials (get-credential) -ignoreCertificateError -nonDefaultArray
connect-viserver -Server vcenter-02

$cluster = get-cluster Embarcadaro

New-PfaHostGroupfromVcCluster -cluster $cluster -iscsi -flasharray $flasharray

New-PfaVasaProvider -flasharray $flasharray -credentials (get-credential)

Mount-PfaVvolDatastore -flasharray $flasharray -cluster $cluster -datastoreName m50-VVolDS

А так в консоли vSphere Client:

Это гостевой пост нашего спонсора - сервис-провайдера ИТ-ГРАД, предоставляющего услугу аренды виртуальных машин из облака. В 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 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.

Не так давно мы писали о функции Site Locality в кластере VMware vSAN и некоторых ситуациях, когда эту функцию полезно отключать. Недавно Дункан Эппинг еще раз вернулся к этой теме и рассказал, что при использовании растянутых кластеров VMware vSAN надо иметь в виду некоторые особенности этого механизма.

При создании растянутого кластера вам предоставляют опции по выбору уровня защиты данных RAID-1 или RAID-5/6 средствами политики FTT (Failures to tolerate), а также позволяют определить, как машина будет защищена с точки зрения репликации ее хранилищ между датацентрами.

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

В старом интерфейсе vSphere Web Client это настраивается вот тут:

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

Это, конечно же, со всех сторон плохо, особенно с точки зрения производительности.

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

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

Те, кто используют серверы HPE ProLiant с гипервизором VMware ESXi и пакетом управления HPE Agentless Management (AMS) для кастомизированных образов ESXi от HP, могут столкнуться со следующим сообщением об ошибке в клиенте vSphere Client:

The ramdisk 'tmp' is full

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

Проблема актуальна для всех версий VMware ESXi 6.0, VMware ESXi 6.5 и VMware ESXi 6.7 с пакетом Agentless Management Service (AMS) версии 11.4.0.

Если зайти в консоль ESXi и выполнить там команду vdf, то можно увидеть, что раздел /tmp заполнен на 99%:

В самом же разделе tmp есть файлик ams-bbUsg.txt, который и является источником проблем:

Для временного решения этой проблемы нужно просто удалить этот файлик, и сообщения об ошибке прекратятся. Но чтобы этого не происходило, надо обновить ваш пакет HPE Agentless Management (AMS) версии 11.4.0, где проявляется данная проблема, на версию 11.4.2. О том, как это сделать написано в статье базы знаний HP:

Advisory: VMware - VMware AMS Data File Filling Up Tmp May Cause VUM Updates to Fail On HPE Servers Running VMware ESXi 6.0/6.5/6.7 with AMS Version 11.4.0.

Сам репозиторий с обновленным AMS находится по следующей ссылке:

http://vibsdepot.hpe.com/hpe/may2019

Вчера мы писали об ограничениях технологии 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...

Недавно мы писали об утилите для тестирования производительности хранилищ 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.

Мы много пишем о решении для организации отказоустойчивых хранилищ на базе хостов 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 при записи на флэш-диски распределяет операции записи равномерно между ячейками независимо от размера диска. Это позволяет диску изнашиваться равномерно и иметь бОльшую наработку на отказ.

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

Эти серверы могут исполнять как вычислительную нагрузку для ВМ, так и предоставлять ресурсы хранения. Когда все аспекты инфраструктуры объединяются в единую систему управления, такая инфраструктура называется гиперконвергентной (Hyperconverged Infrastructure, HCI).

Недавно компания StarWind анонсировала HCI-решение Command Center, которое позволит из единого интерфейса осуществлять мониторинг виртуальной среды на базе хранилищ Virtual SAN, а также управлять ею.

Command Center - это веб-интерфейс, построенный на базе технологии HTML5, который дает средства для управления виртуальными машинами и хост-серверами виртуализации, где для каждой из сущностей доступно до 100 различных параметров настройки. Единая панель управления инфраструктуры HCI позволяет выполнять ежедневные операции до 5 раз быстрее по сравнению с использованием нескольких консолей.

С помощью Command Center можно будет не только управлять сущностями виртуальной инфраструктуры, но и контролировать такие процессы, как оркестрация операций, резервное копирование Veeam Backup & Replication и многое другое.

Только 5% функционала Command Center приходится на решение Virtual SAN, остальное - это управление гипервизорами, резервным копированием, инфраструктурой публичных облаков и прочими аспектами. Кстати, Command Center будет поддерживать различные гипервизоры - VMware vSphere, Microsoft Hyper-V, Red Hat KVM и, возможно, другие платформы.

С продуктом можно будет опционально докупить StarWind ProActive Support - она позволит собирать телеметрию с компонентов Command Center и на основе аналитики на стороне StarWind (ML/DL) выявлять причины возникающих проблем.

Скачать StarWind Command Center пока нельзя, но можно запросить демо этого решения.

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

Когда вы планируете кластер vSAN, вам нужно определиться с политикой FTT (Failures to Tolerate) - она определяет, какое количество отказов хостов может пережить кластер хранилищ. Если установлено значение 1 (по умолчанию), то реплика одного VMDK будет размещена на дисках еще одного из хостов кластера.

Также при создании SPBM-политики хранилищ vSAN вы определяете уровень RAID (1, 5 или 6), в который виртуально будут собираться хосты ESXi на уровне дисковых объектов:

Иногда этот уровень RAID также называется FTM (Failure Tolerance Method).

vSAN - это объектное хранилище, где объекты состоят из компонентов. В состав компонентов входят реплики (Replicas - они содержат данные) и Witness (там находятся метаданные, чтобы избежать ситуации split-brain в кластере).

Есть три типа объектов на хранилище vSAN:

• VM Home (домашняя директория)
• VM Swap (файлы подкачки)
• VM Disk (диски с данными)

На хостах ESXi при этом размещаются компоненты для каждого из объектов в соответствии с заданной политикой SPBM:

FTM, то есть способ размещения данных на хостах ESXi, как мы сказали выше, может быть:

• RAID-1 (Mirroring, то есть зеркалирование объектов на хостах).
• RAID-5/6 (оно же Erasure Coding - алгоритм кодирования с коррекцией ошибок).

Таким образом, в зависимости от FTT вам понадобится следующее минимальное количество хостов ESXi для RAID-1:

Для RAID-5/6 вам потребуется вот такое минимальное число хостов ESXi:

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

С момента последних обновлений, инфраструктура отказоустойчивых хранилищ VMware vSAN теперь нативно поддерживает кластеры Microsoft SQL Server. На данный момент эта поддержка реализована только в облачной IaaS-инфраструктуре VMware Cloud on AWS версии 1.6, но скоро она появится и в онпремизной инфраструктуре VMware vSphere.

Суть поддержки заключается в том, что теперь облачный vSAN работает с командами SCSI-3 Persistent Reservation (SCSI3-PR), которые обеспечивают доступ к общим дискам на физическом уровне абстракции.

Таким образом, пользователи SQL Server не нуждаются в перепроектировании их Availability Groups, а могут просто перенести свои кластеры БД в облако.

Чтобы построить SQL Server Cluster нужно расшарить общий диск между его узлам таким образом, чтобы каждый из узлов мог управлять устройством на физическом уровне. Этот подход описан в документе о SCSI-3 Persistent Reservation (SCSI3-PR).

Для включения поддержки SCSI3-PR для выбранного виртуального диска машины нужно:

• Выставить режим диска в Independent – Persistent.
• Виртуальный диск должен быть привязан к SCSI-контроллеру, для которого параметр SCSI Bus Sharing выставлен в Physical.
• Для управления устройством Shared Disk и его Persistent Reservations имеет смысл создать отдельную политику хранилищ в целях лучшей управляемости.

На данный момент для такой инфраструктуры поддерживаются кластеры SQL Server Clusters 2012 и более свежие, работающие на платформе Windows Server 2012 и более свежей. С точки зрения лимитов, поддерживается до 8 узлов SQL Server на кластер и до 64 устройств на узел.

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

Вот как создается общий диск с описанными настройками:

Далее такой диск нужно подключить ко всем узлам SQL Server кластера:

Во время настройки, кстати, вам может оказаться полезным документ "Microsoft SQL Server Workloads and VMware Cloud on AWS: Design, Migration, and Configuration".

После того, как диск подцеплен ко всем узлам, можно валидировать кластер, перед тем, как создавать Cluster Management Point:

После завершения создания кластера закончите настройку инфраструктуры SQL Server как обычно.

Политика ограничения виртуальных машин по операциям ввода-вывода (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 и всегда четко его документировать в описании конфигурации виртуальной инфраструктуры.

Еще на конференции VMworld 2018 компания VMware анонсировала инициативу по использованию в качестве инфраструктуры блочных хранилищ сервисов Amazon Elastic Block Store (называлось это EBS backed vSAN). Несколько позднее это оформилось в виде технологии VMware Elastic vSAN, которая будет доступна в ближайшем будущем.

Изначально сервис VMware vCloud on AWS, предоставляющий виртуальную инфраструктуру виртуальных машин в аренду из облака Amazon, использовал инстансы I3.Metal в облаке EC2. Но для некоторых пользователей, имеющих существенные объемы данных, масштабирование за счет только увеличения числа инстансов в кластере не подходило - столько вычислительных ресурсов не требовалось, а требования к объему дискового пространства упирались в физические возможности хостов (10 ТБ на инстанс I3.Metal).

Поэтому VMware предложила другое решение - сделать хранилище инфраструктуры vSphere в облаке внешним, взяв за основу инстанс R5.Metal и подключив к нему масштабируемое облачное хранилище Elastic Block Store (EBS):

При создании бездисковых хостов Elastic vSAN пользователь указывает объем хранилища на хост (от 15 до 35 ТБ с шагом 5 ТБ), который требуется для кластера виртуальной инфраструктуры хранилищ, и она достраивается из компонентов блочного пространства EBS.

Когда технология Elastic vSAN включена, каждый хост имеет 3 дисковых группы, а каждая группа имеет от 3 до 7 дисков полезной емкости (помимо кэш-дисков):

Для такой конфигурации, чтобы обеспечить политику Failures to Tolerate = 1, рекомендуется включать RAID-5 (для этого нужно минимально 4 узла) и настройку "Compression only mode" для экономии дискового пространства. В этом случае не потребуется включать дедупликацию (она и недоступна в целях обеспечения высокой производительности), компрессии будет достаточно.

Все это дает возможность использовать меньшее число хостов, чем в случае с I3.Metal, что особенно полезно для нагрузок, которым не требуется много вычислительных ресурсов, но требуется много хранилища (например, файловые помойки). Это дает 140 ТБ сырой емкости на 4-узловой кластер и 560 ТБ на 16 узлов. Этого должно хватить практически всем.

Также при использовании I3.Metal или онпремизного кластера vSAN, в ситуации с эвакуацией виртуальных машин хоста для целей обслуживания, приходилось переносить все его содержимое на другой инстанс, что занимало значительное время. Для бездисковых инстансов R5.Metal получается так, что в случае выведения хоста из эксплуатации его хранилища на стороне EBS можно за небольшое время просто переподключить к новому инстансу - это и будет миграцией хоста без физического переноса данных.

Помимо упрощения обслуживания, такая архитектура дает еще несколько возможностей по построению гибких решений, в которых можно внедрять новые фичи Elastic vSAN быстрее, чем в онпремизных решениях. Заявлено, что новая архитектура будет выдавать до 10K IOPS на устройство/том (вне зависимости от его размера, минимальный размер 3 ТБ) и пропускную способность до 160 Мбит/с.

Обо всех будущих новых возможностях VMware vCloud on AWS вы можете узнавать на специальной странице. Ну и рекомендуем посмотреть запись сессии об Elastic vSAN с VMworld 2018 (там есть еще и интересная презентация в PDF).

Как вы знаете, мы часто пишем о лучшем продукте для создания отказоустойчивых хранилищ под виртуализацию StarWind Virtual SAN. На днях это решение было обновлено - вышел StarWind Virtual SAN Version 8 Build 12767. Надо отметить, что это первый релиз продукта в этом году. Прошлый состоялся в ноябре 2018 года.

Давайте посмотрим на новые функции и багофиксы StarWind Virtual SAN V8:

1. Основные возможности:

• Поддержка Signature Version 2 для S3-совместимых репликаторов Cloud Storage replicators.
• Запланированное удаление файлов с виртуального ленточного устройства на стороне публичного облака.
• Поддержка решения Azure Government storage для продукта StarWind VTL.
• Улучшена стабильность соединений и починены возможные маловероятные проблемы разрывов во время логина по протоколу iSCSI.

2. Исправления ошибок, пофикшены проблемы в:

• Механизме SMI-S.
• Сервисном модуле.
• Модуле репликации при получении неожиданных ответов от целевого сервера (System.Net.Http.HttpRequestException).
• Процессе построения списка репликаторов.
• Клиенте при переведения узла в режим обслуживания и изменении статуса синхронизации.
• Процессе переустановки NVMf Target.

Загрузить новый апдейт StarWind Virtual SAN V8 можно по этой ссылке. Release Notes доступны тут.

На сайте VMware появился полезнейший технический документ, даже практически книга об использовании фреймворка PowerCLI для инфраструктуры отказоустойчивых кластеров хранилищ - VMware PowerCLI Cookbook for vSAN.

На 88 страницах авторы (Jase McCarty и его коллеги), работавшие с PowerCLI/PowerShell для управления инфраструктурой vSAN более 4 лет, рассказывают обо всех аспектах управления хранилищами с помощью сценариев.

Книга дает "рецепты" в следующих сферах:

• Конфигурация решения vSAN
• Операционные ежедневные задачи
• Функции отчетности о текущем состоянии среды

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

Кстати, это только первый релиз книги (1.0), со временем она будет дополняться. Скачать VMware PowerCLI Cookbook for vSAN можно по этой ссылке.

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

• Что нового будет в VMware vSAN следующей версии, часть 2: поддержка First Class Disk (FCD)
• Анонсы VMworld Europe 2018, часть 3 - технология VMware vSAN Native Data Protection (первая статья серии)

В этой заметке мы поговорим еще об одной возможности, касающейся способов хранения данных в кластере - vSAN Scalable File Services. Как вы знаете, vSAN предоставляет пространство хранения для виртуальных машин и дисков VMDK (в том числе дисков FCD), а также дает возможность использовать логические тома по протоколу iSCSI.

Так вот, функциональность vSAN File Services дает возможность использовать дисковое пространство по протоколам NFS и SMB, что дает возможность раздавать ресурсы кластера через эти протоколы для внешних потребителей без необходимости создания отдельных машин для файловых помоек, например, с Windows Server на борту.

Также файловые шары NFS/SMB будут находиться под управлением политик Storage Policy Based Management (SPBM), а также будут работать в растянутых кластерах vSAN, что позволит рассматривать их как часть общего пространства vSAN в распределенных датацентрах. С помощью SPBM можно будет использовать такие сервисы, как FTT (переносимость отказов хостов ESXi), шифрование и развертывание хранилищ, растущих по мере наполнения данными (thin provisioning).

Механизм файлового шаринга работает на базе файловой системы vSAN Distributed File System (vDFS), которая позволяет агрегировать дисковые объекты vSAN для предоставления пространства хранения, а сервисы управления предоставляет платформа Storage Services Platform.

С точки зрения интерфейса создания и экспорта файловых шар, эти сервисы будет представлять vCenter и vSphere Client (там же будут назначаться права доступа, квоты и прочее).

Сервисы vSAN FIle Server (в демо они были показаны как виртуальные модули, Virtual Appliances) будут реализовывать экспорт папок. Кроме того, они будут иметь механизм обнаружения сбоев и перезапуска этих машин на других серверах:

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

Кроме того, vSAN File Services будут предоставлять свои ресурсы на уровне файлов для контейнеров на платформе Kubernetes:

Также вы можете посмотреть 2 интересных видеопрезентации с VMworld 2018 и VMworld Europe 2018, посвященных vSAN Scalable File Services:

• HCI3041BE – VMworld Europe 2018 session: Introducing Scalable File Storage on vSAN with Native File Services. Также к этому видео прилагается презентация в формате PDF.

• HCI3728KE – VMworld Europe 2018 session:  Innovating Beyond HCI: How VMware is Driving the Next Data Center Revolution.

Подписаться на бету следующей версии продукта VMware vSAN можно по этой ссылке. Ожидается, что первая реализация будет поддерживать NFS 4.1 с аутентификацией в AD, шары SMB, Kerberos, протокол OpenLDAP и механизм vSAN Data Protection.

Во время прошедшего летом прошлого года VMworld 2018 компания VMware представила много интересных новостей на тему будущей функциональности продукта для создания отказоустойчивых хранилищ VMware vSAN. Например, мы писали о технологии Native Data Protection (это часть 1 этого цикла статей), а сегодня поговорим о сервисах хранения.

Диски First Class Disk (FCD)

Для vSAN уже есть поддержка так называемых дисков First Class Disk (FCD), они же называются Improved Virtual Disk (IVDs) или Managed Virtual Disk. Они были придуманы для того, чтобы управлять сервисами, заключенными в VMDK-диски, но не требующими виртуальных машин для своего постоянного существования.

К таким относятся, например, тома VMware App Volumes, на которых размещаются приложения, и которые присоединяются к виртуальным машинам во время работы пользователя с основной машиной. Также к таким дискам относятся хранилища для cloud native приложений и приложений в контейнерах, например, работающих через Docker Plugin и драйвер Kubernetes (он называется vSphere Cloud Provider) для создания постоянных (persistent) томов контейнеров Docker. Этим всем занимается опенсорсный проект Project Hatchway от VMware.

Работать с такими дисками очень неудобно - для них приходится создавать отдельную виртуальную машину к которой цепляется этот диск, а потом, по завершении какого-либо процесса, отсоединяется, и машина уничтожается. Так, например, работает средство для резервного копирования App Volumes Backup Utility, о котором мы писали вот тут. При бэкапе этих дисков создается временная Backup VM:

Второй пример - инфраструктура vSphere Integrated OpenStack (VIO), где для того, чтобы включить хранилище Cinder (OpenStack Block Storage) для потребления дисковой емкости VMDK-файлов, нужно создавать вспомогательные Shadow VM для каждого тома Cinder, к которому цепляется VMDK-диск.

Все это неудобно, поэтому и придумали формат дисков First Class Disk (FCD), которому не требуются временные виртуальные машины и которые реализуют сервисы, необходимые приложениям или другим сервисам. Например, бэкап таких дисков можно делать без создания вспомогательной ВМ.

Информация о дисках FCD хранится в каталоге базы данных vCenter. Она содержит глобальные уникальные идентификаторы UUID и имена дисков. UUID позволяет переместить диск в любое место без конфликтов.

Впервые API для работы с FCD появился в VMware vSphere 6.5, например, вот хороший пост от Вильяма Лама об этом. Но в этом релизе было ограничение на резервное копирование FCD-дисков, которые не присоединены к ВМ (в качестве workaround приходилось все же использовать Dummy VM).

В vSphere 6.7 это ограничение было снято, но остались еще некоторые требования - FCD нужно было восстанавливать с тем же UUID и на тот же датастор, откуда он был взят. Также еще одним ограничением была невозможность API отслеживать блоки, изменившиеся с момента последней резервной копии, то есть невозможность инкрементального резервного копирования (подробнее здесь).

Ну а в vSphere 6.7 Update 1 была анонсирована ограниченная поддержка FCD для vSAN. Пока поддержка предоставляется еще с ограничениями для служб health service и capacity monitoring. Однако при этом пользователи Kubernetes могут использовать диски FCD на хранилищах vSAN для персистентных хранилищ контейнеров, и в то же самое время тома vSAN могут использоваться для виртуальных машин:

Подписаться на бету следующей версии продукта VMware vSAN можно по этой ссылке.

В следующей статье мы расскажем про Cloud Native Storage (CNS) и vSAN File Services.

Компания StarWind, ведущий производитель решений для создания отказоустойчивых программных хранилищ под виртуализацию VMware vSphere и Microsoft Hyper-V, приглашает на бесплатный вебинар "Building a stretched cluster: Keep your data always secure".

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

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

Регистрируйтесь бесплатно!

Компания 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 можно по этой ссылке.

Компания VMware, прислушавшись к фидбэку пользователей, сделала несколько улучшений в онлайн-утилите VMware Compatibility Guide в плане поиска поддержки VVols (кстати, почитайте нашу статью о политиках SPBM на томах VVols).

Теперь новый VCG позволяет получить ответы на следующие вопросы:

• Какой дисковый массив поддерживает технологию VVols?
• Какую версию ESXi поддерживает тот или иной вендор оборудования?
• Какая есть сертификация VASA?
• Какие возможности VVols поддерживает устройство?
• Какие проблемы или ограничения имее реализация VASA Provider на устройстве?

Кликнув на производителя (Partner Name), вы увидите какие типы VASA Provider он поддерживает и на каких моделях дисковых массивов.

Также, выбрав нужную вам фичу VVols, например, VVols Storage Replication, вы можете вывести всех производителей, кто ее поддерживает:

Раскрыв категорию Partner Name для нужного производителя, вы увидите какие версии ESXi какие функции поддерживают:

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

Также есть еще один полезный раздел, который открывается по клику на "Click here for more Details":

Тут уже можно найти детальную информацию о поддерживаемых протоколах, статьях базы знаний (KB), версии VASA provider и VASA VVol Spec, а также многое другое.