VMGU.ru - технологии виртуализации и виртуальные машины

Использование одного устройства для NVMe Tiering и для датасторов VMFS на платформе VMware vSphere

Tue, 10 Dec 2024 13:20:32 UTC

Продолжаем рассказывать о технологии ярусной памяти Memory Tiering, которая появилась в VMware vSphere 8 Update 3 (пока в статусе Tech Preview). Вильям Лам написал об интересной возможности использования одного устройства как для NVMe Tiering, так и для датасторов VMFS на платформе VMware vSphere.

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

Оказывается, можно использовать одно устройство NVMe для NVMe Tiering!

Для владельцев систем малого форм-фактора, таких как ASUS NUC, с ограниченным количеством NVMe-устройств, есть такой вариант: вы можете запустить ESXi с USB-устройства, сохранив возможность использовать локальный VMFS-датастор и NVMe Tiering. Таким образом, у вас даже останется свободный слот или два для vSAN OSA или ESA!

Важно: Это решение не поддерживается официально со стороны VMware. Используйте его на свой страх и риск.

Шаг 1 - Убедитесь, что у вас есть пустое устройство NVMe, так как нельзя использовать устройство с существующими разделами. Для идентификации и получения имени SSD-устройства используйте команду vdq -q.

Шаг 2 – Скачайте скрипт calculateSharedNVMeTeiringAndVMFSPartitions.sh на ваш хост ESXi и укажите значения для трёх необходимых переменных:

SSD_DEVICE – имя NVMe-устройства, полученное на шаге 1.
NVME_TIERING_SIZE_IN_GB – объём хранилища (в гигабайтах), который вы хотите выделить для NVMe Tiering.
VMFS_DATASTORE_NAME – имя VMFS-датастора, который будет создан на NVMe-устройстве.

Убедитесь, что скрипт имеет права на выполнение, выполнив команду:

chmod +x /tmp/calculateSharedNVMeTeiringAndVMFSPartitions.sh

Затем запустите его, как показано на скриншоте ниже:

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

Пример выполнения сгенерированных команд для конкретной настройки: есть NVMe-устройство объёмом 1 ТБ (913,15 ГБ), из которого выделяется 256 ГБ для NVMe Tiering, а оставшееся пространство будет использовано для VMFS-датастора.

С помощью клиента ESXi Host Client мы можем увидеть два раздела, которые мы только что создали:

Шаг 3 – Включите функцию NVMe Tiering, если она еще не активирована, выполнив следующую команду ESXCLI:

esxcli system settings kernel set -s MemoryTiering -v TRUE

Шаг 4 – Настройте желаемый процент использования NVMe Tiering (от 25 до 400), исходя из конфигурации вашей физической оперативной памяти (DRAM), выполнив следующую команду:

esxcli system settings advanced set -o /Mem/TierNvmePct -i 400

Шаг 5 – Наконец, перезагрузите хост ESXi, чтобы настройки NVMe Tiering вступили в силу. После перезагрузки ваш хост ESXi будет поддерживать использование одного NVMe-устройства как для NVMe Tiering, так и для локального VMFS-датастора, готового для размещения виртуальных машин.

Стоимость и аппаратные конфигурации для виртуальной тестовой лаборатории VMware Cloud Foundation (VCF)

Mon, 09 Dec 2024 12:14:40 UTC

Вильям Лам написал интересный пост, посвященный конфигурациям для тестовых лабораторий, в которых можно развернуть полнофункциональный стенд на платформе виртуализации VMware Cloud Foundation (VCF) с гипервизором VMware vSphere.

В последнее время Вильям получает множество запросов как изнутри VMware, так и извне, по поводу рекомендаций по оборудованию для создания нового или обновления существующего домашнего лабораторного/тестового окружения с целью развертывания полноценного решения VMware Cloud Foundation (VCF). Обычно он получает не менее шести запросов в неделю по теме VMware Homelabs, но сейчас их количество возросло. Возможно, это связано с недавними распродажами в США на Black Friday и Cyber Monday, а возможно, некоторые уже готовятся к переезду на VCF 9.

В любом случае, он обычно направляет пользователей к своему проекту VMware Community Homelab, основанному на коллективной работе, где участники могут делиться своими списками оборудования (bill of materials, BOM), совокупными затратами на оборудование и решениями VMware, которые они используют в полученной среде.

Проект VMware Community Homelab существует уже несколько лет и помог множеству пользователей. Однако большинство предоставленных конфигураций в основном охватывают лишь часть портфолио VMware, и только небольшое количество из них включает VCF. Более того, некоторые из этих конфигураций устарели на несколько лет.

Внутри компании уже несколько человек поделились более актуальными списками оборудования (BOM) для создания среды, способной запускать последнюю версию VCF 5.x. Также Вильям нашел несколько подобных решений вне VMware. Поэтому он решил, что было бы полезно и своевременно собрать их аппаратные конфигурации, чтобы дать пользователям представление о том, что работает и какие варианты доступны, особенно в преддверии обновления лабораторий к 2025 году.

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

Ознакомьтесь с этой статьей VMware KB о выводе из эксплуатации и прекращении поддержки процессоров в выпусках vSphere, чтобы понять, какие процессоры будут поддерживаться в будущем, особенно с учетом следующего крупного релиза vSphere.
Многие сотрудники используют популярный сайт PC Server and Parts для поиска мощных, но относительно недорогих настольных рабочих станций старых поколений. Это хороший вариант, если вы не хотите тратить деньги на процессоры Intel или AMD последнего поколения.
Если вы выберете процессор, который больше не поддерживается, убедитесь, что он поддерживает инструкцию XSAVE CPU. Также можно обойти проверку установщика ESXi, используя параметр allowLegacyCPU=TRUE.
Память часто является первым ресурсом, который исчерпывается, поэтому убедитесь, что у вас есть достаточная емкость NVMe для использования новой функции vSphere NVMe (Memory) Tiering. Это кардинально меняет правила игры, независимо от того, запускаете ли вы нагрузки в лаборатории или будете использовать их в будущем в продакшене.
Что касается выбора процессоров, Вильям заметил, что всё больше пользователей отдают предпочтение процессорам AMD, а не Intel. Причина — не только стоимость, но и общие возможности (количество ядер, энергопотребление, охлаждение и т. д.). Например, у Raiko (см. ниже для получения дополнительной информации) есть отличная конфигурация, которую многие считают очень экономически выгодной. Многие планируют использовать его BOM для своих VCF-лабораторий.

Вот основные моменты его конфигурации (кликните для увеличения картинки):

Независимо от того, создаете ли вы лабораторную среду для работы или дома, в конечном счете, дело не только в самом оборудовании (хотя и в нем тоже), а в инвестиции в себя и свою карьеру. Вы получите от этой работы столько, сколько в нее вложите. У всех разные потребности, поэтому универсального решения не существует. Ресурсы проекта VMware Community Homelab Project и конфигурации, представленные ниже, помогут вам понять, что работает, ну а в конечном итоге выбор лучшей конфигурации зависит от ваших требований, бюджета и целей.

Примечание: если вы недавно (в течение последнего года) построили новую лабораторную среду для запуска VCF 5.x или более поздних версий и хотите поделиться своим опытом, отправьте их через VMware Community Homelab Project, перейдя сюда.

Ну и, собственно, таблица наиболее удачных конфигураций:

Автор	Стоимость ($)	Система	Процессор	Память, ГБ	Хранилище	Сеть	Графический адаптер
Daniel Krieger (подробнее)	~$4K	4 x Minisforum MS-01	Intel i9-13900H (14-Core)	96	iSCSI	2x10GbE + 2x2.5GbE	N/A
Dave Boucha	$3653.78	1x Dell Precision T7920 Workstation w/FlexBay	2 x Intel Xeon Gold 6230 (20-Core)	768	1TB SATA + 4TB SATA + 2x4TB M.2	Intel x550 PCIe (Dual Port)	Nvidia Quadro K420
Doug Parker	~$2K	1 x Dell Precision T7820	2 x Intel Xeon 6262V (24-Core)	384	1.92TB + 512GB SATA + 2x4TB M.2	Unknown	Nvidia Quadro NVS 510
Erik Bussink	$5500	1 x Custom (Supermicro H12SSl-NT)	1 x AMD EPYC 7713P (64-Core)	512	2x4TB M.2 + 2x2TB M.2	2xIntel X550-AT2	N/A
Jonathan Copeland (подробнее)	Не опубликовано	4 x Dell Precision 7820 Workstation	2 x Intel Xeon Silver 4114 (10-Core)	384	1TB SATA + 2TB M.2	Intel x540 PCIe (Dual Port)	Nvidia Quadro K600
Ryan McClain	$2503.54	1 x Custom (Supermicro X11SPM-F)	2 x Intel Xeon Gold 6148 (20-Core)	384	64GB SATADOM + 2x2TB M.2	Broadcom 57412 SFP+	N/A
Raiko Mesterheide (подробнее)	$3500	1 x Supermicro H12SSL-NT	AMD EPYC 7513 (32-Core)	512	4TB SATA + 2x4TB M.2	1GbE + 10GbE	N/A
Tim Sommer	~$2K	1 x Dell T7920 Workstation	2 x Intel Xeon Gold 6148 (20-Core)	678	512GB SATA + 2x4TB M.2	2x1GbE + 1xIntel i350 PCIe (Quad Port)	N/A
vAndu (подробнее)	$48000	3 x Custom (SuperMicro X11SPi-TF)	1 x Intel Xeon Platinum 8176 (28-Core)	512	4x2TB M.2	10GbE + 100GBE MT27700 Family [ConnectX-4]	N/A

Вышел Veeam Backup & Replication v12.3: новые возможности и улучшения

Thu, 05 Dec 2024 13:32:34 UTC

Компания Veeam, лидирующий на рынке вендор решений для резервного копирования, выпустила обновленную версию продукта Veeam Backup & Replication v12.3.

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

1. Поддержка облачных рабочих нагрузок

Microsoft Entra ID:
- Ускоренное обнаружение изменений и точечное восстановление данных.
- Автоматизация процессов резервного копирования для соблюдения требований соответствия.
- Восстановление на уровне объектов, включая регистрацию приложений.

2. Поддержка онпремизных рабочих нагрузок

Поддержка Microsoft Windows Server 2025 и Windows 11 24H2.
Расширенные возможности защиты Nutanix AHV.
Поддержка баз данных MongoDB 8, PostgreSQL 17, Oracle RMAN (23ai), SAP HANA и последних версий Linux и macOS.

3. Улучшения в области киберустойчивости

Indicators of Compromise (IoC) Detection: обнаружение инструментов злоумышленников и аномалий файловой системы.
Veeam Threat Hunter: встроенный механизм обнаружения угроз, основанный на машинном обучении и эвристическом анализе.

4. Облачное хранилище Veeam Data Cloud Vault

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

5. Искусственный интеллект

Veeam Intelligence: встроенная помощь на базе AI, предоставляющая рекомендации по оптимизации производительности и устранению неполадок.

6. Новые возможности резервного копирования

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

7. Поддержка структурированных данных

Интеграция с NetApp SnapDiff для ускоренного резервного копирования.

8. Улучшения для агентов

Новые функции в Veeam Agent for Windows, Linux и Mac, включая автоматическое восстановление "на голое железо".

9. Интеграция с корпоративными приложениями

Улучшенные возможности восстановления и управления резервными копиями для баз данных SQL Server, Oracle, MongoDB, PostgreSQL.

10. Поддержка бэкап-целей

