Новости Статьи VMware Veeam StarWind Microsoft ИТ-ГРАД Citrix Symantec 5nine События Релизы Видео Контакты Авторы RSS
Виртуализация и виртуальные машины

Виртуализация vSphere, Hyper-V, XenServer и Red Hat

Более 4830 заметок о виртуализации и виртуальных машинах VMware, Microsoft, Citrix, Red Hat

VM Guru | Ссылка дня: Номинация vExpert на вторую половину 2019 года уже открыта!

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


На сайте 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, HCIBench, Update, Performance, ESXi, vSphere, vSAN, VMDK, Storage

Траблшутинг низкой производительности кластера VMware vSAN - алгоритм действий.


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

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


Таги: VMware, vSAN, Performance, Troubleshooting

Новый документ "Persistent Memory Performance in vSphere 6.7 with Intel Optane DC persistent memory".


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


Таги: VMware, PMEM, Performance, Whitepaper, Intel, Memory, Storage

StarWind iSCSI Accelerator - бесплатная утилита для оптимизации производительности вашего инициатора.


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


Таги: StarWind, iSCSI, Accelerator, Storage, Performance

Маркетплейс Super Metric Sample Exchange для решения VMware vRealize Operations.


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


Таги: VMware, vRealize, Operations, Performance

Проверка производительности кластера VMware vSAN с помощью утилиты HCIBench.


Недавно мы писали об утилите для тестирования производительности хранилищ 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, vSAN, Performance, ESXi, vSphere, HCIBench, Storage

Улучшения планировщика side-channel aware scheduler (SCA) в VMware vSphere 6.7 Update 2.


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


Таги: VMware, ESXi, Performance, Security, vSphere, vCPU, VMachines

Подробно о дисковых группах VMware vSAN - что это такое и как работает.


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


Таги: VMware, vSAN, Storage, VMachines, Performance

Основные рекомендации по исполнению нагрузок Microsoft SQL Server в кластере хранилищ VMware 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, vSAN, Microsoft, SQL, Performance

Обнаружение девиантов по трафику в группе виртуальных машин с помощью VMware vRealize Network Insight.


Мы часто писали о решении 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, хотя бы только с этой стороны - полезная штука!

Источник.


Таги: VMware, vRNI, Networking, Performance, Monitoring

Лимитирование по IOPS виртуальных машин в кластере VMware vSAN - как это влияет на машину и ее соседей.


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


Таги: VMware, vSAN, Performance, Storage, VMachines

Полезная бесплатная утилита StarWind rPerf для тестирования производительности RDMA-соединений.


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


Таги: StarWind, Storage, Performance

Нагрузочное тестирование Veeam Backup&Replication.


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

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

Таги: Selectel, Veeam, Backup, Performance, Cloud, IaaS

Что такое и как работает кэширование Log-structured Write Cache (LWC) в решении StarWind Virtual SAN.


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


Таги: StarWind, Cache, Performance, Storage, LWC, iSCSI

Увеличение производительности Storage DRS и скорости развертывания ВМ в VMware vSphere 6.7 по сравнению с версией 6.5.


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


Таги: VMware, Storage DRS, Performance, Storage, ESXi, vSphere, Enterprise

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


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

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

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

1. Технология Deep Application Performance Testing.

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

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

Скачать пробную версию Login PI Release 3 можно по этой ссылке.

Таги: VMware, VDI, Login PI, Performance, Update

Документ о тестировании работы баз данных Oracle в All-Flash кластере VMware vSAN 6.7.


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

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

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

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

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

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

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

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


Таги: VMware, vSAN, Performance, Oracle, AWS, Cloud, Storage, Flash, SSD, Whitepaper

Задачи машинного обучения в инфраструктуре VMware vSphere на оборудовании NVIDIA GRID (vGPU).


Мы много писали о рещениях 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.


Таги: VMware, vSphere, vGPU, NVIDIA, Performance, ML

Что такое и как работает Network I/O Control (NIOC) в VMware vSphere 6.7.


Не все администраторы платформы виртуализации VMware vSphere знают, что такое Network I/O Control (NIOC). Причина проста - функции механизма регулирования полосы пропускания NIOC для различных видов трафика на стороне vSphere Distributed Switch (vDS) есть только в издании vSphere Enterprise Plus, которое, как правило, приобретают большие и средние компании.

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

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

  • Fault tolerance traffic
  • iSCSI traffic
  • vMotion traffic
  • Management traffic
  • vSphere Replication traffic
  • Network file system (NFS) traffic
  • Virtual machine (VM) traffic
  • User-defined traffic

Механизм NIOC появился еще в 2010 году в VMware vSphere 4.1, и с тех пор был очень сильно доработан (сейчас в vSphere 6.7 Update 1 доступна третья версия NIOC v3).

В интерфейсе HTML5-клиента vSphere Client эти настройки выглядят так (новый клиент полностью поддерживает рабочие процессы NIOC):

В vSphere Web Client вы можете увидеть эти настройки по адресу vDS > Manage > Resource Allocation > System traffic:

