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

Раньше DRS был сфокусирован на выравнивании нагрузки на уровне всего кластера хостов ESXi в целом (на базе расчета стандартного отклонения по производительности), то есть бралась в расчет загрузка аппаратных ресурсов каждого из серверов ESXi, на основании которой рассчитывались рекомендации по миграциям vMotion виртуальных машин. Теперь же механизм запускается каждую минуту, а для генерации рекомендаций используется механизм VM DRS Score (он же VM Hapiness), отражающий удовлетворение потребности виртуальной машины в свободных ресурсах.

В документе "Load Balancing Performance of DRS in vSphere 7.0" компания VMware наглядно демонстрирует ситуации в которых новый DRS отрабатывает лучше старого. Давайте на них посмотрим.

Пример 1 - хост с отклонением нагрузки от большинства

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

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

Пример 2 - неравномерная загрузка хостов в кластере

В старом DRS был порог по дисбалансу в кластере, и если он не превышен - то механизм балансировки не запускался. Это могло приводить к образованием групп хостов с разными уровнями средней загрузки процессора и памяти:

В ситуации с новым DRS ситуация в итоге, опять-таки, получается более справедливая:

Также полезной оказывается метрика DRS Score (она же VM Hapiness), которая формируется из 10-15 главных метрик машин. Основные метрики из этого числа - Host CPU Cache Cost, VM CPU Ready Time, VM Memory Swapped и Workload Burstiness.

Если все машины чувствуют себя "комфортно" на всех хостах, то DRS Score оказывается максимальным:

Если подать нагрузку на пару хостов ESXi, то их средний DRS Score падает, а на дэшборде указывается число машин, для которых рассчитаны низкие уровни DRS Score:

После того, как DRS обработает эту ситуацию, нагрузка на хосты выравнивается, а значение DRS Score увеличивается:

В документе еще много чего интересного - читайте.

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

Что это значит для администраторов?

Переход на Continuous Beta означает, что обновленные билды с новыми фичами vSphere будут выкладываться и обновляться на VMware Communities по ссылке выше постоянно, без длинных промежутков между ними.

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

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

Ну и самое главное - новая бета-версия VMware vSphere уже ждет вас на портале программы. Переходите по этой ссылке, чтобы зарегистрироваться в VMware vSphere Continuous Beta Program.

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

1. Обновился мобильный клиент vSphere Mobile Client до версии 1.13

Тут появилось не так много нового, но все же:

• Страница информации о датасторе - Datastore details page (туда можно перейти со страницы виртуальной машины)
• Исправлена ошибка с соединением к консоли ВМ отдельного хоста ESXi
• Исправлена ошибка, возникавшая при переключении между серверами

Скачать vSphere Mobile Client 1.13 можно по этой ссылке. О прошлой версии можно почитать у нас тут.

2. Обновилось средство App Volumes Entitlement Sync до версии 4.1

Оно позволяет прочитать, сравнить и синхронизировать права доступа к объектам между экземплярами App Volumes на географически разделенных площадках. После аутентификации на обеих площадках вы сможете выбрать права доступа, которые надо сравнить или синхронизировать.

Из нового:

• Можно получить версию App Volumes через API с возможностью получения номера билда
• Версия App Volumes 2006 и более поздняя имела проблему с Entitlement Sync 4.0 при возвращении строкового значения

Скачать App Volumes Entitlement Sync 4.1 можно по этой ссылке. Напомним, что про предыдущую версию Entitlement Sync 4.0 мы рассказывали вот тут.

3. Новая версия Power vRA Cloud 1.3

Напомним, что это средство позволяет отобразить сложное множество программных интерфейсов VMware vRealize Automation Cloud API в простой набор функций PowerShell. 

Что появилось нового:

• 4 новых командлета для VMC (VMware Cloud)
• 5 новых командлетов для AWS
• Поддержка Powershell 7 on Windows
• Исправления ошибок

Скачать Power vRA Cloud 1.3 можно по этой ссылке. О возможностях версии 1.1 можно почитать у нас вот тут.

Компания NAKIVO, выпускающая решения для резервного копирования и защиты данных виртуальной инфраструктуры, выпустила новую версию продукта NAKIVO Backup & Replication v10. Напомним, что мы писали о версии NAKIVO B&R 7.2 почти три года назад. С тех пор функциональность продукта существенно улучшилась, и это теперь полноценное Enterprise-решение.

Давайте посмотрим, что нового появилось в десятой версии NAKIVO Backup & Replication:

• Поддержка vSphere 7 - теперь эта платформа полностью поддерживается одновременно с поддержкой и более ранних версий. Администраторы могут получить все новые возможности обновленной платформы, включая резервное копирование, репликацию, гранулярное восстановление и функции disaster recovery.
• Резервное копирование в хранилища Wasabi Hot Cloud Storage - теперь создание бэкапов в блочном облачном хранилище полностью поддерживается со стороны NAKIVO B&R v10. Напрямую в облако Wasabi можно передавать резервные копии виртуальных машин, физических серверов, баз данных Oracle, а также инстансы Amazon EC2. При мгновенном прямом восстановлении поддерживаются не только виртуальные машины, но и файлы и папки, а также объекты приложений.
• Восстановление Physical-to-Virtual (P2V) - теперь с помощью десятой версии NAKIVO вы можете перенести свои физические машины в виртуальную среду. Создание виртуальной машины происходит через легковесные агенты в физических ОС. Также можно и восстанавливать резервные копии физических систем напрямую в облако.
• Бэкап десктопов Linux - теперь можно производить резервное копирование рабочих станций с Ubuntu Linux на борту так же, как это делается и для физических серверов. Все операции делаются в едином дэшборде.
• Улучшения пользовательского интерфейса - централизованный дэшборд теперь позволяет контролировать все аспекты резервного копирования и более интуитивно выполнять операции.

Скачать NAKIVO Backup & Replication v10 можно по этой ссылке.