Расширенная интеграция с Google Cloud и платформами Red Hat Virtualization (RHV).

11. Инфраструктура резервного копирования

Улучшенная миграция репозиториев резервных копий и поддержка шифрования на уровне архива.

12. Интеграция с хранилищами

Автоматическое создание объектов в S3-хранилищах для повышения производительности.

13. Консоль управления

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

14. API-расширения

Поддержка PowerShell и REST API для автоматизации управления резервными копиями.

Скачать последнюю версию решения Veeam Backup & Replication v12.3 можно по этой ссылке.

Сравнение VMware vSphere 8 Update 3 и Red Hat OpenShift Virtualization: в 1.5 раза больше ВМ и на 62% больше транзакций

Wed, 04 Dec 2024 15:25:49 UTC

Последнее независимое исследование, проведенное компанией Principled Technologies, показало, что по сравнению с Red Hat OpenShift Virtualization 4.16.2, платформа VMware vSphere поддерживает на 62% больше транзакций баз данных и сохраняет их стабильную производительность при увеличении количества виртуальных машин. Кроме того, vSphere поддерживает в 1.5 раза больше виртуальных машин на хост, чем OpenShift, без необходимости дополнительной настройки для переподписки памяти (memory overcommitment).

VMware vSphere — это корпоративная платформа виртуализации вычислительных ресурсов, разработанная для предоставления преимуществ облачных технологий в рамках локальных рабочих нагрузок. Она объединяет передовые облачные инфраструктурные технологии с ускорением, основанным на процессорах для обработки данных (DPU) и графических процессорах (GPU), чтобы повысить производительность машин. Сегодня более 300 000 компаний используют vSphere для обеспечения цифровой трансформации. vSphere позволяет ИТ-командам повысить операционную эффективность, ускорить внедрение DevOps-решений и усилить безопасность.

Последнее обновление VMware vSphere 8 Update 3 включает специальную функцию управления памятью для технологии memory overcommitment, которая помогает балансировать производительность виртуальных машин и их плотность. Но как управление памятью в vSphere соотносится с конкурирующими решениями? Компания Principled Technologies провела детальное исследование производительности и плотности виртуальных машин для VMware vSphere 8 Update 3 в сравнении с Red Hat OpenShift Virtualization версии 4.16.2.

Обзор протестированных сценариев

Исследование Principled Technologies началось с тестирования 10 виртуальных машин с установленной СУБД SQL Server c использованием нагрузки TPROC-C для оценки производительности OLTP-транзакций (измеряемой в операциях в минуту, NOPM) для каждой платформы. Начальная конфигурация предполагала memory overcommitment без фактического перераспределения памяти или стрессового использования других ресурсов сервера. Затем плотность виртуальных машин постепенно увеличивалась: сначала до 12 ВМ, создавая сценарий с небольшой переподпиской по памяти, после чего добавлялись ВМ до тех пор, пока производительность платформы не снизилась на 10% или более. Как только платформа показывала значительное ухудшение производительности, тестирование масштабирования для него прекращалось.

Оба сценария использовали один и тот же сервер Dell PowerEdge R650, отличалась только используемая платформа виртуализации.

Ключевые результаты исследования от Principled Technologies

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

В базовом тесте каждое окружение было настроено с 10 виртуальными машинами по 28 ГБ виртуальной памяти (vRAM) каждая, что составило 280 ГБ выделенной памяти без необходимости переподписки. VMware vSphere 8 Update 3 обеспечила на 27,6% больше NOPM (новых операций в минуту), чем OpenShift, при этих условиях.

На следующем этапе тестирования на обех платформах виртуальное окружение масштабировалось до 12 виртуальных машин, что превысило физическую память сервера и потребовало переподписки. vSphere 8 Update 3 успешно справилась с этим увеличением без дополнительных настроек, обеспечив рост NOPM на 6% относительно базового уровня. Напротив, OpenShift потребовала ручной настройки переподписки памяти, что привело к снижению NOPM на 6,9% относительно базового уровня.

Эти результаты показывают, что vSphere 8 Update 3 не только эффективно поддерживает переподписку памяти на производственном уровне, но и увеличивает плотность виртуальных машин и производительность транзакций с минимальным вмешательством в конфигурацию.

vSphere 8 достигает более высоких пределов плотности виртуальных машин с минимальным падением производительности

Когда оба решения были доведены до предела их возможностей для определения порога плотности виртуальных машин, была зафиксирована значительная деградация (снижение NOPM более чем на 10%). VMware vSphere 8 Update 3 достигла значительной деградации при 20 виртуальных машинах, показав снижение NOPM на 14,31% по сравнению с конфигурацией из 12 виртуальных машин с небольшой переподпиской памяти. В то же время OpenShift Virtualization 4.16.2 столкнулась с деградацией уже при 13 виртуальных машинах, продемонстрировав снижение NOPM на 23,19% по сравнению с конфигурацией из 12 виртуальных машин. Это указывает на более низкий порог плотности для оптимальной производительности в случае OpenShift.

При запуске 20 виртуальных машин решение vSphere 8 Update 3 достигло пикового уровня загрузки процессора в 94,4%. При 12 виртуальных машинах загрузка процессора у vSphere составила 91,7%, а при 10 виртуальных машинах — 80,1%. В то же время решение OpenShift Virtualization 4.16.2 показало загрузку процессора в 58,3% при 13 виртуальных машинах, 61,5% при 12 виртуальных машинах и 52,1% при 10 виртуальных машинах. Этот тест демонстрирует, что vSphere 8 Update 3 может справляться с более высокой плотностью виртуальных машин, обеспечивая лучшую стабильность производительности при переподписке выделенной памяти по сравнению с OpenShift.

Производительность технологии VMware vSGA на базе оборудования Intel Data Center GPU Flex в рамках VDI-нагрузок

Mon, 02 Dec 2024 06:17:49 UTC

Интересный документ выпустила компания VMware - "Improving VDI Workload Consolidation with VMware vSGA and Intel Data Center GPU Flex Series", в нем рассматриваются аспекты тестирования производительности VDI-нагрузок в различных контекстах на базе оборудования Intel Data Center GPU Flex в режиме vSGA (то есть совместного использования видеоадаптера несколькими ВМ)...

Интересное видео: RAG Pipelines с VMware Private AI Foundation и NVIDIA - использование AI для повышения эффективности

Fri, 29 Nov 2024 09:44:02 UTC

На второй день конференции VMware Explore в Барселоне обсуждались передовые технологии, включая решения VMware Private AI Foundation и их интеграцию с решениями от NVIDIA. В видео ниже ведущие эксперты делятся опытом применения Retrieval Augmented Generation (RAG) и другими ключевыми возможностями Private AI для повышения эффективности работы корпоративных систем и оптимизации использования AI.

Основные темы видео:

Что такое VMware Private AI?
- VMware Private AI — это платформа, которая позволяет использовать возможности искусственного интеллекта, сохраняя конфиденциальность данных.
- RAG (Retrieval Augmented Generation) — технология, интегрирующая базу данных с частными данными в модели AI, что обеспечивает точные ответы и минимизирует "галлюцинации" модели.
Ключевые сценарии использования Private AI:
- Внутренние чат-боты: помощь сотрудникам, например, операторам колл-центров, в быстром получении ответов с использованием внутренних данных компании.
- Генерация кода: создание инструментов для разработчиков на основе частных данных, таких как внутренний исходный код.
- Работа с внутренними базами знаний: быстрый доступ к информации, хранящейся в документации или системах управления знаниями, таких как Confluence.
RAG: Что это и как работает?
- Использует внутренние базы данных (векторные базы данных) для поиска информации, релевантной запросу.
- Пример: при запросе информация сначала ищется в базе знаний, а затем контекст передается модели AI для создания точного и краткого ответа.
Интеграция с NVIDIA:
- Использование NVIDIA NGC для адаптации моделей под ресурсы, такие как GPU, с возможностью значительного повышения производительности (в 2–8 раз).
- Поддержка различных уровней точности вычислений (FP32, FP16 и другие) для оптимального баланса скорости и качества.
Модельное управление и тестирование:
- Встроенные инструменты для проверки моделей AI на наличие ошибок, галлюцинаций и других проблем до их использования.
- Гибкая интеграция любых моделей, включая те, что загружаются из Hugging Face, NVIDIA или создаются внутри компании.
Преимущества подхода Private AI:
- Сохранение конфиденциальности данных в онпремизных средах.
- Повышение точности работы моделей за счет использования внутренних данных.
- Улучшение взаимодействия сотрудников с клиентами и внутри команды.

Для кого это видео:

Системных администраторов, DevOps-инженеров, специалистов по AI.
Компаний, стремящихся внедрить передовые технологии AI, сохраняя конфиденциальность данных.
Тех, кто хочет углубить знания в области RAG и Private AI.

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

Устаревание контроля ввода-вывода (SIOC) для балансировщика нагрузки VMware Storage DRS

Wed, 27 Nov 2024 13:45:33 UTC

Недавно компания VMware сделала важный анонс относительно компонента балансировщика нагрузки ввода-вывода Storage DRS (SDRS), который включает в себя механизм балансировки нагрузки на основе reservations для SDRS I/O и контроля ввода-вывода Storage I/O Control (SIOC). Все они будут устаревшими в будущих выпусках vSphere. Анонс был сделан в рамках релиза платформы VMware vSphere 8.0 Update 3. Об этом рассказал Дункан Эппинг.

Текущие версии ESXi 8.x и 7.x продолжат поддерживать эту функциональность. Устаревание затронет балансировку нагрузки на основе задержек (latency) для ввода-вывода и балансировку на основе reservations для ввода-вывода между хранилищами в кластере хранилищ Storage DRS. Кроме того, включение SIOC на хранилище и установка reservations и приоритетов с помощью политик хранения SPBM также будут устаревшими. Начальное размещение и балансировка нагрузки Storage DRS на основе хранилищ и настроек политик хранения SPBM для лимитов не будут затронуты.

Для Storage DRS (SDRS) это означает, что функциональность «балансировки по емкости» (capacity balancing) останется доступной, но все, что связано с производительностью, будет недоступно в следующем крупном выпуске платформы. Кроме того, обработка «шумных соседей» (noisy neighbor) через SIOC с использованием приоритетов или, например, reservations ввода-вывода также больше не будет доступна.

Некоторые из вас, возможно, уже заметили, что в интерфейсе на уровне отдельных ВМ исчезла возможность указывать лимит IOPS. Что это значит для лимитов IOPS в целом? Эта функциональность останется доступной через управление на основе политик (SPBM), как и сейчас. Таким образом, если вы задавали лимиты IOPS для каждой ВМ в vSphere 7 отдельно, после обновления до vSphere 8 вам нужно будет использовать настройку через политику SPBM. Опция задания лимитов IOPS через SPBM останется доступной. Несмотря на то, что в интерфейсе она отображается в разделе «SIOC», на самом деле эта настройка применяется через планировщик дисков на уровне каждого хоста.

О программе-вымогателе Termite Ransomware и ее перехвате с помощью VMware Carbon Black

Tue, 26 Nov 2024 15:56:31 UTC

Термит — это оператор программ-вымогателей (шифрование, кража данных, вымогательство), который недавно заявил о нескольких жертвах во Франции, Канаде, Германии, Омане и США. Их атаки нацелены на такие секторы, как государственные учреждения, образование, нефтегазовая промышленность, водоочистка и автомобилестроение. Логотип группы представляет собой стилизованного синего термита с элементами, напоминающими электронные схемы.