Механизм NIOC включен по умолчанию (для vSphere 6.0 и выше), но для типов трафика не заданы никакие ограничения (Limit) и резервации (Reservation) - только приоритеты между типами трафика (Shares). Работают эти 3 техники регулирования типа трафика так же, как и аналогичные механизмы для хранилищ или вычислительных ресурсов:

  • Reservation - гарантирует тому или иному типу трафика пропускную способность канала в Мбит/с. Важно помнить, что эта ширина канала резервируется, но в случае ее простоя ее смогут использовать другие типы системного трафика. Между тем, простой канала зарезервированного системного трафика не дает возможность распределить полосу на виртуальные машины. В любом случае, Reservation (если он вам очень нужен) нужно выставлять таким, чтобы обеспечить только минимальные запросы сервиса для его функционирования, а не средние и максимальные.
  • Limit - ограничивает сверху используемый канал для выбранного типа трафика.
  • Shares - с помощью чисел приоритета (от 1 до 100) позволяет выделить группы которые будут получать больше или меньше пропускной способности канала (например, если одна группа имеет 100, а другая 50 - то первая будет получать в два раза больше на фоне распределения всего трафика адаптеров по группам). Механизм этот начинает распределять канал после раздачи всех заданных резерваций.

Есть еще один нюанс - только 75% совокупной ширины канала на хосте ESXi может быть зарезервировано (а если говорить точнее - от адаптера с самой низкой пропускной способностью в этой группе на хосте). Остальные 25% остаются на всякий случай (например, компенсация всплесков управляющего трафика). Все, что не распределено с помощью Reservation, будет регулироваться средствами механизма Shares.

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

Для удобства Shares можно указывать не цифрами, а выбрать из комбо-бокса один из вариантов - Low (25), Normal (50) и High (100). В этом случае цифры для Shares автоматически подберутся (они указаны в скобках), чтобы составлять верные соотношения согласно выставленным приоритетам. После выставления этих параметров они будут применены на всех физических адаптерах хостов ESXi, подключенных к распределенному коммутатору vDS на сервере vCenter.

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

NIOC v3 также позволяет сконфигурировать резервации как на уровне отдельных виртуальных машин (в свойствах адаптера), так и создавать собственные пользовательские пулы (User-Defined Network Resource Pools), которые являются подмножеством корневого пула Virtual machine (VM) traffic.

Для User-Defined Network Resource Pools выставление лимитов и Shares не предусмотрено - только Reservation.

В свойствах адаптера vNIC резервации на уровне отдельной ВМ можно выставить в ее настройках (это только гарантированная полоса, но машина может использовать и больше, если есть доступные ресурсы):

Если вы выставляете Reservation для адаптеров виртуальных машин, то их суммарная резервация не может быть больше, чем резервация для VM system traffic на этом хосте:

Если нужно настроить сетевые пулы ресурсов для групп виртуальных машин, то нужно создать новый пул в Web Client:

А потом указать резервацию для него:

Потом этот пул нужно указать при настройке распределенной группы портов на распределенном коммутаторе vDS:

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

При этом если вы задали резервацию 1 Мбит/с, а физических адаптеров на хосте ESXi у вас 5, то такая распределенная группа портов получит до 5 Мбит/с на свои виртуальные машины.

В итоге картина выглядит подобным образом:

Когда вы создадите новый пул в разделе Network Resource Pools, вы сможете посмотреть список виртуальных машин в нем на вкладке Virtual Machines:

Ну и напоследок отметим, что лимиты для сетевых адаптеров машин должны согласовываться с лимитами политики traffic shaping для распределенной группы портов, куда они воткнуты. Например, если для адаптера выставлен лимит 200 Мбит/с, а для всей порт-группы на vDS только 100 Мбит/с, то эффективным ограничением будет именно 100 Мбит/с.


Таги: VMware, vSphere, NIOC, Networking, Performance, Обучение, ESXi, vDS

VMware TestDrive - реальное тестирование различных продуктов для партнеров и клиентов VMware.


Многие из вас пользуются лабораторными работами VMware Hands-on Labs, которые позволяют освоить работу с различными продуктами и технологиями, проходя по шагам интерфейса. Но это подходит только для целей обучения работе в интерфейсе этих решений, а если хочется полноценно запустить какой-нибудь продукт (например, vSAN, NSX или PKS) в реальных условиях и посмотреть на его производительность - то для этого есть портал VMware TestDrive, о котором недавно написал Дункан Эппинг.

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

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

TestDrive работает в облаке Softlayer от IBM и доступен во всех глобальных регионах по миру (US, EMEA, APJ). При этом, работая с инфраструктурой, вы можете делать множество интересных вещей под аккаунтом SuperUser, свободу сильно не ограничивают, за исключением удаления объектов. VMware говорит, что TestDrive в этом году использовали уже 344 тысячи раз.

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

Чтобы партнерам VMware использовать данный сервис, им нужна компетенция VTSP HCI, после чего TestDrive будет доступен через Partner Central. Для начала получения компетенции зайдите в Partner University и подпишитесь на аккредитацию Hyper-Converged Infrastructure accreditation:

Одно из самых интересных на портале - возможность тестирования кластеров хранилищ vSAN (на данный момент это vSAN 6.7, но скоро окружение будет обновлено до vSAN 6.7 Update 1). Там доступно управление виртуальной инфраструктурой десктопов Horizon и машинами, а также есть доступ к средству тестирования нагрузки HCIBench. С помощью решений vSAN Health and Performance Service и vROPs можно замерять задержки (latency) и число операций ввода-вывода в секунду (IOPS) в различных условиях эксплуатации виртуальных машин:

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

Для доступа к сервису нужно попросить его у своего поставщика, являющегося партнером VMware, который должен зарегистрироваться на портале vmtestdrive.com.

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


Таги: VMware, vSAN, TestDrive, Performance

Бесплатное решение SexiGraf для мониторинга виртуальной инфраструктуры VMware vSphere - 17 самых интересных панелей.


Один из наших читателей Сергей справедливо отметил, что мы обошли вниманием бесплатное решение SexiGraf, предназначенное для мониторинга виртуальной инфраструктуры VMware vSphere. Оно было сделано энтузиастами (Raphael Schitz и Frederic Martin) в качестве альтернативы платным продуктам для мониторинга серверов ESXi и виртуальных машин.

Представления SexiPanels для различных метрик в различных разрезах есть не только для VMware vSphere и vSAN, но и для ОС Windows и FreeNAS, но мы остановимся только на панелях для vSphere. Да и то, давайте посмотрим только на 17 самых интересных из них, поскольку различных фильтров, вариаций и комбинаций этих панелей и представлений очень много, все в одну статью не поместится.

SexiGraf представляет собой виртуальный модуль (Virtual Appliance) с веб-интерфейсом администрирования, который можно удобно настроить под себя. Давайте посмотрим, какие самые интересные представления есть в SexiGraf:

1. Полная статистика по одному или нескольким кластерам.

Кое-что здесь взято из раздела производительности vCenter, но большинство метрик отличаются и могут быть вам очень интересны:

2. Полная статистика по одному или нескольким серверам ESXi.

Это представление похоже на предыдущее, только статистика по датасторам и адаптерам vmnic не агрегируется и представляется отдельно:

3. Планирование емкости одного или нескольких кластеров.

Прикольная штука - задаете кластер (один или несколько), масштаб заполнения для процессорных ресурсов (scale) и получаете статистики по числу используемых виртуальных машин и сколько их еще можно в кластер вместить:

4. Использование процессоров и памяти.

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

5. Хранилища по IOPS и Latency.

Можно вывести датасторы и сравнить их по числу операций в секунду (IOPS) и возникающей задержке:

6. Агрегированное заполнение ресурсов по кластерам.

Выбираем кластер, и нам показывают...Читать статью далее->>


Таги: VMware, ESXi, Monitoring, Бесплатно, vSphere, Virtual Appliance, Performance

Возвращение дискового пространства гостевой ОС в VMware vSAN 6.7 Update 1 в сторону аппаратного хранилища (TRIM / UNMAP).


Не так давно мы писали про новые возможности решения для создания отказоустойчивых кластеров хранилищ VMware vSAN 6.7 Update 1. Одной из новых возможностей этого продукта стала функция возвращения неиспользуемого гостевыми ОС дискового пространства в сторону физической дисковой подситсемы. Ранее эта возможность не работала, о чем мы писали вот тут.

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

В этом случае очень бы хотелось это место вернуть опять как свободное на сторону дискового хранилища, так вот функции TRIM и UNMAP именно это и делают. vSAN 6.7 U1 теперь полностью обрабатывает SCSI/ATA-команды TRIM/UNMAP и автоматически возвращает дисковое пространство хранилищу. При этом, поскольку vSAN не использует тома LUN или VMFS, в рамках этой процедуры не требуется прохождения рабочего процесса через эти уровни абстракции.

Помимо очевидного преимущества очистки хранилища, процесс возвращения дисковых блоков имеет еще 3 позитивных эффекта:

  • Блоки, вышедшие из пространства vSAN, не нужно реплицировать между хостами и тратить на это ресурсы.
  • Эти блоки не надо обрабатывать со стороны систем резервного копирования.
  • Очистка грязных страниц из кэша на чтение, что уменьшает число копируемых блоков между кэшем и ярусом хранения (capacity tier).

VMware говорит, что в целом TRIM/UNMAP не влияет на производительность, но если происходит большое число команд UNMAP, то надо посматривать за производительностью.

Для включения этого механизма можно использовать команду:

vsan.unmap_support VSAN-Cluster -e

Windows Server 2012 и более поздние версии ОС поддерживают автоматическое возвращение дискового пространства. Чтобы проверить работу этой функции, надо выполнить команду:

Get-ItemProperty -Path "HKLM:\System\CurrentControlSet\Control\FileSystem" -Name DisableDeleteNotification

Для включения этой возможности на уровне гостевой ОС надо выполнить команду:

Set-ItemProperty -Path "HKLM:\System\CurrentControlSet\Control\FileSystem" -Name DisableDeleteNotification -Value 0

Надо отметить, что процесс возвращения блоков происходит асинхронно, поэтому результат проявляется не сразу. Чтобы в Windows запустить TRIM для диска можно выполнить команду PowerShell:

PS C:\>Optimize-Volume -DriveLetter H -ReTrim -Verbose

Результат будет, например, таким:

Также TRIM можно сделать и с помощью утилиты дефрагментации, запустив ее с флагом /L:

Defrag C: D: /L

За производительностью процесса TRIM/UNMAP можно наблюдать в консоли vSAN, в разделе Monitor->vSAN->Performance.

Здесь два основных параметра на нижнем графике:

  • UNMAP Throughput - скорость прохождения команд UNMAP к дисковым группам хоста.
  • Recovery UNMAP Throughput - скорость прохождения команд UNMAP, которые выполняются как часть процесса object repair при отсутствующем или испорченном дисковом объекте.

Таги: VMware, vSAN, Storage, Performance

Память Persistent memory (PMEM) в VMware vSphere - что это такое, как работает и насколько быстро?


В последней версии платформы виртуализации VMware vSphere 6.7 появилась новая возможность - поддержка Persistent Memory (PMEM). Это новый вид памяти, который покрывает разрыв между оперативной памятью (RAM) и дисковой памятью (Flash/SSD) с точки зрения быстродействия и энергонезависимости.

PMEM имеет 3 ключевые характеристики:

  • Параметры задержки (latency) и пропускной способности (bandwidth) как у памяти DRAM (то есть примерно в 100 быстрее, чем SSD).
  • Процессор может использовать стандартные байт-адресуемые инструкции для сохранения данных и их подгрузки.
  • Сохранение значений в памяти при перезагрузках и неожиданных падениях устройства хранения.

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

А ее характеристики соотносятся с SSD и DRAM памятью следующим образом:

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

На данный момент vSphere 6.7 поддерживает 2 типа решений PMEM, присутствующих на рынке:

  • NVDIMM-N от компаний DELL EMC и HPE - это тип устройств DIMM, которые содержат как DRAM, так и модули NAND-flash на одной планке. Данные передаются между двумя модулями при загрузке, выключении или любом событии, связанном с потерей питания. Эти димы поддерживаются питанием с материнской платы на случай отказа. Сейчас обе компании HPE и DELL EMC поставлют модули 16 GB NVDIMM-N.
  • Модули Scalable PMEM от компании HPE (доступно, например, в серверах DL380 Gen10) - они позволяют комбинировать модули HPE SmartMemory DIMM с устройствами хранения NVMe (интерфейс Non-volatile Memory дисков SSD) и батареями, что позволяет создавать логические устройства хранения NVDIMM. Данные передаются между DIMMs и дисками NVMe. Эта технология может быть использована для создания систем с большим объемом памяти PMEM на борту.

При этом накладные затраты на использование виртуализации с устройствами PMEM не превышают 3%. Вот так выглядят примерные численные характеристики производительности памяти NVMe SSD и NVDIMM-N по сравнению с традиционными дисками:

С точки зрения предоставления памяти PMEM виртуальной машине, есть 2 способа в vSphere 6.7:

  • vPMEMDisk - vSphere представляет PMEM как обычный диск, подключенный к виртуальной машине через контроллер SCSI. В этом случае ничего не нужно менять для гостевой ОС или приложений. В таком режиме работают любые системы, включая старые ОС и приложения.
  • vPMEM - vSphere представляет PMEM как устройство NVDIMM для виртуальной машины. Большинство последних версий операционных систем (например, Windows Server 2016 и CentOS 7.4) поддерживают устройства NVDIMM и могут предоставлять их приложениям как блочные или байт-адресуемые устройства. Приложения могут использовать vPMEM как устройство хранения через тонкий слой файловой системы direct-access (DAX), либо замапить регион с устройства и получать к нему прямой доступ через байтовую адресацию. Такой режим может быть использован старыми или новыми приложениями, но работающими в новых версиях ОС, при этом версия Virtual Hardware должна быть не ниже 14.

Вот так это выглядит с точки зрения логики работы:

Если у вас хост VMware ESXi имеет на борту устройства с поддержкой PMEM, вы можете увидеть это в его свойствах в разделе Persistent Memory:

При создании новой виртуальной машины вы сможете выбрать, какое хранилище использовать для нее - стандартное или PMem:

Параметры диска на базе PMEM можно установить в разделе Customize hardware:

Также в свойствах виртуальной машины можно добавить новый жесткий диск в режиме vPMEMDisk:

Если же вы хотите добавить хранилище в режиме vPMEM, то надо указать соответствующий объем использования устройства в разделе New NVDIMM:

Надо отметить, что хранилище PMEM может быть на хосте ESXi только одно и содержит только устройства NVDIMM и виртуальные диски машин (то есть вы не сможете хранить там файлы vmx, log, iso и прочие). Для такого датастора единственное доступное действие - это просмотр статистик (при этом в vSphere Client на базе HTML5 датасторы PMEM вообще не видны). Вывести статистику по устройствам PMEM можно командой:

# esxcli storage filesystem list

Пример результатов вывода:

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

