Новости Статьи VMware Veeam StarWind vStack Microsoft Nakivo Citrix Symantec События Релизы Видео Контакты Авторы RSS
Виртуализация и виртуальные машины

Все самое нужное о виртуализации и облаках

Более 6180 заметок о VMware, AWS, Azure, Veeam, Kubernetes и других

VM Guru | Ссылка дня: Какие есть версии и номера билдов VMware vCenter, ESXi, Tools и Connection Server?

Ранжирование памяти (Memory Tiering) в будущих версиях VMware vSphere


Недавно Дункан Эппинг выступал с докладом на конференции VMUG в Бельгии, где была тема «Инновации в VMware от Broadcom». В ходе доклада он кратко изложил процесс и различные типы инноваций, а также то, к чему это может привести. Во время сессии он рассмотрел три проекта, а именно vSAN ESA, Distributed Services Engine и проект, над которым сейчас работают, под названием Memory Tiering.

Memory Tiering — это очень интересная концепция, которая впервые была публично представлена на конференции VMware Explore несколько лет назад как потенциальная будущая фича гипервизора. Вы можете задаться вопросом, зачем кому-то захочется ранжировать память, ведь влияние этого процесса на производительность может быть значительным. Существует несколько причин для этого, одна из которых — стоимость памяти. Еще одна проблема, с которой сталкивается индустрия, заключается в том, что емкость (и производительность) памяти не росли такими же темпами, как емкость CPU, что привело к тому, что во многих средах память стала узким местом. Иными словами, дисбаланс между процессором и памятью значительно увеличился. Именно поэтому VMware запустила проект Capitola.

Когда обсуждался проект Capitola, большинство внимания было уделено Intel Optane, и большинство интересующихся знает, что с этим случилось. Некоторые думали, что это также приведет к закрытию проекта Capitola, а также технологий ранжирования и объединения памяти. Но это совершенно не так: VMware продолжает активно работать над проектом и публично обсуждает прогресс, хотя нужно знать, где искать эту информацию. Если вы посмотрите эту сессию, станет ясно, что существует множество усилий, которые позволят клиентам ранжировать память различными способами, одним из которых, конечно, являются различные решения на базе CXL, которые скоро появятся на рынке.

Один из способов — это Memory Tiering с помощью карты ускорителя CXL, по сути, это FPGA, предназначенная исключительно для увеличения емкости памяти, аппаратной разгрузки техник ранжирования памяти и ускорения определенных функций, где память имеет ключевое значение, таких как, например, vMotion. Как упоминалось в сессии SNIA, использование карты ускорителя может привести к сокращению времени миграции на 30%. Такая карта ускорителя также открывает другие возможности, например, memory pooling, чего клиенты просили с тех пор, как в VMware создали концепцию кластера.

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

Именно здесь вступают в игру технологии VMware. На VMworld в 2021 году, когда был представлен проект Capitola, команда VMware также поделилась результатами последних тестов производительности, и было показано, что снижение производительности составило около 10% при использовании 50% оперативной памяти (DRAM) и 50% памяти Optane. Эта демонстрация показывает истинную мощь VMware vSphere, а также техник ранжирования памяти и ускорения (проект Peaberry).

В среднем снижение производительности составило около 10%, при этом примерно 40% виртуальной памяти было доступно через ускоритель Peaberry. Обратите внимание, что tiering полностью прозрачен для приложения, поэтому это работает для всех типов рабочих нагрузок. Важно понимать, что поскольку гипервизор уже отвечает за управление памятью, он знает, какие страницы являются "горячими", а какие "холодными", а это значит, что он может определить, какие страницы можно переместить на другой уровень, сохраняя при этом производительность.

В общем, ждем больше интересной информации от VMware на эту тему!


Таги: VMware, vSphere, Capitola, Memory, Performance, Blogs

Новая версия VMware VMmark 4 - первые результаты бенчмарков уже доступны


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

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

VMmark 4 также включает инфраструктурные нагрузки, такие как vMotion, Storage vMotion, Cross vMotion и Clone & Deploy. В дополнение к ним, VMware vSphere DRS также работает в тестируемом кластере для балансировки нагрузок. В VMmark 4.0 было сделано улучшение полностью автоматизированного процесса развертывания, который появился в VMmark 3 - это сокращает время, необходимое пользователям для получения ценных результатов. Большинство пользователей теперь смогут перейти от загружаемого шаблона VMmark до результатов VMmark 4 примерно за два часа для "турбо" запуска.

Бенчмарк VMmark 4:

  • Позволяет точно и повторяемо оценивать производительность виртуальных датацентров на основе vSphere.
  • Использует разнообразные традиционные, устаревшие и современные нагрузки приложений в разнородном модульном подходе.
  • Облегчает анализ и сравнение изменений в оборудовании, программном обеспечении и конфигурациях виртуальных сред VMware.
  • Уровни создаваемой нагрузки теперь значительно выше, чем в предыдущих версиях VMmark, чтобы лучше отражать современные реалии.

Обновления удобства использования VMmark 4:

  • Новый режим "Быстрый старт" для развертывания, запуска и получения результатов бенчмарка с помощью одной команды.
  • Новые режимы развертывания, которые позволяют большую гибкость в распределении виртуальных машин по более разнообразным хранилищам.
  • Функциональность частичных модулей (Partial Tile) для увеличения гранулярности бенчмарка через предписанное включение рабочих нагрузок приложений в конечный модуль.
  • Дизайн "Автоматизация в первую очередь" - многие основные операции администрирования vSphere теперь доступны пользователям. Операции, такие как deleting_all_vmmark4, manual_xvmotion и power_vmmark4_tiles, помогают пользователям в полной автоматизации VMmark 4. Посмотрите вывод команды vmmark4service для получения списка из более чем 20 новых доступных операций.
  • Улучшенная HTML-отчетность - пользователи теперь автоматически получают улучшенный HTML-вывод для пропускной способности, качества обслуживания и операций инфраструктуры для каждого запуска.
  • Новое приложение "disclosure creator", которое упрощает и автоматизирует создание HTML файлов.
  • Сбор данных о потреблении энергии - новый подход VMmark 4 к пониманию потребления энергопотребления. Этот режим собирает метрики энергопотребления на тестируемых системах и генерирует улучшенный HTML-отчет, чтобы помочь пользователям посчитать потребление энергии как хостами, так и виртуальными машинами.
  • Интеграция оповещений - оповещения в Slack и Google Chat легко встраиваются в VMmark 4 и включаются одним параметром.

Рабочие нагрузки приложений VMmark 4:

  • NoSQLBench - это новая рабочая нагрузка приложения в VMmark 4, используемая для анализа производительности новой распределенной NoSQL базы данных Apache Cassandra на 3 узлах.
  • SocialNetwork - эта новая рабочая нагрузка приложения в VMmark использует Docker-контейнеры для моделирования социальной сети с операциями, такими как создание постов, подписка на пользователей и т.д.
  • DVDstore (обновлено до версии 3.5) - включает PostgreSQL и параллельную загрузку базы данных, сокращая время на развертывание первого модуля.
  • Weathervane (обновлено до версии 2.0) - это масштабируемое веб-приложение, имитирующее онлайн-аукцион, теперь работает в Kubernetes контейнерах и в виртуальных машинах.
  • Standby - сервер Standby имитирует heartbeat-сервер, который периодически пингуется, чтобы убедиться, что он все еще работает и подключен.

Инфраструктурные нагрузки VMmark 4:

  • vMotion - эта операция инфраструктуры выполняет живую миграцию одной из Standby ВМ по круговой схеме, чтобы смоделировать современные операции системного администратора.
  • Storage vMotion - для этой операции одна из ВМ AuctionWebF мигрируется на указанное пользователем хранилище для обслуживания, а затем через некоторое время возвращается в исходное место.
  • Cross vMotion (XvMotion) - эта операция одновременно перемещает одну из ВМ DS3WebA на альтернативный хост и хранилище для обслуживания. Аналогично операции Storage vMotion, через некоторое время ВМ возвращается в исходное место.
  • Автоматическое балансирование нагрузки (DRS) - VMmark требует, чтобы DRS был включен и работал, чтобы гарантировать типичные операции ребалансировки в тестируемой среде.

Скачать VMware VMmark 4.0 можно по этой ссылке.

Также на днях стали доступны первые результаты тестирования производительности различного оборудования с помощью VMmark 4.0. Их можно посмотреть вот тут.


Таги: VMware, VMmark, Update, Performance, ESXi, vSphere

Тестирование производительности рабочих нагрузок Oracle на платформе VMware vSAN ESA


Продолжаем рассказывать о производительности решения vSAN Express Storage Architecture (ESA), где реализовано высокопроизводительное кодирование RAID 5/6 с исправлением ошибок. Клиенты могут ожидать, что RAID-5/6 будет работать наравне с RAID-1 при использовании vSAN ESA. Новая архитектура обеспечит оптимальные уровни устойчивости, которые также эффективны с точки зрения использования пространства, при этом соблюдается высокий уровень производительности. Все это достигается с использованием технологии RAID-6 на базе новой журналируемой файловой системы и формата объектов.

Компания VMware провела тестирование работы баз данных Oracle в среде vSAN ESA и опубликовала некоторые результаты.

Тестовый стенд

Тестовая площадка представляла собой кластер из 8 узлов vSAN 8 Express Storage Architecture (ESA) со следующими настройками:

  • Версия vCenter 8.0.2 сборка 22385739
  • 8 серверов Lenovo ThinkAgile VX7531 Node, 2 сокета, 28 ядер на сокет, Intel Xeon Gold 6348 CPU @ 2.60GHz, 1TB RAM
  • VMware ESXi 8.0.2, сборка 22380479 с vSAN ESA (все хранилища - NVMe)
  • Oracle 21.13 Grid Infrastructure, ASM Storage и Linux udev (размер блока базы данных 8k)
  • OEL UEK 8.9

Детали кластера vSAN Express Storage Architecture (ESA) "env175" показаны ниже. Кластер ESA состоит из 8 серверов Lenovo ThinkAgile VX7531, как показано на картинке:

Каждый сервер Lenovo ThinkAgile VX7531 имеет 2 сокета, 28 ядер на сокет, Intel Xeon Gold 6348 CPU на частоте 2.60GHz и 1TB RAM:


Каждый сервер Lenovo ThinkAgile VX7531 имеет 6 внутренних накопителей NVMe, таким образом каждый сервер дает 6 внутренних устройств NVMe в качестве емкости датастора vSAN ESA:

Информация о сервере ThinkAgile VX7531 "env175-node1.pse.lab" в части деталей HBA и внутренних устройств NVMe:

Политики хранения кластера vSAN Express Storage Architecture (ESA) показаны на картинке ниже.

Базовая политика Oracle "Oracle ESA – FTT0 – NoRAID" была создана только для получения эталонных метрик для сравнения, кроме того, настоящая производственная нагрузка никогда не настраивается с FTT=0 (количество допустимых отказов) и без RAID (то есть без защиты).

  • Oracle ESA – FTT0 – NoRAID
  • Oracle ESA – FTT1 – R5
  • Oracle ESA – FTT2 – R6

Детали виртуальной машины "Oracle21C-OL8-DB_ESA" показаны на картинке ниже.

Виртуальная машина имеет 28 vCPU, 256 ГБ RAM. Один экземпляр базы данных "ORA21C" был создан с опцией multi-tenant на базе инфраструктуры Oracle Grid (ASM). Версия базы данных - 21.13 на операционной системе OEL UEK 8.9.

Oracle ASM использовалась как платформа хранения данных с Linux udev для обеспечения персистентности устройств. Oracle SGA и PGA были установлены на 64G и 10G соответственно. Также были соблюдены все лучшие практики платформы Oracle на VMware.

Виртуальная машина "Oracle21C-OL8-DB_ESA" имеет 4 контроллера vNVMe для дополнительной производительности:

58 устройств хранения привязаны к ВМ "Oracle21C-OL8-DB_ESA", они показаны ниже:

  • NVME 0:0 – 80G для OS (/)
  • NVME 0:1 – 80G для Oracle Grid и бинарников RDBMS
  • NVME 0:2 – 100G для GRID_DG
  • NVME 0:3 – 200G для DATA_DG
  • NVME 0:4 – 200G для DATA_DG
  • NVME 0:5 – NVME 0:12 – 8 дисков vmdk, каждый 25 ГБ – REDO_DG
  • NVME 1:0 – 1:14 – 15 дисков vmdk, каждый 50 ГБ – SLOB_DG
  • NVME 2:0 – 2:14 – 15 дисков vmdk, каждый 50 ГБ – SLOB_DG
  • NVME 3:0 – 3:14 – 15 дисков vmdk, каждый 50 ГБ – SLOB_DG

Детали тестов разных политик хранения vmdk для ВМ "Oracle21C-OL8-Customer" показаны ниже:

  • Тест 1 – Прогон теста со всеми vmdk с политикой хранения "Oracle ESA – FTT0 – NoRAID"
  • Тест 2 – Прогон теста со всеми vmdk с политикой хранения "Oracle ESA – FTT1 – R5"
  • Тест 3 – Прогон теста со всеми vmdk с политикой хранения "Oracle ESA – FTT2 – R6"

Детали группы дисков Oracle ASM показаны ниже:

Тестовый сценарий

Результаты ниже являются тестовым сценарием, демонстрирующим преимущества производительности использования vSAN 8 vSAN Express Storage Architecture (ESA) для бизнес-критичных производственных нагрузок Oracle.

Генератор нагрузки SLOB был запущен против 2 TB табличного пространства SLOB с 3 различными политиками хранения.

  • Oracle ESA – FTT0 – NoRAID
  • Oracle ESA – FTT1 – R5
  • Oracle ESA – FTT2 – R6

В качестве генератора нагрузки для этого эксперимента был выбран SLOB 2.5.4.0 с следующими установленными параметрами SLOB:

UPDATE_PCT=30
RUN_TIME=300
SCALE=25G
WORK_UNIT=1024

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

Размер рабочего блока был установлен в 1024 для максимизации объема ввода-вывода без перегрузки REDO для изучения различий в показателях производительности между 3 различными политиками хранения на vSAN ESA.

В VMware провели несколько прогонов SLOB для вышеупомянутого кейса и сравнили метрики Oracle, как показано в таблице ниже.

Напомним, что базовая политика Oracle "Oracle ESA – FTT0 – NoRAID" была создана ИСКЛЮЧИТЕЛЬНО для получения базовых метрик для сравнения, так как настоящая производственная нагрузка никогда не настраивается с FTT=0 и без RAID.

Мы видим, что метрики базы данных с новым высокопроизводительным кодированием RAID 5/6 архитектуры vSAN Express Storage Architecture (ESA) сопоставимы с базовыми показателями при использовании без RAID.

Как было сказано ранее, клиенты могут ожидать, что RAID-5/6 будет работать наравне с RAID-1 при использовании vSAN ESA. Новая архитектура обеспечит оптимальные уровни устойчивости, а также эффективность с точки зрения использования пространства.

Углубляясь в профили нагрузки основных баз данных, мы видим схожие метрики баз данных для исполнений запросов (SQL), транзакций, чтения/записи в IOPS и чтения/записи в МБ/сек как для прогонов политик хранения "Oracle ESA – FTT1 – R5", так и для "Oracle ESA – FTT2 – R6", а именно:

  • Выполнение запросов (SQL) в секунду и транзакции в секунду сопоставимы для всех трех прогонов
  • Запросы на чтение IO в секунду и запросы на запись IO в секунду сопоставимы для всех трех прогонов
  • Чтение IO (МБ) в секунду и запись IO (МБ) в секунду сопоставимы для всех трех прогонов

Углубляясь в изучение основных событий ожидания (wait events) базы данных, мы видим схожие события ожидания базы данных с похожими временами ожидания (wait times) для прогонов политик хранения "Oracle ESA – FTT1 – R5" и "Oracle ESA – FTT2 – R6".

Рассматривая статистику GOS, мы также можем видеть сопоставимые показатели производительности для запусков политик хранения "Oracle ESA – FTT1 – R5" и "Oracle ESA – FTT2 – R6":

В итоге нам удалось получить сопоставимые показатели производительности как с общей точки зрения базы данных, так и с точки зрения GOS для прогонов политик хранения "Oracle ESA – FTT1 – R5" и "Oracle ESA – FTT2 – R6".


Таги: VMware, vSAN, Oracle, Performance, ESXi, Storage, VMDK, ESA

Результаты тестирования нового инстанса m7i в инфраструктуре VMware Cloud on AWS для нагрузки Microsoft SQL Server


Пару лет назад мы писали о производительности Microsoft SQL Server в облаке VMware Cloud on AWS для инстанса AWS-i4i.metal. С тех пор много что изменилось, а компания VMware анонсировала новый тип экземпляра m7i для VMware Cloud на AWS, который использует сетевое хранилище NFS вместо vSAN. Это предоставляет клиентам гибкое и масштабируемое хранилище на основе VMware Cloud Flex Storage и Amazon FSx для NetApp ONTAP.

Для других типов экземпляров VMware Cloud на AWS включено хранилище vSAN, которое базируется на локальных дисках каждого хоста. Хранилища данных vSAN растут вместе с кластером по мере добавления новых узлов. С m7i количество хранилища не зависит от числа хостов, и вы можете настроить его в зависимости от требований к хранилищу.

Ниже рассмотрим производительность виртуальных машин SQL Server, работающих на 3-узловом кластере m7i с хранилищем NFS, по сравнению с 3-узловым кластером i4i с хранилищем vSAN. Инстансы m7i основаны на процессорах Intel, которые на одно поколение новее, чем i4i. Вот чем отличаются эти инстансы:

Методология

Для тестов использовался набор ВМ с 16 vCPU и 24 vCPU. Поскольку экземпляры m7i имели 48 ядер, как 16 vCPU, так и 24 vCPU были равномерно распределены по общему количеству ядер, что облегчало сравнение производительности и делало его понятным. Для поддержки максимального числа ВМ с 16 vCPU на кластере m7i каждой ВМ назначили 60 ГБ ОЗУ.

Для тестов использовали ВМ Windows Server 2022 с установленным Microsoft SQL Server 2022 и применили открытый инструментарий бенчмаркинга DVD Store 3.5 для запуска нагрузок OLTP-приложений на SQL Server и измерения результатов. DVD Store симулирует онлайн-магазин, где клиенты просматривают, оставляют отзывы и оценивают, регистрируются и покупают продукты. Результаты выражаются в заказах в минуту (OPM), что является мерой пропускной способности. Чем выше показатели OPM - тем лучше.

Результаты производительности ВМ SQL Server с 24 vCPU против 16 vCPU

Результаты на рисунках 1 и 2 показывают производительность ВМ с 24 vCPU и 16 vCPU. Линия обозначает общую пропускную способность в OPM по всем ВМ в каждом тесте. Количество ВМ увеличивается в каждом тесте, начиная с 1 и заканчивая максимально возможным, исходя из количества vCPU, соответствующих числу доступных потоков в кластере.

Темп прироста OPM замедляется, когда количество vCPU превышает количество физических ядер и необходимо использовать второй логический поток (hyperthread) на каждом ядре. Это начинается с 8 и 12 ВМ для тестов с 24 и 16 vCPU соответственно.

Столбцы в каждом графике представляют использование CPU трех хостов для каждого теста. По мере добавления ВМ, VMware Distributed Resource Scheduler (DRS) автоматически размещал и, возможно, динамически перемещал ВМ между хостами для управления нагрузкой. Как показывают результаты, это поддерживало использование CPU на всех хостах довольно стабильным, даже когда нагрузка увеличивалась.

Последняя точка данных в тесте с 16 vCPU (рисунок 2) показывает небольшое снижение OPM, поскольку на этом этапе теста кластер немного перегружен. Несмотря на это, можно было продолжить масштабирование производительности кластера m7i, добавляя больше инстансов. В этих тестах был использован только кластер из 3 инстансов, но можно было бы добавить больше инстансов в кластер для увеличения его емкости.

Рисунок 1 - производительность виртуализированного SQL Server и использование CPU ESXi для кластера из 3 хостов VMware Cloud на AWS с 24 vCPU на ВМ:

Рисунок 2 - производительность виртуализированного SQL Server и использование CPU ESXi для кластера из 3 хостов VMware Cloud на AWS с 16 vCPU на ВМ:

Рисунок 3 сравнивает производительность ВМ с 16 vCPU и 24 vCPU таким образом, что в каждом тестовом случае назначалось одинаковое общее количество vCPU. Например, для 48 vCPU 2?24 vCPU сравниваются с 3?16 vCPU (по сумме - 48 в обоих случаях).

Рисунок 3 - производительность ВМ SQL Server: 16 vCPU по сравнению с 24 vCPU:

Сравнение производительности m7i с i4i

Те же ВМ были перенесены на кластер i4i и тесты повторили. Важно отметить, что чтобы сохранить ВМ максимально идентичными, им не увеличивали объем RAM, несмотря на то, что в кластере i4i было примерно в 2,5 раза больше RAM.

Как показывает рисунок 4, результаты для i4i были схожи в плане OPM и использования CPU хоста. Основное отличие: получилось запустить до 24 ВМ на i4i против максимума 18 ВМ на m7i. Это связано с большим количеством ядер и большей памятью в экземплярах i4i.

Рисунок 4 - трехузловой кластер i4i VMware Cloud on AWS: SQL Server ВМ и использование CPU хоста на ВМ с 16 vCPU по сравнению с vSAN:

Рисунок 5 показывает различия между m7i и i4i. Поскольку отдельные ядра экземпляров m7i имеют более высокую производительность, чем ядра кластера i4i, рисунок 5 показывает преимущество в производительности на левой стороне графика. Как только экземплярам m7i необходимо полагаться на второй логический поток (hyperthread) от каждого физического ядра для поддержки рабочих нагрузок, производительность i4i становится схожей. И, наконец, когда экземпляры i4i полностью используют преимущество большего количества ядер, их производительность превышает производительность m7i.

Рисунок 5 - различие между m7i и i4i:

Тестирование производительности говорит о хорошей работе SQL Server на m7i в рамках предоставляемой экземплярами m7i ресурсной емкости. Поскольку экземпляры m7i имеют меньше ядер и меньше памяти, чем i4i, важно использовать инструмент VMC Sizer, чтобы убедиться, что платформа соответствует потребностям баз данных.

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


Таги: VMware, Cloud, AWS, SQL, Performance, Hardware

Метрика Health Score для определения здоровья приложений в решении VMware Avi Load Balancer


Продолжаем рассказывать о решении VMware Avi Load Balancer, которое недавно стало доступно в качестве балансировщика как услуги (Load Balancer as a Service, LBaaS) для решения Aria Automation 8.16.1.

Часто менеджеров датацентров мучает простой вопрос – как администраторы знают, что приложения находятся в "хорошем" состоянии? В VMware провели огромное количество встреч и дебатов по теме, касающейся "здоровья приложений" - приведем ниже основные моменты статьи сотрудников Avi, касающейся здоровья приложений.

В команде были люди с разным опытом, им всем задали один и тот же вопрос – "что для вас значит здоровье приложения?". Вот некоторые из ответов, которые были получены:

  • "Здоровье" – это пропускная способность (throughput), которую может обеспечивать приложение. Если она составляет 10 Гбит/с, это значит, что оно в хорошем состоянии.
  • Здоровье плохое, когда CPU и память загружены более чем на 100%.
  • Здоровье хорошее, когда задержка (latency) ниже 100 мс.
  • Здоровье хорошее, если приложение работает и отвечает на проверки (health checks).