Группа, по всей видимости, использует модифицированную версию печально известного вымогательского ПО Babuk. После запуска вируса на устройстве файлы шифруются, и к их названиям добавляется расширение .termite. Также оставляется записка с требованиями выкупа (How To Restore Your Files.txt) с кратким описанием действий. Преступники предоставляют ссылку на свой Onion-сайт, а также уникальный токен и адрес электронной почты для связи. На сайте жертвам предлагается форма для прямой коммуникации, в которой нужно указать название компании, описание ситуации, полное имя, адрес электронной почты и "токен поддержки".

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

Компания Symantec, входящая в группу Broadcom, защищает от этой угрозы следующими способами:

На основе решения VMware Carbon Black

Связанные вредоносные индикаторы блокируются и обнаруживаются существующими политиками в продуктах VMware Carbon Black. Рекомендуется как минимум заблокировать запуск всех типов вредоносных программ (известных, подозрительных и PUP) и включить задержку выполнения для проверки в облаке, чтобы максимально использовать преимущества службы репутации VMware Carbon Black Cloud.

На основе файлов

Здесь должен отработать модуль Ransom.Babuk,

На основе машинного обучения

Тут работает модуль Heur.AdvML.B.

Более подробно об этом можно узнать тут.

Производительность облачных приложений: распространённые причины замедленной работы

Mon, 25 Nov 2024 08:27:34 UTC

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

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

Эта распространённая ситуация часто вызвана задержками ввода-вывода, связанными с передачей данных. Представьте, что это же приложение снова запускается на физическом сервере, но в следующем сценарии: устройство хранения базы данных создаётся на удалённом хранилище с Network File System (NFS).

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

Количество приложений, обращающихся к конечной точке хранилища (предполагается, что оно быстрое по своему устройству).
Это будет влиять на общую производительность отклика из-за производительности подсистемы ввода-вывода хранилища.
Способ, которым приложение извлекает данные из базы данных.
Кэширует ли оно данные, или просто отправляет очередной запрос? Являются ли запросы небольшими или крупными?
Задержка, вызванная сетевым доступом к хранилищу, и общая скорость работы хранилища.
При доступе к сетевому устройству несколько ключевых факторов влияют на скорость передачи данных:
- Доступная скорость соединения
- Используемое максимальное время передачи (MTU) / максимальный размер сегмента (MSS)
- Размер передаваемой полезной нагрузки
- Настройки TCP окна (скользящее окно)
- Среднее время задержки при прохождении маршрута (RTT) от точки A до точки B в мс.

В датацентре скорость соединения обычно не является проблемой, поскольку все узлы соединены с пропускной способностью не менее 1 Гбит/с, иногда 10 Гбит/с, и подключены к одному коммутатору. MTU/MSS будет оптимальным для настроенного соединения. Остаются размер передаваемой полезной нагрузки, скользящее окно TCP и среднее RTT. Наибольшее влияние окажут размер полезной нагрузки, задержка соединения и его качество, которые будут влиять на параметры скользящего окна.

Вот пример задержек между узлами в текущей настройке Kubernetes:

При увеличении размера полезной нагрузки пакета в пинге, как только он превышает текущий MTU, время отклика начинает увеличиваться. Например, для node2 размер полезной нагрузки составляет 64k — это экстремальный случай, который наглядно демонстрирует рост задержки.

Учитывая эти три момента (размер передаваемой полезной нагрузки, скользящее окно TCP и среднее RTT), если разработчик создаёт приложение без использования встроенных возможностей кэширования, то запросы к базе данных начнут накапливаться, вызывая нагрузку на ввод-вывод. Такое упущение направляет все запросы через сетевое соединение, что приводит к увеличению времени отклика всего приложения.

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

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

Тесты показали, что алгоритм скользящего окна привёл к снижению скорости передачи данных (для справки: это механизм, используемый удалённым хранилищем на основе NFS). При среднем размере полезной нагрузки 4 Кб скорость передачи данных упала с 12 МБ/с на быстром соединении 1 Гбит/с (8 мс задержки) до ~15 Кбит/с, когда задержка соединения достигла 180 мс. Скользящее окно может вынудить каждую передачу данных возвращать пакет подтверждения (ACK) отправителю перед отправкой следующего пакета на соединениях с низкой задержкой.

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

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

Ниже приведён реальный пример, показывающий время отклика приложения. База данных развернута на node2.

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

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

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

Это значительное улучшение производительности было достигнуто за счёт сокращения задержек сетевых запросов (round trip), то есть перемещения контейнера базы данных на тот же узел.

Ещё одним распространённым фактором, влияющим на производительность Kubernetes, являются ESXi-среды, где узлы кластера имеют избыточную нагрузку на ввод-вывод сети, а узлы Kubernetes развёрнуты в виде виртуальных машин. Узел Kubernetes не может увидеть, что CPU, память, ввод-вывод диска и/или подключённое удалённое хранилище уже находятся под нагрузкой. В результате пользователи сталкиваются с ухудшением времени отклика приложений.

Как оптимизировать производительность приложения

Учтите кэширование в дизайне приложения.
Убедитесь, что приложение учитывает кэширование (общих запросов, запросов к базе данных и так далее) и не выполняет лишних запросов.
Отключите переподписку ресурсов (oversubscription) в средах ESXi.
Если Kubernetes/OpenShift работают поверх ESXi, убедитесь, что переподписка ресурсов отключена для всех доступных CPU и памяти. Учтите, что даже небольшие задержки могут быстро накопиться и привести к эластичному поведению времени отклика приложения. Кроме того, если хост ESXi уже находится под нагрузкой, запущенные на нём образы не будут осведомлены об этом, и оркестратор Kubernetes может развернуть дополнительные поды на этом узле, считая ресурсы (CPU, память, хранилище) всё ещё доступными. Поэтому, если вы используете Kubernetes/OpenShift, а у вас есть возможность запустить их на физическом сервере, сделайте это! Вы получите прямую и полную видимость ресурсов хоста.
Минимизируйте сетевые задержки ввода-вывода в Kubernetes.
Сократите сетевые задержки ввода-вывода при развёртывании подов. Упакуйте контейнеры в один под, чтобы они развертывались на одном узле. Это значительно снизит сетевые задержки ввода-вывода между сервером приложений и базой данных.
Размещайте контейнеры с высокими требованиями к базе данных на узлах с быстрым хранилищем.
Развёртывайте контейнеры, которым требуется быстрый доступ к базе данных, на узлах с быстрым хранилищем. Учитывайте требования к высокой доступности и балансировке нагрузки. Если хранилище NFS недостаточно быстрое, рассмотрите возможность создания PV (Persistent Volume) на определённом узле с локальным RAID 10 диском. Учтите, что в этом случае резервирование придётся настраивать вручную, так как оркестратор Kubernetes не сможет управлять этим при отказе оборудования конкретного узла.

Как мониторить задержки между компонентами

Для Kubernetes, OpenShift и Docker (Swarm) можно использовать Universal Monitoring Agent (UMA), входящий в решения AIOps and Observability от Broadcom, для мониторинга взаимодействия всего окружения. Этот агент способен извлекать все релевантные метрики кластера. Если UMA обнаруживает поддерживаемую технологию, такую как Java, .Net, PHP или Node.js, он автоматически внедряет пробу (probe) и предоставляет детализированную информацию о выполнении приложения по запросу. Эти данные включают запросы ввода-вывода (I/O) от компонента к базе данных, удалённые вызовы и другие внутренние метрики приложения.

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

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

User front-end => Web-Server front-end => app-server => databases | remote services

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

Видео Extreme Performance Series 2024 - улучшение консолидации серверов с помощью технологии Memory Tiering

Fri, 22 Nov 2024 11:40:56 UTC

Компания VMware недавно выпустила интересное видео в рамках серии Extreme Performance, где рассматривается, как технологии Memory Tiering могут оптимизировать серверную инфраструктуру, улучшить консолидацию серверов и снизить общую стоимость владения (TCO). Ведущие эксперты, работающие в сфере производительности платформ VMware, делятся новейшими разработками и результатами тестов, которые помогут сделать работу администраторов с серверами более эффективной.

Основные моменты видео:

Что такое Memory Tiering? Memory Tiering — это технология, реализованная в ядре ESXi, которая прозрачно для приложений и гостевых ОС разделяет память на два уровня:
- Tier 1: Быстрая память DRAM.
- Tier 2: Бюджетные и емкие устройства памяти, такие как NVMe SSD и CXL.
Преимущества Memory Tiering:
- Увеличение доступной памяти за счет использования NVMe в качестве памяти второго уровня.
- Снижение затрат на память до 50%.
- Исключение таких проблем, как ballooning и случайный обмен страницами.
Реальные результаты:
- Удвоение плотности виртуальных машин (VMs): на одной хост-машине можно разместить вдвое больше ВМ без заметной потери производительности (<3%).
- Оптимизация работы баз данных: для SQL Server и Oracle наблюдалось почти линейное масштабирование с минимальными потерями производительности.
- Стабильный пользовательский опыт (VDI): эталонный тест Login VSI показал, что даже при удвоении числа ВМ пользовательский опыт остается на высоком уровне.
Ключевые метрики и рекомендации:
- Active memory: один из основных параметров для мониторинга. Оптимальный уровень — около 50% от объема Tier 1 (DRAM).
- Использование NVMe: рекомендации по чтению и записи (до 200 мс latency для чтения и 500 мс для записи).
Практические примеры и кейсы:
- Клиенты из финансового и медицинского секторов, такие как SS&C Cloud, уже успешно применяют Memory Tiering, чтобы уменьшить затраты на серверы и улучшить их производительность.
Советы по настройке и мониторингу:
- Как отслеживать активность NVMe-устройств и состояние памяти через vCenter.
- Какие показатели важны для анализа производительности.

Кому будет полезно:

Системным администраторам, DevOps-инженерам и специалистам по виртуализации.
Организациям, которые стремятся сократить затраты на ИТ-инфраструктуру и повысить плотность виртуализации.
Любителям передовых технологий, которые хотят понять, как современные подходы меняют управление памятью в дата-центрах.

Memory Tiering — это прорывная технология, которая уже сегодня позволяет добиться больших результатов в консолидации серверов. Узнайте, как её применить в вашем окружении, и станьте частью следующего поколения производительности серверов.

VMware Cloud Foundation 9 - возможности Federated Storage View для VMware vSAN

Thu, 21 Nov 2024 14:46:35 UTC

Дункан Эппинг продолжает рассказывать о новых возможностях платформы VMware Cloud Foundation 9, которая была представлена на прошедшей конференции VMware Explore 2024.

На этот раз Дункан рассказал о работе функции Federated Storage View для платформы VMware vSAN, а также для других традиционных систем хранения данных. Это представление позволит получить визуальную информацию о емкостях и производительности хранилищ, а также наглядно отобразит конфигурацию растянутого кластера (stretched cluster).

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

Операционная система Windows Server 2025 официально сертифицирована для VMware vSphere

Wed, 20 Nov 2024 06:56:53 UTC

Broadcom сообщила, что ОС Windows Server 2025 официально сертифицирована для работы на платформе VMware vSphere версий 7.0 U3, 8.0, 8.0 U1, 8.0 U2 и 8.0 U3. Эти версии прошли тестирование и валидацию, обеспечивая стабильную и высокопроизводительную платформу для запуска Windows Server 2025 в качестве гостевой операционной системы в виртуальных машинах. Для получения подробной информации о поддерживаемых версиях обратитесь к Broadcom Compatibility Guide.

Что нового?

Сертификация VMware vSphere в рамках программы Microsoft SVVP