Что касается миграции ВМ с устройством PMEM, то особенности этой миграции зависят от режима использования машиной устройства. Для миграции между хостами ESXi машины с PMEM включается не только vMotion, но и Storage vMotion, а на целевом хосте должно быть достаточно места для создания резервации от мигрируемой машины. При этом машину с хранилищем в режиме vPMEMDisk можно перенести на хост без устройства PMEM, а вот машину с vPMEM - уже нет.

В самом плохом случае при миграции ВМ с хранилищем NVMe SSD ее простой составит всего полсекунды:

Технологии VMware DRS и DPM (Distributed Power Management) полностью поддерживают память PMEM, при этом механизм DRS никогда не смигрирует машину, использующую PMEM на хосте, на сервер без устройства PMEM.

VMware недавно провела тестирование памяти PMEM с помощью различных бенчмарков и описала результаты в документе "Persistent Memory Performance on vSphere 6.7 - Performance Study". Приведем некоторые графики из него:

1. Бенчмарк FIO для latency:

vPMEM-aware - это использование устройства PMEM гостевой ОС, которая умеет работать с модулем PMEM на хосте через прямой доступ к постоянной памяти устройства.

2. Бенчмарк FIO для пропускной способности (Throughput):

3. Бенчмарк HammerDB для Oracle, тестирование числа операций в секунду:

4. Тест Sysbench для базы данных MySQL, тестирование пропускной способности в транзакциях в секунду:

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

Документация на тему использования Persistent Memory в VMware vSphere 6.7 доступна тут и тут.


Таги: VMware, vSphere, Memory, Performance, Storage, Machines

Не просто документ, а целая книга о производительности виртуальной инфраструктуры - "Performance Best Practices for VMware vSphere 6.7".


Компания VMware наконец-то обновила свой главный документ о производительности основной платформы виртуализации - "Performance Best Practices for VMware vSphere 6.7". Несколько ранее мы писали о документе "What’s New in Performance - VMware vSphere 6.7", в котором были рассмотрены основные нововведения последней версии продукта в плане производительности, но там было всего 13 страниц, а в этой книге о производительности - аж 88!

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

  • Hardware-assisted virtualization
  • Storage hardware considerations
  • Network hardware considerations
  • Memory page sharing
  • Getting the best performance with iSCSI and NFS storage
  • Getting the best performance from NVMe drives
  • vSphere virtual machine encryption recommendations
  • Running storage latency-sensitive workloads
  • Network I/O Control (NetIOC)
  • DirectPath I/O
  • Running network latency-sensitive workloads
  • Microsoft Virtualization-Based Security (VBS)
  • CPU Hot Add
  • 4KB native drives
  • Selecting virtual network adapters
  • The vSphere HTML5 Client
  • vSphere web client configuration
  • Pair-wise balancing in DRS-enabled clusters
  • VMware vSphere update manager
  • VMware vSAN performance

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

Несколько интересных моментов из документа:

  • Начиная с версии vSphere 6.7, платформа больше не поддерживает программную виртуализацию CPU (только аппаратную).
  • vSphere Flash Read Cache (vFRC) может негативно влиять на производительность vMotion.
  • Для VVols массив сам обнуляет блоки перед созданием тома, поэтому нет возможности указать тип диска "eager" или "lazy".
  • Если вы используете виртуальный сетевой адаптер старой модели с пониженной пропускной способностью, например, Vlance, который показывает в гостевой ОС 10 Мбит/с - это не значит, что он будет работать на этой скорости. Он будет работать на скорости, максимально поддерживаемой физическим оборудованием и хостом ESXi.

Остальные полезные фишки - в документе.


Таги: VMware, vSphere, Performance, Whitepaper

Тестирование дисковой системы в облаке.


С каждым днем все больше компаний выбирают в качестве основы своей ИТ-инфраструктуры облако в модели IaaS.

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


Таги: IT-Grad, IaaS, Storage, Performance, Cloud

Улучшения служб мониторинга производительности в VMware vSAN 6.7.


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

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

На каждом из серверов VMware ESXi служба vSAN performance service развертывается отдельно и позволяет независимо от сервера vCenter собирать данные о производительности кластера и предоставлять их внешним потребителям - CLI, PowerCLI, различным SDK и серверам vCenter:

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

Данные о производительности собираются на уровне дисковых объектов, которым назначена определенная политика хранения (Storage Policy). Посмотреть эти объекты можно в разделе vSAN->Virtual Objects:

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

В последней версии диски и дисковые группы были консолидированы в одну категорию, то есть можно посмотреть статистики по группе в целом, а также по отдельному физическому диску. Кроме того, можно смотреть информацию и об устройствах кэширования на хосте (buffer/cache device) в рамках дисковой группы:

В зависимости от того, какой вид просмотра группы или устройства вы выберете, будут доступны те или иные графики производительности. Например, для дисков хранения (capacity devices) будут показаны дополнительные графики "vSAN Layer IOPS" и "vSAN Layer Latency".

Также претерпели изменения разделы "VMkernel Adapters" и "VMkernel Adapters Aggregation" сетевых ресурсов хостов ESXi, которые были объединены в едином представлении Host Network:

Теперь можно выбрать просмотр агрегированных статистик по всем VMkernel адаптерам на хосте, либо выбрать отдельный адаптер. Надо помнить, что статистика по IO в данном разделе - это весь трафик VMkernel, а не только трафик vSAN (например, еще vMotion).

