В последнем релизе VMware vSAN 8.0 Update 3, утилита vSAN IO Trip Analyzer была существенно доработана. В чем именно заключается это улучшение? Теперь IO Trip Analyzer может быть включен для нескольких ВМ одновременно. Это особенно полезно при устранении проблем с производительностью комплексного сервиса, состоящего из нескольких ВМ.
Данное улучшение позволяет вам одновременно мониторить несколько ВМ и анализировать, на каком уровне у каждой из выбранных ВМ возникает задержка (latency). Обратите внимание, что это улучшение работает как для vSAN ESA, так и для vSAN OSA.
Дункан Эппинг записал на эту тему интересное обзорное видео:
Современные задачи искусственного интеллекта (AI) и машинного обучения (ML) требуют высокопроизводительных решений при минимизации затрат на инфраструктуру, поскольку оборудование для таких нагрузок стоит дорого. Использование графических процессоров NVIDIA в сочетании с технологией NVIDIA AI Enterprise и платформой VMware Cloud Foundation (VCF) позволяет компаниям...
Компания Broadcom выпустила интересное видео, где Mark Achtemichuk и Uday Kulkurne обсуждают оптимизацию AI/ML нагрузок с использованием аппаратной платформы NVIDIA GPU и решения VMware Cloud Foundation:
Производительность и эффективность виртуализации графических процессоров (GPU) является одним из ключевых направлений для разработки решений в области искусственного интеллекта (AI) и машинного обучения (ML).
Виртуализация AI/ML задач, работающих на GPU, представляет собой вызов, так как традиционно считается, что виртуализация может значительно снижать производительность по сравнению с «чистой» конфигурацией на физическом оборудовании (bare metal). Однако VMware Cloud Foundation демонстрирует почти аналогичную производительность с минимальными потерями за счет умной виртуализации и использования технологий NVIDIA.
Рассматриваемые в данном видо графические процессоры от NVIDIA включают модели H100, A100 и L4, каждая из которых имеет уникальные характеристики для обработки AI/ML задач. Например, H100 оснащен 80 миллиардами транзисторов и способен ускорять работу трансформеров (на основе архитектуры GPT) в шесть раз. Особенностью H100 является возможность разделения GPU на несколько независимых сегментов, что позволяет обрабатывать задачи параллельно без взаимного влияния. A100 и L4 также обладают мощными возможностями для AI/ML, с небольшими различиями в спецификациях и применимости для графических задач и машинного обучения.
VMware Cloud Foundation (VCF) позволяет использовать все преимущества виртуализации, обеспечивая при этом производительность, близкую к физическому оборудованию. Одна из ключевых возможностей — это поддержка дробных виртуальных GPU (vGPU) с изоляцией, что позволяет безопасно распределять ресурсы GPU между несколькими виртуальными машинами.
Используя виртуализированные конфигурации на базе VCF и NVIDIA GPU, компании могут значительно снизить общие затраты на владение инфраструктурой (TCO). VMware Cloud Foundation позволяет консолидировать несколько виртуальных машин и задач на одном физическом хосте без существенной потери производительности. Это особенно важно в условиях современных датацентров, где необходимо максимизировать эффективность использования ресурсов.
В серии тестов было проверено, как виртуализированные GPU справляются с различными AI/ML задачами по сравнению с физическим оборудованием. Используя стандартные бенчмарки, такие как ML Commons, было показано, что виртуализированные GPU демонстрируют производительность от 95% до 104% по сравнению с bare metal конфигурациями в режиме инференса (вычисления запросов) и около 92-98% в режиме обучения. Это означает, что даже в виртуализированной среде можно добиться почти той же скорости, что и при использовании физического оборудования, а в некоторых случаях — даже превзойти её.
Основное преимущество использования VMware Cloud Foundation с NVIDIA GPU заключается в гибкости и экономии ресурсов. Виртуализированные среды позволяют разделять ресурсы GPU между множеством задач, что позволяет более эффективно использовать доступные мощности. Это особенно важно для компаний, стремящихся к оптимизации капитальных затрат на инфраструктуру и повышению эффективности использования серверных мощностей.
Компания VMware представила обновленную версию документа "Best Practices for VMware vSphere 8.0 Update 3", описывающего лучшие практики повышения производительности для последней версии платформы VMware vSphere 8.0 Update 3 — ценный ресурс, наполненный экспертными советами по оптимизации быстродействия. Хотя это и не является всеобъемлющим руководством по планированию и настройке ваших развертываний, он предоставляет важные рекомендации по улучшению производительности в ключевых областях.
Краткий обзор содержания:
Глава 1: Оборудование для использования с VMware vSphere (Стр. 11) — узнайте важные советы по выбору правильного оборудования, чтобы максимально эффективно использовать вашу среду vSphere.
Глава 2: ESXi и виртуальные машины (Стр. 25) — ознакомьтесь с лучшими практиками для платформы VMware ESXi и тонкими настройками виртуальных машин, работающих в этой среде.
Глава 3: Гостевые операционные системы (Стр. 57) — узнайте, как правильно оптимизировать гостевые ОС, работающие в ваших виртуальных машинах vSphere.
Глава 4: Управление виртуальной инфраструктурой (Стр. 69) — получите советы по эффективному управлению для поддержания высокопроизводительной виртуальной инфраструктуры.
Независимо от того, хотите ли вы грамотно настроить свою систему или просто ищете способы повышения эффективности, этот документ является отличным справочником для обеспечения максимальной производительности вашей среды VMware vSphere.
Платформа VMware vSAN 8 Express Storage Architecture (ESA), работающая на процессорах Intel Xeon Scalable 4-го поколения, представляет собой современное решение для гиперконвергентной инфраструктуры (HCI), способствующее консолидации серверов и поддержке высокопроизводительных рабочих нагрузок, включая ИИ.
Преимущества работы vSAN 8 ESA на Intel Xeon 4 поколения
Оптимизация хранения: в отличие от двухуровневой архитектуры предыдущих версий, ESA использует одноуровневую систему с NVMe-накопителями на базе TLC флэш-памяти, что позволяет увеличить емкость и производительность хранилища. Это снижает расходы на хранение данных, благодаря более эффективной компрессии данных и встроенной системе снапшотов.
Скорость и производительность: VMware vSAN 8 ESA, в сочетании с Intel Xeon 4, значительно ускоряет работу как традиционных, так и современных приложений. Интеграция с новейшими технологиями Intel, такими как AMX (Advanced Matrix Extensions) и AVX-512 (Advanced Vector Extensions), увеличивает количество транзакций и снижает время отклика при обработке больших данных.
Снижение задержек и повышение производительности: в тестах ESA показала до 6.2-кратного роста производительности и до 7.1-кратного снижения задержек по сравнению с предыдущими поколениями vSAN и Intel Xeon. Это позволяет консолидировать критически важные рабочие нагрузки, такие как базы данных SQL и VDI, без снижения производительности.
Поддержка AI и современных рабочих нагрузок
Для обеспечения поддержки AI-приложений, vSAN 8 ESA, благодаря новейшим процессорам Intel Xeon, справляется с обработкой больших объемов данных, необходимых для глубокого обучения и инференса, особенно в задачах классификации изображений и обработки естественного языка. Тесты показали до 9-кратного увеличения производительности при использовании INT8 в задачах машинного обучения.
Снижение затрат и повышение эффективности
За счет высокой плотности виртуальных машин и оптимизированного использования ресурсов, VMware vSAN 8 ESA позволяет сократить инфраструктурные расходы, связанные с оборудованием и энергопотреблением. Использование RAID-6 на уровне кластера с производительностью RAID-1 повышает надежность и безопасность данных без ущерба для производительности.
Заключение
VMware vSAN 8 ESA, в сочетании с процессорами Intel Xeon четвертого поколения, представляет собой мощное и экономичное решение для поддержки как традиционных, так и современных рабочих нагрузок, включая AI-приложения. Это позволяет компаниям модернизировать свою инфраструктуру, улучшить производительность и оптимизировать использование ресурсов, что особенно важно в условиях сокращающихся ИТ-бюджетов и растущих требований к производительности приложений.
Компания VMware выпустила интересный документ "Troubleshooting vSAN Performance", в котором рассматриваются вопросы решения проблем в области производительности отказоустойчивых хранилищ VMware vSAN.
Статья на VMware Core разделена на несколько ключевых разделов:
1. Определение проблемы: начальный этап, включающий идентификацию проблемы и её масштаба. 2. Обзор конфигурации: анализ текущей конфигурации vSAN, включая параметры хранилища, сеть и оборудование. 3. Анализ рабочих нагрузок: изучение типов нагрузок, которые могут влиять на производительность. 4. Метрики и инструменты: описание ключевых метрик и инструментов для мониторинга и диагностики, таких как vSAN Observer и vRealize Operations. 5. Рекомендации по оптимизации: практические советы по настройке и оптимизации для повышения производительности, включая изменения в программных и аппаратных компонентах.
Каждый из этих этапов направлен на систематическое выявление и устранение узких мест в производительности vSAN. Статья предлагает практические примеры и сценарии для понимания и решения типичных проблем.
Недавно Дункан Эппинг выступал с докладом на конференции 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 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 был включен и работал, чтобы гарантировать типичные операции ребалансировки в тестируемой среде.
Также на днях стали доступны первые результаты тестирования производительности различного оборудования с помощью VMmark 4.0. Их можно посмотреть вот тут.
Продолжаем рассказывать о производительности решения vSAN Express Storage Architecture (ESA), где реализовано высокопроизводительное кодирование RAID 5/6 с исправлением ошибок. Клиенты могут ожидать, что RAID-5/6 будет работать наравне с RAID-1 при использовании vSAN ESA. Новая архитектура обеспечит оптимальные уровни устойчивости, которые также эффективны с точки зрения использования пространства, при этом соблюдается высокий уровень производительности. Все это достигается с использованием технологии RAID-6 на базе новой журналируемой файловой системы и формата объектов.
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", они показаны ниже:
Детали тестов разных политик хранения 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:
Для имитации модели нагрузки с многосхемной работой использовались несколько схем 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
Для других типов экземпляров 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 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, и что означают все эти пункты:
Почти два года назад мы писали о решении 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 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
В прошлом году мы много писали о технологии 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 на 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%. Эти процессы восстановления полностью автоматизированы и прозрачны для пользователей приложений и тех, кто администрирует рабочие нагрузки.
Сокращение времени для восстановления показывает, что платформа становится более надежной. Но более быстрое восстановление после аппаратных сбоев имеет еще одно преимущество. Общие ресурсы становятся доступными для ваших рабочих нагрузок быстрее. Это уменьшает время, в которое может быть достигнут пиковый уровень производительности, и повышает постоянство производительности, обеспечиваемой системой.
Напомним, что в конце прошлого года в решении vSAN 8 появилась новая архитектура гиперконвергентной инфраструктуры Express Storage Architecture (ESA). Она позволяет достичь максимальных показателей производительности и эффективности на базе высокопроизводительных систем хранения.
С помощью флэш-памяти TLC на основе технологии NVMe, архитектура ESA имеет множество преимуществ со стандартной vSAN Original Storage Architecture (OSA), которая также продолжит поддерживаться для стандартного на текущий момент оборудования (устройства SATA/SAS).
Посмотрим на некоторые полезные скриншоты из видео. Улучшения производительности на уровне отдельного VMDK (RAID-6 ESA работает лучше, чем RAID-1 OSA):
Результаты теста SPEC - время отклика при увеличении числа операций в секунду:
Зависимость задержек (latency) от числа снапшотов на хранилище:
В руководство добавили различные рекомендации и новые максимальные значения инфраструктуры, касающиеся именно 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 можно по этой ссылке.
Microsoft SQL Server долгое время считается золотым стандартом для критически важных рабочих нагрузок баз данных среднего класса. Однако полноценное использование возможностей SQL Server требует соответствующей инфраструктуры.
Партнерство между Lenovo для линейки ThinkAgile VX Series и VMware в рамках технологии vSAN Express Storage Architecture (ESA) позволяет создать передовую гиперконвергентную инфраструктуру (HCI), работающую на новейших аппаратных платформах. Это решение разработано для удовлетворения сложных потребностей современных организаций, ориентированных на данные.
В 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
На конференции 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. С помощью этих возможностей возможно улучшить производительность, освободить ресурсы на хосте и изолировать рабочую нагрузку и инфраструктурные домены.
Ну и несколько картинок по результатам тестирования хостов ESXi с модулями SmartNIC/DPU на борту, которые показывают, какой прирост производительности дает новая технология:
Недавно опубликованный компанией 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" можно по этой ссылке.
Как и всегда, документ разбит на 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 можно по этой ссылке.
Архитектура 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 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.
Там приведены результаты тестирования производительности рабочих нагрузок обучения 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 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, 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, как показано на рисунке:
Мы еще не рассказывали о новых функциях по обнаружению виртуальных машин-зомби, над которыми компания 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 аноснировала финальную доступность продукта 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 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
На сайте проекта 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
Традиционно документ разбит на 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 можно по этой ссылке.
RSS