VMware vSphere 7.0 U3, 8.0, 8.0 U1, 8.0 U2 и 8.0 U3 входят в число первых гипервизоров, сертифицированных в рамках программы Microsoft Windows Server Virtualization Validation Program (SVVP). Эта сертификация подтверждает официальную поддержку Microsoft и VMware для работы Windows Server 2025 в средах VMware vSphere. Подробнее ознакомиться с сертификацией можно на странице сертификации VMware vSphere SVVP.

Поддержка VMware Tools с первого дня для Windows Server 2025

Все драйверы в режиме ядра VMware Tools полностью сертифицированы для Windows Server 2025, что обеспечивает высокую совместимость, стабильность и безопасность. Дополнительную информацию можно найти в блоге: VMware Tools 12.5.0 готов к работе с новейшими операционными системами Windows.

Драйверы VMware PVSCSI и VMXNET3 включены в Windows Server 2025

Начиная с Windows Server 2022, а теперь и для Windows Server 2025, драйверы VMware Paravirtual SCSI (PVSCSI) и сетевого адаптера VMXNET3 предустановлены в ОС от Microsoft. Это упрощает процесс настройки и обеспечивает эффективное развертывание виртуальных машин Windows Server с высокопроизводительными виртуальными устройствами без необходимости ручной установки драйверов.

Новый плагин VMXNET3 KDNET для отладки сетевого ядра

В Windows Server 2025 включён плагин расширения VMXNET3 KDNET для отладки сетевого ядра. Это позволяет выполнять отладку напрямую в виртуальной среде, предоставляя разработчикам удобный и эффективный процесс отладки. Дополнительную информацию о настройке сетевой отладки ядра можно найти в документации Microsoft.

Установка Windows Server 2025 в VMware vSphere

Перед развертыванием виртуальных машин с Windows Server 2025 в VMware vSphere рекомендуется ознакомиться с Руководством по совместимости Broadcom, чтобы убедиться в совместимости вашего оборудования и продуктов VMware. Это руководство содержит важную информацию о поддерживаемых серверах, устройствах хранения, сетевых адаптерах и других компонентах.

Для получения подробных инструкций по установке обратитесь к документации VMware: "Руководство по установке Windows Server 2025".

Ссылки и известные проблемы

Для устранения неисправностей и оптимизации развертывания виртуальных машин Windows Server 2025 на VMware vSphere ознакомьтесь с приведёнными ниже статьями базы знаний (KB). Эти статьи охватывают вопросы совместимости VMware Tools, а также решения известных проблем.

Все презентации VMware Explore 2024 US и Europe доступны для скачивания

Mon, 18 Nov 2024 15:25:15 UTC

После прошедших главных конференций года VMware Explore 2024 US и Europe Вильям Лам провел большую работу по сбору и категоризации сессий, выложив их все в открытом доступе в своем репозитории на Github. Эти презентации доступны как в виде ссылок на видеозаписи, так и в виде pdf-документов, где можно найти массу информации о новых продуктах и технологиях VMware.

Материалы с VMware Explore 2024 US доступны тут:

Всего из американского Explore собрано 218 презентаций в 5 категориях:

Top 10 Sessions (лучшие презентации по мнению Вильяма)
Cloud Infrastructure (120)
Innovation (25)
Modern Applications (28)
Networking, Security and Load Balancing (32)
Software-Defined Edge (13)

Презентации VMware Explore 2024 Europe собраны вот тут:

Всего из европейского Explore собрано 155 презентаций в 5 категориях:

Cloud Infrastructure (124)
Innovation (10)
Modern Applications (12)
Network, Security & Load Balancing (12)
Software-Defined Edge (11)

Анонсы VMware Explore 2024 Europe: новые возможности VMware vSAN 9 в составе VMware Cloud Foundation 9

Fri, 15 Nov 2024 12:16:25 UTC

На конференции Explore в Барселоне было сделано несколько объявлений и показаны элементы дорожной карты, которые не были представлены ранее в Лас-Вегасе. Так как сессии в Барселоне не записывались, Дункан Эппинг поделился функциями, о которых он говорил на Explore, и которые в настоящее время планируются для платформы VCF 9. Обратите внимание, что неизвестно, когда эти возможности станут общедоступными, и всегда существует вероятность, что они могут не выйти вообще.

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

Для тех, кто не смотрит видео, ниже кратко описана функциональность, над которой VMware работает для VCF 9. Публичное объявление об этом пока не сделано, поэтому большого количества деталей не будет.

vSAN Automated Site Maintenance

В среде с растянутым кластером vSAN, когда вы хотите выполнить обслуживание узла, на сегодняшний день вам нужно переводить каждый хост в режим обслуживания по одному. Это не только административная/операционная нагрузка, но и увеличивает риск случайного перевода в режим обслуживания неправильных хостов. Более того, из-за последовательного подхода данные, хранящиеся на хосте 1 в сайте A, могут отличаться от данных на хосте 2 в сайте A, что создает несогласованность данных в пределах сайта.

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

vSAN Site Takeover

Одной из функций, которой многим не хватало долгое время, была возможность сохранить работоспособность сайта в случае, если два из трех сайтов одновременно выходят из строя. Здесь на помощь приходит функция Site Takeover. Если вы оказались в ситуации, когда одновременно выходят из строя как Witness Site, так и сайт с данными, вы все равно хотите иметь возможность восстановить работу. Особенно учитывая, что на втором сайте, скорее всего, имеются здоровые объекты для каждой ВМ. Функция vSAN Site Takeover поможет в этом. Она позволит вручную (через интерфейс или скрипт) указать vSAN, что, несмотря на потерю кворума, локальный набор RAID для каждой затронутой ВМ должен быть снова доступен. После этого, конечно, vSphere HA даст хостам команду включить эти ВМ.

Запуск VMwre ESXi-Arm V2 в виде вложенной виртуальной машины (Nested ESXi)

Thu, 14 Nov 2024 05:26:58 UTC

Недавно мы писали о том, что команда ESXi-Arm выпустила новую версию популярной платформы виртуализации ESXi-Arm Fling (v2.0) (ссылка на скачивание тут), которая теперь основана на базе кода ESXi версии 8.x и конкретно использует последний релиз ESXi-x86 8.0 Update 3b.

Вильям Лам рассказал о том, что теперь вы можете запустить экземпляр ESXi-Arm V2 внутри виртуальной машины, что также называется Nested ESXi-Arm. На конференции VMware Explore в США он использовал Nested ESXi-Arm, так как у него есть ноутбук Apple M1, и ему нужно было провести демонстрацию для сессии Tech Deep Dive: Automating VMware ESXi Installation at Scale, посвященной автоматизированной установке ESXi с помощью Kickstart. Поскольку и ESXi-x86, и ESXi-Arm имеют одинаковую реализацию, возможность запуска Nested ESXi-Arm оказалась полезной (хотя он использовал версию, отличающуюся от официального релиза Fling). Такой же подход может быть полезен, если вы хотите запустить несколько виртуальных машин ESXi-Arm для изучения API vSphere и подключить Nested ESXi-Arm к виртуальной машине x86 VCSA (vCenter Server Appliance). Возможно, вы разрабатываете что-то с использованием Ansible или Terraform - это действительно открывает множество вариантов для тех, у кого есть такая потребность.

Arm Hardware

Так же как и при создании Nested ESXi-x86 VM, выберите опцию типа ВМ "Other" (Другое) и затем выберите "VMware ESXi 8.0 or later", настроив как минимум на 2 виртуальных процессора (vCPU) и 8 ГБ оперативной памяти.

Примечание: Текущая версия ESXi-Arm НЕ поддерживает VMware Hardware-Assisted Virtualization (VHV), которая необходима для запуска 64-битных операционных систем в Nested или внутренних виртуальных машинах. Если вы включите эту настройку, запустить Nested ESXi-Arm VM не получится, поэтому убедитесь, что эта настройка процессора отключена (по умолчанию она отключена).

VMware Fusion (M1 и новее)

Еще одна хорошая новость: для пользователей Apple Silicon (M1 и новее) теперь также можно запускать виртуальные машины Nested ESXi-Arm! Просто выберите «Other» (Другое), затем тип машины «Other 64-bit Arm» и настройте ВМ с как минимум 2 виртуальными процессорами (vCPU) и 8 ГБ оперативной памяти. Вильяму как раз потребовалась эта возможность на VMware Explore, когда он демонстрировал вещи, не связанные напрямую с архитектурой Arm. Он попросил команду инженеров предоставить внутреннюю сборку ESXi-Arm, которая могла бы работать на Apple M1, теперь же эта возможность ESXi-Arm доступна для всех.

Примечание: поскольку для работы Nested-ESXi-Arm требуется режим promiscuous mode, при включении виртуальной машины в VMware Fusion вас могут раздражать запросы на ввод пароля администратора. Если вы хотите отключить эти запросы, ознакомьтесь с этой статьей в блоге для получения дополнительной информации.

Платформы VMware Workstation и VMware Fusion стали абсолютно бесплатными для всех (в том числе для коммерческого использования)

Tue, 12 Nov 2024 06:57:56 UTC

В мае этого года мы писали о том, что настольные платформы виртуализации VMware Workstation Pro и VMware Fusion Pro стали бесплатными для домашних пользователей (но не для коммерческого использования).

Теперь же в рамках конференции VMware Explore 2024 Europe было объявлено о том, что теперь обе этих платформы стали полностью бесплатными. Начиная с 11 ноября 2024 года, эти гипервизоры для настольных компьютеров стали бесплатны для всех — любых коммерческих компаний, образовательных организаций и обычных пользователей.

Что изменится, и что это значит для текущих подписчиков?

Сразу же оба продукта — VMware Fusion и VMware Workstation — переходят на бесплатную модель, что означает, что теперь вы можете пользоваться этими инструментами в любых целях. Платные версии, такие как Workstation Pro и Fusion Pro, больше не будут доступны для покупки.

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

Как эти изменения повлияют на текущую поддержку и функционал Desktop Hypervisor?

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

Модель поддержки для бесплатных продуктов

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

Доступ к сообществу: присоединяйтесь к растущему сообществу пользователей, чтобы делиться инсайтами, советами и решениями. Для Workstation это здесь, а для Fusion - тут.
Обширная документация по продукту: подробная документация поможет вам максимально эффективно использовать эти инструменты. Для Workstation - вот, а для Fusion - вот.
Статьи из базы знаний: доступ к обширной библиотеке статей по устранению неполадок и расширенным функциям. Ссылка тут.

Планы на будущее

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

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

Для получения дополнительной информации о новостях и ресурсах по VMware Desktop Hypervisor посетите страницу продукта и раздел FAQ.

Анонсы VMware Explore 2024 Europe: расширение экосистемы Private AI за счет решения Microsoft Azure AI Video Indexer

Mon, 11 Nov 2024 08:07:36 UTC

С момента основания VMware ее цель заключалась в том, чтобы обеспечить клиентам и партнёрам широкий выбор типов приложений и сервисов, которые они могут запускать в облачной инфраструктуре. Этот основной принцип также лежит в основе подхода к экосистеме Private AI.

Сегодня среди множества поддерживаемых коммерческих и открытых моделей и сервисов AI, клиенты теперь могут запускать Azure AI Video Indexer, поддерживаемый технологией Azure Arc, на платформе VMware Cloud Foundation на локальных серверах или в облаке Azure VMware Solution.