Кстати, интересно, что метрика packet loss, отображаемая как в формате, например, 23%o - это на самом деле не проценты, а так называемое permille-значение. То есть количество потерянных пакетов из одной тысячи (а не из ста, как в случае с процентами). Таким образом, 23%o соответствует значению 2.3% потерянных пакетов.

Еще одно полезное нововведение службы performance service в vSAN 6.7 - это возможность перестраивать размещение графиком в соответствии с разрешением экрана устройства. Например, на небольших устройствах графики будут идти последовательно вниз друг за другом, а на больших экранах показывается вот такой дэшборд:

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


Таги: VMware, vSAN, Performance, Storage, Troubleshooting

Новый документ - What’s New in Performance - VMware vSphere 6.7.


Компания VMware на днях выпустила новый документ, раскрывающий основные моменты улучшения производительности VMware vSphere 6.7 по сравнению с прошлой версией - What’s New in Performance - VMware vSphere 6.7.

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

  • Увеличение в 2 раза числа операций vCenter в секунду по сравнению с vCenter 6.5.
  • vCenter использует в 3 раза меньше памяти для основного процесса vpxd.
  • Уменьшение времени на операции, связанных с DRS, до 3 раз (например, запуск виртуальной машины).
  • Улучшение производительности Virtualization Based Security.

Здесь повышение производительности в числе транзакций в минуту составило 33% по сравнению с работой VBS в vSphere 6.5:

  • Поддержка больших страниц памяти (Large Memory Pages) размером 1 ГБ.

Хост ESXi с размером страницы в 1 ГБ (появилось в vSphere 6.7) работает на 26% лучше, чем хост со страницей в 2 МБ:

  • Улучшения драйвера vmxnet3 версии 4 в плане механизмов RSS (улучшение 28-146% в числе полученных пакетов в секунду) и VXLAN/Geneve Offload (до 415% улучшение в пропускной способности канала при некоторых условиях).
  • Поддержка новых сервисов Persistent Memory.

С помощью технологии vSphere Persistent Memory пользователи могут применять специальные аппаратные модули от Dell-EMC и HPE (DRAM NVDIMM), которые могут использовать высокопроизводительные системы хранения с большим числом IOPS или предоставлять их возможности гостевым системам как non-volatile memory.

Работает это быстрее, чем SSD (vPMEMDisk - это работа такой памяти как локальное хранилище хоста ESXi, а vPMEM - прямое предоставление хранилища гостевой системе как устройства):

  • Скорость создания мгновенных клонов (Instant Clones) виртуальных машин по сравнению со скоростью создания связанных клонов.

Мгновенные клоны создаются почти в три раза быстрее, чем связанные (время в секундах на создание 64 клонов):

Все остальное - в документе "What’s New in Performance - VMware vSphere 6.7".


Таги: VMware, vSphere, Performance

Механизм Degraded Device Handling в VMware vSAN.


Как знают пользователи решения для создания отказоустойчивых кластеров VMware vSAN, этот продукт имеет множество средств для обработки ситуаций отказа физических устройств - дисков HDD и SSD. В vSAN есть специальный механизм Degraded Device Handling (DDH), который приводит кластер в жизнеспособное сосотояние при отказе одного диска или всей дисковой группы. При этом отказом устройства считается не только его полная физическая поломка, но и резкое снижение производительности, что ведет к ухудшению качества обслуживания пользователей.

Давайте посмотрим, как это работает:

1. Механизм DDH в VMware vSAN 6.1.

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

Вот что будет в этом случае в логах:

2015-09-15T02:21:27.270Z cpu8:89341)VSAN Device Monitor: WARNING – READ Average Latency on VSAN device naa.6842b2b006600b001a6b7e5a0582e09a has exceeded threshold value 50 ms 1 times.
2015-09-15T02:21:27.570Z cpu5:89352)VSAN Device Monitor: Unmounting VSAN diskgroup naa.6842b2b006600b001a6b7e5a0582e09a

Компоненты на такой дисковой группе механизм DDH помечает как "Absent". Ребилд для таких компонентов начнется через 60 минут после отказа устройства, когда истечет rebuild timer. Если этот компонент не является частью группы RAID-1 или RAID-5/6, то он становится недоступным.

В случае с RAID-1 все продолжает работать, и если компонент witness работает, то вы получите только оповещение в vSphere Client:

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

2. Улучшения DDH в vSAN 6.2.

Здесь появилось 4 новых момента:

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

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

esxcfg-advcfg –set 1 /LSOM/lsomSlowTier1DeviceUnmount

После ее выполнения кэш-устройства и их дисковые группы будут размонтироваться при привышении порога latency на запись.

3. DDH мониторит устройства в рамках случайных 10-минутных интервалов и учитывает несколько таких интервалов. Это предотвращает ложные срабатывания механизма в случае таких операций, как vSAN component recovery, ремапинг секторов HDD-дисков, сбор мусора на SSD и прочее. Теперь для срабатывания DDH нужно 4 превышения latency в непоследовательных 10-минутных интервалах, которые случайно распределены в окне 6-7 часов.