В реальном мире, если спросить вас - "вы считаете, что у меня хорошее здоровье, если я пробежал сегодня 3 мили?", в зависимости от того, кто вы, вы, скорее всего, ответите: "это зависит от разных факторов", "конечно!", "ты пробежал только сегодня или бегаешь каждый день?" или "каков был твой пульс и жизненные показатели после бега?". У вас будет много дополнительных вопросов, чтобы углубиться в детали. С этой точки зрения, теннисист Роджер Федерер, скорее всего, выиграл бы по этому показателю у большинства людей, даже если бы бегал с гриппом. Сделало бы это его здоровым? Конечно нет!

Как вы видите, простой факт возможности пробежки на 3 мили недостаточен для врача, чтобы выдать заключение о хорошем здоровье. Аналогично, если вы думаете, что можете определить здоровье сервера, исходя из простого факта, что он может обрабатывать пропускную способность 10 Гбит/с, вы, вероятно, ошибаетесь. Автору было трудно с этим смириться, особенно учитывая, что большую часть своей карьеры до Avi он провел в компании по производству оборудования, где было нормально считать, что сетевое оборудование в отличном состоянии, когда соединение работает и передает данные с пропускной способностью 10 Гбит/с.

Аналогии со здоровьем человека

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

На секунду давайте представим команду Golden State Warriors как веб-приложение. Тогда звездный баскетболист Стефен Карри, вероятно, был бы важным микросервисом в этом приложении. Как бы мы измеряли его здоровье? Конечно, когда Карри здоров, мы ожидаем, что он будет набирать около 30 очков за игру в среднем. Мы также не ожидаем, что он устанет во время игры. В хорошем состоянии здоровья (измеряемом с помощью таких показателей, как пульс, кровяное давление и т. д.) от Карри ожидают, что он будет последовательно и ровно выступать.

Автор применил аналогичную философию к измерению здоровья приложений. Вот определение здоровья от Merriam-Webster, которое он счел релевантным:

"состояние организма в отношении выполнения его жизненно важных функций, особенно оцениваемое субъективно или непрофессионально"

Автор немного улучшил это определение для "оценки здоровья" приложений в Avi:

"Avi Health (Score) – это мера производительности приложения и его постоянства, которая отражает любые риски для приложения в контексте различных факторов, таких как ресурсы и безопасность."

Пока все хорошо. Авторы определили оценку здоровья Avi. Однако оставался "слон в комнате" — как определять термины "производительность", "риски" и т. д. Вот как дальше было конкретизировано определение оценки здоровья:

  • Performance Score: оценка производительности приложения отражает способность приложения соответствовать и превосходить SLA (соглашения об уровне обслуживания). Метрики производительности должны однозначно показывать хорошее состояние против плохого и указывать на соответствие приложения SLA. В этом случае метрики, такие как максимальное количество одновременных подключений или транзакций в секунду, стали неприемлемы, поскольку эти метрики не могли быть выражены как хорошие или плохие транзакции. Поэтому в VMware построили платформу, использующую множество метрик производительности, таких как качество ответа, качество соединения и качество опыта клиентов, для представления производительности приложения.
  • Resources Risk (Penalty): следующим важным набором метрик было определение, достаточно ли у приложений ресурсов (или выносливости, энергии и т.д.) для постоянного соответствия требованиям производительности. Оценка здоровья Avi комбинирует несколько метрик, таких как использование CPU, использование памяти, использование программной очереди, использование лицензий и т.д. Вместо прямой шкалы были применены человеческие принципы к ресурсам, которые накладывают штрафы только тогда, когда использование ресурсов превышает пороговое значение (скажем, 80%).
  • Security Risk (Penalty): так же, как люди лучше работают, когда они находятся в безопасной умственной, физической и социальной среде, в VMware пришли к выводу, что уязвимости приложения должны приводить к снижению его здоровья. Например, использование слабых шифров для SSL приводит к снижению оценки здоровья Avi.
  • Application Performance Consistency (Anomaly penalty): тут считается, что согласованность производительности является очень важной мерой здоровья приложения. Неважно, если производительность достаточна в периоды низкой нагрузки, если она снижается в периоды пиковой нагрузки.

Теперь, когда определена оценка здоровья Avi, все еще нужно проработать детали того, как комбинировать качество сети с качеством HTTP-ответа, как рассчитывать оценку, когда и память, и CPU используются более чем на 80% и т.д.

Уточнение алгоритма

Пока спор о том, как определить оценку здоровья Avi, еще не был урегулирован, у авторов возник еще один горячий спор о том, как должны работать числа. Аналитическая команда Avi создала два правила, которые должны служить руководящими принципами для объединения информации, связанной со здоровьем приложений:

1. Когда есть две метрики или факторы здоровья различного рода, то используется наименее здоровый фактор для представления Health Score. Например, у человека может быть очень крепкое сердце, но опухоль в головном мозге. Нет смысла вычислять "среднее здоровье" между этими органами, но важно подчеркнуть, что тело не в очень хорошем состоянии из-за опухоли в мозге. Для программного обеспечения выразили эти ситуации как здоровье = min(здоровье_A, здоровье_B), когда необходимо объединить здоровье двух факторов A и B.

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

Еще одним важным моментом было, должно ли здоровье приложения основываться на мгновенных метриках или должно включать историю производительности. Большинство пользователей и сотрудников разделились на две группы: 1) команда с опытом в индустрии аппаратного обеспечения, которая отвечала, что здоровье приложения должно основываться на мгновенной информации и 2) команда с программным/операционным опытом, которая склонялась к анализу тенденций и истории. Опять же, в VMware использовали стратегии принятия решений в области здоровья человека, чтобы разрешить спор – считается, что человек еще не в хорошем здоровье, если он все еще восстанавливается после недавней болезни.

Поэтому было принято решение смотреть на метрики последних 6 часов, чтобы определить оценку здоровья приложения. На платформе Avi Vantage, когда администратор приложения видит идеальную оценку здоровья (100), он может с уверенностью сказать, что за предыдущие 6 часов здоровье приложения было идеальным и приложение соответствовало его ожиданиям по производительности.

Avi Health Score - это основа

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

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

Так что теперь вы знаете, как работает метрика Health Score в Avi, и что означают все эти пункты:


Таги: VMware, Avi, Networking, Performance

Что нового в технологии VMware Cloud Flex Storage на февраль 2024 года?


Почти два года назад мы писали о решении Cloud Flex Storage, которое представляет собой распределенное хранилище и средства управления данными, полностью управляемые со стороны VMware. Это комбинация cloud-native абстракций, реализующих службы хранения для клиентов, которая предоставляет высокопроизводительные сервисы для современных нагрузок.

С помощью VMware Cloud Services Console пользователи могут масштабировать облачные хранилища без необходимости добавления дополнительных хостов и регулировать доступные емкости как вверх, так и вниз, для каждого из работающих приложений. Также здесь работает модель оплаты по мере потребления ресурсов (pay-as-you-go).

Когда VMware впервые представила Cloud Flex Storage на мероприятии VMware Explore 2022, основной целью было предоставить решение для управления данными и облачным хранилищем уровня предприятия. С тех пор компании разных размеров уже внедрили Cloud Flex Storage для легкого масштабирования хранилищ без добавления хостов, что для многих из них привело к значительной экономии средств. Теперь, с улучшениями, которые были представлены недавно, существенно расширен спектр поддерживаемых рабочих нагрузок, включая критически важные задачи. Основные направления развития продукта - это увеличение масштабируемости сервиса и укрепление его устойчивости.

Итак, давайте посмотрим, что нового:

1. Увеличенная масштабируемость: расширение объема облачного хранилища с эластичным ростом

В этом обновлении VMware Cloud Flex Storage теперь предоставляется дизагрегированное хранилище уровня петабайтов на платформе VMware Cloud on AWS. VMware удвоила доступную емкость на одном хранилище с 400 ТБ до 800 ТБ. Кроме того, теперь поддерживаются до 4 хранилищ на одном SDDC, что позволяет клиентам использовать до 3.2 петабайт хранилища в одном SDDC.

2. Повышение устойчивости: обеспечение производительности для критических приложений

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

За подробностями о нововведениях технологии VMware Cloud Flex Storage вы можете обратиться к этой странице.


Таги: VMware, Cloud, Storage, Enterprise, Performance, Update

Минимальное число хостов VMware vSAN ESA в зависимости от типа RIAD


С выходом обновленной версии VMware vSAN 8 в этом решении появилась новая архитектура гиперконвергентной инфраструктуры Express Storage Architecture (ESA). Она позволяет достичь максимальных показателей производительности и эффективности на базе высокопроизводительных систем хранения.

Дункан Эппинг в ответ на запрос пользователей решения vSAN ESA сделал интересный пост на тему минимально необходимого числа хостов, которое требуется для поддержания определенного уровня избыточности - RAID-0/1/5/6.

В VMware vSAN 8 Update 1 появился адаптивный алгоритм записи, который существенно уменьшает избыточность записи на RAID-конфигурации. Когда мы рассматриваем, куда записываются данные по умолчанию используя путь записи ESA для объекта, использующего erasure codes для RAID-6, это уменьшает избыточность записи данных с 4,5x (3x для тройного зеркала + 1,5x для полосы RAID-6 4+2 с двойной паритетной проверкой) до всего лишь 1,5x. Это не только сокращает объем вычислений в процессорах, но и уменьшает сетевой трафик. Этот новый адаптивный путь записи приводит к большему объему передачи данных для всех рабочих нагрузок, которые склонны генерировать большие размеры I/O или большое количество ожидающих операций, создавая ситуации, обычно называемые большим количеством необработанных операций ввода-вывода (high outstanding I/O).

Теперь для vSAN ESA на базе RAID-5, в зависимости от размера кластера, могут быть использованы конфигурации 2+1 или 4+1, а конфигурация 3+1 больше не поддерживается. При этом для RAID-1 и RAID-6 в конфигурациях ничего не изменилось.

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


Таги: VMware, vSAN, ESA, Storage, Hardware, Performance, ESXi

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


В прошлом году мы много писали о технологии SmartNIC/DPU (data processing unit). На конференции VMworld 2020 Online ковидного года компания VMware представила одну из самых интересных своих инициатив по сотрудничеству с вендорами оборудования - Project Monterey. Тогда же и была представлена технология SmartNIC, которая позволяет обеспечить высокую производительность, безопасность по модели zero-trust и простую эксплуатацию в среде VCF.

SmartNIC - это специальный сетевой адаптер (NIC) c модулем CPU на борту, который берет на себя offload основных функций управляющих сервисов (а именно, работу с хранилищами и сетями, а также управление самим хостом).

DPU (data processing unit) - это эволюционное развитие технологии SmartNIC. Этот модуль включает в себя функции оффлоадинга, гибкого программируемого конвейера, обработки данных и CPU, характерные для SmartNIC. Однако DPU является эндпоинтом сетевой инфраструктуры, а не сервером, в котором он находится. DPU содержат специализированные чипы и, в некоторых случаях, настраиваемые программируемые вентильные массивы или специальные интегральные схемы под конкретный сценарий использования.

DPU может поддерживать гораздо больше функций, чем SmartNIC, включая сетевые возможности на основе программируемых конвейеров P4, состояний брандмауэров четвертого уровня, сетевого взаимодействия L2/L3, балансировки нагрузки L4, маршрутизации хранения данных, аналитики хранения и VPN. Функциональность DPU варьируется в зависимости от производителя. Некоторые из крупнейших игроков на рынке в 2022-2023 годах - это Fungible, AMD Pensando и Marvell.

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

Приведем немного интересных скриншотов из видео. Результаты теста iperf по сравнению с обычными сетевыми картами:

Результаты теста под нагрузкой на CPU (здесь очевидно результаты лучше, так как DPU берет на себя функции CPU в части обработки сетевых функций):

Нормализованное использование ядер хостовых процессоров на 1 Гбит/сек при обработке сетевых задач (CPU почти не используется, когда есть DPU):


Таги: VMware, Networking, Performance, Hardware, DPU, SmartNIC, Video