Клиенты и партнёры VMware просили более тесно сотрудничать с Microsoft для интеграции сервисов Azure в инфраструктуру VMware на локальных серверах. Включение Azure Video Indexer on Arc в VMware Cloud Foundation является важным первым шагом в этом направлении.

Возможности VMware Private AI и Azure Video Indexer

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

Azure Video Indexer — это сервис видеоаналитики в облаке и на периферии, использующий AI для извлечения полезных данных из аудио- и видеофайлов. При развертывании в виде расширения Arc на Kubernetes-кластерах он предоставляет мощные возможности видеоанализа для локальных сред.

Зачем интегрировать VMware Private AI с Azure Video Indexer on Arc?

Интеграция этих двух технологий даёт несколько важных преимуществ:

Конфиденциальность данных и контроль: обработка чувствительного видеоконтента на локальных серверах при сохранении полного контроля над данными.
Экономичность: использование существующей инфраструктуры VMware для AI-нагрузок, что потенциально снижает затраты на облако.
Улучшенное обнаружение контента: возможность поиска с автоматическим извлечением метаданных из видеоконтента.
Интеллектуальная оптимизация инфраструктуры: динамическое объединение и распределение ресурсов AI, включая вычислительные мощности, сеть и данные.
Соответствие требованиям: соблюдение регуляторных требований с размещением данных и средств их обработки в контролируемой среде.
Упрощённое управление: управление как инфраструктурой, так и AI-нагрузками через привычные инструменты VMware.

Примеры использования

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

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

Интеграция VMware Private AI с Azure Video Indexer on Arc, работающего на кластерах Tanzu Kubernetes внутри VCF, представляет собой отличное решение для организаций, стремящихся использовать AI для анализа видео, сохраняя контроль над данными и инфраструктурой. Эта комбинация предлагает улучшенную конфиденциальность, масштабируемость и производительность, открывая новые возможности для AI-инсайтов в различных отраслях.

Новая сборка ESXi-Arm на базе VMware vSphere 8.0 Update 3b

Fri, 08 Nov 2024 11:01:28 UTC

Вильям Лам сообщает, что команда ESXi-Arm недавно выпустила новую версию популярной платформы виртуализации ESXi-Arm Fling (v2.0) (ссылка на скачивание тут), которая теперь основана на базе кода ESXi версии 8.x и конкретно использует последний релиз ESXi-x86 8.0 Update 3b. Это очень значимое обновление, так как изначальный релиз ESXi-Arm Fling (выпущенный 4 года назад) был основан на ESXi 7.x при начальной адаптации x86-дистрибутива для архитектуры ARM.

После выпуска первого коммерческого продукта ESXi-Arm в составе vSphere Distributed Service Engine (vDSE), ранее известного как Project Monterey, команда ESXi-Arm активно работала над унификацией кодовой базы ESXi-Arm, которая также используется и для работы коммерческой технологии vDSE.

В дополнение к переезду ESXi-Arm с версии 7.x на 8.x, команда продолжает поддерживать широкий спектр систем на базе Arm, которые представлены в списке ниже:

Серверы на базе Ampere Computing Altra и AltraMax (системы с одним процессором, такие как HPE ProLiant RL300 Gen 11, или системы с двумя процессорами, как Ampere 2U Mt. Collins)
Платформа mini-ITX SolidRun HoneyComb LX2K на базе NXP LayerScape 2160A
Raspberry Pi 4B (только с 8 ГБ памяти)
Raspberry Pi 5 (только с 8 ГБ памяти)
PINE64 Quartz64 Model A и вычислительный модуль SOQuartz на базе Rockchip RK3566
Firefly ROC-RK3566-PC и StationPC Station M2 на базе Rockchip RK3566

Для тех, кто обновляется с Fling версии 1.x, потребуется небольшое ручное обновление конфигурационных файлов виртуальных машин. Обязательно прочитайте главу 3 "Upgrading from Fling v1" в документации к ESXi. Чтобы загрузить последнюю версию ESXi-Arm ISO/Offline Bundle вместе с обновленной документацией по ESXi-Arm, используйте вашу бесплатную учетную запись или зарегистрируйтесь на Broadcom Community и посетите портал VMware Flings.

Анонсы VMware Explore 2024 Europe: Intelligent Assist for vDefend

Thu, 07 Nov 2024 13:51:54 UTC

VMware vDefend с инновационным помощником на основе GenAI ускоряет защиту от угроз программ-вымогателей (ransomware), предоставляя объяснения, ориентированные на контекст цепочки атаки, коррелированные сведения о кампаниях угроз и направленные рекомендации по их устранению.

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

VMware vDefend находится на переднем крае инноваций в области AI и ML, включая использование AI для рекомендаций по правилам микросегментации и применение ML к трафику и контекстам рабочих нагрузок для получения детализированных сведений. Сейчас VMware сделала логичный, но важный следующий шаг, используя GenAI и крупные языковые модели (LLM), чтобы ещё больше помочь клиентам защитить свои ценные активы.

За последний год команда VMware усердно работала над инициативой под названием Project Cypress. Результатом стал Intelligent Assist for vDefend, основанный на GenAI и LLM. Эта новая возможность упрощает работу команд виртуализации, сетевой безопасности и SOC, помогая им понять детальную, контекстуальную информацию об активных угрозах и их влиянии. Всего за несколько кликов команды могут инициировать устранение, упрощая процессы, которые раньше требовали сложных рабочих процессов с использованием нескольких продуктов. Улучшая реакцию на угрозы, Intelligent Assist for vDefend позволяет командам по безопасности и инфраструктуре работать более слаженно для защиты от атак вымогателей и вносить больший вклад в безопасность.

Детализация сложных угроз и предупреждений безопасности

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

Зачастую важный контекст события — например, что происходило до и после него — упускался из виду. Хотя существует множество систем для оценки серьезности или влияния уязвимостей, они не могут передавать эту информацию на естественном языке, что затрудняет оценку масштаба кампаний угроз. Обмен индикаторами компрометации (Indicators of Compromise, IoC) для обнаружения угроз также был исторически сложным по аналогичным причинам.

Генеративный AI ускоряет и упрощает операции по поддержанию безопасности. Инструменты на базе GenAI значительно увеличивают способность команд безопасности обрабатывать большие объемы предупреждений, которые иначе были бы перегружающими из-за их количества. GenAI может сэкономить часы — или даже дни — ручных усилий, интеллектуально приоритизируя и коррелируя эти предупреждения для надлежащего устранения. Это повышение скорости напрямую улучшает защиту от угроз.

Решение Intelligent Assist для vDefend

В основе Intelligent Assist лежит интерактивный чат-бот на базе большой языковой модели (LLM), интегрированный непосредственно в интерфейс vDefend. Этот чат-бот объясняет события обнаружения простым языком, помогая командам безопасности понять полный масштаб угроз, одновременно улучшая сотрудничество по всей организации. Это не только снижает частоту ложных срабатываний, но и ускоряет процесс устранения угроз. С помощью простого интерфейса на естественном языке аналитики могут задавать конкретные вопросы для получения более глубокого контекстного понимания, когда это необходимо.

Ключевые функции Intelligent Assist для vDefend включают объяснение угроз на простом языке, а также возможности автоматизированного реагирования и устранения. Платформа разработана на принципах простоты и интуитивности.

Давайте рассмотрим эти функции подробнее.

Объяснимость

Рассмотрим типичную ситуацию с программой-вымогателем, включающую эксфильтрацию данных с использованием таких инструментов, как dnscat, который создает зашифрованное управление и контроль (Command-and-Control, C&C) по протоколу DNS.

Благодаря обширному набору сигнатур IDS, vDefend обнаруживает эту вредоносную активность и генерирует событие высокого уровня важности. Intelligent Assist предоставляет дополнительный контекст для оператора SOC, указывая, что другие события предполагают, что исходным вектором атаки стал Darkside ransomware. Более того, он подтверждает, что влияние значительное, но в настоящее время ограничено определенной рабочей нагрузкой. Обладая этой информацией, команда SOC может уверенно сделать вывод, что событие является истинно положительным, и инициировать немедленные действия.

Способность Intelligent Assist объяснять угрозы и события на простом языке позволяет командам по безопасности, сетям и виртуализации мгновенно оценивать масштаб и влияние отдельных угроз. Автоматически выявляя связанные события и отображая индикаторы компрометации (IoC), он устраняет пробелы в видимости в рамках стека безопасности и значительно ускоряет получение информации по сравнению с тем, что было доступно ранее.

Автоматический ответ и устранение

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

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

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

Когда Intelligent Assist выявляет кампанию атаки, он рекомендует соответствующую стратегию реагирования. В приведенном ниже примере, касающемся продолжающейся атаки программ-вымогателей, Intelligent Assist рекомендовал политику комплексного устранения. Несмотря на автоматизацию создания политик, Intelligent Assist не предназначен для работы в полностью автономном режиме. Окончательное решение остается за командой безопасности — Intelligent Assist генерирует политику, но она не применяется, пока ее не проверит и не активирует эксперт по безопасности. В данном случае рекомендованная политика блокирует всю исходящую DNS-коммуникацию от затронутой рабочей нагрузки, чтобы предотвратить дальнейшее распространение угрозы.

Бесшовный и интуитивно понятный интерфейс

При разработке Intelligent Assist в VMware сосредоточились на том, чтобы сделать интерфейс максимально удобным и интуитивно понятным для конечного пользователя. Такие функции, как экспорт чата, позволяют пользователям легко сохранять и делиться важными инсайтами из диалогов с другими командами, а встроенные механизмы обратной связи обеспечивают улучшение ответов системы со временем. Intelligent Assist также предлагает рекомендации по запросам, помогая даже самым неопытным пользователям раскрыть весь его потенциал. Административная панель создана для упрощения управления пользователями, а поддержка многопользовательских сессий и инструменты управления рабочими процессами способствуют эффективному сотрудничеству между различными командами. Развертывание Intelligent Assist не требует усилий — решение использует безопасное расширение для браузера Chrome, обеспечивая прямой канал связи. Просто скачайте расширение, и все готово к работе.

Чтобы узнать больше о Intelligent Assist, посмотрите техническую сессию VMware Explore Las Vegas 2024, доступную здесь.

Анонсы VMware Explore 2024 Europe: VeloRAIN — новая сетевая архитектура на базе AI для оптимизации рабочих нагрузок

Wed, 06 Nov 2024 08:22:27 UTC

На конференции VMware Explore 2024 в Барселоне компания Broadcom представила революционную сетевую архитектуру VeloRAIN, предназначенную для поддержки и оптимизации рабочих нагрузок, связанных с искусственным интеллектом (AI), в рамках больших предприятий. VeloRAIN (RAIN - это Robust AI Networking) создана для улучшения производительности и безопасности AI-нагрузок в распределенных средах, что делает её важным инструментом для современных предприятий, сталкивающихся с растущими потребностями в передаче данных и выполнении AI-задач.

Основные Преимущества VeloRAIN

Выявление AI-приложений с помощью AI и машинного обучения (ML)

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

Повышение эффективности сети и оптимизация трафика

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

Динамическая система управления приоритетами на основе AI

Новая динамическая платформа управления политиками автоматизирует присвоение приоритетов для приложений, что упрощает управление сетью. С помощью функции Dynamic Application-Based Slicing (DABS) платформа VeloRAIN обеспечивает высокое качество обслуживания для каждого приложения, даже если сети, по которым передаются данные, не поддерживают послойную сегментацию. DABS также использует профили пользователей, чтобы предоставлять приоритетный трафик ключевым сотрудникам, улучшая их опыт и общую производительность сети.