Некоторые из вас знают, что есть такое решение VMware vRealize Network Insight (vRNI), которое предназначено для мониторинга и защиты сетевой инфраструктуры виртуальной среды VMware vSphere.

Администраторам виртуальной инфраструктуры часто приходится делать копии различных ее управляющих компонентов, в том числе vRNI. Сейчас VMware рекомендует делать резервную копию конфигурации vRNI на уровне всей виртуальной машины (см. KB 55829). Рекомендуется выключить ВМ с vRNI, скопировать ее целиком, а потом включить снова - это единственный поддерживаемый способ на данный момент.

Martijn Smit опубликовал интересный пост о том, что на самом деле у vRNI есть способ резервного копирования и восстановления конфигурации через API, для которого есть специальный API endpoint по пути /settings/backup:

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

Используя API endpoint /api/ni/settings/backup, вы можете создать резервную копию конфигурации vRNI и перенаправить ее по SSH или FTP на бэкап-сервер в виде tar-файла со следующим содержимым:

Большинство этих файлов человекочитаемы, если вы откроете их в текстовом редакторе. Там находятся копии настроек приложений, объектов pinboards, data sources, сохраненный поиск, системные настройки (Syslog, SMTP и т.п.), пользовательские конфигурации и многое другое.

Для работы с конфигурациями vRNI через API Martijn сделал модуль PowervRNI. Вот пример использования сценария резервного копирования:

PS # $backupSchedule = @{ "enable" = $true; "schedule_period" = "DAILY"; "minute" = 30; "hour" = 12; "day_of_week" = 1 }

  PS # $sshServer = @{ "server_address" = "my-ssh-server"; "port" = 22; "username" = "vrni-backups"; "password" = "VMware1!"; "backup_directory" = "/home/vrni-backups/"; "backup_file_name" = "vrni-backup.tar" }

PS # Set-vRNIBackup -RunNow $true -BackupSchedule $backupSchedule -SSHServer $sshServer
config_filter

  -------------

  @{applications=True; snmp=True; smtp=True; data_sources=True; analytics_thresholds=True; analytics_outliers=True; events=True; syslog=True; pinboards=True; ldap=True; vidm=True; user_data=True; user_preferences=True; physical_subnet_v…
PS # Get-vRNIBackupStatus
status status_updated_timestamp

  ------ ------------------------

  IN_PROGRESS 1595425176027 Smit

  PowervRNI
  

Переменная $backupSchedule содержит в себе расписание резервного копирования, в примере выше она установлена на 12:30 (формат 24h) каждого дня.

Источник.

На сайте проекта VMware Labs обновилась утилита Horizon Reach до версии 1.1, которая позволяет проводить мониторинг и алертинг для развертываний VMware Horizon на площадках заказчиков (только в реальном времени, без исторических данных). Horizon Reach предназначен для тех окружений VMware Horizon, которые образуются в крупных компаниях на уровне площадок (Pod) в рамках концепции Cloud Pod Architecture как отдельный домен отказа (либо где площадки изолированы, но хочется иметь доступ к мониторингу в моменте из одной точки).

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

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

• Теперь утилитой можно напрямую мониторить компоненты Unified Access Gateways, также доступны функции скачивания конфигурации и логов
• Пользовательские сессии можно просматривать в рамках следующих представлений:
  • Pools
  • Farms
  • Unified Access Gateways
  • Global Entitlements
  • Global Application Entitlements
• Алармы были полностью переработаны, чтобы поддерживать отправку нотификаций в следующие каналы:
  • SMTP
  • Slack
  • Сторонние средства через сценарии PowerShell
• LDAP-интеграция алармов поддерживает кириллицу
• Улучшенный дэшборд алармов
• Обновления vCenter:
  • Хосты теперь видимы, и для них отслеживается производительность
  • Датасторы теперь видимы, показано свободное пространство
  • Кастеры теперь видимы, для них доступны различные представления - пулы, фермы и т.п. Также можно использовать интеграцию PowerShell и API
• Профили vGPU теперь показаны в представлении пулов
• Множество исправлений ошибок

Скачать VMware Horizon Reach 1.1 можно по этой ссылке.

Возможно, некоторые администраторы VMware vSphere попадали в ситуацию, когда один из датасторов в виртуальной инфраструктуре оказывался не привязанным ни к какому хосту ESXi, но при этом у него также была неактивна опция Delete Datastore из контекстного меню:

Paul Braren написал полезную инструкцию у себя в блоге о том, как решить эту проблему.

Такой зомби-датастор можно удалить только из базы данных vCenter Server Appliance (vCSA), поэтому вы полностью должны быть уверены в том, что он не используется никаким из хостов, а также в том, что он не презентует никакое физическое устройство в вашей инфраструктуре.

Первое что вам надо сделать - это включить доступ к vCSA по SSH (картинки - отсюда):

Далее нужно зайти по SSH на vCSA, запустить там шелл командой shell и далее запустить утилиту psql для работы с базой данных следующей командой:

/opt/vmware/vpostgres/current/bin/psql -d VCDB -U postgres

После этого нужно найти id датастора следующей командой:

Когда вы нашли id, нужно удалить упоминание об этом датасторе из таблиц базы данных vCSA следующими командами:

DELETE FROM vpx_ds_assignment WHERE ds_id=3089;
DELETE FROM vpx_datastore WHERE id=3089;
DELETE FROM vpx_vm_ds_space WHERE ds_id=3089;

При выполнении второй операции вы получите следующую ошибку:

ERROR: update or delete on table "vpx_datastore" violates foreign key constraing "fk_vpxspace"
DETAIL: Key (id)=(3089) is still referenced from table "vpx_vm_ds_space".

Не обращайте на нее внимания и выполняйте третью. Затем нужно перезагрузить vCSA и снова выполнить второй DELETE, который в этот раз должен завершиться успешно. После этого датастор пропадет из списка в vSphere Client.

Помните, что выполняя данную операцию, вы должны понимать, что именно делаете:)

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

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