Улучшения производительности VMware Cloud On AWS от релиза к релизу


Компания VMware с каждым релизом улучшает все аспекты платформы Cloud on AWS, включая производительность и надежность. Хотя эти улучшения происходят постепенно с каждым новым релизом, в совокупности они дают впечатляющие улучшения, если смотреть на них через несколько релизов. Давайте оглянемся назад и посмотрим, как много эти постепенные улучшения дали клиентам в плане производительности и устойчивости их рабочих нагрузок, работающих в VMware Cloud на AWS.

Сравнение релиза 1.03 с релизом 1.24

За последние шесть лет VMware отслеживала постепенные улучшения, добавляемые с каждым новым релизом. Сложное валидационное тестирование VMware гарантирует, что новые функции и возможности всегда приводят к улучшению платформы для клиентов. В мире платформенных решений "лучше" может означать разные вещи. Хотя простота использования и другие характеристики, безусловно, важны, такие характеристики, как производительность и операционная эффективность, гораздо проще измерить в плане улучшений. Ниже представлены данные сравнения релиза 1.03, дебютировавшего 7 марта 2018 года, с релизом 1.24, доступным с 14 ноября 2023 года, для одного и того же типа инстанса i3.metal.

Производительность ввода/вывода

Мелкие операции ввода/вывода (I/O). Операции чтения и записи, состоящие из мелких I/O, иногда считаются более легким типом ввода/вывода для обработки системой хранения. Однако они ставят некоторые проблемы, насыщая внутренние очереди и буферы, и остаются важным типом ввода/вывода для приложений, генерирующих последовательные I/O. В релизе 1.24 операции чтения блоков 4KB показывают увеличение производительности на 21% по сравнению с релизом 1.03, а операции записи 4 KB показывают улучшение на 76% по сравнению с релизом 1.03.

Большие операции ввода/вывода. Операции чтения и записи, состоящие из больших размеров I/O, обычно являются наиболее сложными в обработке для систем хранения. Они запрашивают или записывают огромное количество данных для относительно небольшого числа команд чтения и записи. Это может создать нагрузку на физическую пропускную способность сети и аппаратное обеспечение сервера. Если сравнить большие операции I/O, состоящие из чтения и записи блоками 256 KB, можно увидеть значительные улучшения. В релизе 1.24 операции чтения 256 KB показывают увеличение производительности на 53% по сравнению с релизом 1.03, а операции записи 256 KB показывают улучшение на 89% по сравнению с релизом 1.03.

Улучшение производительности ввода/вывода имеет очевидное преимущество в том, что хосты смогут обрабатывать больше операций в секунду (IOPS) и больший объем данных (throughput), а рабочие нагрузки могут коллективно достигать более высоких уровней производительности, если приложения этого требуют. Но часто упускаемым из виду и, возможно, даже более важным является улучшение постоянства производительности. Задержки будут более последовательными, поскольку система хранения может обработать операции чтения и записи быстрее, сокращая период, в течение которого приложения могут конкурировать за ресурсы.

Операционная эффективность

Преимущества улучшения производительности не ограничиваются только лучшей производительностью рабочих нагрузок. Эти улучшения переводятся в реальные улучшения операционной эффективности. Например, телеметрические данные VMware показывают, что при сравнении релиза 1.03 с релизом 1.24 время, необходимое системе для восстановления от воздействия аппаратного сбоя, сократилось более чем на 80%. Эти процессы восстановления полностью автоматизированы и прозрачны для пользователей приложений и тех, кто администрирует рабочие нагрузки.

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


Таги: VMware, Cloud, AWS, Performance, Update

Интересное видео о производительности архитектуры VMware vSAN Express Storage Architecture (ESA)


Напомним, что в конце прошлого года в решении vSAN 8 появилась новая архитектура гиперконвергентной инфраструктуры Express Storage Architecture (ESA). Она позволяет достичь максимальных показателей производительности и эффективности на базе высокопроизводительных систем хранения.

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

Ранее мы рассказывали об объектах Storage Pools в vSAN ESA, а также о реализации механизмов повышенной производительности в VMware vSAN 8 Update 1. Ну а недавно компания VMware опубликовала интересное видео, в котором рассказывается о производительности vSAN ESA в сравнении с OSA:

Посмотрим на некоторые полезные скриншоты из видео. Улучшения производительности на уровне отдельного VMDK (RAID-6 ESA работает лучше, чем RAID-1 OSA):

Результаты теста SPEC - время отклика при увеличении числа операций в секунду:

Зависимость задержек (latency) от числа снапшотов на хранилище:

Также почитайте, как именно улучшения производительности VMware vSAN 8 Update 1 влияют на разные типы приложений.


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

Обновленный документ Performance Best Practices for VMware vSphere 8.0 Update 2


В начале года мы писали о документе "Performance Best Practices for VMware vSphere 8.0", в котором приведены основные рекомендации по обеспечению высокой производительности флагманской платформы виртуализации компании VMware. В середине этого года было сделано обновление этого руководства, которое было выпущено под названием "Performance Best Practices for VMware vSphere 8.0 Update 1".

В конце октября вышел очередной апдейт этого сверхполезного документа на 100 страницах - "Performance Best Practices for VMware vSphere 8.0 Update 2".

В руководство добавили различные рекомендации и новые максимальные значения инфраструктуры, касающиеся именно vSphere 8 Update 2 и vSAN 8 Update 2.

Как и всегда, документ разбит на 4 больших блока, касающихся оборудования, самой платформы vSphere и серверов ESXi, виртуальных машин, их гостевых систем и средств управления виртуальной инфраструктурой:

  • Hardware for Use with VMware vSphere (страница 11)
  • ESXi and Virtual Machines (страница 25)
  • Guest Operating Systems (страница 55)
  • Virtual Infrastructure Management (страница 67)

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

Скачать Performance Best Practices for VMware vSphere 8.0 Update 2 можно по этой ссылке.


Таги: VMware, Performance, vSphere, ESXi, vSAN, Whitepaper, Update

Опубликована референсная архитектура Microsoft SQL Server на платформе VMware vSAN ESA


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

Партнерство между Lenovo для линейки ThinkAgile VX Series и VMware в рамках технологии vSAN Express Storage Architecture (ESA) позволяет создать передовую гиперконвергентную инфраструктуру (HCI), работающую на новейших аппаратных платформах. Это решение разработано для удовлетворения сложных потребностей современных организаций, ориентированных на данные.

Референсная архитектура Microsoft SQL Server на платформе VMware vSAN ESA посвящена запуску Microsoft SQL Server на VMware vSAN ESA с Lenovo ThinkAgile VX Series.

В VMware vSAN 8 и vSAN ESA произошли значительные изменения, которые включают в себя использование высокопроизводительных NVMe-дисков и новый, быстрый и эффективный путь передачи данных. vSAN ESA обеспечивает эффективность RAID 5/6 с производительностью RAID 1.

Тестирование показало, что 8-узловой кластер vSAN ESA на Lenovo Agile VX Series может обеспечить 720 000 агрегированных IOPS по мере увеличения количества виртуальных машин SQL Server с одной до восьми. Результаты подтверждают последовательную масштабируемость и надежную производительность для рабочих нагрузок.

В документе приведены обширные рекомендации по проектированию и сайзингу, отчеты о проверке решений и лучшие практики для администраторов и владельцев систем на основе Microsoft SQL Server.


Таги: VMware, vSAN, ESA, Storage, Microsoft, SQL, Performance

Новый документ: "Optimizing Networking and Security Performance Using VMware vSphere and NVIDIA BlueField DPU with BWI"


На конференции VMworld 2020 Online ковидного года компания VMware представила одну из самых интересных своих инициатив по сотрудничеству с вендорами оборудования - Project Monterey. Тогда была представлена технология SmartNIC/DPU, которая позволяет обеспечить высокую производительность, безопасность по модели zero-trust и простую эксплуатацию в среде VCF.

 

SmartNIC - это специальный сетевой адаптер (NIC) c модулем CPU на борту, который берет на себя offload основных функций управляющих сервисов (а именно, работу с хранилищами и сетями, а также управление самим хостом).

В данном решении есть три основных момента:

  • Поддержка перенесения сложных сетевых функций на аппаратный уровень, что увеличивает пропускную способность и уменьшает задержки (latency).
  • Унифицированные операции для всех приложений, включая bare-metal операционные системы.
  • Модель безопасности Zero-trust security - обеспечение изоляции приложений без падения производительности. Ведь если основной ESXi для исполнения рабочих нагрузок будет скомпрометирован, то управляющий DPU сможет обнаружить ее и устранить уязвимость.

В статье об аппаратных нововведениях платформы VMware vSphere 8 Update 2, представленных на конференции Explore 2023, мы писали о том, что VMware еще в vSphere 8 представила поддержку DPU, позволяя клиентам переносить инфраструктурные рабочие нагрузки с CPU на специализированный модуль DPU, тем самым повышая производительность бизнес-нагрузок. Ну а в vSphere 8 U2 клиенты, использующие серверы Lenovo или Fujitsu, теперь смогут использовать новые функции интеграции vSphere DPU и его преимущества в производительности.

Теперь в платформах vSphere 8 и NSX есть полноценная поддержка устройств SmartNIC или так называемых устройств обработки данных (DPU). Реализация DPU в vSphere называется vSphere Distributed Service Engine.

DPU (SmartNIC) — это сетевые карты с встроенным интеллектом, которые могут выполнять различные сетевые функции непосредственно на адаптере через свои собственные программируемые процессоры. В дополнение к сетевым ускорителям, такие DPU, как NVIDIA BlueField, также имеют ядра общего назначения на базе процессора Arm, которые могут запускать полноценную систему ESXi (вот для чего и пригодился гипервизор VMware ESXi Arm Edition).

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

Об этом всем и рассказывается в документе "Optimizing Networking and Security Performance Using VMware vSphere and NVIDIA BlueField DPU with BWI", который очень полезно прочитать для общего развития:

Ну и несколько картинок по результатам тестирования хостов ESXi с модулями SmartNIC/DPU на борту, которые показывают, какой прирост производительности дает новая технология:


Таги: VMware, SmartNIC, DPU, Hardware, NVIDIA, Performance, Whitepaper

Новый документ VMware: "Troubleshooting TCP Unidirectional Data Transfer Throughput"


Недавно опубликованный компанией VMware технический документ "Troubleshooting TCP Unidirectional Data Transfer Throughput" описывает, как устранить проблемы с пропускной способностью однонаправленной (Unidirectional) передачи данных по протоколу TCP. Решение этих проблем, возникающих на хосте vSphere/ESXi, может привести к улучшению производительности. Документ предназначен для разработчиков, опытных администраторов и специалистов технической поддержки.

Передача данных по протоколу TCP очень распространена в средах vSphere. Примеры включают в себя трафик хранения между хостом VMware ESXi и хранилищем данных NFS или iSCSI, а также различные формы трафика vMotion между хранилищами данных vSphere.

В компании VMware обратили внимание на то, что даже крайне редкие проблемы с TCP могут оказывать несоразмерно большое влияние на общую пропускную способность передачи данных. Например, в некоторых экспериментах с чтением NFS из хранилища данных NFS на ESXi, кажущаяся незначительной потеря пакетов (packet loss) в 0,02% привела к неожиданному снижению пропускной способности чтения NFS на 35%.

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

Рассматриваемые проблемы с TCP включают в себя потерю пакетов и их переотправку (retransmission), длительные паузы из-за таймеров TCP, а также проблемы с Bandwidth Delay Product (BDP). Для проведения анализа используется решение Wireshark и описывается профиль для упрощения рабочего процесса анализа. VMware описывает системный подход к выявлению общих проблем с протоколом TCP, оказывающих значительное влияние на пропускную способность канала передачи данных - поэтому инженерам, занимающимся устранением проблем с производительностью сети, рекомендуется включить эту методологию в стандартную часть своих рутинных проверок.

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

