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

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

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

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

В последней версии 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 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, воспользуйтесь информацией по этой ссылке.

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

В этом месяце 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% выше!

Вильям Лам написал наиполезнейшую статью о сбросе/восстановлении пароля консоли сервера 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, выполнив следующую команду:

Следующие три каталога: .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!

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

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

Недавно компания Veeam представила второй релиз бесплатного решения Veeam Hardened Repository ISO. Первая версия была выпущена еще в июне 2023 года, сейчас вышло ее обновление. Veeam Hardened ISO Repository (VHR) предназначен для облегчения создания защищённого Linux-репозитория для решения Veeam Backup and Replication, так как не каждый администратор имеет достаточный опыт работы с Linux для эффективной защиты операционной системы. Veeam предлагает инструмент, который позволяет сделать это быстро и легко. Скачивание доступно бесплатно, но поскольку это технологическое превью, этот инструмент пока не следует использовать в производственных средах. ISO позволит вам создать безопасный репозиторий с функцией неизменяемости данных (immutability).

Преимущества ISO

• Главное преимущество ISO заключается в том, что вам не нужно выполнять дополнительные настройки или запускать скрипты (система уже защищена благодаря специальному установщику).
• В системе нет пользователя root.
• Благодаря использованию Rocky Linux в качестве основы, вы получаете 10 лет поддержки для ОС.
• После выхода официальной версии вы также получите поддержку от Veeam.
  

Требования

• Оборудование, поддерживаемое RedHat (для развертывания в производственной рекомендуется физический сервер, для лабораторных условий возможна виртуальная машина), сам ISO основан на Rocky Linux.
• Те же требования к CPU и RAM, что и для Linux-репозиториев.
• 2 диска с объёмом не менее 100 ГБ каждый.
• Поддерживается только внутреннее хранилище или напрямую подключаемое хранилище с аппаратным RAID-контроллером и кэшем записи.
• UEFI должен быть активирован.
• Минимальная версия Veeam - V12.2.

Veeam Hardened ISO — это загрузочный ISO-образ, разработанный для упрощения настройки Veeam Hardened Repositories. Этот новый метод доставки устраняет необходимость в глубоком знании Linux, делая его доступным для более широкой аудитории. Развертывая защищённые репозитории через этот ISO, пользователи могут значительно снизить затраты на постоянное управление и повысить безопасность своей инфраструктуры резервного копирования.

Одной из ключевых особенностей Veeam Hardened ISO является возможность создания безопасного и неизменяемого репозитория для резервного копирования. Это означает, что после записи данных в репозиторий их нельзя изменить или удалить, что защищает их от атак программ-вымогателей и других вредоносных действий. Такой уровень безопасности крайне важен в современном мире, где утечки данных и кибератаки становятся всё более частыми.

Вам предоставляется преднастроенная операционная система с автоматически применённым профилем безопасности DISA STIG. Также доступен инструмент настройки защищённого репозитория (Hardened Repository Configurator Tool), который упрощает настройку сети и позволяет изменить такие параметры, как настройки HTTP-прокси, имя хоста, пароль для пользователя vhradmin, временное включение SSH, обновление ОС и компонентов Veeam, сброс защиты от смещения времени, а также выполнять простые действия, такие как вход в систему, перезагрузка или выключение.

Ключевые особенности Veeam Hardened ISO

• Упрощённое развертывание — Veeam Hardened ISO значительно упрощает процесс развертывания, позволяя пользователям настраивать защищённые репозитории без необходимости глубокого знания Linux. Эта простота в использовании гарантирует, что даже пользователи с ограниченными техническими навыками могут воспользоваться передовыми возможностями защиты данных от Veeam.
• Повышенная безопасность — неизменяемость Veeam Hardened Repository гарантирует, что данные резервного копирования остаются защищёнными и не могут быть изменены. Это особенно важно в условиях атак программ-вымогателей, где целостность данных резервного копирования играет ключевую роль.
• Экономическая эффективность — благодаря снижению потребности в постоянном управлении и обслуживании, Veeam Hardened ISO помогает организациям экономить на операционных расходах. Такая эффективность делает решение привлекательным для компаний любого размера.
• Обратная связь сообщества — поскольку Veeam Hardened ISO на данный момент находится в статусе Community Preview, пользователи могут предоставлять обратную связь и вносить свой вклад в его развитие. Такой совместный подход помогает создать продукт, который будет соответствовать потребностям и ожиданиям сообщества Veeam.

Скачать Veeam Hardened Repository ISO можно по этой ссылке. Дефолтный пароль - VHRISO.

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

Veeam Intelligent Diagnostics, функция, входящая в состав Veeam ONE (часть пакета Veeam Data Platform Advanced), позволяет автоматически выявлять известные проблемы в конфигурации и производительности инфраструктуры резервного копирования. Активировав эту функциональность через Veeam ONE, вы получаете уведомления об общих ошибках, что позволяет вам быстрее их устранять с помощью статей из базы знаний и предлагаемых решений, что снижает риски в вашей среде и гарантирует готовность к защите или восстановлению данных в любой момент.

Сигнатуры Veeam Intelligent Diagnostics

У Veeam более 550 000 клиентов, что, если задуматься, является огромным числом. Клиенты Veeam бывают самых разных размеров и работают в различных областях. От технологических компаний до медицинских организаций, нефтегазовых компаний и образовательных учреждений — Veeam защищает огромный объём данных своих клиентов.

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

С помощью Veeam Intelligent Diagnostics можно использовать уроки, извлечённые из этих сред, чтобы снизить риски для всех клиентов.

Как VID анализирует виртуальные среды

С помощью простого агента, установленного на сервер Veeam Backup & Replication через Veeam ONE, состояние вашей среды Veeam анализируется безопасно, при этом вы полностью контролируете свои данные. Установка на серверы Veeam выполняется в один клик (если это не было сделано при подключении к среде Veeam ONE).

При этом никакие ваши данные никогда не отправляются на серверы Veeam. Вместо этого Veeam ONE просто загружает новые сигнатуры Veeam Intelligent Diagnostics с серверов Veeam, а агент, установленный на сервере Veeam, выполняет анализ. Клиенты, использующие Veeam Data Platform Advanced и Premium, могут в любое время проверить наличие новых сигнатур через Veeam ONE Data Protection View или загрузить их напрямую с веб-сайта Veeam и импортировать на сервер Veeam ONE.

Анализ логов VID может быть настроен на ежедневный запуск, а также выполняться по запросу в любое время. На самом деле, не существует более простого способа для принятия проактивных мер по защите вашей среды Veeam Backup & Replication.

Исправляйте проблемы до того, как они повлекут последствия

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

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

Этот пример касается задач резервного копирования на ленту, он идентифицирует причину срабатывания аларма и предлагает способы её устранения. В этом случае можно увидеть, что обновление до последней версии Veeam Backup and Replication может помочь решить проблему. Если это не помогает, вам предоставляется номер тикета Veeam Intelligent Diagnostics, чтобы упростить процесс поддержки и получить частное исправление.

В данном случае Veeam Intelligent Diagnostics предоставил правильное решение, которое требует обновления. Просто подождите установки обновления 15-20 минут, и вы больше не столкнетесь с этой проблемой. Это отличный пример того, как Veeam помогает своим клиентам действительно понять, что происходит в их среде, и избежать возможных обращений в службу поддержки.

Все клиенты Veeam Data Platform могут снизить риски в своих средах, используя Veeam Intelligent Diagnostics, и в индустрии нет ничего подобного. Veeam безопасно обрабатывает информацию из логов вашей среды непосредственно на ваших серверах Veeam. Ваши данные никогда не отправляются на сервера Veeam или куда-либо ещё.

Опираясь на опыт более чем 550 000 клиентов, Veeam постоянно обновляет определения VID и отправляет их при возникновении новых проблем и рисков, помогая клиентам устранять сложности до того, как они повлекут серьезные последствия.