Для предотвращения подобных типов угроз есть такие специализированные средства, как VMware Carbon Black, vRealize Log Insight и vRealize Network Insight, но базовые требования информационной гигиены нужно соблюдать и на уровне гостевых систем.

На этом уровне важной составляющей является пакет VMware Tools, имеющий широкие возможности доступа к виртуальной машине - ОС и приложениям. Управление поведением тулзов происходит с помощью вот этих утилит:

• C:\Program Files\VMware\VMware Tools\VMwareToolboxCmd.exe (Windows)
• /usr/bin/vmware-toolbox-cmd (Linux)

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

И вот тут рекомендуется принять во внимание следующие факторы на уровне VMware Tools:

1. Отключить синхронизацию времени с хостом VMware ESXi

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

VMwareToolboxCmd.exe timesync disable

2. Отключить автообновление VMware Tools

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

VMwareToolboxCmd.exe config set autoupgrade allow-upgrade false
VMwareToolboxCmd.exe config set autoupgrade allow-add-feature false
VMwareToolboxCmd.exe config set autoupgrade allow-remove-feature false

3. Отключить возможность кастомизации ОС при клонировании

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

VMwareToolboxCmd.exe config set deployPkg enable-customization false

4. Контроль над информацией, предоставляемой через Appinfo

Об интерфейсе Appinfo мы писали вот тут (он же Application Discovery). Он позволяет, например, собирать информацию о запущенных приложениях внутри гостевой системы (по умолчанию сбор идет каждые 30 минут, это настраивается). 

Отключить Appinfo в виртуальной машине можно следующей командой VMware Tools:

VMwareToolboxCmd.exe config set appinfo disabled true

5. Отключить Guest Operations (оно же Invoke-VMScript)

Командлет Invoke-VMScript - это мощный механизм для разработчиков, позволяющий работать с гостевой системой виртуальной машины со стороны механизма сценариев PowerCLI. Очевидно, что этот интерфейс расширяет поверхность потенциальной атаки, и если вы им не пользуетесь, то его лучше отключить. Делается это следующей командой:

VMwareToolboxCmd.exe config set guestoperations disabled true

6. Отключение ненужных компонентов

Это базовое правило - чем меньше компонентов VMware Tools у вас установлено, тем меньше вероятность, что через какой-то из них произойдет атака. Например, не всем пользователям и администраторам нужны такие возможности, как Service Discovery, AppDefense и Shared Folders. Но здесь, очевидно, нужно соблюдать разумный баланс - не надо отключать что-то нужное, о чем вы потом будете думать: "почему оно не работает?".

Подробнее об отключении компонентов VMware Tools при развертывании через утилиту командной строки написано тут.

На днях компания VMware выпустила обновление своего решения для мониторинга и защиты сетевой инфраструктуры виртуальной среды VMware vRealize Network Insight 5.3. О версии vRNI 5.1, анонсированной на VMworld 2019, мы писали вот тут.

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

Давайте посмотрим, что нового появилось в vRNI 5.3:

1. Новые возможности VMware SD-WAN (бывшие технологии VeloCloud)

Появилась новая диаграмма Flow visibility, показывающая распределение потоков, рождающихся на уровне SD-WAN Edge и дальше уходящих на уровень интернета:

Также можно выставить фильтр на уровне клиентских IP (чтобы видеть трафик конкретных клиентов), а также на уровнях Flow Path, приложения и Destination Edge.

Кроме этого, появилась диаграмма End-to-end путей в разрезе потоков и конфигураций:

Теперь можно визуализовать путь трафика для конкретного потока между конечными точками клиентов (flow based). А еще можно сделать диаграмму и на уровне сетевой конфигурации, которая у вас настроена (config based).

2. Интеграции с NSX-T

В этом плане появились дополнительные возможности по измерению различных типов задержек в сети (latency): vNIC to vNIC, pNIC to vNIC, VTEP to VTEP.

Помимо этого, была добавлена поддержка продуктов NSX-T 3.0 и NSX-T в облаке VMware Cloud on AWS, а также поддержка TCP Retransmission (отслеживание приложений, испытывающих проблемы с повторной передачей TCP-трафика в случае неудачной первой доставки).

Вот тут показаны TCP retransmissions на базе потоков:

3. Улучшение поддержки сетевого оборудования

Была добавлена поддержка устройств HP Enterprise FlexFabric 5940 и FlexNetwork 10500. Также добавили коммутаторы Mellanox серий SN2100 и SN2410.

4. Прочие улучшения

В целом, было сделано множество небольших улучшений и нововведений, вот основные из них:

• Важные сообщения от устройств Arista соотносятся с самим устройством (Port down, проблемы Fan & PSU и другое)
• Метрика Quality of Experience на уровне туннеля для SD-WAN Edge.
• На дэшборде SDDC теперь есть представление VMware Cloud on AWS Direct Connects.
• Security Planner был оптимизирован для больших инсталляций и теперь обрабатывает большие объемы данных корректно.
• Виртуальный модуль Collector теперь может обрабатывать до 35 000 виртуальных машин на одном сервере vCenter.

Скачать VMware vRealize Network Insight 5.3 можно по этой ссылке. Release Notes доступны тут.

Некоторые функции vCloud Director (VCD) по работе с виртуальными машинами по-прежнему недоступны через стандартные командлеты PowerCLI, поэтому к ним необходимо обращаться через VCD API.

Jon Waite в своем блоге опубликовал PowerCLI-сценарий, с помощью которого можно обратиться к VCD API и увеличить размер загрузочного диска ВМ. Надо сказать, что при подобного рода манипуляциях (как увеличение, так и уменьшение диска) всегда есть риск потери данных, поэтому обязательно сделайте резервную копию.

Собственно, сам скрипт (исходник доступен тут):

Комментарии от автора:

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

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

PS /> $VM = Get-CIVM -Name 'TestVM01'
PS /> $VM | Update-CIVMBootDisk -NewSizeMB 2048
Disk resize for VM TestVM01 submitted successfully.