Скачать whitepaper "Troubleshooting TCP Unidirectional Data Transfer Throughput" можно по этой ссылке.


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

Документ от VMware: Performance Best Practices for VMware vSphere 8.0 Update 1


В начале года мы писали о документе "Performance Best Practices for VMware vSphere 8.0", в котором приведены основные рекомендации по обеспечению высокой производительности флагманской платформы виртуализации компании VMware. В середине этого года было сделано обновление этого руководства, которое было выпущено под названием "Performance Best Practices for VMware vSphere 8.0 Update 1".

Как и всегда, документ разбит на 4 больших блока, касающихся оборудования, самой платформы vSphere и серверов ESXi, виртуальных машин, их гостевых систем и средств управления виртуальной инфраструктурой:

  • Hardware for Use with VMware vSphere
  • ESXi and Virtual Machines
  • Guest Operating Systems
  • Virtual Infrastructure Management

Все рекомендации, который были даны для vSphere 8, по-прежнему, в силе, мы не нашли новых моментов, касающихся именно Update 1. Но некоторые косметические и уточняющие правки в документе все-таки есть.

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

Скачать Performance Best Practices for VMware vSphere 8.0 можно по этой ссылке.


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

Реализация механизмов повышенной производительности в VMware vSAN 8 Update 1


Вчера мы писали о том, какие результаты для производительности различных типов приложений дают новые функции в VMware vSAN 8 Update 1. Сегодня мы поговорим о том, как именно они реализованы.

Архитектура Express Storage Architecture (ESA) в vSAN 8 реализует новый способ обработки и хранения данных. Она предоставляет пользователям совершенно новые возможности, обеспечивает лучшую производительность и улучшает эффективность использования дискового пространства, при этом потребляя меньше ресурсов процессора.

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

1. Алгоритм VMware vSAN ESA Adaptive Write Path

Новый адаптивный путь записи в vSAN 8 U1 предоставляет ESA один из двух методов записи данных. Стандартный путь записи обрабатывает операции ввода-вывода (I/O) разных размеров, в то время как новый альтернативный путь записи оптимизирован для обработки больших I/O от гостевых ВМ. Зачем здесь два способа записи данных? Немного контекста поможет объяснить, почему это так важно.

Современные флэш-устройства предпочитают обрабатывать запись некоторого минимального объема данных. Это помогает уменьшить износ и активности по сбору мусора на устройствах. vSAN ESA была специально разработана для записи блоков данных, оптимально подходящих для этих устройств. Однако ESA также записывает данные эффективным образом с использованием минимального количества усилий. Для достижения этого используется кодирование RAID-5/6, где данные записываются в полные полосы (full stripe writes). Такие записи избегают шагов чтение-модификация-запись, часто связанных с записью данных с использованием erasure codes.

К сожалению, ВМ не всегда записывают данные большими блоками. Часто они обновляют только небольшие объемы данных. Учитывая это, ESA использует журналируемую (log-structured) файловую систему для объединения входящих операций ввода-вывода и сохранения данных и метаданных в журнал, чтобы можно было отправить подтверждение записи как можно быстрее. Это обеспечивает низкую и стабильную задержку для ВМ. Ну а данные из журнала записываются полной полосой (full stripe) позже. Это представляет собой стандартный путь записи (default write path), который был реализован в ESA на платформе vSAN 8.

Однако ВМ часто могут выполнять и крупные записи. Именно адаптивный путь записи в vSAN 8 U1 помогает записывать данные в таких условиях оптимальным образом. Когда vSAN определяет ситуацию, когда идут записи с использованием больших размеров I/O или большого количества ожидающих I/O, он будет использовать новый путь записи для больших I/O.

ESA в vSAN 8 U1 фиксирует эти I/O из буфера в памяти как полную полосу записи (full stripe) и записывает только метаданные в журналируемую файловую систему. Подтверждение записи будет отправлено ВМ, когда данные будут записаны напрямую в полную полосу записи на диск, а метаданные - в устойчивый журнал (durable log). Несмотря на то что основные данные обходят durable log, очень небольшое количество метаданных все же записывается для избыточности на двойное или тройное зеркало (в зависимости от назначенной политики хранения), чтобы гарантировать надежное хранение блоков.

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

Когда мы рассматриваем, куда записываются данные по умолчанию используя путь записи ESA для объекта, использующего erasure codes для RAID-6, это уменьшает избыточность записи данных с 4,5x (3x для тройного зеркала + 1,5x для полосы RAID-6 4+2 с двойной паритетной проверкой) до всего лишь 1,5x. Это не только сокращает объем вычислений в процессорах, но и уменьшает сетевой трафик. Этот новый адаптивный путь записи приводит к большему объему передачи данных для всех рабочих нагрузок, которые склонны генерировать большие размеры I/O или большое количество ожидающих операций, создавая ситуации, обычно называемые большим количеством необработанных операций ввода-вывода (high outstanding I/O).

2. Оптимизированный процессинг операций ввода-вывода для отдельных объектов VMDK

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

vSAN 8 U1 вводит дополнительные вспомогательные потоки в распределенном менеджере объектов - слое стека vSAN, который отвечает за координацию и обработку операции ввода-вывода к объекту. Эти вспомогательные потоки помогают распределять усилия между большим количеством ядер процессора и помогают уменьшить истощение ресурсов процессора, если отдельный процесс перегружен.

Это увеличение параллелизма будет наиболее заметным на ресурсоемких ВМ, обрабатывающих большое количество I/O на VMDK, которые ранее были ограничены стеком каким-либо образом. Будь то критически важные приложения или системы с интенсивной транзакционной активностью, пользователи смогут увидеть улучшение производительности IOPS и пропускной способности до 25%.

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


Таги: VMware, vSAN, Performance

Как именно улучшения производительности VMware vSAN 8 Update 1 влияют на разные типы приложений


В начале этого года компания VMware выпустила значимое обновление решения vSAN 8 Update 1, где было заявлено достаточно много улучшений в сфере производительности, особенно для архитектуры vSAN ESA (например, Adaptive Write Path).

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

1. Приложения для видеонаблюдения

Эти типы решений часто генерируют большие объемы последовательных записей, которые для системы хранения могут быть одним из наиболее требовательных типов профилей рабочей нагрузки, потому что записывается большое количество данных с использованием больших размеров операций ввода-вывода (I/O). При сравнении производительности с OSA (Original Storage Architecture) в VMware обнаружили, что ESA предоставляет улучшение производительности до 240%. То есть вы можете увеличить обмен I/O более чем в три раза, используя то же самое оборудование! Это улучшение демонстрирует возможности нового алгоритма Adaptive Write Path, добавленного в vSAN 8 U1, который может определить, когда происходят такие операции записи, и использовать наиболее оптимальный путь записи для этих условий.

2. Сервисы Apache Kafka

Характеристики потока ввода-вывода Apache Kafka имеют некоторые сходства с приложениями для видеотрансляции, где они могут предъявлять высокие требования к системе хранения. Распределенные решения для потоковой передачи событий, такие как Kafka, были разработаны для удобного масштабирования, и в зависимости от конфигурации, могут генерировать очень большие объемы данных для непрерывной записи. При проведении сравнительных тестов в VMware обнаружили, что ESA обеспечивает улучшение производительности до 80% при работе с Kafka. И это также демонстрирует, насколько хорошо ESA справляется с рабочими нагрузками, генерирующими плотный поток записи.

3. Приложения в сфере здравоохранения

Продукты, использующие реляционные базы данных, являются основой многих приложений в широком спектре отраслей. Отрасль здравоохранения в большой степени зависит от решений Electronic Health Records (EHR), чтобы обеспечивать наилучший уход за пациентами, что является ярким примером "критически важных" приложений. vSAN всегда была идеальной платформой для среды здравоохранения, и с появлением ESA она стала еще лучше. Тесты VMware показали, что эти зависящие от баз данных медицинские приложения предлагают до 50% лучшую производительность при работе на платформе ESA. Это впечатляющий уровень улучшений, учитывая высокую транзакционную природу этих приложений.

4. NoSQL приложения

Некоторые решения используют нереляционную базу данных NoSQL для хранения данных своих приложений. NoSQL может просто масштабироваться и часто используется в ряде открытых и коммерческих приложений. В VMware обнаружили, что приложения на основе NoSQL работают на 15% быстрее с использованием ESA. Это довольно значимо, учитывая что процессор, память и сетевая задержка часто являются наиболее распространенными препятствиями для производительности в среде NoSQL.

Хотя показатели производительности ESA весьма впечатляющи, учитывая постоянные улучшения производительности, внесенные в vSAN OSA, есть и второстепенные преимущества ESA, которыми не следует пренебрегать.

  • Эффективное использование ресурсов. ESA потребляет меньше аппаратных ресурсов для обработки и хранения данных. Это означает, что в сравнении с OSA вам, возможно, понадобится меньше хостов для удовлетворения тех же требований к рабочей нагрузке, или вы сможете запускать больше рабочих нагрузок на том же объеме оборудования. Оба варианта эффективно снижают затраты на владение виртуальной средой.
  • Повышенная стабильность и производительность. Более эффективный стек хранения уменьшает спрос на физические ресурсы, такие как процессор, и может помочь повысить стабильность уровня производительности, предоставляемого гостевым ВМ. Это может быть особенно важно для систем, которые являются критически важными и которые должны иметь не только низкий уровень задержек, но и стабильность в плане производительности.
  • Лучшая эффективность использования пространства. vSAN ESA предлагает улучшенную эффективность использования пространства без компромиссов. В отличие от OSA, он может надежно хранить данные с использованием кодирования RAID-5/6 при производительности на уровне RAID-1. Это обеспечивает гарантированную эффективность использования пространства при надежном хранении данных. ESA также может сжимать данные с минимальным использованием ресурсов и даже уменьшать использование пропускной способности канала.
  • Проще в управлении. Идея "производительности без компромиссов" также улучшает управление. Рекомендации по оптимизации для достижения наилучшей возможной производительности стали проще с vSAN ESA (подробнее об этом рассказано тут).

На этом пока все, ну а завтра мы расскажем, собственно, о самом механизме Adaptive Write Path и других нововведениях VMware vSAN 8 Update 1.


Таги: VMware, vSAN, Update, Performance, Applications

Новый документ "VMware vSphere 8 Performance Is in the “Goldilocks Zone” for AI/ML Training and Inference Workloads"


Недавно компания VMware опубликовала интересный документ "VMware vSphere 8 Performance Is in the “Goldilocks Zone” for AI/ML Training and Inference Workloads".

Там приведены результаты тестирования производительности рабочих нагрузок обучения AI/ML на платформе виртуализации VMware vSphere с использованием нескольких графических процессоров NVIDIA A100-80GB с поддержкой технологии NVIDIA NVLink. Результаты попадают в так называемую "зону Голдилокс", что означает область хорошей производительности инфраструктуры, но с преимуществами виртуализации.

Результаты показывают, что время обучения для нескольких тестов MLPerf v3.0 Training1 увеличивается всего от 6% до 8% относительно времени тех же рабочих нагрузок на аналогичной физической системе.

Кроме того, в документе показаны результаты теста MLPerf Inference v3.0 для платформы vSphere с графическими процессорами NVIDIA H100 и A100 Tensor Core. Тесты показывают, что при использовании NVIDIA vGPU в vSphere производительность рабочей нагрузки, измеренная в запросах в секунду (QPS), составляет от 94% до 105% производительности на физической системе.

vSphere 8 и высокопроизводительная виртуализация с графическими процессорами NVIDIA и NVLink.

Партнерство между VMware и NVIDIA позволяет внедрить виртуализированные графические процессоры в vSphere благодаря программному слою NVIDIA AI Enterprise. Это дает возможность не только достигать наименьшего времени обработки для виртуализированных рабочих нагрузок машинного обучения и искусственного интеллекта, но и использовать многие преимущества vSphere, такие как клонирование, vMotion, распределенное планирование ресурсов, а также приостановка и возобновление работы виртуальных машин.