Автоматизация и мониторинг сети с использованием AI

VeloRAIN позволяет компаниям получить глубокую видимость работы сети, автоматизировать процессы приоритезации и мониторинга, а также сократить вмешательство со стороны IT-специалистов. Это особенно важно для AI-нагрузок, которые являются автономными и требуют оркестрации, а не ручного администрирования. Используя VeloRAIN, предприятия могут более эффективно и оперативно настраивать свои сети под потребности бизнес-нагрузок, что улучшает адаптивность к изменениям в рабочем процессе и инфраструктуре.

Стратегическая Значимость VeloRAIN для современного бизнеса

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

Цель Broadcom в развитии сетевой инфраструктуры на базе AI

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

Прочие анонсы VeloCloud

VeloCloud Edge 4100 и 5100: высокопроизводительные устройства для крупных предприятий

Broadcom представила устройства VeloCloud Edge 4100 и 5100, которые обеспечивают повышенную пропускную способность и масштабируемость. Устройство Edge 4100 поддерживает до 30 Гбит/с и до 12 000 туннелей, а Edge 5100 — до 100 Гбит/с и до 20 000 туннелей. Эти решения упрощают сетевую архитектуру и обеспечивают высокую надежность для AI и других рабочих нагрузок.

Titan: Новая партнерская программа для поддержки MSP

Программа Titan предлагает партнерам Managed Service Providers (MSP) эксклюзивные преимущества, такие как стабильный рост бизнеса, доступ к передовым технологиям, новую модель лицензирования и улучшенные возможности по предоставлению управляемых услуг для клиентов.

Особенности новой программы:

Вознаграждение на основе показателей, включая совместную разработку решений, признание на рынке и стабильный и предсказуемый рост бизнеса.
Эксклюзивный доступ к инновационным технологиям и каналам выхода на рынок.
Новая модель лицензирования, обеспечивающая переносимость лицензий, простоту управления и стабильность цен.
Программа создания услуг, ориентированная на ключевые ценностные драйверы, вертикальное выравнивание и более высокие маржинальные показатели.
Новое предложение «White label», позволяющее партнерам высшего уровня расширять базу VeloCloud через региональных и специализированных партнеров канала.

Изменения в продуктовом портфеле Broadcom для VMware Cloud Foundation (VCF) и VMware vSphere Foundation (VVF)

Tue, 05 Nov 2024 07:13:44 UTC

В ноябре этого года компания Broadcom объявила о продолжении эволюции портфолио в сфере серверной виртуализации, включающего в себя платформы VMware Cloud Foundation (VCF) и VMware vSphere Foundation (VVF).

VMware Cloud Foundation остаётся флагманским решением, предоставляя комплексную интегрированную платформу частного облака, которая обеспечивает масштаб и гибкость публичного облака вместе с локальной безопасностью, устойчивостью, производительностью и низкой общей стоимостью владения — как для локальной инфраструктуры, так и для периферии (edge locations), а также публичных и партнерских облаков провайдеров.

Чтобы предложить клиентам более мощное и ценное решение корпоративного класса для гиперконвергентной инфраструктуры (HCI), которое позволяет запускать виртуальные машины и контейнеры с оптимизацией ИТ-инфраструктуры, VMware увеличит объём предоставляемого дискового пространства vSAN в составе VMware vSphere Foundation в 2.5 раза — до 250 GiB на ядро (аналог гигабайт). А для завершения портфеля, для клиентов, сосредоточенных на виртуализации вычислений, теперь будет два издания платформы: VMware vSphere Enterprise Plus (раньше это издание отменили, а теперь возвращают снова) и VMware vSphere Standard. Весь портфель VCF доступен конечным пользователям через дистрибьюторскую сеть или напрямую от Broadcom.

Спасибо Сергею за новость.

Резервное копирование MongoDB в Veeam Backup and Replication

Thu, 31 Oct 2024 13:35:32 UTC

В последней версии Veeam Backup and Replication 12.2 компания Veeam добавила еще один модуль для резервного копирования баз данных - Veeam Explorer for MongoDB.

С помощью Veeam Explorer для MongoDB можно выполнять детальное восстановление одной или нескольких коллекций MongoDB, а также баз данных, или восстанавливать всю инстанцию MongoDB целиком.

Требования для резервного копирования MongoDB:

MongoDB 7.0, MongoDB 6.0 или MongoDB 5.0.
Поддерживаются только 64-битные версии ОС для сервера базы данных: Debian 9 или новее, RHEL 6.2 или новее, CentOS 6.2 или новее, Oracle Linux 6.2 или новее, Rocky 8.0 или новее, Alma 8.0 или новее, SLES 12 SP4 – SP5, SLES 15 SP1 – SP5, Ubuntu 16.04 или новее.

Нативная поддержка в Veeam 12.2 означает, что вы выполняете резервное копирование не только базовой ОС Linux (с помощью Linux-агента), но и самой MongoDB. Восстановлением можно управлять через стандартный интерфейс Veeam Explorer, как обычно для такого типа резервных копий на уровне приложений.

Когда вы впервые выполняете повторное сканирование набора реплик MongoDB (группы экземпляров, которые поддерживают один и тот же набор данных), Veeam Backup & Replication разворачивает следующие компоненты Veeam на каждом компьютере, где обнаружен основной демон MongoDB (mongod):

Служба Veeam Transport Service отвечает за соединение между Veeam Backup & Replication и компонентами Veeam, работающими на компьютере с MongoDB. Агент Veeam Mongo Agent — это компонент, который собирает информацию об иерархии базы данных с компьютера и взаимодействует с демоном mongo для операций резервного копирования. Агент Veeam для Linux — это компонент, который выполняет резервное копирование томов с данными MongoDB и отправляет резервную копию в целевое хранилище.

Теперь за счет Veeam Explorer для MongoDB вы получаете следующие преимущества:

Усиленная защита данных: благодаря поддержке MongoDB в Veeam ИТ-администраторы могут быть уверены, что их данные защищены от сбоев оборудования, человеческих ошибок и киберугроз.
Гибкие варианты резервного копирования: новая функция позволяет выполнять как резервное копирование на уровне образа, так и на уровне приложений, предоставляя администраторам гибкость выбора наиболее подходящего подхода для их нужд.
Бесшовный процесс восстановления: в случае потери данных мощные возможности восстановления Veeam позволяют быстро и эффективно восстановить данные, минимизируя время простоя и обеспечивая непрерывность бизнеса.
Масштабируемость: решение Veeam разработано с учетом масштабирования вместе с развертыванием MongoDB, что позволяет учитывать растущие объемы данных и сложные окружения.

Более подробно о Veeam Explorer для MongoDB с описанием процессов резервного копирования и восстановления можно почитать вот в этом документе.

Для тех, кто не обновил VMware vSphere 8 в сентябре - ESXi 8.0 Update 3b и vCenter Server 8.0 Update 3b

Wed, 30 Oct 2024 14:53:57 UTC

Если вы пропустили новость о том, что вышло обновление платформы VMware vSphere 8 Update 3b, то сейчас самое время подумать об обновлении, так как сообщений о каких-то серьезных багах не поступало.

Итак, что нового в VMware ESXi 8.0 Update 3b:

DPU/SmartNIC - появилась поддержка VMware vSphere Distributed Services Engine с DPU NVIDIA Bluefield-3. Устройства DPU NVIDIA Bluefield-3 поддерживаются как в режиме одиночного DPU, так и в dual-DPU конфигурациях.
ESXi 8.0 Update 3b добавляет поддержку vSphere Quick Boot для нескольких серверов, включая:
- HPE ProLiant DL145 Gen11
- HPE ProLiant MicroServer Gen11
- Cisco UCSC-C245-M8SX
- Supermicro AS-2025HS-TNR

Для полного списка поддерживаемых серверов смотрите VMware Compatibility Guide.

Улучшения в проектировании переменных cloud-init guestInfo: начиная с ESXi 8.0 Update 3b, попытка обычных пользователей задать переменные cloud-init guestInfo внутри гостевой ОС приводит к ошибке. Для получения дополнительной информации см. KB 377267.

Что нового в VMware vCenter 8.0 Update 3b:

Этот выпуск устраняет уязвимости CVE-2024-38812 и CVE-2024-38813. Для получения дополнительной информации об этих уязвимостях и их влиянии на продукты VMware посмотрите статью VMSA-2024-0019.
VMware vCenter Server 8.0 Update 3b предоставляет исправления ошибок, описанные в разделе Resolved Issues.
Для информации об обновлениях VMware vSphere with Tanzu смотрите Release Notes для VMware vSphere IaaS Control Plane 8.0.
Для информации об обновлениях Photon OS смотрите обновления безопасности VMware vCenter Server Appliance Photon OS.

Если вы не знаете, как скачать VMware vSphere 8 Update 3b, воспользуйтесь информацией по этой ссылке.

Топ-5 основных нагрузок для гиперконвергентных хранилищ на платформе VMware vSAN

Tue, 29 Oct 2024 13:37:48 UTC

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

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

VMware недавно заказала исследование Key Workloads and Use Cases for Virtualized Storage у компании Enterprise Strategy Group, чтобы изучить роль гиперконвергентного хранилища, его преимущества и ключевые случаи применения, где оно оказывает значительное влияние. Рекомендации основаны на опросах сотен пользователей гиперконвергентных хранилищ, а также на тысячах реальных внедрений.

Почему хранилище является проблемой

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

Роль гиперконвергентного хранилища

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

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

Ключевые рабочие нагрузки для гиперконвергентного хранилища

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

1. Виртуальная инфраструктура рабочих столов (VDI): с увеличением числа удаленных сотрудников виртуальные рабочие столы стали критически важными. Однако VDI требует высокой производительности, линейного масштабирования и технологий для сокращения объема данных, чтобы оптимизировать затраты на хранение. vSAN решает эту задачу, предлагая масштабируемое решение. Его архитектура поддерживает высокую производительность и различные технологии сокращения данных для минимизации требований к объему хранения.

2. Бизнес-критичные приложения: для требовательных приложений баз данных, таких как Oracle, SQL Server и SAP HANA, vSAN обеспечивает высокую производительность и масштабируемость. Архитектура vSAN Express Storage Architecture предоставляет высокую производительность и устойчивость, даже с использованием кодирования ошибок RAID 5/6 для эффективности. vSAN также позволяет независимо масштабировать вычислительные ресурсы и ресурсы хранения, что полезно для рабочих нагрузок OTLP, которые часто растут быстрее по объему хранения, чем по вычислительным требованиям.

3. «Мейнстримные» рабочие нагрузки: веб-серверы, аварийное восстановление и защита данных. Это зрелые и широко используемые приложения, для которых требуется простое в управлении и недорогое хранилище. vSAN упрощает работу с этим хранилищем для разных рабочих нагрузок за счет управления на основе политик и снижает затраты, используя серверы промышленного стандарта для достижения необходимой производительности. Он также упрощает аварийное восстановление, позволяя реплицировать данные между сайтами без дорогостоящего специального оборудования.

4. Рабочие нагрузки на периферии (edge workloads): гиперконвергентные решения для хранилищ обеспечивают масштабируемость, гибкость и повышенную производительность на периферии с меньшими затратами, в компактном формате и, что особенно важно, в упрощенном форм-факторе серверов. Ключевые возможности vSAN включают:

возможность экономного масштабирования
поддержку нативного файлового и блочного хранения для уменьшения физического объема
высокую производительность благодаря поддержке NVMe-based TLC NAND flash для приложений с высокой чувствительностью к задержкам
централизованное управление всеми удаленными сайтами из одного инструмента