На днях компания VMware обновила свое решение для распространения готовых к использованию приложений VMware ThinApp посредством подключаемых виртуальных дисков к машинам. Теперь App Volumes 4.1 (она же официально версия 2006) может работать еще и в облачной среде Horizon Cloud on Azure (подробнее об этом здесь).

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

• При изменении назначений (assignments) возникает диалоговое окно с обзором изменений, которые будут сделаны. Если они обновляются, то теперь не требуется удалять прошлые назначения, они просто обновляются.
• Администраторы могут ограничить доставку пакетов приложений на компьютеры с определенным префиксом в имени машины.
• App Volumes Manager теперь позволяет использовать единый рабочий процесс для сторонних пакетов и запускать их параллельно с нативными. Пакеты MSIX с привязанными VHD можно использовать средствами утилиты App Volumes Packaging Utility.
• Поддержка LDAP Channel Binding and LDAP Signing.
• Изменение версионирования - теперь это не номер версии 4.1, а год и месяц, то есть текущая версия - 2006. Для агента и App Volumes Manager версия 4.1 останется.
• Улучшения производительности при логине пользователя.
• Функции rolling upgrade опять вернулись - теперь можно обновить один из App Volumes Manager, когда остальные продолжают работать.
• Добавлена поддержка Microsoft Office 2019, Microsoft SQL Server 2019 и Microsoft Windows 10, version 2004.
• Обновления документации.

Скачать VMware App Volumes 2006 можно по этой ссылке.

При описании новых возможностей VMware vSphere 7 мы рассказывали о функциях платформы, появившихся в результате приобретения VMware компании Bitfusion. Эти возможности позволяют оптимизировать использование графических процессоров GPU в пуле по сети, когда vGPU может быть частично расшарен между несколькими ВМ. Это может применяться для рабочих нагрузок задач AI/ML (например, для приложений, использующих PyTorch и/или TensorFlow).

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

Технология эта называлась FlexDirect, теперь это продукт vSphere Bitfusion:

На днях это продукт стал доступен для загрузки и использования в онпремизных инфраструктурах.

Ключевыми особенностями vSphere Bitfusion являются:

• Возможность динамической привязки GPU к любой машине в датацентре, по аналогии с тем, как вы привязываете к ней хранилище.
• Возможность использования ресурсов GPU как одной машине, так и разделения его между несколькими. При этом администратор может выбрать, какой объем Shares выделить каждой из машин, то есть можно приоритизировать использование ресурсов GPU между потребителями.
• Возможность предоставления доступа как по TCP/IP, так и через интерфейс RDMA, который может быть организован как подключение Infiniband или RoCE (RDMA over Converged Ethernet). О результатах тестирования такого сетевого взаимодействия вы можете почитать тут.
• Передача инструкций к серверным машинам и обратно на уровне CUDA-вызовов. То есть это решение не про передачу содержимого экрана как VDI, а про высокопроизводительные вычисления.
• Прозрачная интеграция - с точки зрения приложений менять в инфраструктуре ничего не нужно.

Для управления инфраструктурой доставки ресурсов GPU используется продукт vSphere Bitfusion Manager, который и позволяет гибко распределять ресурсы между потребителями. Раньше он выглядел так:

Теперь же он интегрирован в vSphere Client как плагин:

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

С точки зрения лицензирования, решение vSphere Bitfusion доступно как аддон для издания vSphere Enterprise Plus и лицензируется точно так же - по CPU. Для других изданий vSphere, увы, этот продукт недоступен.

Скачать vSphere Bitfusion можно по этой ссылке. Документацию можно найти на странице продукта. Также Bitfusion интегрирован с инфраструктурой vSphere with Kubernetes, о чем можно почитать вот в этом документе.

Те, кто следит за обновлениями ресурса VMware Labs, знают, что там часто появляются всякие полезности для решения VMware App Volumes. Например, App Volumes Entitlement Sync позволяет прочитать, сравнить и синхронизировать права доступа к объектам между экземплярами App Volumes на географически разделенных площадках, а App Volumes Migration Utility дополняет средства App Volumes по облегчению жизни администраторов, занимающихся обслуживанием решения.

На днях вышла еще одна полезная штука - App Volumes Packaging Utility. Она, как ясно из названия, позволяет упаковывать приложения. С помощью нее можно добавить необходимые метаданные в приложение MSIX на базе дисков VHD таким образом, чтобы их можно было использовать вместе с пакетами формата AV. Получившиеся VHD формата MSIX будут требовать App Volumes 4 версии 2006 или более поздней, а также Windows 10 версии 2004 или более поздней.

Формат использования утилиты таков:

AppCapture.exe /addmeta <msixvhdfilepath> /msix <packagerootpath>

В итоге в папке с VHD вы получите .json-файл с таким же именем, который позволит импортировать MSIX-приложение в App Volumes Manager:

Скачать App Volumes Packaging Utility можно по этой ссылке. Инструкции по использованию доступны здесь.

Как многие из вас знают, совсем недавно Veeam выпустила обновление своей главной платформы для обеспечения доступности виртуальных датацентров Veeam Availability Suite v10 (мы писали о его новых возможностях здесь). Особенно много нового появилось в новой версии Veeam Backup and Replication v10.

Сегодня, 9 июля, в 11:00 утра по Москве пройдет демо этого семейства продуктов на русском языке, где вы сможете позадавать свои вопросы. В рамках демонстрации вы получите подробный технический обзор возможностей новой версии Veeam Backup & Replication — ключевого компонента Veeam Availability Suite.

В ходе сессии системный инженер Veeam рассмотрит следующие темы:

• Эффективное резервное копирование NAS
• Механизм мгновенного восстановления ВМ нового поколения
• Резервные копии с защитой от программ-вымогателей

Приходите, будет интересно! Возможно несколько позже будет выложена запись вебинара.

Многие администраторы VMware vSphere знают, что иногда в виртуальной инфраструктуре может возникнуть ситуация APD (All Paths Down). Это состояние, когда хост-сервер ESXi не может получить доступа к устройству ни по одному из путей, а также устройство не дает кодов ответа на SCSI-команды. При этом хост не знает, в течение какого времени будет сохраняться такая ситуация.