VMware, Dell и NVIDIA достигли производительности, близкой или превышающей аналогичную конфигурацию на физическом оборудовании со следующими настройками:

  • Dell PowerEdge XE8545 с 4-мя виртуализированными графическими процессорами NVIDIA SXM A100-80GB
  • Dell PowerEdge R750xa с 2-мя виртуализированными графическими процессорами NVIDIA H100-PCIE-80GB

Для вывода в обеих конфигурациях требовалось всего 16 из 128 логических ядер ЦП. Оставшиеся 112 логических ядер ЦП в дата-центре могут быть использованы для других задач. Для достижения наилучшей производительности виртуальных машин во время обучения требовалось 88 логических ядер CPU из 128. Оставшиеся 40 логических ядер в дата-центре могут быть использованы для других активностей.

Производительность обучения AI/ML в vSphere 8 с NVIDIA vGPU

На картинке ниже показано сравнительное время обучения на основе тестов MLPerf v3.0 Training, с использованием vSphere 8.0.1 с NVIDIA vGPU 4x HA100-80c против конфигурации на физическом оборудовании с 4x A100-80GB GPU. Базовое значение для физического оборудования установлено как 1.00, и результат виртуализации представлен в виде относительного процента от базового значения. vSphere с NVIDIA vGPUs показывает производительность близкую к производительности на физическом оборудовании, где накладные расходы на виртуализацию составляют 6-8% при обучении с использованием BERT и RNN-T.

Таблица ниже показывает время обучения в минутах для тестов MLPerf v3.0 Training:

Результаты на физическом оборудовании были получены Dell и опубликованы в разделе закрытых тестов MLPerf v3.0 Training с ID 3.0-2050.2.

Основные моменты из документа:

  • VMware vSphere с NVIDIA vGPU и технологией AI работает в "зоне Голдилокс" — это область производительности для хорошей виртуализации рабочих нагрузок AI/ML.
  • vSphere с NVIDIA AI Enterprise, используя NVIDIA vGPUs и программное обеспечение NVIDIA AI, показывает от 106% до 108% от главной метрики физического оборудования (100%), измеренной как время обучения для тестов MLPerf v3.0 Training.
  • vSphere достигла пиковой производительности, используя всего 88 логических ядер CPU из 128 доступных ядер, оставив тем самым 40 логических ядер для других задач в дата-центре.
  • VMware использовала NVIDIA NVLinks и гибкие группы устройств, чтобы использовать ту же аппаратную конфигурацию для обучения ML и вывода ML.
  • vSphere с NVIDIA AI Enterprise, используя NVIDIA vGPU и программное обеспечение NVIDIA AI, показывает от 94% до 105% производительности физического оборудования, измеренной как количество обслуживаемых запросов в секунду для тестов MLPerf Inference v3.0.
  • vSphere достигла максимальной производительности вывода, используя всего 16 логических ядер CPU из 128 доступных, оставив тем самым 112 логических ядер CPU для других задач в дата-центре.
  • vSphere сочетает в себе мощь NVIDIA vGPU и программное обеспечение NVIDIA AI с преимуществами управления дата-центром виртуализации.

Более подробно о тестировании и его результатах вы можете узнать из документа.


Таги: VMware, NVIDIA, Hardware, AI/ML, Performance, Whitepaper

Новый документ: Leveraging the Full Power of Oracle Cloud VMware Solution and VMware vSphere


Компания VMware выпустила очень интересный документ, рассказывающий о производительности рабочих нагрузок в публичном облаке Oracle Cloud, построенном на базе инфраструктурного стека VMware vSphere - "Leveraging the Full Power of Oracle Cloud VMware Solution and VMware vSphere".

Он раскрывает аспекты производительности виртуальных машин, работающих в инфраструктуре решений вендоров VMware, Oracle, AMD и Deloitte:


В этом документе рассматривается, как именно Oracle Cloud VMware Solution (OCVS) отличается от публичных облачных сред IaaS. Там также приводится описание следующих процессов:

  • Перенос виртуальных машин Oracle и SQL Server из локального датацентра в облако OCVS без перенастройки с обеспечением того же уровня производительности.
  • Демонстрация, как облако OCVS, работающее на оборудовании с процессорами AMD EPYC, достигает повышения производительности баз данных.
  • Наглядно показывается, что NSX Data Center может ускорить работу с нагрузками Oracle со ссылками на исследования VMware и Deloitte Consulting.
  • Обоснование экономических и технических преимуществ управления хостами со стороны клиентов.

Об облаке OCVS

OCVS включает следующие продукты VMware: vSphere, vSAN, NSX Data Center и vCenter Server. Эта унифицированная облачная инфраструктура и платформа для операций позволяет ИТ-специалистам предприятий быстро переносить и модернизировать приложения, бесшовно перемещая рабочие нагрузки между локальными средами и инфраструктурой Oracle Cloud Infrastructure (OCI) в больших масштабах. Кроме того, ИТ-команды могут легко использовать такие сервисы, как Oracle Autonomous Database, Oracle Exadata Cloud и Oracle Database Cloud, имея постоянный доступ к облачному порталу и современные API.

Производительность OCVS

VMware vSphere - это проверенная корпоративная платформа виртуализации, которая успешно работает с виртуальными машинами Oracle более 12 лет. Как показано на рисунке ниже, виртуальная машина Oracle Database, выполняющая сложную корпоративную нагрузку в OCVS, работает почти так же хорошо, как и в локальном датацентре. Когда мы масштабируем виртуальные машины Oracle Database до 8, виртуальные машины на OCVS работают даже немного лучше, чем виртуальные машины в локальных средах.

Также, используя эталонный тест VMware для измерения производительности базы данных DVD Store, компания Deloitte в независимом исследовании показывает, что виртуальные машины Oracle Database работают до 4-8 раз быстрее с VMware NSX, как показано на рисунке:

За более подробной информацией об исследовании производительности облака OCVS обращайтесь к документу "Leveraging the Full Power of Oracle Cloud VMware Solution and VMware vSphere".


Таги: VMware, Whitepaper, Oracle, Cloud, Performance

Система обнаружения виртуальных машин-зомби в VMware vSphere


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

VMware определяет "зомби" как виртуальные машины и серверы, которые изначально были развернуты для конкретной цели, но больше не выполняют полезной работы. VMware обнаружила, что зомби-ВМ распространены в облачных средах клиентов (а это от 15% до > 50% от всех серверов и виртуальных машин).

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

Например, в 2019 году, завершая миграцию дата-центра, VMware обнаружила, что 47% ее виртуальных машин не используются и были устаревшими! Зомби-ВМ так распространены, потому что их легко создать (подумайте, сколько у вас зомби-приложений на телефоне?), но их может быть сложно найти. Продукты VMware vRealize Operations и CloudHealth могут помочь найти те, которые выключены или имеют низкую или нулевую загрузку процессора. Однако, многие зомби-ВМ имеют некую остаточную активность, которая вспомогательна по отношению к основному приложению, такую как сканирование на вирусы, обновление патчей и резервное копирование. Современные детекторы пропустят эти "ползучие зомби", потому что, основываясь на их активности, они выглядят так, будто они могут выполнять продуктивную работу.

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

Совпадающее поведение зомби-ВМ по нескольким метрикам активности подкрепляет ее статус. Поскольку работающие с полезной нагрузкой виртуальные машины могут оставаться неактивными на длительные периоды (недели или месяцы), система обнаружения зомби-ВМ терпелива, чтобы минимизировать ложные срабатывания. Если виртуальная машина снова становится активной, она удаляется из списка потенциальных зомби-ВМ. В конечном итоге, целью VMware является определение такх машин в облачных средах клиентов, выделение связанных с ними финансовых и углеродных затрат и предоставление вариантов устранения (например, с помощью Virtual Machine Desired State Configuration) для снижения затрат и освобождения ресурсов. VMware находится в процессе тестирования этого на данных клиентов, чтобы уточнить алгоритм обнаружения.

На картинке выше, ряд метрик отражает использование ресурсов с резким падением с около 80% до нового стабильного состояния - около 20%. Красные пунктирные вертикальные столбцы показывают область аномалии смены точек, а фиолетовые точки указывают на путь среднего предиктора с уменьшающейся величиной через область аномалии. Серые треки - это асимметричные погрешности вокруг среднего предиктора с уменьшающейся величиной. В какой-то момент ряд достаточно выравнивается, чтобы подтвердить постоянное, более низкое состояние активности. В этом случае "новая норма" выглядит как остаточный фон, состоящий из периодической активности малой амплитуды. Этот остаточный сигнал анализируется на предмет известного класса непродуктивного фона, такого как регулярное сканирование на вирусы или накатывание патчей.

Пока эти функции еще не внедрены в VMware vSphere, но их появление ожидается уже в самом ближайшем будущем.


Таги: VMware, vSphere, Performance

VMware выпустила GemFire 10


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

GemFire 10 был предварительно анонсирован на конференции SpringOne Essentials в январе, а позже был выпущен в качестве общедоступной бета-версии. С тех пор VMware упорно работала над окончательным выпуском.

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

Давайте посмотрим на новые возможности GemFire 10:

  • VMware GemFire Management Console – новый управляющий интерфейс позволяет разработчикам и операторам настраивать и управлять кластерами GemFire. Отсюда видны все объекты ваших развертываний GemFire.
  • VMware GemFire Search - разработчики могут реализовать все возможности полнотекстового поиска в своих приложениях, которые могут работать очень быстро при исполнении их в памяти. Поиск и индексирование реализованы в рамках одного продукта.
  • VMware GemFire for Redis Apps - этот релиз расширяет совместимость с приложениями Redis и добавляет поддержку новых политик в модуле расширения.
  • Spring for VMware GemFire - улучшенная совместимость и долговременная поддержка для приложений Spring.
  • JSON document improvements - теперь есть возможности хранения документов BSON или нативных объектов Portable Data eXchange для in-memory приложений с реализацией хранилища, оптимизированного по пространсту хранения.
  • Java 17 support - GemFire был полностью оттестирован для Java 17. Сборщик Z Garbage Collector выбран по умолчанию, что дает лучшую производительность для больших размеров кучи.
  • Jakarta Enterprise Edition (JEE) 9  - модули репликации состояния сессии теперь поддерживают Apache Tomcat 10 и Jakarta EE 9.
  • Pluggable modules - разработчики могут упаковывать и развертывать server-side компоненты независимо, без конфликтов с существующими библиотеками GemFire.
  • Cross-cluster replication improvements - объекты приложений, которые хранят частичные апдейты, могут быть более эффективно реплицированы в другие кластеры.
  • Updated defaults - были улучшены параметры для тюнинга, что дает меньше затрат на первоначальную конфигурацию и установку.
  • Deploy and run everywhere - GemFire может быть запущен в онпремизной инфраструктуре или в облаке, а также в виртуальных машинах, физических или в контейнерах. Также доступны функции автоматизированного управления и бесшовных апгрейдов для Kubernetes и VMware Tanzu Application Service.

Загрузить GemFire 10 можно по этой ссылке. Developer Center находится тут, а документация здесь.


Таги: VMware, GemFire, Update, Spring, Performance, Cloud

Новые возможности VMware vSAN 8 Update 1


На прошлой неделе мы рассказали о новых возможностях обновленной версии платформы VMware vSphere 8 Update 1, а также новых функциях инфраструктуры хранилищ (Core Storage). Сегодня мы поговорим о новой версии vSAN 8 Update 1 - решения для организации отказоустойчивых кластеров хранилищ для виртуальных машин.

В vSAN 8 компания VMware представила архитектуру хранилища vSAN Express Storage Architecture (ESA), сделав весомый вклад в развитие гиперконвергентной инфраструктуры. В первом пакете обновлений vSAN компания VMware продолжает развивать этот продукт, позволяя клиентам использовать современные массивы, которые обеспечивают новый уровень производительности, масштабируемости, надежности и простоты использования.

Обзор основных возможностей vSAN 8 Update 1 вы также можете увидеть в видео ниже (откроется в новом окне):

В vSAN 8 Update 1 продолжают разрабатывать и улучшать обе архитектуры - vSAN OSA и vSAN ESA. Давайте посмотрим, что нового появилось в vSAN U1:

1. Масштабирование распределенных хранилищ

Обработка разделенных ресурсов вычисления и хранения в кластерах улучшена в версии vSAN 8 U1. Клиенты могут масштабироваться новыми способами, совместно используя хранилища данных vSAN с другими кластерами vSAN или только с вычислительными кластерами vSphere в рамках подхода HCI Mesh.

  • Управление распределенными хранилищами HCI Mesh с помощью архитектуры Express Storage

В vSAN 8 U1 архитектура Express Storage Architecture (ESA) позволяет клиентам максимизировать использование ресурсов устройств нового поколения путем предоставления общего доступа к хранилищами в нескольких нерастянутых кластерах для подхода HCI Mesh. Пользователи могут монтировать удаленные хранилища данных vSAN, расположенные в других кластерах vSAN, и использовать кластер vSAN ESA в качестве внешнего хранилища ресурсов для кластера vSphere.

  • Использование внешнего хранилища с помощью растянутых кластеров vSAN для OSA

В vSAN 8 U1 появилась поддержка распределенных хранилищ HCI Mesh при использовании растянутых кластеров vSAN на основе архитектуры хранения vSAN OSA. Теперь пользователи могут масштабировать хранение и вычислительные мощности независимо - в стандартных и растянутых кластерах.

  • Потребление емкостей хранилищ vSAN для разных экземпляров vCenter Server

vSAN 8 U1 также поддерживает распределенные хранилища в разных средах с использованием нескольких серверов vCenter при использовании традиционной архитектуры хранения (OSA).

2. Улучшение платформы

  • Улучшенная производительность с использованием нового адаптивного пути записи

В новом релизе представлен новый адаптивный путь записи, который позволяет рабочим нагрузкам с множеством записей и частопоследовательными записями записывать данные оптимальным способом. Улучшенная потоковая запись на ESA обеспечит увеличение пропускной способности на 25% и снижение задержки для последовательных записей. Это обновление не только повлияет на приложения с преобладающим профилем последовательной записи I/O, но и расширит разнообразие нагрузок, которые работают оптимальным образом на ESA vSAN.

  • Улучшенная производительность для отдельных нагрузок

Чтобы извлечь максимальную пользу из современного оборудования NVMe, в vSAN ESA 8 U1 была оптимизирована обработка I/O для каждого объекта, находящегося на хранилище данных vSAN ESA, повысив производительность на каждый VMDK на 25%. Эти улучшения производительности для отдельных объектов на ESA будут очень эффективны на критически важных виртуальных машинах, включая приложения, такие как реляционные базы данных и нагрузки OLTP.

  • Улучшенная надежность во время сценариев режима обслуживания.

В vSAN 8 U1 для ESA была добавлена еще одна функция, которая присутствует в vSAN OSA: поддержка RAID 5 и RAID 6 erasure coding с функциями дополнительной защиты от потери данных во время плановых операций обслуживания. Эта новая возможность гарантирует, что данные на ESA хранятся с избыточностью в случае неожиданного сбоя хоста в кластере во время режима обслуживания.

  • Улучшения управления датасторами

В vSAN 8 U1 администраторы смогут настраивать размер объектов пространства имен, что позволит им более просто хранить файлы ISO и библиотеки контента.

3. Упрощение управления

При использовании управления хранилищем на основе политик (SPBM), клиенты могут определять возможности хранения с помощью политик и применять их на уровне виртуальных машин. vSAN 8 U1 есть несколько новых улучшений, которые упрощают ежедневные операции администраторов, а также добавляют несколько новых возможностей, чтобы помочь глобальной команде поддержки VMware (GS) быстрее решать проблемы клиентов.

  • Автоматическое управление политиками для Default Storage Policies (ESA)

В vSAN ESA 8 U1 появилась новая, необязательная кластерная политика хранения по умолчанию, которая поможет администраторам работать с кластерами ESA с оптимальной надежностью и эффективностью. В конфигурации на уровне кластера доступен новый переключатель "Auto-Policy Management". При включении этой функции кластера будет создана и назначена эффективная политика хранения по умолчанию на основе размера и типа кластера.

  • Skyline Health Score и исправление конфигурации

В vSAN 8 U1 модуль Skyline UX был переработан и теперь содержит новую панель управления состоянием с упрощенным видом "здоровья" каждого кластера. Новый пользовательский интерфейс поможет ответить на вопросы: "Находится ли мой кластер и обрабатываемые им нагрузки в работоспособном и здоровом состоянии?" и "Насколько серьезно это состояние? Следует ли решить эту проблему?".

С таким четким пониманием потенциальных проблем и действий для их устранения вы можете сократить среднее время до устранения проблем (mean time to resolution, MTTR).

  • Более высокий уровень детализации для улучшенного анализа производительности

Доступный как в Express Storage Architecture, так и в Original Storage Architecture, сервис производительности vSAN 8 U1 теперь включает мониторинг производительности почти в реальном времени, который собирает и отображает показатели производительности каждые 30 секунд.

  • Упрощенный сбор диагностической информации о производительности

В vSAN 8 U1 в I/O Trip Analyzer для виртуальных машин появился новый механизм планировщика. Вы можете запускать диагностику программно, что позволяет собирать больше и лучших данных, что может быть критически важно для выявления временных проблем производительности. Это улучшение идеально подходит для сред, где ВМ имеет повторяющуюся (хоть и кратковременную) проблему с производительностью.

  • Новая интеграция PowerCLI

В vSAN 8 U1 PowerCLI поддерживает множество новых возможностей как для архитектур ESA (Express Storage Architecture), так и OSA (Original Storage Architecture). С помощью этих интеграций клиенты ESA получат простой доступ к своему инвентарю для мониторинга и автоматизации управления своей средой и выделением ресурсов.

4. Функции Cloud Native Storage

Выделенные окружения DevOps увеличивают сложность всего центра обработки данных и увеличивают затраты. Используя существующую среду vSphere для хостинга рабочих нагрузок Kubernetes DevOps, клиенты дополнительно увеличивают ценность и ROI платформы VMware. VMware продолжает фокусироваться на потребностях разработчиков: в vSAN 8 U1 были реализованы новые улучшения производительности, простоты и гибкости для разработчиков, которые используют среду, и для администраторов, ответственных за саму платформу.

  • Поддержка CNS для vSAN ESA

В vSAN 8 U1 мы добавили поддержку Cloud Native Storage (CNS) для vSAN ESA. Клиенты могут получить преимущества производительности vSAN ESA для своих сред DevOps.

  • Поддержка DPp общих виртуальных коммутаторов

vSAN 8 U1 снижает стоимость и сложность инфраструктуры за счет того, что решения DPp (Data Persistence) теперь совместимы с VMware vSphere Distributed Switch. Клиентам нужны только лицензии vSphere+/vSAN+, чтобы использовать платформу Data Persistence — на vSAN OSA или ESA — и запускать приложения, что дает более низкую общую стоимость владения и упрощение операций.

  • Развертывние Thick provisioning для vSAN Direct Configuration

Наконец, в vSAN 8 U1 были доработаны кластеры, работающие в конфигурации vSAN Direct Configuration — это уникальная кластерная конфигурация, настроенная под Cloud Native Workloads. С vSAN 8 U1 постоянные тома могут быть программно выделены разработчиком как "thick" (это определяется в классе хранения).

Более подробно о новых возможностях VMware vSAN 8 Update 1 можно почитать на специальной странице.


Таги: VMware, vSAN, Update, Storage, OSA, ESA, Performance

Новая версия HCIBench 2.8.1 на VMware Labs


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

Давайте посмотрим, что нового в HCIBench 2.8.1:

  • Добавлена поддержка нескольких параметров учетных записей для серверов ESXi
  • Поля для коэффициентов сжатия и дедупликации добавлены для страниц Vdbench и Fio
  • Оптимизированная функция Easy-Run - добавлены коэффициенты compression/deduplication при тестировании датастора vSAN с включенным режимом dd/c
  • Руководство пользователя обновлено до версии 2.8.1
  • Добавлены рекомендации по политикам хранилищ для архитектуры vSAN ESA на шаге предварительной валидации
  • Несколько исправлений ошибок

Скачать последнюю версию HCIBench 2.8.1 можно по этой ссылке.


Таги: VMware, Labs, HCIBench, Update, Performance, Storage

Новый документ: Performance Best Practices for VMware vSphere 8.0


В самом конце ушедшего года компания VMware обновила главный документ о производительности своей флагманской платформы виртуализации - Performance Best Practices for VMware vSphere 8.0. Напомним, что в последний раз об этом документе мы писали, когда с пакетом обновлений Update 3 долгое время были проблемы (в том числе с производительностью), а в итоге стала доступна стабильная версия обновления vSphere 7.0 Update 3c.

Традиционно документ разбит на 4 больших блока, касающихся оборудования, самой платформы vSphere и серверов ESXi, виртуальных машин, их гостевых систем и средств управления виртуальной инфраструктурой:

  • Hardware for Use with VMware vSphere
  • ESXi and Virtual Machines
  • Guest Operating Systems
  • Virtual Infrastructure Management

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

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

Скачать Performance Best Practices for VMware vSphere 8.0 можно по этой ссылке.


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

Новый документ - VMware vSphere 8.0 Virtual Topology Performance Study


Как вы знаете, главным релизом этого года стала новая версия платформы VMware vSphere 8, где появилось множество новых возможностей и улучшений уже существующих технологий. Одной из интересных функций стала vSphere Virtual Topology.

Для виртуальных машин с Hardware version 20 теперь доступно простое конфигурирование vNUMA-топологии для виртуальных машин:

Для виртуальных машин теперь доступна информационная панелька CPU Topology с конфигурацией vNUMA:

Недавно компания VMware выпустила документ "vSphere 8.0 Virtual Topology Performance Study", где рассматриваются аспекты производительности новой технологии, которую назвали vTopology. Виртуальная топология CPU включает в себя такие техники, как virtual sockets, узлы virtual non-uniform memory access (vNUMA), а также механизм кэширования virtual last-level caches (LLC).

До vSphere 8.0 дефолтной конфигурацией виртуальных машин было одно виртуальное ядро на сокет - это в некоторых случаях создавало затыки в производительности и неэффективность использования ресурсов. Теперь же ESXi автоматически подстраивает число виртуальных ядер на сокет для заданного числа vCPU.

На картинке ниже показана высокоуровневая архитектура компонентов двухсокетной системы. Каждый сокет соединен с локальным узлом памяти (memory bank) и образует с ним NUMA-узел. Каждый сокет имеет 4 ядра (он имеет кэши L1 и L2), а ядра шарят между собой общий кэш last-level cache (LLC).

Когда создается виртуальная машина с четырьмя vCPU, в vSphere она конфигурируется на одном сокете, вместо четырех, как это было ранее:

Так это выглядит в выводе команды CoreInfo для двух рассмотренных топологий:

Слева - это старая конфигурация, где был один vCPU на сокет, а справа - 4 vCPU (виртуальных ядер ВМ) на один сокет.

В указанном документе VMware проводит различных конфигураций (от 8 до 51 vCPU на машину) для разных нагрузок с помощью бенчмарков и утилит DVD Store 3.5, Login VSI, VMmark, Iometer, Fio и Netperf в операционных системах Windows и Linux. Забегая вперед, скажем, что для нагрузок Oracle прирост производительности составил 14%, а для Microsoft SQL server - 17%.

Итак, результаты теста DVD Store для БД Oracle:

Статистики NUMA hits NUMA misses для гостевой ОС Linux:

Результаты тестов для Microsoft SQL server:

Результаты тестирования хранилищ с помощью IOmeter:

Производительность в разрезе метрики CPU cycles per I/O (CPIO):