4. DDH пытается снова смонтировать устройства vSAN, которые были ранее размонтированы по превышению latency. Число таких попыток - 24 в окне 24 часа (то есть примерно раз в час). Если условие размонтирования сохраняется, то попытки обратного монтирования прекратятся через сутки.

3. Улучшения DDH в vSAN 6.6 и более поздних версиях.

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

Для HDD дисков был сделан threshold 500 миллисекунд на запись, для SSD - 50 миллисекунд на чтение и 200 миллисекунд на запись.

Теперь, если вышедший из строя диск является последней копией данных, но с него еще как-то можно получить данные, то vSAN не пометит диск как Absent, но начнет эвакуацию данных, таймер vSAN CLOM Rebuild Timer не включится.

В этом процессе есть 4 стадии:

1. Preventative evacuation in progress - желтый аларм сработает, чтобы дать администратору знать о проблеме. vSAN сам превентивно эвакуирует данные, без необходимых действий со стороны администратора.

2. Preventative evacuation is incomplete due to lack of resources - превентивная эвакуация данных не удалась вследствие недостатка ресурсов. В этом случае будет показан красный аларм. Администратору нужно будет высвободить дисковое пространство, например, удалить ВМ или добавить больше дисков, чтобы завершить эвакуацию данных. Разработчики vSAN рекомендуют на такие случаи держать 25-30% кластера свободными.

3. Preventative evacuation is incomplete due to inaccessible objects - это самая плохая ситуация, говорящая о том, что дисковые объекты degraded-устройства недоступны. Если добавление новых ресурсов не помогает, то остается только удалить этот диск из конфигурации vSAN, выбрав опцию "no data migration".

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


Таги: VMware, vSAN, Performance, Monitoring, Hardware

Обновился VMware I/O Analyzer - теперь с поддержкой vSphere 6.5 и 6.7.


Еще в далеком 2011 году мы писали о средстве VMware I/O Analyzer, которое позволяет сгенерировать нагрузку на хранилища VMware vSphere, а после чего замерить производительность этих хранилищ. Делается это средствами интегрированного фреймворка, который поддерживает распределенную архитектуру - центральный управляющий виртуальный модуль и воркеры (генераторы нагрузки).

В 2014 году это средство еще раз обновилось для поддержки актуальных на тот момент версий ESXi, ну а на днях появилось обновление VMware I/O Analyzer 1.6.2u1, которое поддерживает VMware vSphere 6.5 и более поздние версии, то есть vSphere 6.7.

Напомним основные возможности VMware I/O Analyzer:

  • Интегрированный фрейворк для тестирования производительности хранилищ.
  • Простая настройка и возможность исполнения тестов на одном или нескольких хостах ESX/ESXi.
  • Возможность просмотра результатов производительности как на уровне хоста, так и на уровне гостевой ОС.
  • Возможность экспорта данных для последующего анализа.
  • Средства "повторения" нагрузки на хранилища путем ее воспроизведения из трейса ввода-вывода.
  • Возможность загрузки трейсов ввода-вывода для автоматического извлечения необходимых метрик.
  • Графическая визуализация метрик и результатов анализа производительности.

В новой версии I/O Analyzer 1.6.2u1 появились следующие фичи:

  • Поддержка последних версий vSphere.
  • Обновление протокола до версии OpenSSL 1.0.2o.
  • Сценарий для горячего обновления с прошлой версии 1.6.2.
  • В прошлой версии 1.6.2 были пофикшены уязвимости Shellshock и Heartbleed.

Скачать VMware I/O Analyzer 1.6.2u1 можно по этой ссылке. Инструкция к данному средству тестирования доступна тут.


Таги: VMware, Labs, Analyzer, Storage, Performance

Новый документ - VMware vSAN PoC Performance Checklist.


Компания VMware сделала доступным интересный документ VMware vSAN PoC Performance Checklist, в котором рассматриваются различные аспекты производительности кластеров хранилищ VMware vSAN, которые пользователи развертывают в рамках PoC (proof of concept).

Сначала в рамках чеклиста нам предлагают прочесть следующие документы:

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

Разделы документа:

  • "Before you Start" Tasks
  • Host Based Tasks after vSAN is Deployed
  • Choosing An Appropriate Policy to Test
  • Choosing Data Services
  • Prepping for the HCIBench Benchmark
  • Initial Functional Test -HCIBench Easy Run
  • HCI Bench - Further Tuning

Надо сказать, что эти проверки могут оказаться полезными всем тем, кто испытывает проблемы с производительностью vSAN и поиском их причин. Также в онлайн-документе VMware vSAN PoC Performance Checklist есть возможность скачать его в формате PDF. Ну и если ничего не помогло, то всегда есть почта для обращений - vsanperformance@vmware.com.


Таги: VMware, vSAN, Performance, Storage, Whitepaper

1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9    >   >>
Реклама







Зал Славы Рекламодателя
Ближайшие события в области виртуализации:

Быстрый переход:
VMware Veeam IT-Grad StarWind PowerCLI Offtopic Gartner Citrix VSAN GDPR 5nine Hardware VeeamON Nutanix vSphere RVTools Enterprise Security Code Cisco vGate Microsoft Cloud SDRS Parallels IaaS HP VMFS VM Guru Oracle Red Hat Azure KVM VeeamOn 1cloud Docker Storage NVIDIA Partnership Dell Virtual SAN Virtualization VMTurbo vRealize VirtualBox Symantec Softline EMC Login VSI Xen Teradici Amazon NetApp VDI Linux Hyper-V IBM Google VSI Security Windows vCenter VMachines Webinar View VKernel Events Windows 7 Caravan Apple TPS Hyper9 Nicira Blogs Sun VMC Xtravirt Novell IntelVT Сравнение VirtualIron XenServer CitrixXen ESXi ESX ThinApp Books P2V Labs Tools vSAN vCloud Forum iSCSI SRM HCI App Volumes Video vROPs Workspace ONE Backup Horizon VMUG NSX vRNI HA Update Manager VCP VVols Workstation Update UEM DR Networking Cache Storage DRS VMworld Workspace DRS Fusion Lifecycle Visio Log Insight Operations Manager SDDC Virtual Appliance OpenStack PowerShell LSFS Client vCSA Datacenter Intel Agent esxtop Book Photon Cloud Computing SSD Comparison Blast Performance Nested AWS XenDesktop VSA vNetwork SSO Host Client VMDK VTL Whitepaper Appliance VUM V2V Support Обучение Web Client Mobile Automation Replication Desktop Fault Tolerance Vanguard SaaS Connector Event Free SQL Sponsorship Finance FT Containers Converter XenApp Snapshots vGPU Auto Deploy SMB RDM Mirage XenClient MP SC VMM Certification VDP Partners PCoIP RHEV vMA Award Network USB Licensing Logs Server Demo vCHS Calculator Бесплатно vExpert Beta SAN Exchange MAP ONE DaaS Monitoring VPLEX UCS SDK Poster VSPP Receiver vMotion VDI-in-a-Box Deduplication Reporter vShield ACE Go nworks iPad XCP Data Recovery Documentation Sizing Pricing VMotion Snapshot FlexPod VMsafe Enteprise Monitor vStorage Essentials Live Migration SCVMM TCO Studio AMD-V VirtualCenter NFS ThinPrint Memory CLI Helpdesk Troubleshooting VIC Upgrade VDS Bug Migration Director Stencils API Android Graphics Diagram Air Plugin DPM SIOC Flex Mac Open Source SSH VAAI Chargeback Heartbeat MSCS Ports SVMotion Bugs Composer
Интересные плакаты:

Постер VMware vSphere PowerCLI 6.3:

Постер VMware ESXi 5.1:

Постер VMware Hands-on Labs 2015:

Постер VMware Platform Services Controller 6.0:

Постер VMware vCloud Networking:

Постер VMware NSX (референсный):

Постер VMware vCloud SDK:

Постер VMware vCloud Suite:

Постер VMware vCenter Server Appliance:

Порты и соединения VMware vSphere 6:

Порты и соединения VMware Horizon 7:

Порты и соединения VMware NSX:

Управление памятью в VMware vSphere 5:

Как работает кластер VMware High Availability:

Постер VMware vSphere 5.5 ESXTOP (обзорный):

Постер Veeam Backup & Replication v8 for VMware:

Постер Microsoft Windows Server 2012 Hyper-V R2:

 

Популярные статьи:
Как установить VMware ESXi. Инструкция по установке сервера ESXi 4 из состава vSphere.

Включение поддержки технологии Intel VT на ноутбуках Sony VAIO, Toshiba, Lenovo и других.

Как настроить запуск виртуальных машин VMware Workstation и Server при старте Windows

Как работают виртуальные сети VLAN на хостах VMware ESX / ESXi.

Что такое и как работает виртуальная машина Windows XP Mode в Windows 7.

Типы виртуальных дисков vmdk виртуальных машин на VMware vSphere / ESX 4.

Сравнение Oracle VirtualBox и VMware Workstation.

Инфраструктура виртуальных десктопов VMware View 3 (VDI)

Бесплатные утилиты для виртуальных машин на базе VMware ESX / ESXi.

Как использовать возможности VMware vSphere Management Assistant (vMA).

Проектирование инфраструктуры виртуализации VMware vSphere 4.

Как поднять программный iSCSI Target на Windows 2003 Server для ESX

Работа с дисками виртуальных машин VMware.

Бесплатные программы для VMware ESX / ESXi в среде Virtual Infrastructure / vSphere (часть 2).

Новые возможности VMware vSphere 5.0 - официально.

Все ресурсы о виртуализации:
Интервью:

Alessandro Perilli
virtualization.info
Основатель

Ратмир Тимашев
Veeam Software
Президент


Купить:

VMware vSphere 6.5


Veeam Backup 9.5


Полезные ресурсы:


Видео компании VMware

Видео про Citrix Xen

Видео о виртуализации Microsoft

Утилиты для виртуальных машин Microsoft.

Книги на английском языке

Блоги на английском языке

Блоги на русском языке

Агрегация статей в твиттере VMC:


Copyright VM Guru 2006 - 2019, Александр Самойленко. Правила перепечатки материалов.