Типичный пример - отказ FC-коммутаторов в фабрике или выход из строя устройства хранения. В этом случае хост ESXi будет периодически пытаться обратиться к устройству (команды чтения параметров диска) через демон hostd и восстановить пути. В этом случае демон hostd будет постоянно блокироваться, что будет негативно влиять на производительность. Этот статус считается временным, так как устройство хранения или фабрика могут снова начать работать, и работа с устройством возобновится.

При настройке механизма VMware vSphere HA на уровне кластера у вас есть следующие опции реагирования на такую ситуацию:

• Disable - ничего не делать с виртуальными машинами
• Issue Event - ничего не делать, но сгенерировать событие
• Power Off / Restart – Conservative
• Power Off / Restart – Aggressive

Последние два варианта - Conservative и Aggressive - не очень ясны. Отличие между ними заключается в том, что в консервативном (Conservative) сценарии механизм VMCP (VM Component Protection) сработает только тогда (выключит ВМ), когда убедится, что виртуальные машины могут быть перезапущены на других хостах кластера. В этом случае ESXi убеждается, что связь с другими хостами есть и у них есть доступ к хранилищу ВМ.

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

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

das.restartVmsWithoutResourceChecks = true

Источник.

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

Для этого нужно во время установки выбрать пункт "Upgrade ESXi, preserver VMFS datastore". Под датастором тут имеется в виду, что на нем сохранится предыдущая установка ESXi:

Кстати, как видно из скриншота, можно сделать и свежую установку ESXi с возможностью отката к предыдущей версии.

Сделать апгрейд на ESXi 7 с сохранением предыдущей версии платформы не выйдет - в VMware vSphere 7 поменялась структура разделов гипервизора ESXi.

Итак, вы сделали апгрейд ESXi, но что-то пошло не так. Например, ваше железо больше не поддерживается (к примеру, CPU), и вам надо сделать откат к прошлой версии ESXi. Для этого во время загрузки вам нужно нажать комбинацию клавиш Shift + <R>:

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

Также можно делать бэкап и восстановление конфигурации VMware ESXi - об этом рассказано в KB 2042141.

Компания VMware, учитывая обстоятельства всеобщей неопределенности, объявила о проведении ежегодной конференции VMworld 2020 в формате онлайн. Как все знают, VMworld - это главное событие года в области виртуализации, в этом году оно состоится в период с 29 сентября по 1 октября.

Главная новость, конечно же, в том, что VMworld 2020 Online - полностью бесплатен для всех желающих. Зарегистрироваться на него вы можете прямо сейчас.

Забесплатно вы получите:

• Блок Solutions Exchange - раздел с информацией от всех спонсоров и вендоров решений.
• Лабораторные работы Hands on Labs - одна из самых интересных частей мероприятия. Будут свежие лабы, и можно будет ознакомиться с интерфейсом новых продуктов онлайн.
• 500 сессий VMworld, доступных по запросу на портале мероприятия.
• 7 лайв-каналов непосредственно в даты конференции в режиме стриминга.

Кроме бесплатного билета, доступен также и платный за $299:

Помимо плюшек бесплатной версии, он включает в себя:

• Доступ к сессиям, где установлен лимит на подключения.
• Возможность поговорить с экспертами VMware в рамках roundtable sessions.
• Консультации с экспертами 1 на 1.
• Расширенный нетворкинг с участниками, игры и возможность выиграть призы.
• Скидка $100 на билет на VMworld 2021.
• Ваучер на экзамен на VMware Certified Professional (VCP), он будет доступен для покупки только во время регистрации (обычная цена экзамена - $250, то есть вы сэкономите $125).

Если вы никогда не были на VMworld, то за $0 в этом году вы, наконец-то, сможете принять в нем участие :)

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

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

Посмотрим, что нового в HCIBench 2.4:

• Исправлена частая ошибка при указании хоста во время развертывания
• Поддержка варианта запуска easy run для "растянутого" (stretched) кластера
• Исправлена ошибка в отображении таймзоны в PDF-отчете, также в отчет было добавлено немного полезной информации о vSAN
• Установка testname и testcase как переменных фреймворка Grafana
• Добавлена информация о CPU workload на страницу конфигурации модели fio
• Обновлен пакет rbvmomi - теперь он поддерживает vSphere 7.0+
• Улучшенные дашборды компонентов fio и vdbench graphite

Скачать HCIBench 2.4 можно по этой ссылке. Документация доступна тут.

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

• Intel Family 6, Model = 2C (Westmere-EP)
• Intel Family 6, Model = 2F (Westmere-EX)

Однако для тех, кому очень надо, компания VMware оставила небольшую возможность все-таки установить ESXi 7.0 на старом железе со старыми процессорами, но без каких-либо гарантий по работоспособности и поддержке (то есть, статус у этого режима - unsupported). В частности, коллеги написали статью об установке vSphere 7 на сервер IBM M3 X3550 Series.

Для начала решили ставить ESXi на USB-диск, так как RAID-контроллер сервера больше не поддерживается со стороны ESXi 7:

Далее при загрузке установщика ESXi с CD-ROM или ISO нужно нажать комбинацию клавиш Shift + <O> (это буква, а не ноль), после чего появится приглашение ко вводу. Надо ввести вот такую строчку в дополняемую строку:

allowLegacyCPU=true

Далее для установки выбрали USB-диск и начали установку ESXi на него:

После того, как ESXi установится на ваш сервер, вам нужно будет снова нажать Shift + <O> и повторно вбить указанный выше параметр при первом запуске:

Теперь нужно сделать так, чтобы данный параметр добавлялся при каждой загрузке ESXi. Сначала включим сервисы командной строки ESXi и удаленного доступа по SSH. Для этого нужно запустить службы TSM и TSM-SSH на хосте ESXi:

Далее подключаемся к ESXi по SSH и с помощью следующей команды находим файл конфигурации загрузки:

find / -name "boot.cfg

Далее добавляем в него параметр allowLegacyCPU=true в разделе kernelopt:

Два загрузочных модуля ESXi находятся в директориях /bootbank и /altbootbank. На всякий случай надо поменять boot.cfg в обеих директориях.

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

Ну и, собственно, сам сервер ESXi 7.0.0, нормально работающий на сервере IBM x3550 M3:

Бонусом шутка про редактор vi, которым редактировался файл boot.cfg:

Как вы знаете, в продуктовой линейке VMware есть два решения, предназначенных для виртуализации сетей и централизованного управления сетевым взаимодействием виртуальных машин на уровне всего датацентра - это продукты NSX-T и NSX-V.

NSX-T предназначен для гибридных окружений, как в смысле поддержки разных гипервизоров (ESXi и KVM), так и в плане поддержки облачных инфраструктур (например, AWS). Решение NSX-V разработано специально для виртуальной среды VMware vSphere и использует виртуальные коммутаторы vSphere Distributed Switch (vDS). Оба решения могут быть использованы под одной лицензией, что дает пользователям гибкость при выборе нужного типа развертывания.

(картинка отсюда)

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

Ну и вот обзорное видео об основных отличиях NSX-T и NSX-V:

Те из вас, кто следит за анонсами Apple, наверняка знают, что компания решила отказаться от процессоров Intel в новом поколении компьютеров Mac, включая MacBook. Процессоры, разработанные компанией Apple, будут созданы на базе ARM-архитектуры, которая откроет возможности по увеличению производительности, уменьшению использования батареи и перспективы совместимости приложений между устройствами Apple других форм-факторов (телефоны и планшеты) без каких-либо изменений со стороны разработчиков. С точки зрения ОС, это все будет имплементировано в следующем поколении операционных систем, начиная с macOS Big Sur.

Но для нас в этой новости главное вот что - из-за смены архитектуры Intel на собственную ARM-платформу Apple перестанут работать решения для виртуализации настольных ПК VMware Fusion и Parallels Desktop, обеспечивающие работу виртуальных машин с гостевыми ОС Windows.

Не секрет, что пользователи Mac и MacBook все меньше и меньше пользуются Windows в ежедневной работе, ну а такой переход, возможно, и вовсе принудительно отменит ставшую уже небольшой необходимость.

В новой ОС для маков будет присутствовать решение по трансляции кода Rosetta 2, которое будет обеспечивать работоспособность x86/x64-приложений на базе архитектуры Apple. Но - за исключением платформ виртуализации VMware и Parallels, которые используют довольно много расширенных возможностей процессоров Intel.

Кроме того, не будет работать и механизм двойной загрузки операционной системы Boot Camp.

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

На сайте проекта VMware Labs очередное обновление - новая версия утилиты vSphere Software Asset Management Tool 1.2. Напомним, что средство vSAM предназначено для сбора подробной информации об инсталляции VMware vSphere на вашей площадке, касающуюся лицензий - инвентаря и доступных лицензий. О прошлой версии vSAM мы писали вот тут (там появилась поддержка vSphere 7).

Посмотрим на новые возможности vSAM 1.2:

• Отображение в отчете информации об инфраструктуре кластеров хранилищ vSAN
• Можно открытым текстом выводить лицензионные ключи в отчете, если выставлена соответствующая опция
• В отчет добавлена таблица License Inventory

Скачать vSphere Software Asset Management Tool 1.2 можно по этой ссылке.

Если вы следите за обновлениями VMware vSphere 7, то наверняка знаете, что не так давно уже выходили минорные обновления vCenter 7.0 Update 0a и vSphere with Kubernetes.

На днях VMware выпустила еще один небольшой апдейтик - vCenter 7.0.0b (на момент написания заметки дистрибутив еще недоступен для скачивания).

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

• Новые алармы: vCenter Server 7.0.0b получил еще один аларм для vCenter Server Appliance, который срабатывает в случае, когда состояние репликации меняется на READ_ONLY. Аларм гасится, если состояние возвращается в Normal. С помощью этого аларма легко обнаружить проблемы в репликации между узлами vCenter на одной или нескольких площадках.
• C vCenter Server 7.0.0b можно использовать кнопку "Show only rollup updates", позволяющую отфильтровать и выбрать патчи, которые вы хотите включить в бейслайн для vSphere Lifecycle Manager. Кнопка доступна на вкладке Updates панели Lifecycle Manager. Также эта опция доступна в мастере создания нового бейслайна.
• Решено несколько проблем и исправлены некоторые ошибки. Посмотреть информацию о них можно тут.
• Про обновления движка VMware vSphere with Kubernetes рассказано здесь.

Скачать VMware vCenter 7.0.0b в составе vSphere 7 можно по этой ссылке.

Мы уже очень много писали о нововведениях VMware vSphere 7, но все еще есть о чем рассказывать. Не так давно мы говорили об улучшениях горячей миграции виртуальных машин vMotion в ESXi 7 (и тут), а сегодня посмотрим, как был улучшен механизм горячей миграции хранилищ Storage vMotion.

При миграциях SVMotion используется техника Fast Suspend and Resume (FSR), которая очень близка к vMotion, но не идентична ему. При горячей миграции хранилища ВМ происходит создание теневой копии этой машины на том же хосте ESXi, куда подцепляются новые хранилища или устройства, после чего происходит копирование метаданных памяти и состояния устройств от исходной ВМ к целевой. В этот момент машина "замирает" примерно на 1 секунду, а затем происходит включение уже целевой ВМ, а исходная ВМ выключается и удаляется:

Такая же методика применяется и для механизма Hot Add / Remove, который позволяет добавлять и удалять устройства виртуальной машины "на горячую" без необходимости ее выключения. Для выключенной ВМ добавление и удаление устройств - это лишь изменения в конфигурационном файле VMX.

Сам процесс FSR в целом работал довольно неплохо для небольших виртуальных машин, а прерывание работы ВМ укладывалось, как правило, в одну секунду. Но для больших машин (Monster VM) процесс копирования метеданных памяти мог занять продолжительное время.

Во время приостановки ВМ происходит копирование блоков памяти Page Frames (PFrames), представляющих собой маппинги между виртуальной памятью машины и физическими адресами Machine Page Numbers (MPN).

Эти блоки и нужно скопировать во время паузы FSR:

До VMware vSphere 7 во время копирования метаданных памяти использовался только один vCPU машины, в то время как остальные процессоры ВМ ждали окончания процесса и простаивали:

Очевидно, что для больших машин с большим объемом памяти и числом vCPU процесс работал неоптимально. В VMware vSphere 7 для копирования блоков PFrame используются все vCPU. Метаданные памяти разделяются на сегменты, и за копирование каждого сегмента отвечает свой виртуальный процессор. Сам процесс копирования происходит в параллельном режиме, что существенно экономит время на копирование:

Для обычных ВМ это улучшение вряд ли получится почувствовать на практике, но если вы используете Monster VMs, то эффект от обновленного FSR можно будет заметить. Например, VMware взяла машину с 1 ТБ памяти и 48 vCPU, которую перемещала под нагрузкой с помощью Storage vMotion. Так вот время переключения со старым FSR составило 7.7 секунды, а с новым - около 0.5 секунды для VMware vSphere 7:

Многие из вас знают, что в решении для организации отказоустойчивых кластеров хранилищ VMware vSAN есть функции дедупликации и сжатия данных (deduplication and compression, DD&C). С помощью этих функций можно более эффективно использовать ярус хранения данных виртуальных машин (Capacity Tier). О некоторых аспектах применения дедупликации и сжатия данных в vSAN мы рассказывали вот тут, а сегодня поговорим об их общем влиянии на производительность дисковой подсистемы.

Как знают администраторы vSAN, это решение использует двухъярусную архитектуру, создающую оптимальное соотношение цена/качество для хранилищ ВМ - на Cache Tier, собранном из дорогих SSD-дисков (быстро работающих на дисках), размещается Write Buffer и Read Cache, а на дешевых SSD/HDD-дисках - постоянные данные виртуальных машин.

Механизм DD&C работает так - если он включен, то как только из Cache Tier виртуальной машине отправляется квитанция о записи данных, то может начаться процесс дестейджинга данных на Capacity Tier, во время которого сам механизм и вступает в действие. Сначала с помощью механики дедупликации в рамках дисковой группы (deduplication domain) находятся идентичные блоки размером 4 КБ и дедуплицируются, а затем блоки сжимаются. При этом, если блок сжимается менее, чем на 50%, то целевое хранилище записывается оригинал блока в целях быстрого доступа при чтении (без декомпрессии).

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

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

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

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

Такая двухъярусная система vSAN имеет 2 теоретических максимума:

• Max burst rate - возможность Cache Tier сбрасывать обработанные пакеты данных в сторону Capacity Tier
• Max steady state rate - установившаяся максимальная скорость записи данных на приемнике Capacity Tier

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

Если у вас идет дестейджинг данных с включенным DD&C, это потенциально может повлиять на производительность записи данных на Capacity Tier. При использовании DD&C снижается максимальная скорость записи данных на ярус постоянного хранения, так как перед этой записью должны быть выполнены операции дедупликации и сжатия.

Иными словами, кластер с включенным DD&C может давать такие же показатели качества обслуживания, как и кластер с более медленными устройствами в Capacity Tier, но с выключенным DD&C.

Логично ожидать, что при включенном DD&C буффер Write Buffer будет заполняться скорее, так как будут возникать задержки ожидания отработки DD&C. Но пока буффер полностью не заполнен - заметных просадок в производительности не будет. Очищаться также Write Buffer будет медленнее при включенном DD&C.

Также может измениться и время отсылки квитанции о записи (acknowledgment time, оно же write latency), которое увеличит latency для виртуальной машины. Это произойдет, если уже начался дестейджинг данных, а машина запрашивает ACK и ждет ответа с уровня буффера. Хотя в целом vSAN построен таким образом, чтобы как можно быстрее такой ответ дать.

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

Если вы также используете RAID 5/6 для кластеров vSAN, то совместно с техниками DD&C могут возникнуть серьезные эффекты с влиянием на производительность. Об этих аспектах подробно рассказано вот тут - обязательно ознакомьтесь с ними (см. также комментарий к статье).

По итогу можно сделать следующие выводы из этой схемы:

• Если вам хочется использовать DD&C, и вы видите, что у ВМ высокая latency - попробуйте более быстрые диски на Capacity Tier.
• Используйте больше дисковых групп, так как Buffer и его пространство hot working set используется на уровне дисковой группы. Две группы на хосте нужно минимум, а лучше три.
• Альтернативой DD&C могут стать устройства большой емкости - там просто все поместится).
• Используйте последнюю версию vSAN - алгоритмы работы с данными все время совершенствуются.
• Также помните, что RAID 5/6 также экономит место по сравнению с RAID1, что может стать альтернативой DD&C.

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

Компания VMware недавно выпустила интересную бесплатную книгу "Micro-segmentation for Dummies Guide, 2nd Edition".

Те из вас, кто использует решение для сетевой виртуализации и агрегации трафика VMware NSX и средство обеспечения сетевой безопасности vRealize Network Insight, знают о таком подходе как микросегментация. С помощью него можно управлять сетевыми политиками на базе контекстов приложений - сетевом (на уровне 7 модели OSI), пользовательском (ID, сессия RDSH и прочее), а также рабочей нагрузки (тэги, группы безопасности).

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

Из книжки вы узнаете:

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

Скачать книгу "Micro-segmentation for Dummies Guide, 2nd Edition" можно по этой ссылке.

Часто при создании отладочного пакета vCenter Appliance log bundle на сервере VMware vCSA (он нужен для техподдержки VMware и траблшутинга) администраторы сталкиваются с недостатком свободного места в разделе /storage/log. Это бывает даже, когда у вас есть 5 ГБ свободного места - да, логи в рамках одной выгрузки могут занимать и больше!

Чтобы найти прошлые логи и удалить их с сервера vCSA, нужно зайти на него по SSH и перейти в категорию /storage/log. Далее найти логи можно командой:

find . -iname *.tgz

В соответствующих папках будут лежать эти файлы журналов. Удалить их можно стандартной командой:

rm *.tgz

После этого нужно перезапустить управляющие службы vCSA:

service-control --stop --all
service-control --start --all

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

На сайте проекта VMware Labs обновилась полезная утилита VMware App Volumes Entitlement Sync до версии 4.0. Напомним, что она позволяет прочитать, сравнить и синхронизировать права доступа к объектам между экземплярами App Volumes на географически разделенных площадках. После аутентификации на обеих площадках вы сможете выбрать права доступа, которые надо сравнить или синхронизировать. О прошлой версии Entitlement Sync 2.3 мы писали вот тут.

Давайте посмотрим на возможности обновленного App Volumes Entitlement Sync 4:

• Добавлена поддержка App Volumes 4.x - как для Application Packages, так и старых Legacy 2.x AppStacks
• Все еще поддерживаются App Volumes Managers версии 2.x
• Исправления ошибок в связке Application / Package при репликации
• Сохранение адреса сервера, имени пользователя и домена в реестре
• Улучшенный механизм логгирования и обработки ошибок
• Возможность с инхронизировать объекты Application Package Markers
• Можно удалять пустые приложения
• Определение и отображения выбранного типа назначения (assignment type)
• Отображение версии текущего маркера (либо показывается, что его нет)
• Отображение версии App Volumes Manager на главной странице

На портале VMware Learning появились новые лабы (они же Hands-on Labs), которые посвящены новой версии платформы VMware vSphere 7:

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

На данный момент доступны следующие лабы:

• HOL-2111-01-SDC – VMware vSphere – What’s New
• HOL-2111-02-SDC – VMware vSphere – Advanced Topics
• HOL-2111-03-SDC – VMware vSphere – Security Getting Started

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

Также уже довольно давно доступна лаба VMware Cloud Foundation 4 Hands-on Lab - напомним, что архитектура VCF 4 также построена на базе VMware vSphere 7.

Мы много писали о возможностях новой версии платформы VMware vSphere 7 (например, тут и тут), но нововведений там столько, что это не уместить и в десять статей. Сегодня мы поговорим об изменениях в структуре разделов (Partition Layout), которые произошли в VMware ESXi 7.

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

Поэтому в vSphere 7 были увеличены размеры загрузочных областей, а системные разделы, которые стали расширяемыми, были консолидированы в один большой раздел.

В VMware vSphere 6.x структура разделов выглядела следующим образом:

Как мы видим, размеры разделов были фиксированы, кроме раздела Scratch и опционального VMFS datastore. Они зависят от типа загрузочного диска (boot media) и его емкости.

В VMware vSphere 7 произошла консолидация системных разделов в область ESX-OSData:

Теперь в ESXi 7 есть следующие 4 раздела:

• System boot - хранит boot loader и модули EFI. Формат: FAT16.
• Boot-banks (2 штуки) - системное пространство для хранения загрузочных модулей ESXi. Формат: FAT16.
• ESX-OSData - унифицированное хранилище дополнительных модулей, которые не необходимы для загрузки. К ним относятся средства конфигурации и сохранения состояния, а также системные виртуальные машины. Формат: VMFS-L. Для этой области нужно использовать долговременные хранилища на базе надежных устройств.

Как вы видите, ESX-OSData разделен на две части: ROM-data и RAM-data. Часто записываемые данные, например, логи, трассировка томов VMFS и vSAN EPD, глобальные трассировки, горячие базы данных - хранятся в RAM-data. В области ROM-data хранятся нечасто используемые данные, например, ISO-образы VMware Tools, конфигурации, а также дампы core dumps.

В зависимости от размера устройства, куда устанавливается ESXi, меняется и размер всех областей, кроме system boot:

Если размер устройства больше 128 ГБ, то ESXi 7 автоматически создает VMFS-тома.

Когда вы используете для запуска ESXi устройства USB или карточки SD, то раздел ESX-OSData создается на долговременном хранилище, таком как HDD или SSD. Когда HDD/SSD недоступны, то ESX-OSData будет создан на USB-устройстве, но он будет содержать только ROM-data, при этом RAM-data будет храниться на RAM-диске (и не сохранять состояние при перезагрузках).

Для подсистем ESXi, которым требуется доступ к содержимому разделов, используются символьные ссылки, например, /bootbank и /altbootbank. А по адресу /var/core лежат дампы core dumps:

В VMware vSphere Client можно посмотреть информацию о разделах на вкладке Partition Details:

Ту же самую информацию можно получить и через интерфейс командной строки ESXi (команда vdf):

Обратите внимание, что соответствующие разделы смонтированы в BOOTBANK1 и 2, а также OSDATA-xxx.

Кстати, вы видите, что OSDATA имеет тип файловой системы Virtual Flash File System (VFFS). Когда OSDATA размещается на устройствах SDD или NVMe, тома VMFS-L помечаются как VFSS.

ESXi поддерживает множество устройств USB/SD, локальных дисков HDD/SSD, устройств NVMe, а также загрузку с тома SAN LUN. Чтобы установить ESXi 7 вам нужно выполнить следующие требования:

• Boot media размером минимум 8 ГБ для устройств USB или SD
• 32 ГБ для других типов устройств, таких как жесткие диски, SSD или NVMe
• Boot device не может быть расшарен между хостами ESXi

Если вы используете для установки ESXi такие хранилища, как M.2 или другие не-USB девайсы, учитывайте, что такие устройства могут быстро износиться и выйти из строя, например, если вы используете хранилища VMFS на этих устройствах. Поэтому удалите тома VMFS с таких устройств, если они были созданы установщиком по умолчанию.