Результаты тестов для NVMe хранилищ:

Результаты тестов сети и другие выводы вы можете найти в документе "VMware vSphere 8.0 Virtual Topology Performance Study".


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

VMware vSAN 8.0 Express Storage Architecture - куда делись дисковые группы?


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

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

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

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

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

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

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

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

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


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

Производительность Microsoft SQL Server в облаке VMware Cloud on AWS


Недавно компания VMware анонсировала новый тип инстанса для самых тяжелых нагрузок в публичном облаке VMware Cloud on AWS - AWS-i4i.metal. Теперь пользователи могут выбрать один из трех типов инстансов, каждый из которых заточен под определенный профиль задач:

В VMware недавно провели тестирование СУБД Microsoft SQL Server в облаке VMConAWS с помощью инструмента DVD Store, который измеряет производительность баз данных в числе выполненных операций в минуту (orders per minute, OPM).

Для целей тестирования было создано 3 кластера, каждый из трех соответствующих инстансов, которые отрабатывали нагрузки SQL Server:

Для начала была протестирована производительность SQL Server на одной машине каждого из кластеров. Результат получился таким:

  • Инстанс I4i производительнее I3 на 158% (более, чем в 2.5 раза)
  • I3en производительнее I3 на 52%

Далее тестовая нагрузка была запущена на двух хостах каждого кластера:

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

Ну и результат при запуске теста на всех трех хостах для каждого из кластеров:

Здесь коэффициент масштабирования по производительности в отношении одного хоста составил 2.6-2.9x, что очень и очень неплохо.

Инстанс I4i показывает себя хорошо как для задач общего назначения, так и для специфических нагрузок, таких как реляционные СУБД (Microsoft SQL Server, Oracle Database, MySQL) и NoSQL базы данных (MongoDB, Couchbase, Aerospike, Redis), а также VDI нагрузки.

Описание тестового окружения представлено на картинке ниже:


Таги: VMware, Cloud, AWS, SQL, Microsoft, Performance

Сравнение VMware Horizon и Citrix Virtual Apps and Desktops от компании Principled Technologies


Многие из вас знают, что на рынке виртуализации и доставки настольных ПК и приложений конкурируют, по-сути, всего два решения: VMware Horizon и Citrix Virtual Apps and Desktops. Недавно компания Principled Technologies провела тестирование этих продуктов и выпустила отчет "Scale virtual desktops faster and provision virtual apps more easily with VMware Horizon and VMware App Volumes". Судя по всему, отчет был подготовлен в интересах компании VMware.

Тестирование состояло из трех основных фаз:

  • Измерение скорости и простоты развертывания неперсистентных виртуальных десктопов
  • Более детальное рассмотрение способов доставки приложений с помощью технологий VMware App Volumes и Citrix App Layering
  • Тестирование производительности приложений в неперсистентных десктопах в VDI-окружениях VMware и Citrix

Саммари этого тестирования представлено на картинке ниже и в этом документе:

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


Таги: VMware, Citrix, Horizon, VDI, Performance

На VMware Labs обновился HCIBench до версии 2.8.0 - что нового?


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

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

Давайте посмотрим, что нового в HCIBench 2.8.0:

  • Компонент fio обновлен до версии 3.30
  • Добавлен целевой параметр latency для fio
  • Исправлена уязвимость CVE-2021-40438
  • Добавлен vSAN support bundle graph для режима vSAN Debug mode
  • Улучшен отчет об использовании ресурсов
  • Добавлена поддержка возможности тестирования vSAN 8 ESA
  • Исправлена ошибка при тестировании на архитектуре VMware Cloud

Скачать HCIBench 2.8.0 можно по этой ссылке.


Таги: VMware, Labs, HCIBench, Update, vSAN, Performance

Высокопроизводительные снапшоты Native Snapshots в рамках архитектуры vSAN Express Storage Architecture (ESA)


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

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

Снапшоты, создаваемые для специфических целей администраторов, часто разрастаются в разных ветках, что в итоге приводит к падению производительности виртуальной машины и операционным сложностям при консолидации (например, недостаток места). При этом снапшоты - это вещь нужная для таких процессов, как резервное копирование и автоматизированные рабочие процессы Continuous Integration/Continuous Delivery (CI/CD), Copy Data Management (CDM), а также управление виртуальными ПК VMware Horizon.

Часто в большой инфраструктуре VMware vSphere можно обязательно найти вот такую машину, которая "почему-то тормозит":

Традиционно снапшоты в VMware vSphere строились на базе технологии redo-log (дельта диск отличий от основного VMDK), которая имеет ограничения по масштабируемости и производительности. Снапшоты типа VMFSsparse использовались по умолчанию в файловой системе VMFS5 для дисков менее 2 ТБ и для всех дисков на системах до VMFS5.

VMFSsparse работает поверх VMFS как redo-log, который создается пустым, как только для ВМ создается снапшот, и растет до размера родительского VMDK-диска, накапливая данные. Начиная с VMFS5, для дисков более 2 ТБ и для всех дисков VMFS6 был добавлен формат снапшота VMFS SEsparse. Это эволюционное изменение снапшотов, которое давало улучшения в плане склеивания снапшотов и в отношении их больших цепочек, где ранее происходила потеря производительности.

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

Также были сделаны некоторые оптимизации "подмораживания" (stun) при различного рода операциях со снапшотами, а также специфические технологии, такие как Mirror driver, но концептуально суть снапшотов не поменялась. Поэтому VMware продолжала давать рекомендации не хранить их более 48 часов и не создавать длинных цепочек снапшотов, особенно для критичных нагрузок.

Архитектура снапшотов в vSAN базируется на традиционных redo-log снапшотах, которые были доработаны - так появился формат vsanSparse (начиная с vSAN 6). Он использует механизм redirect-on-write и снижает некоторые технические ограничения снапшотов за счет кэширования, но проблемы подмораживания и долгого времени удаления снапшотов остаются.

В новой версии vSAN 8 при использовании архитектуры ESA, снапшоты используются совершенно другим образом, нежели в прошлых версиях платформы. Вместо использования традиционной цепочки базового и дельта-дисков, механизм снапшотов использует lookup table, применяя структуры B-Tree.

Файловая система log structured file system в vSAN ESA позволяет новым операциям записи помещаться в новые сегменты хранилища с их указателями метаданных, интеллектуально размещая их в соответствии с принадлежностью к снапшотам. В этом случае время удаления снапшота снижается более чем в 100 раз по сравнению с прошлыми версиями платформы vSAN.

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

Мало того, пользователь получает подтверждение удаления снапшота сразу же, а удаление данных и метаданных происходит позже, в асинхронном режиме. Новая архитектура снапшотов ESA позволяет использовать практически неограниченное количество снапшотов - однако текущие параметры платформы vSphere ограничивают число снапшотов числом 32 на один объект.

Как знают администраторы VMware vSphere, решения для резервного копирования используют снапшоты через vSphere Storage API (также называемые VADP) для передачи резервных копий на хранилища. Новая функциональность vSAN ESA автоматически заменит старый механизм снапшотов, а пользователи увидят реальный прирост производительности при консолидации снапшотов, а также при работе продуктов VMware SRM и vSphere Replication в кластерах ESA.


Таги: VMware, vSAN, Update, Snapshots, Storage, ESA, Performance

1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12    >   >>
Интересное:





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

26/08/2024:  VMware Explore 2024 Лас-Вегас
04/11/2024:  VMware Explore 2024 Барселона

Быстрый переход:
VMware VMachines Offtopic NAKIVO vStack Gartner Veeam Vinchin StarWind Nakivo IT-Grad Cloud Teradici VeeamON VMworld PowerCLI Citrix VSAN GDPR 5nine Hardware Nutanix vSphere RVTools Enterprise Security Code Cisco vGate Microsoft SDRS Parallels IaaS HP VMFS VM Guru Oracle Red Hat Azure KVM VeeamOn 1cloud DevOps Docker Storage NVIDIA Partnership Dell Virtual SAN Virtualization VMTurbo vRealize VirtualBox Symantec Softline EMC Login VSI Xen Amazon NetApp VDI Linux Hyper-V IBM Google VSI Security Windows vCenter Webinar View VKernel Events Windows 7 Caravan Apple TPS Hyper9 Nicira Blogs IDC Sun VMC Xtravirt Novell IntelVT Сравнение VirtualIron XenServer CitrixXen ESXi ESX ThinApp Books P2V Update vSAN VCF NSX Aria Tanzu EUC Private AI Avi Broadcom Workstation Community Skyline HCX AI Host Client Explore Chargeback Horizon Labs SASE Workspace ONE Networking Backup Ransomware Tools Performance Lifecycle VCP Network AWS Intel API USB SDDC Fusion Whitepaper SD-WAN Mobile VMUG SRM ARM HCI Converter Photon OS Operations VEBA App Volumes Certification VMConAWS Workspace Imager SplinterDB DRS SAN vMotion Open Source iSCSI Partners HA Monterey Kubernetes V2V vForum Learning vRNI UAG Support Log Insight AMD vCSA NSX-T Graphics NVMe HCIBench SureBackup vCloud Обучение Web Client vExpert OpenStack UEM CPU PKS vROPs Stencils Bug VTL Forum Video Update Manager VVols DR Cache Storage DRS Visio Manager Virtual Appliance PowerShell LSFS Client Datacenter Agent esxtop Book Photon Cloud Computing SSD Comparison Blast Encryption Nested XenDesktop VSA vNetwork SSO VMDK Appliance VUM HoL Automation Replication Desktop Fault Tolerance Vanguard SaaS Connector Event Free SQL Sponsorship Finance FT Containers XenApp Snapshots vGPU Auto Deploy SMB RDM Mirage XenClient MP iOS SC VMM VDP PCoIP RHEV vMA Award Licensing Logs Server Demo vCHS Calculator Бесплатно Beta Exchange MAP ONE DaaS Hybrid Monitoring VPLEX UCS GPU SDK Poster VSPP Receiver 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 KB VirtualCenter NFS ThinPrint Stretched Director ESA Troubleshooting Android Python Upgrade ML Hub Guardrails CLI VCPP Memory Driver Foundation HPC Orchestrator Optimization Bugs SVMotion Diagram Ports SIOC Plugin Helpdesk VIC VDS Migration Air DPM Flex Mac SSH VAAI Heartbeat MSCS Composer
Полезные постеры:

Постер VMware vSphere PowerCLI 10

Постер VMware Cloud Foundation 4 Architecture

Постер VMware vCloud Networking

Постер VMware Cloud on AWS Logical Design Poster for Workload Mobility

Постер Azure VMware Solution Logical Design

Постер Google Cloud VMware Engine Logical Design

Постер Multi-Cloud Application Mobility

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

Постер VMware vCloud SDK:

Постер VMware vCloud Suite:

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

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

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

 

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

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

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

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

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

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

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

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

Диски RDM (Raw Device Mapping) для виртуальных машин VMware vSphere и серверов ESX.

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

Подключение локальных SATA-дисков сервера VMware ESXi в качестве хранилищ RDM для виртуальных машин.

Где скачать последнюю версию VMware Tools для виртуальных машин на VMware ESXi.

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

Как перенести виртуальную машину VirtualBox в VMware Workstation и обратно

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

Интервью:

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

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


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

Последние 100 утилит VMware Labs

Новые возможности VMware vSphere 8.0 Update 1

Новые возможности VMware vSAN 8.0 Update 1

Новые документы от VMware

Новые технологии и продукты на VMware Explore 2022

Анонсы VMware весной 2021 года

Новые технологии и продукты на VMware VMworld 2021

Новые технологии и продукты на VMware VMworld 2020

Новые технологии и продукты на VMware VMworld Europe 2019

Новые технологии и продукты на VMware VMworld US 2019

Новые технологии и продукты на VMware VMworld 2019

Новые технологии и продукты на VMware VMworld 2018

Новые технологии и продукты на VMware VMworld 2017



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