Современные задачи искусственного интеллекта (AI) и машинного обучения (ML) требуют высокопроизводительных решений при минимизации затрат на инфраструктуру, поскольку оборудование для таких нагрузок стоит дорого. Использование графических процессоров NVIDIA в сочетании с технологией NVIDIA AI Enterprise и платформой VMware Cloud Foundation (VCF) позволяет компаниям...
На конференции 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 для нескольких серверов, включая:
Улучшения в проектировании переменных 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 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, но основные моменты освещены в статье ниже.
Важная особенность: одна плитка (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, загрузив систему в 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 на нашу модифицированную версию.
Примечание: Этот шаг необходим, потому что, если вы просто скопируете модифицированный файл state.tgz напрямую на USB-устройство физического хоста ESXi, вы обнаружите, что система восстановит оригинальный файл state.tgz, даже если на обоих разделах содержится модифицированная версия.
Шаг 8 — Сделайте remove (не удаляйте) VMDK файл вложенной виртуальной машины ESXi с виртуальной машины Linux, затем включите вложенную виртуальную машину ESXi.
После успешной загрузки вложенной виртуальной машины ESXi, она теперь работает с оригинальным файлом encryption.info с нашего физического хоста ESXi, что позволит нам восстановить исходный файл state.tgz.
Шаг 9 — Скопируйте исходный файл state.tgz, созданный на Шаге 2, во вложенную виртуальную машину ESXi, поместите его в каталог /tmp/state.tgz и выполните следующую команду, которая теперь позволит нам расшифровать файл state.tgz с физического хоста ESXi, как показано на скриншоте ниже!
cd /tmp
tar -zxvf state.tgz
rm -f state.tgz
crypto-util envelope extract --aad ESXConfiguration local.tgz.ve local.tgz
rm -f local.tgz.ve
Шаг 10 — После расшифровки исходного файла state.tgz у нас должен появиться файл local.tgz, который мы извлечем локально в каталоге /tmp, выполнив следующую команду:
tar -zxvf local.tgz
Следующие три каталога: .ssh, etc/ и var/ будут размещены в /tmp, а /tmp/var/lib/vmware/configstore/backup/current-store-1 — это хранилище конфигурации ESXi для физического хоста ESXi, которое нам нужно обновить и заменить оригинальный хеш пароля root на желаемый, чтобы мы могли войти в систему.
Для непосредственного изменения хранилища конфигурации ESXi нам необходимо использовать утилиту sqlite3, так как файл хранится в виде базы данных sqlite3. Мы можем выполнить следующую команду на вложенной виртуальной машине ESXi, чтобы проверить текущий хеш пароля root:
/usr/lib/vmware/sqlite/bin/sqlite3 /tmp/var/lib/vmware/configstore/backup/current-store-1 "select * from config where Component='esx' and ConfigGroup = 'authentication' and Name = 'user_accounts' and Identifier = 'root'"
Шаг 11 — Вам потребуется новый хеш пароля в формате SHA512, где вы знаете сам пароль, после чего выполните следующую команду, заменив хеш.
/usr/lib/vmware/sqlite/bin/sqlite3 /tmp/var/lib/vmware/configstore/backup/current-store-1 "update config set UserValue='{\"name\":\"root\",\"password_hash\":\"\$6\$s6ic82Ik\$ER28x38x.1umtnQ99Hx9z0ZBOHBEuPYneedI1ekK2cwe/jIpjDcBNUHWHw0LwuRYJWhL3L2ORX3I5wFxKmyki1\",\"description\":\"Administrator\"}' where Component='esx' and ConfigGroup = 'authentication' and Name = 'user_accounts' and Identifier = 'root'"
Примечание: Вам нужно правильно экранировать любые специальные символы, например, как в приведенном выше примере, где хеш пароля содержит символ "$". Чтобы убедиться, что замена хеша выполнена правильно, вы можете выполнить вышеуказанную команду запроса, чтобы убедиться, что вывод соответствует желаемому хешу пароля, как показано на скриншоте ниже.
Шаг 12 — Теперь, когда мы обновили хранилище конфигурации ESXi с нашим желаемым паролем root, нам нужно заново создать файл state.tgz, который будет содержать наши изменения, выполнив следующие команды:
rm -f local.tgz
tar -cvf /tmp/local.tgz .ssh/ etc/ var/
tar -cvf /tmp/state-recover.tgz encryption.info local.tgz
Скопируйте файл /tmp/state-recover.tgz с вложенной виртуальной машины ESXi на вашу виртуальную машину с Linux, которая затем будет использоваться для монтирования носителя физического хоста ESXi, чтобы заменить файл state.tgz на нашу восстановленную версию.
Шаг 13 — Смонтируйте носитель физического хоста ESXi на вашу виртуальную машину с Linux. Поскольку физический хост ESXi установлен на USB, можно просто подключить USB-устройство напрямую к виртуальной машине с Linux.
Снова мы можем убедиться, что виртуальная машина с Linux видит носитель с установленным физическим хостом ESXi, выполнив команду fdisk -l, и мы должны увидеть два раздела bootbank (5 и 6), как показано на скриншоте ниже.
Шаг 14 — Теперь нам просто нужно смонтировать раздел bootbank и заменить оригинальный файл state.tgz на нашу модифицированную версию (state-recover.tgz).
Примечание: Поскольку физический хост 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 у вашего процессора, нужно выполнить следующую команду:
Чтобы решить проблему на уровне процессора (виртуальной машины), нужно отмаскировать некоторые флаги в наборе инструкций CPU. Вы также можете решить проблему и на уровне приложений (для этого обратитесь к KB, указанной выше).
Итак, нужно добавить в Advanced Configuration Parameters виртуальной машины следующие строчки для проблемных инструкций AVX-512:
Сделать это можно и через интерфейс 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 предоставляет мощные инструменты для защиты рабочих нагрузок от небезопасных протоколов, предотвращая эксплуатацию уязвимостей, боковое перемещение злоумышленников в сети и утечку данных. В видео выше демонстрируется, как можно комбинировать функции брандмауэра и системы предотвращения вторжений для обеспечения всесторонней безопасности корпоративной инфраструктуры.