Если вы уже используете Veeam Data Platform Advanced или Premium, уделите несколько минут, чтобы убедиться, что у вас установлен агент Veeam ONE. Затем вы сможете просмотреть сигнатуры Veeam Intelligent Diagnostics, зайдя в раздел Intelligent Diagnostics в секции Backup & Replication представления Alarm Management.

Если вы ещё не используете Veeam Data Platform Advanced или Premium, вы можете загрузить бесплатную пробную версию на 30 дней, чтобы протестировать функции Veeam Intelligent Diagnostics.

Вчера мы писали об обновленной утилите SexiGraf для мониторинга виртуальной инфраструктуры VMware vSphere. Сегодня мы поговорим еще об одном наборе бесплатных дэшбордов Grafana для мониторинга VMware vSphere, которые сделал Jorge de la Cruz.

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

Итак, сами дэшборды:

1. VMware vSphere - Overview

Этот дэшборд содержит пять различных разделов: один для мониторинга производительности ESXi и vCenter, другой для производительности виртуальных машин, третий для дисков, четвёртый для хранилищ, и последний для хостов и их IPMI. Дэшборд включает переменные, чтобы сделать его использование проще и подходящим для различных типов рабочих нагрузок. Индикаторы автоматически настраиваются в зависимости от выбранных вами хранилищ данных. Если у вас много хранилищ, рассмотрите возможность изменения параметра Min Width для Repeat Panel.

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

2. VMware vSphere - Datastore

Этот дэшборд содержит два раздела: один для мониторинга производительности ESXi и vCenter, другой - для производительности виртуальных машин. Дашборд включает переменные, чтобы упростить его использование и сделать его подходящим для различных типов рабочих нагрузок. Индикаторы автоматически настраиваются в зависимости от выбранных вами хранилищ данных. Если у вас много хранилищ, рассмотрите возможность изменения параметра Min Width для Repeat Panel.

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

3. VMware vSphere - Hosts

Тут видны основные метрики с уровня хоста для каждого из серверов ESXi: конечно же, загрузка аппаратных ресурсов и сети, а также дисковые задержки (latency):

4. VMware vSphere - VMs

Здесь можно увидеть самые полезные метрики для всех виртуальных машин вашего датацентра. Здесь можно увидеть аптайм, загрузку системных ресурсов и сети, latency, счетчик CPU Ready и другое:

Ну и главное - вот эта статья. Она описывает, как настроить мониторинг VMware с помощью дэшбордов Grafana, InfluxDB и Telegraf. В ней пошагово объясняется создание стека контейнеров с использованием Docker Compose, настройка InfluxDB и Telegraf для сбора метрик VMware из vCenter, а также визуализация данных в Grafana. Там подробно рассматривается использование готовых дэшбордов для ускорения процесса настройки и предлагаются советы по устранению неполадок.

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

Наш читатель Сергей справедливо заметил, что мы давно не писали о новых релизах бесплатной утилиты SexiGraf, предназначенной для мониторинга виртуальной инфраструктуры VMware vSphere. В последний раз мы писали об этом в январе прошлого года, а на днях вышло обновление этого продукта - SexiGraf 0.99k (Lighthouse Point).

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

Давайте посмотрим на новые возможности двух недавних релизов:

Релиз Lighthouse Point (0.99k) от 7 октября 2024

VMware Snapshot Inventory

Начиная с версии SexiGraf 0.99h, панель мониторинга «VI Offline Inventory» заменена на VMware Inventory с инвентаризацией ВМ, хостов и хранилищ данных (вскоре добавятся портгруппы и другие элементы). Эти новые панели имеют расширенные возможности фильтрации и значительно лучше подходят для крупных инфраструктур (например, с более чем 50 000 виртуальных машин). Это похоже на извлечение данных из RVtools, которое всегда отображается и актуально.

В релизе v0.99k появилось представление VM Snapshot Inventory:

Улучшения "Cluster health score" для VMware vSAN 8

Вместо того чтобы бесконечно нажимать на кнопку обновления на вкладке «Resyncing Components» в WebClient, начиная с версии SexiGraf 0.99b разработчики добавили панель мониторинга vSAN Resync:

Shell In A Box

В версии SexiGraf 0.99k разработчики добавили отдельный дэшборд Shell In A Box за обратным прокси-сервером, чтобы снова сделать отладку удобной.

Прочие улучшения:

• Официальная поддержка vSphere и vSAN 8.3 API, а также Veeam Backup & Replication v12
• Движок обновлен до Grafana 8.5.9
• PowerShell core обновлен до 7.4.4 LTS
• PowerCLI 13.3
• Graphite 1.2.0
• Автоматическая очистка /var/lib/grafana/png/
• Добавлен выбор версии в панель мониторинга VMware Evo Version
• Добавлена многострочная панель в панель мониторинга репозиториев Veeam
• Обработка учетных записей с очень ограниченными правами
• Опция использования MAC-адреса вместо Client-ID при использовании DHCP
• Добавлено имя хоста гостевой ОС в инвентаризацию виртуальных машин

Релиз St. Olga (0.99j) от 12 февраля 2024

В этой версии авторы добавили официальную поддержку новых API vSphere и vSAN 8.2, а также Veeam Backup & Replication v11+.

Новые возможности:

• Поддержка Veeam Backup & Replication
• Автоматическое слияние метрик ВМ и ESXi между кластерами (функция DstVmMigratedEvent в VROPS)
• Количество путей до HBA
• PowerShell Core 7.2.17 LTS
• PowerCLI 13.2.1
• Grafana 8.5.9 (не 8.5.27 из-за ошибки, появившейся в v8.5.10)
• Ubuntu 20.04.6 LTS

Улучшения и исправления:

• Метрика IOPS для виртуальных машин
• Инвентаризация VMware VBR
• История инвентаризации
• Панель мониторинга эволюции версий активов VMware
• Исправлено пустое значение datastoreVMObservedLatency на NFS
• Различные исправления ошибок

SexiGraf теперь поставляется только в виде новой OVA-аппаратной версии, больше никаких патчей (за исключением крайних случаев). Для миграции необходимо использовать функцию Export/Import, чтобы извлечь данные из вашей предыдущей версии SexiGraf и перенести их в новую.

Актуальная версия SexiGraf доступна для бесплатной загрузки на странице Quickstart.

Продолжаем рассказывать об анонсах новых продуктов и технологий, представленных на конференции VMware Explore 2024.

На мероприятии VMware представила последнюю версию своего пакета безопасности VMware vDefend 4.2, о котором мы рассказывали вот тут. Эта версия представляет собой значительный шаг вперёд и опирается на прочную основу, заложенную её предшественниками, предлагая улучшенную масштабируемость, более точное обнаружение угроз и упрощённое управление.

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

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

Функция распределённого брандмауэра в vDefend 4.2 теперь поддерживает защиту VLAN и распределённых порт-групп наряду с сегментами, поддерживаемыми NSX. Это дополнение дает администраторам большую гибкость в применении политик безопасности для различных сетевых сегментов, что упрощает защиту широкого спектра виртуализированных сред.

Продвинутая защита от угроз

В vDefend 4.2 появилось 14 детекторов сетевого трафика, использующих машинное обучение и AI для обнаружения аномалий. Эта возможность продвинутой защиты от угроз позволяет осуществлять проактивную защиту как от известных, так и от неизвестных угроз. Решение для обнаружения и реагирования на сетевые угрозы (NDR), управляемое AI, непрерывно мониторит сетевой трафик, изучая нормальные шаблоны, чтобы в реальном времени обнаруживать и реагировать на вредоносную активность.

Упрощённое управление и дополнительные функции

Управление обнаружением и предотвращением вредоносного ПО стало проще в vDefend 4.2 благодаря новой функции упрощённого управления жизненным циклом Malware SVM. Эта функция устраняет необходимость в ручной установке веб-серверов, позволяя развертывать служебные виртуальные машины (Service VM) напрямую через API-вызовы. Кроме того, vDefend 4.2 поддерживает файлы OneNote, расширяя возможности обнаружения вредоносного ПО. Решение также вводит настраиваемую пользователем функцию обхода избыточной переподписки, которую можно применить глобально или для отдельных правил, что обеспечивает эффективное управление конкуренцией ресурсов без ущерба для безопасности.

Централизованное управление политиками и мониторинг

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

Интеллектуальная безопасность и интеграция

Интеллектуальная безопасность была ключевым аспектом в разработке vDefend 4.2. Решение теперь беспрепятственно интегрируется с инструментами сторонних разработчиков, такими как SPLUNK и vLog Insight, что позволяет осуществлять комплексное логирование и анализ событий безопасности. Эта интеграция поддерживает более быстрое реагирование на инциденты и более эффективное ограничение угроз.

Как работает система обнаружения и реагирования на сетевые угрозы (NDR)?

Системы Network Detection & Response (NDR) непрерывно мониторят и анализируют огромные объёмы сетевого трафика и событий безопасности по различным элементам и сегментам сети. Эти системы собирают данные как с периметра сети, охватывая трафик «north-south», так и с внутренних сетевых сенсоров, которые отслеживают трафик «east-west». Используя AI и машинное обучение, инструменты NDR устанавливают базовую линию нормальной сетевой активности. Эта базовая линия позволяет системе идентифицировать и отмечать любые отклонения, которые могут указывать на вредоносное поведение.

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

Обновления продукта в будущем

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

• Gen AI Intelligent Assist: VMware планирует интегрировать интеллектуальную помощь на базе GenAI для защиты от угроз, что улучшит сортировку оповещений и предоставит контекстные данные о кампаниях угроз. Эта функция также будет предлагать рекомендации по устранению проблем, что упростит управление и реагирование на инциденты безопасности.
• Продвинутая защита от угроз: ожидаются значительные улучшения производительности распределённых систем IDS/IPS, с увеличением производительности до 3 раз по сравнению с текущими уровнями. VMware также представит настраиваемые сигнатуры для IDS/IPS, возможности быстрой оценки угроз и улучшенные меры по предотвращению вредоносных программ для локальных сред. Кроме того, будут развернуты новые датчики NDR для защиты физических серверов, что расширит возможности обнаружения угроз vDefend.
• Упрощение операций: предстоящие обновления упростят операции безопасности за счёт интеграции рабочих процессов с нативной функциональностью VPC в VCF 9. VMware также планирует ввести поддержку федерации для политик IDS/IPS и улучшить анализ правил брандмауэра, что сделает управление политиками более эффективным.

Более подробно о продукте VMware vDefend можно почитать здесь.

Недавно мы писали о технологии NVMe Tiering, которая появилась в режиме технологического превью в платформе VMware vSphere 8.0 Update 3.

Memory Tiering использует более дешевые устройства в качестве памяти. В Update 3 платформа vSphere использует флэш-устройства PCIe на базе NVMe в качестве второго уровня памяти, что увеличивает доступный объем памяти на хосте ESXi. Memory Tiering через NVMe оптимизирует производительность, распределяя выделение памяти виртуальных машин либо на устройства NVMe, либо на более быструю динамическую оперативную память (DRAM) на хосте. Это позволяет увеличить объем используемой памяти и повысить емкость рабочих нагрузок, одновременно снижая общую стоимость владения (TCO).

Вильям Лам написал интересный пост о выводе информации для NVMe Tiering в VMware vSphere через API. После успешного включения функции NVMe Tiering, которая была введена в vSphere 8.0 Update 3, вы можете найти полезную информацию о конфигурации NVMe Tiering, перейдя к конкретному хосту ESXi, затем выбрав "Configure" -> "Hardware" и в разделе "Memory", как показано на скриншоте ниже.

Здесь довольно много информации, поэтому давайте разберём отдельные элементы, которые полезны с точки зрения NVMe-тиринга, а также конкретные vSphere API, которые можно использовать для получения этой информации.

Memory Tiering Enabled

Поле Memory Tiering указывает, включён ли тиринг памяти на хосте ESXi, и может иметь три возможных значения: "No Tiering" (без тиринга), "Hardware Memory Tiering via Intel Optane" (аппаратный тиринг памяти с помощью технологии Intel Optane) или "Software Memory Tiering via NVMe Tiering" (программный тиринг памяти через NVMe). Мы можем получить значение этого поля, используя свойство "memoryTieringType" в vSphere API, которое имеет три перечисленных значения.

Вот небольшой фрагмент PowerCLI-кода для получения этого поля для конкретного хоста ESXi:

(Get-VMHost "esxi-01.williamlam.com").ExtensionData.Hardware.MemoryTieringType

Tier 0 Memory

Поле Tier 0 представляет общий объём физической оперативной памяти (DRAM), доступной на хосте ESXi. Мы можем получить это поле, используя свойство "memoryTierInfo" в vSphere API, которое возвращает массив результатов, содержащий значения как Tier 0, так и Tier 1.

Вот небольшой фрагмент PowerCLI-кода для получения этого поля для конкретного хоста ESXi:

((Get-VMHost "esxi-01.williamlam.com").ExtensionData.Hardware.MemoryTierInfo | where {$_.Type -eq "DRAM"}).Size

Tier 1 Memory

Поле Tier 1 представляет общий объём памяти, предоставляемой NVMe-тирингом, которая доступна на хосте ESXi. Мы можем получить это поле, используя свойство "memoryTierInfo" в vSphere API, которое возвращает массив результатов, содержащий значения как Tier 0, так и Tier 1.

Примечание: Можно игнорировать термин "Unmappable" — это просто другой способ обозначения памяти, отличной от DRAM.

Вот небольшой фрагмент PowerCLI-кода для получения этого поля для конкретного хоста ESXi:

((Get-VMHost "esxi-01.williamlam.com").ExtensionData.Hardware.MemoryTierInfo | where {$_.Type -eq "NVMe"}).Size

Поле Total представляет общий объём памяти, доступный ESXi при объединении как DRAM, так и памяти NVMe-тиринга, который можно агрегировать, используя размеры Tier 0 и Tier 1 (в байтах).

Устройства NVMe для тиринга

Чтобы понять, какое устройство NVMe настроено для NVMe-тиринга, нужно перейти в раздел "Configure" -> "Storage" -> "Storage Devices", чтобы просмотреть список устройств. В столбце "Datastore" следует искать значение "Consumed for Memory Tiering", как показано на скриншоте ниже. Мы можем получить это поле, используя свойство "usedByMemoryTiering" при энумерации всех устройств хранения.

Вот небольшой фрагмент PowerCLI-кода для получения этого поля для конкретного хоста ESXi:

$storageSystem = Get-View (Get-vmhost "esxi-01.williamlam.com").ExtensionData.ConfigManager.StorageSystem
($storageSystem.StorageDeviceInfo.ScsiLun | where {$_.UsedByMemoryTiering -eq $true}).CanonicalName

Соотношение NVMe-тиринга и DRAM

Отношение объёма DRAM к NVMe по умолчанию составляет 25% и настраивается с помощью следующего расширенного параметра ESXi под названием "Mem.TierNvmePct". Мы можем получить значение этого поля, используя либо vSphere API ("OptionManager"), либо через ESXCLI.

Вот небольшой фрагмент PowerCLI-кода для получения этого поля для конкретного хоста ESXi:

(Get-vmhost "esxi-01.williamlam.com" | Get-AdvancedSetting -Name Mem.TierNvmePct).Value

Сводный отчёт

Вильям собрал все вышеперечисленные парметры и создал скрипт PowerCLI под названием "get-nvme-tiering-info.ps1", который предоставляет удобное резюме для всех хостов ESXi в рамках конкретного кластера Sphere (вы также можете изменить скрипт, чтобы он запрашивал конкретный хост ESXi). Это может быть полезно для быстрого получения информации о хостах, на которых NVMe-тиринг может быть настроен (или нет).

Вот скриншот того, как выглядит вывод скрипта:

В последнем релизе VMware vSAN 8.0 Update 3, утилита vSAN IO Trip Analyzer была существенно доработана. В чем именно заключается это улучшение? Теперь IO Trip Analyzer может быть включен для нескольких ВМ одновременно. Это особенно полезно при устранении проблем с производительностью комплексного сервиса, состоящего из нескольких ВМ.

Данное улучшение позволяет вам одновременно мониторить несколько ВМ и анализировать, на каком уровне у каждой из выбранных ВМ возникает задержка (latency). Обратите внимание, что это улучшение работает как для vSAN ESA, так и для vSAN OSA.

Дункан Эппинг записал на эту тему интересное обзорное видео:

Дункан Эппинг написал интересный пост.

Начиная с обновления VMware vSphere 8.0 Update 2, поддержка опции "None - Stretched Cluster" в политике хранения (Storage Policy) для конфигурации vSAN Stretched Cluster была удалена. Причина этого заключается в том, что данная опция часто приводила к ситуациям, когда клиенты ошибочно ее использовали, и при сбое обнаруживали, что некоторые виртуальные машины перестали работать.

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

Поэтому данную опцию было решено убрать.

Прошло довольно много времени с момента последнего крупного выпуска RabbitMQ — версия 3.0 была запущена еще в ноябре 2012 года. Хотя ожидание следующего большого обновления могло показаться долгим, за это время произошло немало событий. Вместе с несколькими приобретениями команда VMware Tanzu RabbitMQ представила значительные функции и улучшения в промежуточных выпусках. Сегодня RabbitMQ является ключевым компонентом портфеля VMware Tanzu Data Solutions в VMware Tanzu. Приверженность Broadcom к сообществу с открытым исходным кодом также имеет важное значение, поскольку все участники основной инженерной команды являются сотрудниками Broadcom.

Неудивительно, что самая значительная функция RabbitMQ 4.0 является одновременно и нарушением обратной совместимости и в значительной степени невидима для пользователей, однако она критически важна для будущей устойчивости RabbitMQ. Как и многие другие продукты такого типа, RabbitMQ имеет хранилище метаданных в своей основе. Это хранилище используется для хранения определений топологии сообщений, пользователей, виртуальных хостов (vhosts), очередей, обменов, байндингов и параметров выполнения — оно жизненно важно для работы брокера сообщений.

Старое хранилище метаданных Mnesia использовалось столько же, сколько существует RabbitMQ. Как и следовало ожидать, за последние 17 лет в функциональности RabbitMQ произошло множество изменений, и многие функции были улучшены. Новое хранилище метаданных в RabbitMQ 4.0 (Khepri) использует тот же проверенный raft-based алгоритм, который уже несколько лет поддерживает безопасность данных в очередях Quorum Queue. Это делает систему очень устойчивой к разделению сети, что, в свою очередь, делает продукт Tanzu RabbitMQ более надежным.

Другие важные преимущества заключаются в том, что Khepri более эффективен в выполнении задач обслуживания, таких как удаление очередей или обменов, что ведет к общему улучшению производительности ядра Tanzu RabbitMQ. Эти улучшения производительности также прокладывают путь для дальнейших улучшений возможностей кластеризации Tanzu RabbitMQ. Пользователи могут включить Khepri с помощью опционального флага функции, так что никто не будет вынужден использовать эту технологию, если это не требуется. Разумеется, никаких изменений в коде не требуется при его включении, и RabbitMQ автоматически обрабатывает миграцию с Mnesia на Khepri.

Что касается производительности, в этом выпуске протокол AMQP 1.0 включен в ядро RabbitMQ. Это не означает, что старый протокол AMQP 0.9.1 не будет поддерживаться — это просто значит, что теперь можно выбрать более современный и стандартизированный протокол. Поддержка этой новой версии, опубликованной OASIS, укрепляет многопротокольный подход RabbitMQ и увеличивает его универсальность. В соответствии с другими "нативизациями" поддержка AMQP 1.0 также обеспечивает такие же улучшения производительности, которые были достигнуты при внедрении "нативного" MQTT в версиях 3.12 (MQTTv3) и 3.13 (MQTTv5).

На самом деле, пропускная способность (throughput) AMQP 1.0 между версиями 3.13 и 4.0 более чем удвоилась для классических очередей и очередей Quorum, а также для потоков. Как мы видели с нативной реализацией MQTT, такой подход к протоколам ведет к меньшему потреблению памяти на соединение. Это значит, что кластеры RabbitMQ теперь могут обрабатывать более чем в два раза больше соединений AMQP 1.0 по сравнению с предыдущими выпусками. Для получения дополнительной информации об этих улучшениях производительности, пожалуйста, ознакомьтесь с этой статьей в блоге.

Ранее пользователи не могли воспользоваться возможностями управления топологией, определенными в спецификации AMQP 1.0, что требовало заранее заданных очередей, байндингов и обменов. Такая жесткая настройка ограничивала ключевую силу RabbitMQ — его гибкие маршрутизационные возможности. Однако в версии 4.0 клиентские приложения теперь могут самостоятельно объявлять, удалять, очищать, связывать или отсоединять как очереди, так и обмены при использовании AMQP 1.0. Можно даже выполнять команду "get queue", которая предоставляет полезную информацию о лидере очереди и ее репликах в случае очередей Quorum. Эти клиентские библиотеки значительно помогают разработчикам извлекать максимум из протокола с минимальными усилиями. Например, такие функции, как подтверждения отправителя, становятся очень простыми. На сегодняшний день доступны клиенты Java и .NET, а скоро появятся и другие.

Нечасто удаление функции вызывает столько внимания, как удаление классических зеркальных очередей (Classic Mirrored Queues) в RabbitMQ. Несмотря на то, что эти старые зеркальные очереди были устаревшими более 3 лет, многие разочарованы их окончательным удалением. Хорошая новость заключается в том, что, хотя зеркалирование и было удалено, любые очереди, которые были зеркальными, не будут полностью удалены в версии 4.0, только их зеркальная часть. Также стоит отметить, что пользователям не обязательно использовать зеркалирование для публикации или потребления сообщений с конкретных узлов. Фактически, даже после удаления зеркальной очереди можно публиковать сообщения или потреблять их из очереди на любом узле в том же кластере RabbitMQ. Таким образом, приложения могут использовать те же классические очереди, что и раньше. Классические очереди продолжают поддерживаться без каких-либо изменений, нарушающих совместимость с клиентскими библиотеками. Для обеспечения дальнейшей безопасности данных реплицируемыми типами остаются очереди Quorum и потоки, обе из которых являются очень зрелыми технологиями. Дополнительную информацию о том, как мигрировать с классических зеркальных очередей на очереди Quorum, можно найти в этой статье в блоге.

Инженерная команда RabbitMQ продолжает развивать очереди Quorum, чтобы они работали быстрее и безопаснее, чем раньше. Ранее пользователи могли назначать до 255 приоритетов с помощью классических зеркальных очередей, однако это путь к полному приоритетному хаосу и путанице. В спецификации JMS для AMQP 1.0 определено всего два приоритета — нормальный и высокий.

Это то, что было реализовано в очередях Quorum для версии 4.0. Любое значение приоритета между 0 и 4 (включительно) считается нормальным приоритетом. Значения выше 4 считаются высоким приоритетом, а если издатель не указывает приоритет сообщения, предполагается значение 4 (нормальный приоритет). Что делать, если пользователям нужно больше контроля? Возможно, пришло время пересмотреть определения приоритетов сообщений. Приоритеты часто наследуются от старых систем и редко пересматриваются, как видно из спецификации JMS. Если это не удается разрешить, одним из решений является использование нескольких очередей — теперь это стало проще благодаря более быстрому времени загрузки очередей Quorum в RabbitMQ 4.0 и программной декларации AMQP 1.0. Кроме того, в очередях Quorum теперь установлено значение по умолчанию для ограничения на доставку — 20, а также приоритеты для одного активного потребителя (Single Active Consumer).

Добавлен и новый тип обмена — Random Exchange. В основном предназначен для использования в сценариях "запрос-ответ", в которых сообщения всегда доставляются в локальную очередь (чтобы уменьшить задержку при публикации). Если к тому же обмену подключено несколько локальных очередей, для доставки сообщения будет выбрана одна из них случайным образом.

Для пользователей Kubernetes добавлена новая диаграмма Helm, которая развертывает как операторы Kubernetes с открытым исходным кодом, так и коммерческие операторы кластеров и топологии Tanzu. Кроме того, теперь в определениях пользовательских ресурсов Kubernetes (Custom Resource Definitions) поддерживаются регулярные выражения, что позволяет пользователям определять диапазон виртуальных хостов (vhosts) вместо их явного объявления каждый раз.

Функции устойчивости репликации "Горячий резерв" (Warm Standby Replication) также получили улучшения в этом выпуске. В версии 3.13 был добавлен конфигурационный файл, облегчающий пользователям настройку и конфигурацию WSR, который в версии 4.0 был улучшен поддержкой списков и шаблонов для виртуальных хостов и т. д. Поддержка секретов теперь доступна через тот же конфигурационный файл, чтобы помочь обеспечить дополнительную безопасность для репликационной связи между верхним и нижним кластерами; в настоящее время поддерживается Hashicorp Vault. Пользователи также могут помечать конкретные определения shovel и federation для синхронизации в рамках процесса репликации горячего резерва. Оператор Standby Replication для Kubernetes заменен этим конфигурационным файлом, что упрощает настройку WSR независимо от среды.

Таким образом, RabbitMQ 4.0 приносит несколько ключевых улучшений, особенно в области совместимости и устойчивости. Наиболее заметное для пользователей изменение — внедрение AMQP 1.0 как основного протокола с значительными улучшениями пропускной способности и подключений. Этот выпуск и его дополнительные клиентские библиотеки открывают путь к дальнейшему развитию RabbitMQ, что позволит ему оставаться наиболее широко используемым брокером сообщений во всем мире на долгие годы.

Одним из самых больших препятствий в управлении инфраструктурой частного облака является координация с владельцами приложений для планирования временных окон обслуживания, которые соответствуют потребностям их бизнеса. К счастью, VMware vSphere с возможностями живой миграции vMotion и Storage vMotion предлагает решение этой проблемы, обеспечивая проверенные обновления инфраструктуры без простоев. Однако, даже с преимуществами vMotion, бизнес-политики могут всё равно диктовать время и выполнение определённых операций, подчёркивая необходимость минимизировать количество операций по обслуживанию, где это возможно. Уменьшая число таких операций, ИТ-команды могут минимизировать сбои, снизить затраты и повысить общую эффективность инфраструктуры.

Обновление и патчинг в одном рабочем процессе

Одним из ключевых улучшений в VMware Cloud Foundation 5.2 является новая функция под названием «Flexible Bill of Materials (BOM)», которая позволяет выбирать конкретные версии отдельных компонентов во время обновления домена рабочих нагрузок (workload domain). Это упрощает процесс обновления, сокращая количество операций по обслуживанию и минимизируя простои. В предыдущих версиях VCF процесс требовал двух операций обслуживания: одной для обновления и второй для применения асинхронного патча. Теперь же гибкий BOM в VCF 5.2 упрощает процесс, снижая административную нагрузку и потенциальные риски.

Выглядит это следующим образом (кликните на картинку, чтобы открыть анимацию):

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

Также на эту тему есть хорошее обзорное видео от VMware:

Улучшения VCF 5.2 в управлении жизненным циклом

Помимо опции гибкого списка компонентов (BOM), VCF 5.2 вводит несколько других улучшений, упрощающих процесс обновления и развертывания. Например, администраторы VCF теперь могут применять асинхронные патчи напрямую через интерфейс SDDC Manager, что упрощает поддержание актуальности среды. Процесс развертывания доменов рабочих нагрузок также был оптимизирован: асинхронные патчи автоматически включаются, чтобы обеспечить более безопасные и актуальные новые развертывания.

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

На ресурсе Technopedia вышла статья с интригующим заголовком "Cloud Exit: 42% of Companies Move Data Back On-Premises". Интересно узнать, что такой большой процент компаний, оказывается, перемещают свои данные обратно из облака в онпремизную инфраструктуру.

Почему набирает популярность тренд «выход из облака»?

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

42% организаций, опрошенных в США компанией Citrix в начале этого года, рассматривают возможность или уже переместили как минимум половину своих облачных рабочих нагрузок обратно на локальные инфраструктуры.

Фактически, 94% респондентов, участвовавших в этом недавнем опросе, были вовлечены в проекты, связанные с частичным отказом от облака.

Как отмечается в подробной статистике по облачным расходам, высокая стоимость облачных решений оказалась серьезным сдерживающим фактором для корпораций. Более 43% ИТ-руководителей заявили, что перенос приложений и данных из локальной инфраструктуры в облако оказался дороже, чем ожидалось.

Одним из первых известных случаев «выхода из облака» был пример Dropbox в 2015 году, когда компания сократила операционные расходы на 74,6 миллиона долларов за два года. Несмотря на начальные преимущества масштабируемости и гибкости облачных решений, быстрый рост Dropbox сделал постоянные расходы на облако неприемлемыми.

Некоторые компании растут настолько быстро, что для них имеет смысл создать собственную инфраструктуру с использованием кастомных технологий и отказаться от облака. При этом выход из облака помог им снизить зависимость от облачных сервисов крупных поставщиков, таких как Amazon и Google, за счет использования собственных технологий и создания собственной сети.

Выход из облака: ключевая статистика

• 42% организаций в США рассматривают возможность или уже переместили как минимум половину своих облачных рабочих нагрузок обратно в собственную инфраструктуру.
• 94% респондентов опроса участвовали в каком-либо проекте, связанном с частичным отказом от облака.
• 43% ИТ-руководителей считают, что перенос приложений и данных в облако оказался дороже, чем ожидалось.
• Dropbox сэкономил 74,6 миллиона долларов за два года, сократив использование облачных сервисов.
• Basecamp потратил 3,2 миллиона долларов на облачные сервисы в 2022 году и прогнозирует экономию 7 миллионов долларов за пять лет, перейдя на локальную инфраструктуру.
• В настоящее время доля рынка Amazon Web Services составляет 31%, Microsoft Azure — 25%, Google Cloud — 11%.

«Облако — не благотворительность»

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

Агарвал сказал: «Никто не ведет облачный бизнес как благотворительность». Когда компании достигают таких масштабов, при которых создание собственной инфраструктуры становится экономически выгодным, это позволяет значительно сэкономить, устранив «облачного посредника» и связанные с этим расходы.

Тем не менее, облако, конечно, не «просто чей-то компьютер», как гласит шутка. Оно принесло огромную пользу тем, кто смог к нему адаптироваться.

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

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

Мечты об облаке vs. реальность

В 2019 году Gartner смело предсказала, что 80% предприятий закроют свои традиционные центры обработки данных к 2025 году и перейдут в облако, но насколько это предсказание верно?

Всего три года спустя, в отчете Accenture за 2022 год был представлен неоднозначный прогресс. Хотя девять из десяти компаний признают значительные выгоды от своих инвестиций в облако, только 42% полностью реализовали свои ожидаемые результаты, и лишь 32% считают свои облачные проекты завершенными и удовлетворительными.

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

Основные причины отказа от облака

Компании всё чаще пересматривают свои обязательства по использованию облака и изучают возможности стратегий отказа от него. Вот ключевые факторы, которые способствуют изменению настроений на рынке:

1. Финансовые соображения

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

Один из примеров — известный поставщик решений для управления проектами Basecamp, чьи ежемесячные расходы на облако достигли примерно $180 000, когда они обнаружили, что услуги облачных провайдеров, таких как Amazon и Google, оказались дороже и сложнее, чем ожидалось.

Потратив $3,2 млн на облачные сервисы в 2022 году, компания подсчитала, что использование локального оборудования будет стоить $840 000 ежегодно. Отказавшись от этого финансового бремени, Basecamp прогнозирует экономию $7 млн за пять лет.

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

2. Непредсказуемые расходы и избыточность облачных ресурсов

Расходы, которых можно избежать, и избыточные облачные ресурсы стали другой важной проблемой, выявленной в опросе «Стратегия облака 2023» от Hashicorp. 94% респондентов сообщили о ненужных расходах из-за неиспользуемых облачных ресурсов.

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

3. Уязвимости в безопасности

Согласно глобальному опросу PwC «Надежды и страхи сотрудников» за 2024 год, около 47% технических лидеров считают облачные угрозы основной проблемой в сфере кибербезопасности. Распространено мнение, что локальная инфраструктура менее безопасна, поскольку она физически доступна.

Но действительно ли это так, или все дело в том, насколько хорошо контролируется доступ? Правда в том, что удаленный доступ значительно увеличивает вероятность кибератак, так как количество потенциальных точек входа для хакеров растет. Кроме того, облако является привлекательной целью для злоумышленников. Более 80% утечек данных в 2023 году были связаны с данными, хранящимися в облаке, а средняя глобальная стоимость утечки составила $4,45 млн.

Крупные компании, такие как Capital One, Twilio, Pegasus Airlines и Uber, в прошлом сталкивались с утечками через AWS. Эти громкие случаи усилили опасения по поводу хранения конфиденциальных данных в облаке.

4. Проблемы с производительностью и надежностью

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

В 2023 году сбои у крупных облачных провайдеров, таких как Oracle, Azure и AWS, приводили к нарушению работы сотен тысяч пользователей каждый раз, что могло приводить к миллионным потерям для компаний. К сожалению, в 2024 году частота облачных сбоев продолжает расти.

5. Монополистические тенденции в облаке

Зависимость от одного поставщика и ограниченная гибкость — серьезные проблемы, с которыми сталкиваются компании, пытающиеся использовать облачные сервисы. С долей рынка в 31% у Amazon Web Services, 25% у Microsoft Azure и 11% у Google Cloud, небольшое количество крупных провайдеров доминирует на рынке.

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

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

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

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

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

Вильям Лам написал интересную статью о поддержке технологии Intel Neural Processing Unit (NPU) на платформе VMware ESXi.

Начиная с процессоров Intel Meteor Lake (14 поколения), которые теперь входят в новый бренд Intel Core Ultra Processor (серия 1), встроенный нейронный процессор (Neural Processing Unit, NPU) интегрирован прямо в систему на кристалле (system-on-chip, SoC) и оптимизирован для энергоэффективного выполнения AI-инференса.

Автор дает ссылку на эту статью от Chips and Cheese о новом нейронном процессоре Intel Meteor Lake NPU, которую он нашел очень познавательной и определённо рекомендует прочесть, если вы новичок в теме NPU.

Хотя вы уже можете использовать интегрированную графику Intel iGPU на таких платформах, как Intel NUC, с ESXi для инференса рабочих нагрузок, Вильяму стало интересно, сможет ли этот новый нейронный процессор Intel NPU работать с ESXi?

Недавно Вильям получил доступ к ASUS NUC 14 Pro (на который позже он сделает подробный обзор), в котором установлен новый нейронный процессор Intel NPU. После успешной установки последней версии VMware ESXi 8.0 Update 3, он увидел, что акселератор Intel NPU представлен как PCIe-устройство, которое можно включить в режиме passthrough и, видимо, использовать внутри виртуальной машины.

Для тестирования он использовал Ubuntu 22.04 и библиотеку ускорения Intel NPU, чтобы убедиться, что он может получить доступ к NPU.

Шаг 1 - Создайте виртуальную машину с Ubuntu 22.04 и настройте резервирование памяти (memory reservation - это требуется для PCIe passthrough), затем добавьте устройство NPU, которое отобразится как Meteor Lake NPU.

Примечание: вам нужно будет отключить Secure Boot (этот режим включен по умолчанию), так как необходимо установить более новую версию ядра Linux, которая всё ещё находится в разработке. Отредактируйте виртуальную машину и перейдите в VM Options -> Boot Options, чтобы отключить его.

Когда Ubuntu будет запущена, вам потребуется установить необходимый драйвер Intel NPU для доступа к устройству NPU, однако инициализация NPU не удастся, что можно увидеть, выполнив следующую команду:

dmesg | grep vpu

После подачи обращения в поддержку Github по поводу драйвера Intel NPU, было предложено, что можно инициализировать устройство, используя новую опцию ядра, доступную только в версии 6.11 и выше.

Шаг 2 - Используя эту инструкцию, мы можем установить ядро Linux версии 6.11, выполнив следующие команды:

cd /tmp

wget -c https://kernel.ubuntu.com/mainline/v6.11-rc6/amd64/linux-headers-6.11.0-061100rc6_6.11.0-061100rc6.202409010834_all.deb
wget -c https://kernel.ubuntu.com/mainline/v6.11-rc6/amd64/linux-headers-6.11.0-061100rc6-generic_6.11.0-061100rc6.202409010834_amd64.deb
wget -c https://kernel.ubuntu.com/mainline/v6.11-rc6/amd64/linux-image-unsigned-6.11.0-061100rc6-generic_6.11.0-061100rc6.202409010834_amd64.deb
wget -c https://kernel.ubuntu.com/mainline/v6.11-rc6/amd64/linux-modules-6.11.0-061100rc6-generic_6.11.0-061100rc6.202409010834_amd64.deb

dpkg -i *.deb

reboot

После перезагрузки вашей системы Ubuntu вы можете убедиться, что теперь она использует версию ядра 6.11, выполнив команду:

uname -r

Шаг 3 - Теперь мы можем установить драйвер Intel NPU для Linux, и на момент публикации этой статьи последняя версия — 1.8.0. Для этого выполните следующие команды:

cd /tmp

wget https://github.com/intel/linux-npu-driver/releases/download/v1.8.0/intel-driver-compiler-npu_1.8.0.20240916-10885588273_ubuntu24.04_amd64.deb
wget https://github.com/intel/linux-npu-driver/releases/download/v1.8.0/intel-fw-npu_1.8.0.20240916-10885588273_ubuntu24.04_amd64.deb
wget https://github.com/intel/linux-npu-driver/releases/download/v1.8.0/intel-level-zero-npu_1.8.0.20240916-10885588273_ubuntu24.04_amd64.deb
wget https://github.com/oneapi-src/level-zero/releases/download/v1.17.6/level-zero_1.17.6+u22.04_amd64.deb

apt --fix-broken install -y
apt install build-essential libtbb12 cmake -y

dpkg -i *.deb

Нам также нужно создать следующий файл, который включит необходимую опцию ядра (force_snoop=1) для инициализации NPU по умолчанию, выполнив следующую команду:

cat > /etc/modprobe.d/intel_vpu.conf << EOF

options intel_vpu force_snoop=1

EOF

Теперь перезагрузите систему, и NPU должен успешно инициализироваться, как показано на скриншоте ниже.

Наконец, если вы хотите убедиться, что NPU полностью функционален, в библиотеке Intel NPU Acceleration есть несколько примеров, включая примеры малых языковых моделей (SLM), такие как TinyLlama, Phi-2, Phi-3, T5 и другие.

Для настройки вашего окружения Python с использованием conda выполните следующее:

wget https://repo.anaconda.com/miniconda/Miniconda3-latest-Linux-x86_64.sh

bash Miniconda3-latest-Linux-x86_64.sh -b -p $HOME/miniconda
eval "$(/$HOME/miniconda3/bin/conda shell.bash hook)"

conda config --set auto_activate_base true
conda init
conda create -n npu python=3.10 -y
conda activate npu
conda install -c conda-forge libstdcxx-ng=12 -y

pip install accelerate intel-npu-acceleration-library==1.3.0 transformers==4.39.3

git clone https://github.com/intel/intel-npu-acceleration-library.git
cd intel-npu-acceleration-library
git checkout v1.3.0

Автор попробовал пример tiny_llama_chat.py (видимо, тренировочные данные для этой модели могли быть основаны на изображениях или художниках).

Независимо от того, используете ли вы новую библиотеку Intel NPU Acceleration или фреймворк OpenVino, теперь у вас есть доступ к ещё одному ускорителю с использованием ESXi, что может быть полезно для периферийных развертываний, особенно для рабочих нагрузок, требующих инференса AI, и теперь с меньшим энергопотреблением.

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

from openvino.runtime import Core

def list_available_devices():
    # Initialize the OpenVINO runtime core
    core = Core()

    # Get the list of available devices
    devices = core.available_devices

    if not devices:
        print("No devices found.")
    else:
        print("Available devices:")
        for device in devices:
            print(f"- {device}")

        # Optional: Print additional device information
        for device in devices:
            device_info = core.get_property(device, "FULL_DEVICE_NAME")
            print(f"\nDevice: {device}\nFull Device Name: {device_info}")

if __name__ == "__main__":
    list_available_devices()

Компания Broadcom выпустила интересное видео, где Mark Achtemichuk и Uday Kulkurne обсуждают оптимизацию AI/ML нагрузок с использованием аппаратной платформы NVIDIA GPU и решения VMware Cloud Foundation:

Производительность и эффективность виртуализации графических процессоров (GPU) является одним из ключевых направлений для разработки решений в области искусственного интеллекта (AI) и машинного обучения (ML).

Виртуализация AI/ML задач, работающих на GPU, представляет собой вызов, так как традиционно считается, что виртуализация может значительно снижать производительность по сравнению с «чистой» конфигурацией на физическом оборудовании (bare metal). Однако VMware Cloud Foundation демонстрирует почти аналогичную производительность с минимальными потерями за счет умной виртуализации и использования технологий NVIDIA.

Рассматриваемые в данном видо графические процессоры от NVIDIA включают модели H100, A100 и L4, каждая из которых имеет уникальные характеристики для обработки AI/ML задач. Например, H100 оснащен 80 миллиардами транзисторов и способен ускорять работу трансформеров (на основе архитектуры GPT) в шесть раз. Особенностью H100 является возможность разделения GPU на несколько независимых сегментов, что позволяет обрабатывать задачи параллельно без взаимного влияния. A100 и L4 также обладают мощными возможностями для AI/ML, с небольшими различиями в спецификациях и применимости для графических задач и машинного обучения.

VMware Cloud Foundation (VCF) позволяет использовать все преимущества виртуализации, обеспечивая при этом производительность, близкую к физическому оборудованию. Одна из ключевых возможностей — это поддержка дробных виртуальных GPU (vGPU) с изоляцией, что позволяет безопасно распределять ресурсы GPU между несколькими виртуальными машинами.

Используя виртуализированные конфигурации на базе VCF и NVIDIA GPU, компании могут значительно снизить общие затраты на владение инфраструктурой (TCO). VMware Cloud Foundation позволяет консолидировать несколько виртуальных машин и задач на одном физическом хосте без существенной потери производительности. Это особенно важно в условиях современных датацентров, где необходимо максимизировать эффективность использования ресурсов.

В серии тестов было проверено, как виртуализированные GPU справляются с различными AI/ML задачами по сравнению с физическим оборудованием. Используя стандартные бенчмарки, такие как ML Commons, было показано, что виртуализированные GPU демонстрируют производительность от 95% до 104% по сравнению с bare metal конфигурациями в режиме инференса (вычисления запросов) и около 92-98% в режиме обучения. Это означает, что даже в виртуализированной среде можно добиться почти той же скорости, что и при использовании физического оборудования, а в некоторых случаях — даже превзойти её.

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

Компания VMware представила обновленную версию документа "Best Practices for VMware vSphere 8.0 Update 3", описывающего лучшие практики повышения производительности для последней версии платформы VMware vSphere 8.0 Update 3 — ценный ресурс, наполненный экспертными советами по оптимизации быстродействия. Хотя это и не является всеобъемлющим руководством по планированию и настройке ваших развертываний, он предоставляет важные рекомендации по улучшению производительности в ключевых областях.

Краткий обзор содержания:

• Глава 1: Оборудование для использования с VMware vSphere (Стр. 11) — узнайте важные советы по выбору правильного оборудования, чтобы максимально эффективно использовать вашу среду vSphere.
• Глава 2: ESXi и виртуальные машины (Стр. 25) — ознакомьтесь с лучшими практиками для платформы VMware ESXi и тонкими настройками виртуальных машин, работающих в этой среде.
• Глава 3: Гостевые операционные системы (Стр. 57) — узнайте, как правильно оптимизировать гостевые ОС, работающие в ваших виртуальных машинах vSphere.
• Глава 4: Управление виртуальной инфраструктурой (Стр. 69) — получите советы по эффективному управлению для поддержания высокопроизводительной виртуальной инфраструктуры.

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

В обновлении платформы VMware Cloud Foundation 5.2 был представлен новый инструмент командной строки (CLI), называемый VCF Import Tool, который предназначен для преобразования или импорта существующих сред vSphere, которые в настоящее время не управляются менеджером SDDC, в частное облако VMware Cloud Foundation. Вы можете ознакомиться с демонстрацией работы инструмента импорта VCF в этом 6-минутном видео.

Инструмент импорта VCF позволяет клиентам ускорить переход на современное частное облако, предоставляя возможность быстро внедрить Cloud Foundation непосредственно в существующую инфраструктуру vSphere. Нет необходимости приобретать новое оборудование, проходить сложные этапы развертывания или вручную переносить рабочие нагрузки. Вы просто развертываете менеджер SDDC на существующем кластере vSphere и используете инструмент импорта для преобразования его в частное облако Cloud Foundation.

Импорт вашей существующей инфраструктуры vSphere в частное облако VCF происходит без сбоев, поскольку это прозрачно для работающих рабочих нагрузок. В общих чертах, процесс включает сканирование vCenter для обеспечения совместимости с VCF, а затем регистрацию сервера vCenter и его связанного инвентаря в менеджере SDDC. Зарегистрированные экземпляры сервера vCenter становятся доменами рабочих нагрузок VCF, которые можно централизованно управлять и обновлять через менеджер SDDC как часть частного облака VMware. После добавления в инвентарь Cloud Foundation все доступные операции менеджера SDDC становятся доступны для управления преобразованным или импортированным доменом. Это включает в себя расширение доменов путем добавления новых хостов и кластеров, а также применение обновлений программного обеспечения.

Обзор инструмента импорта VCF

Существует два способа начать работу с инструментом импорта VCF.

Если у вас еще нет развернутого виртуального модуля (Virtual Appliance) менеджера SDDC в вашем датацентре, первый шаг — вручную развернуть экземпляр устройства в существующей среде vSphere. Затем вы используете инструмент импорта VCF для преобразования этой среды в управляющий домен VMware Cloud Foundation.

Если в вашем датацентре уже работает экземпляр менеджера SDDC, просто обновите его до версии VCF 5.2 и используйте его для начала импорта существующих сред vSphere как доменов рабочих нагрузок VI. Обратите внимание, что помимо импорта и преобразования сред vSphere в VCF в качестве доменов рабочих нагрузок, инструмент импорта VCF также может быть использован для развертывания NSX в преобразованном или импортированном домене. Это можно сделать как во время преобразования/импорта, так и в качестве операции «Day-2», выполняемой в любое время после добавления среды в качестве домена рабочих нагрузок. Также в инструменте импорта есть функция синхронизации, которая позволяет управлять расхождением конфигураций между сервером vCenter и менеджером SDDC. Подробнее об этих функциях будет рассказано ниже.

Требования для использования инструмента импорта VCF

Чтобы начать работу с инструментом импорта VCF, необходимо выполнить несколько требований. Эти требования различаются в зависимости от того, преобразуете ли вы существующую среду vSphere в управляющий домен VCF или импортируете существующую среду vSphere как домен виртуальной инфраструктуры (VI). Начнем с рассмотрения требований, уникальных для преобразования управляющего домена VCF. Затем перейдем к требованиям, общим для обоих случаев использования — преобразования и импорта.

Примечание: требования и ограничения, указанные в этой статье, основаны на первоначальном релизе инструмента импорта VCF, доступного с VCF 5.2. Обязательно ознакомьтесь с Release Notes, чтобы узнать, применимы ли эти ограничения к версии VCF, которую вы используете.

Требования для преобразования кластера vSphere в управляющий домен VCF

Для преобразования существующей среды vSphere в управляющий домен VCF необходимо учитывать два основных требования.

• Во-первых, среда vSphere, которую вы хотите преобразовать, должна работать на версии vSphere 8.0 Update 3 или выше. Это относится как к экземпляру сервера vCenter, так и к хостам ESXi. Эта версия vSphere соответствует спецификации (Bill of Materials, BOM) VCF 5.2. Это требование связано, в частности, с тем, что сначала нужно развернуть виртуальный модуль менеджера SDDC в кластере, а версия 5.2 этого устройства требует версий vCenter и ESXi 8.0 Update 3 (или выше).
• Во-вторых, при преобразовании среды vSphere сервер vCenter должен работать в кластере, который будет преобразован. В документации это называется требованием «совместного размещения» сервера vCenter с кластером.

Требования для импорта кластера vSphere в домен VI VCF

Как и при преобразовании в новый управляющий домен, при импорте среды vSphere в домен VI VCF также необходимо учитывать два основных требования.

• Во-первых, поддерживаемые версии vSphere для импорта в качестве домена VI — это vSphere 7.0 Update 3 и выше. Это включает как экземпляр сервера vCenter, так и хосты ESXi. Минимальная версия 7.0 с обновлением 3 соответствует версии vCenter и ESXi, которая входит в спецификацию VCF 4.5 (BOM).
• Во-вторых, при импорте среды vSphere сервер vCenter должен работать либо в кластере, который преобразуется (совместно размещенный), либо в кластере в управляющем домене.

Общие требования при преобразовании и импорте кластеров vSphere

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

• Все хосты внутри кластера vSphere должны быть однородными. Это означает, что все хосты в кластере должны быть одинаковыми по мощности, типу хранилища и конфигурации (pNIC, VDS и т.д.). Конфигурации серверов могут различаться между кластерами, но внутри одного кластера хосты должны быть одинаковыми.
• Кластеры, которые будут преобразованы или импортированы, должны использовать один из трех поддерживаемых типов хранилищ: vSAN, NFS или VMFS на Fibre Channel (FC). Это часто вызывает путаницу, так как при развертывании с нуля (greenfield deployment) с использованием устройства Cloud Builder для управляющего домена требуется всегда использовать vSAN. Учтите, что требование vSAN не применяется к преобразованным управляющим доменам, где можно использовать vSAN, NFS или VMFS на FC.
• При использовании vSAN минимальное количество хостов для управляющего домена всегда составляет четыре. Однако при использовании NFS или VMFS на FC минимальное количество хостов составляет три. Это также отличается от требований при развертывании с нуля с использованием Cloud Builder.
• Режим расширенной связи (Enhanced Linked Mode, ELM) не поддерживается инструментом импорта VCF. Каждый экземпляр сервера vCenter, который будет преобразован или импортирован в качестве домена рабочих нагрузок VCF, должен находиться в собственной доменной структуре SSO. Таким образом, каждый преобразованный или импортированный экземпляр vCenter создаст изолированный домен рабочих нагрузок в VCF. Это может стать проблемой для клиентов, которые привыкли к централизованному управлению своей средой VCF через одну панель управления. Обратите внимание на новые дэшборды мониторинга VCF Operations (ранее Aria Operations), которые могут помочь смягчить это изменение.
• Все кластеры в инвентаре vCenter должны быть настроены с использованием одного или нескольких выделенных vSphere Distributed Switches (VDS). Учтите, что стандартные коммутаторы vSphere (VSS) не поддерживаются. Более того, если в кластере настроен VSS, его необходимо удалить перед импортом кластера. Также важно отметить, что VDS не могут быть общими для нескольких кластеров vSphere.
• В инвентаре vCenter не должно быть отдельных хостов ESXi. Отдельные хосты нужно либо переместить в кластер vSphere, либо удалить из инвентаря vCenter.
• Во всех кластерах должно быть включено полное автоматическое распределение ресурсов (DRS Fully Automated), и на всех хостах должна быть настроена выделенная сеть для vMotion.
• Все адаптеры vmkernel должны иметь статически назначенные IP-адреса. В рамках процесса преобразования/импорта в менеджере SDDC будет создан пул сетей с использованием этих IP-адресов. После завершения импорта эти IP-адреса не должны изменяться, поэтому они должны быть статически назначены.
• Среды vSphere не могут иметь несколько адаптеров vmkernel, настроенных для одного и того же типа трафика.

Значимые ограничения инструмента импорта в VCF 5.2

После указания требований для использования инструмента импорта VCF важно отметить несколько ограничений, связанных с версией VCF 5.2, о которых нужно знать. Имейте в виду, что рабочие процессы импорта VCF включают функцию «проверки», которая сканирует инвентарь vCenter перед попыткой преобразования или импорта. Если обнаруживаются ограничения, процесс будет остановлен.

Следующие топологии не могут быть преобразованы или импортированы с использованием инструмента импорта VCF в версии 5.2:

• Среда vSphere, настроенная с использованием NSX.
• Среды vSphere, настроенные с балансировщиком нагрузки AVI.
• Среды vSphere, настроенные с растянутыми кластерами vSAN Stretched Clusters.
• Среды vSphere, где vSAN настроен только в режиме сжатия (compression-only mode).
• Кластеры vSphere с общими распределенными коммутаторами vSphere (VDS).
• Среды vSphere с включенной контрольной панелью IaaS (ранее vSphere with Tanzu).
• Среды vSphere, настроенные с использованием протокола управления агрегированием каналов (LACP).
• Среды VxRail.

Установка NSX на преобразованные и импортированные домены рабочих нагрузок

При обсуждении ограничений, связанных с инструментом импорта VCF, мы отметили, что нельзя преобразовывать или импортировать кластеры, настроенные для NSX. Однако после того, как домен будет преобразован/импортирован, вы можете использовать инструмент импорта VCF для установки NSX. Вы можете выбрать установку NSX одновременно с преобразованием/импортом или в любое время после этого в рамках операций Day-2.

Одна важная вещь, которую следует помнить при использовании инструмента импорта VCF для установки NSX на преобразованный или импортированный домен рабочих нагрузок, заключается в том, что виртуальные сети и логическая маршрутизация не настраиваются в процессе установки NSX. Инструмент импорта устанавливает NSX и настраивает распределенные группы портов в NSX Manager. Это позволяет начать использовать распределенный межсетевой экран NSX для защиты развернутых рабочих нагрузок. Однако для того, чтобы воспользоваться возможностями виртуальных сетей и логического переключения, предоставляемыми NSX, требуется дополнительная настройка, так как вам нужно вручную настроить туннельные эндпоинты хоста (TEPs).

Использование инструмента импорта VCF для синхронизации изменений с сервером vCenter

Помимо возможности импортировать существующую инфраструктуру vSphere в Cloud Foundation, инструмент импорта также предоставляет функцию синхронизации, которая позволяет обновлять менеджер SDDC с учетом изменений, внесенных в инвентарь сервера vCenter, что помогает поддерживать согласованность и точность всей среды.

При управлении инфраструктурой vSphere, которая является частью частного облака Cloud Foundation, могут возникнуть ситуации, когда вам потребуется внести изменения непосредственно в среду vSphere. В некоторых случаях изменения, сделанные непосредственно в инвентаре vCenter, могут не быть захвачены менеджером SDDC. Если инвентарь менеджера SDDC выйдет из синхронизации с инвентарем vCenter, это может временно заблокировать некоторые рабочие процессы автоматизации. Чтобы избежать этого, вы запускаете инструмент импорта CLI с параметром «sync», чтобы обновить инвентарь менеджера SDDC с учетом изменений, внесенных в конфигурацию vCenter.