5. Облачные (cloud-native) рабочие нагрузки: гиперконвергентные решения для хранилищ также являются идеальным подходом, поскольку они поддерживают облачные хранилища и автоматизируют выделение хранилища для контейнерных рабочих нагрузок, что позволяет разработчикам получать доступ к необходимому хранилищу по мере необходимости, одновременно позволяя ИТ-администраторам управлять хранилищем как для контейнеров, так и для виртуальных машин на одной платформе.

Заключение

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

Новые результаты тестов VMmark 4 в плане масштабируемости vSphere 8 и процессоров AMD EPYC 5 поколения

Mon, 28 Oct 2024 09:23:30 UTC

В этом месяце VMware опубликовала девять новых результатов тестов VMmark 4 от компаний Dell Technologies, Hewlett Packard Enterprise и Supermicro, которые демонстрируют производительность и масштабируемость новых серверных процессоров AMD EPYC серии 9005, поддерживающихся в хостах VMware vSphere 8. Результаты можно посмотреть на странице результатов VMmark 4, но основные моменты освещены в статье ниже.

VMmark 4

VMware VMmark 4 — это бесплатный кластерный тест, измеряющий производительность и масштабируемость корпоративных сред виртуализации. Если вы хотите узнать больше о VMmark 4, обратитесь к статье "Введение в VMmark 4: модернизированный эталон консолидации серверов для частных облаков" и к разделу часто задаваемых вопросов по продуктам VMmark.

Важная особенность: одна плитка (tile) VMmark включает 23 виртуальных машины, выполняющих разнообразные рабочие нагрузки — от традиционных Java- и баз данных до Kubernetes, Docker-контейнеров, NoSQL и нагрузок социальных сетей, характерных для современных корпоративных дата-центров.

Результаты тестирования Supermicro

Первое сравнение демонстрирует, как хорошо масштабируются эти новые процессоры при использовании VMmark 4 и последнего гипервизора VMware ESXi при удвоении общего числа ядер с 128 до 256 (результаты - для двух плиток и для четырех).

Как видно из таблицы и графика выше, результат с 256 ядрами в 1,9 раза выше, чем результат с 128 ядрами, при этом в течение 3 часов теста VMmark работало в два раза больше виртуальных машин (разные плитки).

Результаты тестирования Dell Technologies

На данный момент у Dell есть три результата тестирования VMmark 4 на базе процессоров EPYC 9005 с разным количеством ядер (1, 2, 3).

Одна плитка VMmark 4 состоит из 23 виртуальных машин, однако два из этих результатов содержат дробное количество плиток. Что это значит? Ответ заключается в том, что в VMmark 4 была добавлена функция частичных плиток. Частичные плитки запускают подмножество рабочих нагрузок для более точной детализации, что позволяет тестировщикам максимально использовать производительность их решений для виртуализации. Например, 4.6 плитки включают 99 активных виртуальных машин, тогда как 5 плиток — 115 виртуальных машин, что на 16% больше.

Результаты Dell также являются первыми результатами VMmark, использующими NVMe over TCP с подключением к внешнему хранилищу через двухпортовые сетевые карты Broadcom BCM957508-P2100G со скоростью 100 Гбит/с, вместо традиционных адаптеров шины.

Результаты тестирования Hewlett Packard Enterprise

У HPE есть три результата тестирования VMmark 4 (1, 2, 3).

Первый результат использует процессоры предыдущего поколения EPYC 4-го поколения (обозначенные номером "4" в конце модели процессора). Несмотря на одинаковое количество ядер в первых двух результатах, процессоры 5-го поколения показывают производительность выше более чем на 10%.

Если сравнить результат предыдущего поколения с результатом на 1280 ядрах, он оказывается на впечатляющие 45% выше!

Как сбросить (восстановить) пароль root для VMware ESXi 8 или 7 в составе VMware vSphere

Thu, 24 Oct 2024 09:29:21 UTC

Вильям Лам написал наиполезнейшую статью о сбросе/восстановлении пароля консоли сервера VMware ESXi 8 и 7 в составе платформы виртуализации VMware vSphere.

Общее руководство и самый быстрый способ восстановления пароля root для хоста ESXi, если вы забыли или потеряли его, заключается в сбросе с помощью профилей хостов vSphere, если он управлялся сервером vCenter, или просто переустановке ESXi, что позволит сохранить существующие тома VMFS вместе с виртуальными машинами, которые могут на них находиться.

Ранее также было возможно сбросить пароль root ESXi, загрузив систему в Linux и вручную обновив файл /etc/shadow, что похоже на то, как можно сбросить пароль в системе на базе Linux. В сети можно найти множество статей в блогах, описывающих этот процесс. Однако с появлением ESXi Configuration Store данный метод больше не работает для современных версий ESXi, начиная с ESXi 7.0 Update 1 и выше.

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

Хотя в сети было опубликовано множество фрагментов информации (здесь, здесь и здесь), включая информацию от самого Вильяма, было бы полезно выяснить по шагам актуальный процесс восстановления ESXi 7.x или 8.x хоста без необходимости его переустановки.

Предварительные требования:

Доступ к физическому носителю, на который установлен ESXi (USB или HDD/SSD)
Виртуальная машина Linux (Ubuntu или Photon OS)
Виртуальная машина с вложенным ESXi

Для демонстрации описанного ниже процесса восстановления Вильям установил ESXi 8.0 Update 3c на USB-устройство с базовой конфигурацией (имя хоста, сеть, SSH MOTD), чтобы убедиться в возможности восстановления системы. Затем он изменил пароль root на что-то полностью случайное и удалил этот пароль, чтобы нельзя было войти в систему. Хост ESXi, на котором он "забыл" пароль, будет называться физическим хостом ESXi, а вложенная виртуальная машина с ESXi, которая будет помогать в восстановлении, будет называться вложенным хостом (Nested ESXi).

Шаг 1 — Разверните вложенную виртуальную машину с ESXi (скачать с сайта VMware Flings), версия которой должна соответствовать версии вашего физического хоста ESXi, который вы хотите восстановить.

Шаг 2 — Скопируйте файл state.tgz с физического хоста ESXi, который вы хотите восстановить. Обязательно сделайте резервную копию на случай, если допустите ошибку.

Если ваш хост ESXi установлен на USB, отключите USB-устройство, подключите его к настольной системе и скопируйте файл с тома BOOTBANK1.
Если ваш хост ESXi установлен на HDD/SSD, вам нужно будет загрузить физическую систему с помощью Linux LiveCD (Ubuntu или Knoppix) и смонтировать раздел 5 для доступа к файлу state.tgz.

Шаг 3 — Скопируйте файл state.tgz с вашего физического хоста ESXi на вложенный хост ESXi и поместите его в /tmp/state.tgz, затем выполните следующую команду для извлечения содержимого файла:

tar -zxvf state.tgz rm -f state.tgz

Шаг 4 — Войдите на ваш вложенный хост ESXi и выполните следующие команды для извлечения его файла state.tgz, который будет помещен в каталог /tmp/a. Затем мы используем утилиту crypto-util для расшифровки файла local.tgz.ve вложенного хоста ESXi, чтобы получить файл local.tgz, и затем просто удаляем зашифрованный файл вместе с файлом encryption.info вложенного хоста ESXi. После этого мы заменим их файлом encryption.info с нашего физического хоста ESXi и создадим модифицированную версию state.tgz, которая будет загружаться в нашей вложенной виртуальной машине ESXi. Мы используем это для расшифровки исходного файла state.tgz с нашего физического хоста ESXi.

mkdir /tmp/a
cd /tmp/a
tar xzf /bootbank/state.tgz
crypto-util envelope extract --aad ESXConfiguration local.tgz.ve local.tgz
rm -f local.tgz.ve encryption.info
cp /tmp/encryption.info /tmp/a/encryption.info
tar -cvf /tmp/state-mod.tgz encryption.info local.tgz

После успешного выполнения последней команды, нам нужно скопировать файл /tmp/state-mod.tgz на ваш рабочий стол, а затем выключить вложенную виртуальную машину ESXi.

Шаг 5 — Смонтируйте первый VMDK диск из вашей вложенной виртуальной машины ESXi на вашу виртуальную машину с Linux. В данном случае Вильм использует Photon OS, который также управляет и DNS-инфраструктурой.

Шаг 6 — Убедитесь, что VMDK вашей вложенной виртуальной машины ESXi виден в вашей системе Linux, выполнив следующую команду. Мы должны увидеть два раздела bootbank (5 и 6), как показано на скриншоте ниже:

fdisk -l

Шаг 7 — Перенесите файл state-mod.tgz, созданный на Шаге 4, на вашу виртуальную машину с Linux, затем смонтируйте оба раздела bootbank и замените файл state.tgz на нашу модифицированную версию.

mount /dev/sdb5 /mnt
cp ~/state-mod.tgz /mnt/state.tgz -f
chmod 755 /mnt/state.tgz
umount /mnt

mount /dev/sdb6 /mnt
cp ~/state-mod.tgz /mnt/state.tgz -f
chmod 755 /mnt/state.tgz
umount /mnt

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

Шаг 8 — Сделайте remove (не удаляйте) VMDK файл вложенной виртуальной машины ESXi с виртуальной машины Linux, затем включите вложенную виртуальную машину ESXi.

После успешной загрузки вложенной виртуальной машины ESXi, она теперь работает с оригинальным файлом encryption.info с нашего физического хоста ESXi, что позволит нам восстановить исходный файл state.tgz.

Шаг 9 — Скопируйте исходный файл state.tgz, созданный на Шаге 2, во вложенную виртуальную машину ESXi, поместите его в каталог /tmp/state.tgz и выполните следующую команду, которая теперь позволит нам расшифровать файл state.tgz с физического хоста ESXi, как показано на скриншоте ниже!

cd /tmp
tar -zxvf state.tgz
rm -f state.tgz
crypto-util envelope extract --aad ESXConfiguration local.tgz.ve local.tgz
rm -f local.tgz.ve

Шаг 10 — После расшифровки исходного файла state.tgz у нас должен появиться файл local.tgz, который мы извлечем локально в каталоге /tmp, выполнив следующую команду:

tar -zxvf local.tgz

Следующие три каталога: .ssh, etc/ и var/ будут размещены в /tmp, а /tmp/var/lib/vmware/configstore/backup/current-store-1 — это хранилище конфигурации ESXi для физического хоста ESXi, которое нам нужно обновить и заменить оригинальный хеш пароля root на желаемый, чтобы мы могли войти в систему.

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

/usr/lib/vmware/sqlite/bin/sqlite3 /tmp/var/lib/vmware/configstore/backup/current-store-1  "select * from config where Component='esx' and ConfigGroup = 'authentication' and Name = 'user_accounts' and Identifier = 'root'"

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

/usr/lib/vmware/sqlite/bin/sqlite3 /tmp/var/lib/vmware/configstore/backup/current-store-1  "update config set UserValue='{"name":"root","password_hash":"$6$s6ic82Ik$ER28x38x.1umtnQ99Hx9z0ZBOHBEuPYneedI1ekK2cwe/jIpjDcBNUHWHw0LwuRYJWhL3L2ORX3I5wFxKmyki1","description":"Administrator"}' where Component='esx' and ConfigGroup = 'authentication' and Name = 'user_accounts' and Identifier = 'root'"

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

Шаг 12 — Теперь, когда мы обновили хранилище конфигурации ESXi с нашим желаемым паролем root, нам нужно заново создать файл state.tgz, который будет содержать наши изменения, выполнив следующие команды:

rm -f local.tgz 
tar -cvf /tmp/local.tgz .ssh/ etc/ var/ 
tar -cvf /tmp/state-recover.tgz encryption.info local.tgz

Скопируйте файл /tmp/state-recover.tgz с вложенной виртуальной машины ESXi на вашу виртуальную машину с Linux, которая затем будет использоваться для монтирования носителя физического хоста ESXi, чтобы заменить файл state.tgz на нашу восстановленную версию.

Шаг 13 — Смонтируйте носитель физического хоста ESXi на вашу виртуальную машину с Linux. Поскольку физический хост ESXi установлен на USB, можно просто подключить USB-устройство напрямую к виртуальной машине с Linux.

Снова мы можем убедиться, что виртуальная машина с Linux видит носитель с установленным физическим хостом ESXi, выполнив команду fdisk -l, и мы должны увидеть два раздела bootbank (5 и 6), как показано на скриншоте ниже.

Шаг 14 — Теперь нам просто нужно смонтировать раздел bootbank и заменить оригинальный файл state.tgz на нашу модифицированную версию (state-recover.tgz).

mount /dev/sdb5 /mnt 
cp ~/state-recover.tgz /mnt/state.tgz 
chmod 755 /mnt/state.tgz 
umount /mnt

Примечание: Поскольку физический хост ESXi был только что установлен, на втором разделе bootbank не было ничего для замены, но если вы найдете файл state.tgz, его также следует заменить, используя ту же команду, но указав другой номер раздела.

Шаг 15 — Последний шаг: размонтируйте носитель физического хоста ESXi с виртуальной машины Linux, затем включите ваш физический хост ESXi, и теперь вы сможете войти в систему, используя обновленный пароль root!

Возможное повреждение данных в VMware vSAN 8.0 (а также Update 1 и 2) при использовании инструкций AVX-512 процессора сервера

Tue, 22 Oct 2024 09:08:27 UTC

Интересную статью написал Tom Fojta в своем блоге, касающуюся возможного повреждения данных на платформе VMware vSAN 8.0 (включая пакеты обновлений Update 1 и 2). Согласно статье базы знаний KB 367589, такое повреждение может случиться, если в вашей виртуальной машине некоторые приложения используют набор инструкций AVX-512.

Пока известно, что эти инструкции используются СУБД IBM Db2 и SAP HANA (однако и другие приложения могут их потенциально использовать).

Чтобы проверить, есть ли поддержка AVX-512 у вашего процессора, нужно выполнить следующую команду:

cat /proc/cpuinfo |grep avx512

Вывод команды будет примерно таким:

flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ss syscall nx pdpe1gb rdtscp lm constant_tsc arch_perfmon nopl xtopology tsc_reliable nonstop_tsc cpuid tsc_known_freq pni pclmulqdq ssse3 fma cx16 pcid sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand hypervisor lahf_lm abm 3dnowprefetch invpcid_single ssbd ibrs ibpb stibp ibrs_enhanced fsgsbase tsc_adjust bmi1 avx2 smep bmi2 invpcid avx512f avx512dq rdseed adx smap clflushopt clwb avx512cd sha_ni avx512bw avx512vl xsaveopt xsavec xsaves arat pku md_clear flush_l1d arch_capabilities

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

Для того, чтобы обнаружить эту поддержку в гостевой ОС Windows, можно запустить утилиту HWiNFO.

Чтобы воспроизвести проблему, можно просто запустить SSH для передачи данных, так как библиотека openssl может использовать инструкции AVX-512:

$ dd if=/dev/zero bs=1M count=1024 | sha256sum -  > sha256sums.zero # one time checksum generation
$ ( while true; rm -f /tmp/zero.$$.img ; do ssh root@localhost "dd if=/dev/zero iflag=fullblock bs=1M count=1024 status=progress" | dd iflag=fullblock bs=1M status=none of=/tmp/zero.$$.img && sha256sum - < /tmp/zero.$$.img | diff -u sha256sums.zero - || exit 1; done )

В итоге проверка контрльной суммы завершится неудачно:

...
1073741824 bytes (1.1 GB, 1.0 GiB) copied, 2.11915 s, 507 MB/s
1013972992 bytes (1.0 GB, 967 MiB) copied, 2 s, 507 MB/s
1024+0 records in
1024+0 records out
1073741824 bytes (1.1 GB, 1.0 GiB) copied, 2.09118 s, 513 MB/s
1073741824 bytes (1.1 GB, 1.0 GiB) copied, 2 s, 532 MB/s
1024+0 records in
1024+0 records out
1073741824 bytes (1.1 GB, 1.0 GiB) copied, 2.01729 s, 532 MB/s
--- sha256sums.zero     2024-10-21 10:44:48.142238490 +0000
+++ -   2024-10-21 10:54:17.289072688 +0000
@@ -1 +1 @@
-49bc20df15e412a64472421e13fe86ff1c5165e18b2afccf160d4dc19fe68a14  -
+4e841c1d34a2a051fab082d10a8105cd34e10c95ee74ce20d280a7c022eaaa53  -

Чтобы решить проблему на уровне процессора (виртуальной машины), нужно отмаскировать некоторые флаги в наборе инструкций CPU. Вы также можете решить проблему и на уровне приложений (для этого обратитесь к KB, указанной выше).

Итак, нужно добавить в Advanced Configuration Parameters виртуальной машины следующие строчки для проблемных инструкций AVX-512:

featMask.vm.cpuid.AVX512F = “Max:0” featMask.vm.cpuid.AVX512FP16 = “Max:0“

Сделать это можно и через интерфейс vSphere Client или Cloud Director - там нужно создать политику Compute Policy для виртуальных машин (в интерфейсе она называется VM Sizing Policy) с расширенными параметрами:

Работает ли VMware vSAN Data Protection с растянутыми кластерами, и могут ли снапшоты быть растянутыми?

Mon, 21 Oct 2024 15:21:09 UTC

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

vSAN Data Protection основывается на возможности создания снимков (snapshots), которая была введена с vSAN ESA. Эта функция в ESA значительно отличается от того, как это было реализовано в vSAN OSA или VMFS. В vSAN OSA и VMFS при создании снимка создается новый объект (в vSAN) или файл (в файловой системе VMFS). С vSAN ESA это больше не так, так как теперь не создаются дополнительные файлы или объекты, а вместо этого создается копия структуры метаданных. Именно поэтому снапшоты на vSAN ESA работают гораздо лучше, чем для vSAN OSA или VMFS, так как больше не нужно проходить через множество файлов или объектов для чтения данных. Теперь просто используется тот же объект и задействуется структура метаданных для отслеживания изменений.

В vSAN объекты (и их компоненты) размещаются по всему кластеру в соответствии с тем, что указано в политике хранения, связанной с объектом или виртуальной машиной. Другими словами, если политика FTT=1 и RAID-1, то вы увидите две копии данных. Если политика определяет, что данные должны быть растянуты между локациями и защищены RAID-5 в каждой локации, тогда вы увидите конфигурацию RAID-1 между сайтами и конфигурацию RAID-5 внутри каждого сайта. Поскольку снапшоты vSAN ESA являются неотъемлемой частью объекта, они автоматически следуют всем требованиям, определенным в политике. Другими словами, если политика установлена как "stretched", то снимок также будет автоматически растянутым.

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

На диаграмме ниже показан модуль Data Protection Appliance, также известный как менеджер снимков (snapshot manager appliance). Как вы видите, на диаграмме указано "метаданные отделены от модуля" (metadata decoupled from appliance), и оно как-то связано с объектом глобального пространства имен. Этот объект глобального пространства имен хранит все детали защищенных виртуальных машин (и не только). Как вы можете догадаться, как менеджер снимков, так и объект глобального пространства имен должны также быть растянутыми. Для объекта глобального пространства имен это означает, что вам нужно убедиться, что политика по умолчанию для хранилища данных установлена как "stretched", и, конечно, для менеджера снапшотов вы можете просто выбрать правильную политику при его развертывании. В любом случае убедитесь, что политика по умолчанию для хранилища данных соответствует политике аварийного восстановления и защиты данных.

Настройка VMware vDefend Distributed Firewall для защиты инфраструктуры от небезопасных протоколов

Fri, 18 Oct 2024 06:18:18 UTC

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

Проблема небезопасных протоколов

Небезопасные протоколы, такие как SMB версии 1, могут быть уязвимы для атак. Например, уязвимость SMBv1 может позволить злоумышленнику получить доступ к виртуальной машине, если система не была своевременно обновлена. Проблема может усугубляться тем, что в некоторых случаях обновление системы невозможно из-за бизнес-ограничений.

Для демонстрации в видео используются две машины:

Windows 7 с включенным SMBv1, которая не предназначена для предоставления файловых сервисов.
Windows Server 2016, выступающий в роли файлового сервера, который хранит конфиденциальные данные компании.

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

Как VMware vDefend защищает инфраструктуру

1. Ограничение доступа с использованием брандмауэра (DFW)

В первую очередь, демонстрируется, как злоумышленник использует уязвимость на машине с Windows 7, которая не является файловым сервером, но продолжает принимать SMB-трафик. После успешного взлома злоумышленник получает неограниченный доступ к системе.

Чтобы предотвратить подобные атаки, с помощью VMware vDefend создается правило, которое ограничивает доступ к сервисам SMB только для нужных диапазонов IP-адресов (RFC 1918 в этом примере). Все остальные подключения, использующие SMB, будут заблокированы. Таким образом, злоумышленник больше не может воспользоваться уязвимостью Windows 7, и попытка повторного взлома завершается неудачей.

2. Защита файлового сервера с использованием Intrusion Detection and Prevention (IDP)

Вторая часть видео фокусируется на защите Windows Server 2016. Поскольку файловый сервер должен продолжать предоставлять доступ к конфиденциальным данным, простое блокирование SMB не подходит. Для этого используется система обнаружения и предотвращения вторжений (IDP), которая контролирует трафик и блокирует вредоносные пакеты.

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

Мониторинг событий и дальнейшие действия

После блокировки атаки администраторы могут использовать встроенные инструменты мониторинга для детального анализа инцидента. В VMware vDefend доступны такие данные, как IP-адреса источников, целевые машины, идентификаторы сигнатур атак и другие полезные сведения, которые можно передать в команду безопасности (SOC) для дальнейшего расследования.

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

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

Демонстрация продукта VMware vSAN Data Protection от Дункана Эппинга

Wed, 16 Oct 2024 07:48:30 UTC

Блогер Дункан Эппинг записал отличное видео по теме защиты данных кластеров отказоустойчивости средствами продукта VMware vSAN Data Protection для VMware Explore в Лас-Вегасе и Барселоне. Так как ему поступали вопросы от людей по поводу защиты данных vSAN, он решил поделиться демо на YouTube и опубликовать его в своем блоге. Ранее он выпустил несколько статей о защите данных vSAN и стал замечать, что некоторые клиенты начинают тестировать эту функцию и даже использовать её в производственных средах, где это возможно. Как мы также писали ранее, решение vSAN Data Protection доступно только только в рамках архитектуры vSAN ESA, так как она использует новые возможности создания моментальных снимков (снапшотов). Также полностью новый интерфейс был представлен в средстве управления Snap Manager Appliance. Обязательно скачайте, разверните и настройте его в первую очередь.

Собственно, само демо VMware vSAN Data Protection, которое стоит посмотреть, если вы интересуетесь защитой данных в рамках виртуальной инфраструктуры VMware vSphere и vSAN: