Новости Статьи VMware Veeam StarWind Microsoft ИТ-ГРАД Citrix Symantec 5nine События Релизы Видео Контакты Авторы RSS
Виртуализация и виртуальные машины

Виртуализация vSphere, Hyper-V, XenServer и Red Hat

Более 4830 заметок о виртуализации и виртуальных машинах VMware, Microsoft, Citrix, Red Hat

VM Guru | Ссылка дня: Номинация vExpert на вторую половину 2019 года уже открыта!

На сайте VMware Labs обновилась утилита HCIBench до версии 2.1.


На сайте VMware Labs обновилась утилита HCIBench до версии 2.1.

Напомним, что о версии HCIBench 2.0 мы писали вот тут, а здесь мы рассматривали использование этой утилиты для замеров производительности кластеров VMware vSAN. Напомним, что это средство позволяет провести комплексный тест производительности отказоустойчивых кластеров хранилищ Virtual SAN, а также других конфигураций виртуальной инфраструктуры.

Проект HCIbecnh ("Hyper-converged Infrastructure Benchmark") является оберткой для известного open source теста VDbench, он позволяет организовать автоматизированное тестирование гиперконвергентного кластера (HCI-кластера). Гиперконвергентный кластер - это когда все его вычислительные ресурсы, системы хранения и сети виртуализованы и собраны в единую интегрированную сущность и управляются из одной точки.

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

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

  • Интерфейс переключили на темную тему.
  • Переработанная технология подготовки VMDK, которая теперь работает гораздо быстрее за счет использования рандомизации на дедуплицированных хранилищах.
  • Добавлена возможность обновления процесса подготовки VMDK.
  • Добавлена проверка портов базы данных Graphite в процесс превалидации.
  • Пароли vCenter и хостов ESXi затемняются при сохранении
  • Добавлена кнопка удаления гостевой ВМ ("Delete Guest VM").
  • Пофикшены проблемы с дисплеями для Grafana.
  • Пофикшена проблема с пустыми результатами при отработки модели нагрузки FIO (Flexible I/O).
  • Множество мелких исправлений ошибок.

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


Таги: VMware, HCIBench, Update, Performance, ESXi, vSphere, vSAN, VMDK, Storage

Обновления, патчи, апгрейды и нумерация версий VMware vCenter на платформе vSphere - как это устроено?


Очень часто администраторы платформы VMware vSphere задаются следующими вопросами о версиях продукта vCenter: какая разница между обновлением vCenter (он же update) и патчем (patch)? в чем отличие апгрейда (upgrade) и миграции (migration)? почему некоторые версии vCenter нумеруются как-то отдельно? Попробуем дать ответы на эти вопросы ниже, используя материал вот этой статьи в блоге VMware.

Первое, что нужно понять - это нумерация версий vCenter. Она подразумевает 2 компонента - номер версии (например, vCenter 6.7 Update 2a) и номер билда (например, 13643870):

Номер версии имеет также и цифровое обозначение. Если вы зайдете в интерфейс VMware Appliance Management Interface (VAMI), то увидите там номер билда (13643870), а также полный номер версии (6.7.0.31000):

Если же вы зайдете в vSphere Client и перейдете там на вкладку Summary для вашего сервера vCenter (в данном случае vCenter Server Appliance, vCSA), то увидите там версию 6.7.0:

В данном случае в поле Build указан номер билда клиента vSphere Client (13639324), и не стоит его путать с номером билда самого vCenter. Все это как-то более-менее соотносится между собой (VAMI дает более полную информацию о цифровом номере версии).

Теперь, чтобы сложить все это в единую картину и соотнести с датой релиза конкретной версии vCenter, существует статья базы знаний KB 2143838, где есть полезная табличка:

Обратите внимание на последнюю колонку - Client/MOB/vpxd.log. Это версия клиента vSphere Client, и именно она появится в лог-файле vpxd.log, поэтому не стоит удивляться, что она отличается от номера билда vCenter.

Теперь перейдем к апдейтам и патчам. vCenter Server Update - это полноценное обновление платформы, которое может включать в себя новый функционал, исправления ошибок или доработки существующей функциональности. Выходит апдейт довольно редко и имеет свое строковое наименование (например, vCenter 6.7 Update 2a). Для апдейта всегда выпускается документ Release Notes, и его можно скачать через my.vmware.com.

Патч - это постоянно выпускаемое небольшое обновление для vCenter, которое поддерживает уровень безопасности, закрывает критические уязвимости, исправляет фатальные ошибки и т.п. Он может относиться к вспомогательным компонентам vCSA, например, Photon OS, базе данных Postgres DB или фреймворку Java.

Для патча нет выделенного документа Reelase Notes, но информация о нововведениях доступна в VMware vCenter Server Appliance Photon OS Security Patches. Патчи нельзя скачать через my.vmware.com, но они загружаются через VMware Patch Portal. Само собой, патчи включаются в апдейты, выпускаемые на какой-то момент времени. Патчи накатываются в рамках одного цифрового обновления. То есть 6.7 Update 1 не патчится напрямую на 6.7 Update 2b, сначала надо накатить апдейт 6.7 Update 2a, а затем уже пропатчиться на 6.7 Update 2b.

Также на VMware Patch Portal вы можете найти ISO-образы vCenter Server, но их не надо использовать для новых развертываний, они нужны только для восстановления вашего vCenter Server Appliance, если вы используете резервное копирование на уровне файлов.

Теперь перейдем к разнице между апгрейдом и миграцией. Апгрейд - это обновление мажорной версии сервера vCenter одного типа развертывания (например, вы делаете апгрейд vCenter Server Appliance 6.5 на vCenter Server Appliance 6.7). Миграция - это когда вы меняете тип развертывания vCenter, переходя, например, с Windows-платформы на Linux (к примеру, vCenter Server 6.5 for Windows мигрируете на vCenter Server Appliance 6.7).

Если вы обновляете vCSA 6.5 на 6.7, то апгрейд идет как бы ненастоящий - развертывается новый виртуальный модуль vCSA 6.7, и на него переезжают все настройки (FQDN, IP, сертификаты и UUID), а также содержимое базы данных vCSA 6.5.

Также надо упомянуть и back-in-time upgrade - это когда вы хотите обновить, например, vSphere 6.5 Update 2d на vSphere 6.7 Update 1. Прямое обновление тут не поддерживается, так как  Update 2d для версии 6.5 вышел позднее, чем Update 1 для версии 6.7. То есть Update 2d содержит код, которого нет в Update 1, а значит это может вызвать потенциальные конфликты.

Поэтому для каждой новой версии vCenter выпускается раздел Upgrade Notes for this Release, где можно найти информацию о возможности апгрейда:


Таги: VMware, vCenter, Update, Upgrade, vSphere

Проверки кластера VMware vSphere Update Manager перед обновлениями хостов (Remediation).


У средства обновления хостов VMware vSphere Update Manager (VUM) есть полезный механизм проверок Pre-Check Remediation Report, который выполняет предварительную проверку условий для обновления хостов ESXi, чтобы этот процесс не прервался уже после его начала. Эти условия очень просты, но иногда позволяют сэкономить массу времени, особенно в большой инфраструктуре VMware vSphere.

Чтобы запустить эти проверки, надо выбрать нужный вам кластер и нажать кнопку Pre-Check Remediation:

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

Отчет Pre-Check Remediation Report для кластера может содержать следующие пункты:

Номер Текущий статус Рекомендуемое действие Описание
1 Отключен ли DPM? Отключите DPM в кластере

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

2 Включен ли DRS? Включите DRS в кластере

Именно DRS позволяет серверу vCenter смигрировать ВМ на другие хосты ESXi, чтобы обновить целевой хост-сервер.

3 Отключен ли HA admission control? Отключите HA admission control

HA admission control предотвращает миграцию ВМ средствами vMotion, в результате которой не выполняются правила доступности слотов. Перед обновлением этот механизм лучше отключить.

4 Включен ли EVC в кластере? Включите EVC в кластере

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

5 Успешны ли проверки vSAN health check? Проверьте страницу vSAN Health Check на наличие проблем

Проверки vSAN Health Check представляют собой набор тестов для хостов ESXi, составляющих кластер vSAN (например, тесты доступности хранилищ во время обновления). Они должны завершиться успешно перед началом процедуры обновления хостов.

Отчет Pre-Check Remediation Report для виртуальных машин может содержать следующее:

Номер Текущий статус Рекомендуемое действие Описание
1 К ВМ привязан привод CD/DVD Отключите привод CD/DVD

 

Это редкая, но случающаяся проблема, когда такие приводы используются, например, для монтирования ISO-образов.
2 К ВМ привязан floppy-драйв Отключите привод floppy

 

Очень редко, но бывает.
3 Для ВМ включена технология FT Отключите Fault Tolerance для ВМ

 

Технология Fault Tolerance не позволяет VUM обновлять ВМ.
4 На ВМ установлен VMware vCenter Server, при этом DRS в кластере отключена Включите DRS в кластере и убедитесь, что машина может мигрировать средствами vMotion

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

 

5 На ВМ установлен VMware vSphere Update Manager, при этом DRS в кластере отключенаВключите DRS в кластере и убедитесь, что машина может мигрировать средствами vMotion vCenter управляет процессом обновления, поэтому нужно, чтобы он мог переехать на другой хост в процессе обновления ESXi.


Таги: VMware, vSphere, Update Manager, VUM, Update, Обучение, ESXi, VMachines

Обновление безопасности VMSA-2019-0009 для VMware Tools. Как вам можно обновиться.


Компания VMware опубликовала уведомление VMSA-2019-0009 для пакета VMware Tools, который содержит уязвимость, позволяющую непривилегированному пользователю читать данные из гостевой ВМ, а также негативно влиять на ее гостевую ОС. Уязвимости подвержены версии VMware Tools ниже 10.3.10.

В качестве примера использования такой уязвимости можно привести Windows-машины, где включены службы Microsoft Remote Desktop Services. Также риску подвержены службы Microsoft SQL Server или IIS, использующие сервисные аккаунты.

Сначала надо вывести все ВМ, имеющие VMware Tools версии ниже 10.3.10 с помощью следующей команды PowerCLI:

Get-VM | Where-Object {$_.Guest.ToolsVersion -lt ‘10.3.10’} | Sort-Object Name | Format-Table

Вот такая команда выдаст все Windows-машины с VMware Tools ниже, чем 10.3.10:

Get-VM | Where-Object {$_.Guest.ToolsVersion -lt ‘10.3.10’ -and $_.Guest.GuestFamily -eq ‘windowsGuest’} | Sort-Object Name | Format-Table

Проверить версию VMware Tools можно и самостоятельно в VMware vSphere Client:

Помните, что VMware 6.7 Update 2a идет с версией VMware Tools 10.3.5. Надо отметить, что гостевые ОС Linux не подвержены уязвимости, поэтому не пугайтесь, что open-vm-tools имеют только версию 10.3.5.

Последнюю же версию пакета тулзов можно скачать по этой ссылке: https://www.vmware.com/go/tools.

Если вы хотите обновить VMware Tools через офлайн-бандл, то скачайте "VMware Tools Offline VIB Bundle", после чего можно использовать vSphere Update Manager (VUM) для развертывания установщиков пакета на хостах ESXi без простоя. После этого машины должны в течение 5 минут схватить новую версию тулзов (таков период обновления информации об актуальной версии пакета). Установленная версия VMware Tools также проверяется и при vMotion, а, кроме того, и при операциях с питанием ВМ (включение/выключение).

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

Обновление VMware Tools можно инициировать через PowerCLI с помощью следующего командлета:

Get-VM | Where-Object {$_.ExtensionData.Guest.ToolsVersionStatus -eq "guestToolsNeedUpgrade" -and $_.PowerState -eq "PoweredOn"} | Get-VMGuest | Where-Object {$_.GuestFamily -eq "windowsGuest" } | Update-Tools -NoReboot -RunAsync

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

Get-VM “TEST-VM-02” | Where-Object…
Get-Folder “Test VMs - Snapshotted" | Get-VM | Where-Object…

Через vSphere Client тулзы также прекрасно обновляются:

Если вы используете опцию "Automatic Upgrade", то машина будет обновлена автоматически (без взаимодействия с гостевой ОС) и, при необходимости, перезагрузится. Также вы можете использовать обновление тулзов без немедленной перезагрузки, применив инструкции, описанные в KB1018377. Надо помнить, что в этом случае до перезагрузки будет работать старая версия VMware Tools, а значит, что до перезагрузки машины уязвимость будет актуальна.

Еще одна опция - настроить обновления тулзов в настройках виртуальной машины:

 

 

Иногда администраторы гостевой системы имеют эксклюзивный доступ к ней (например, админы бизнес-критичных баз данных) и контролируют все происходящие в ней события. Для этого надо настроить их взаимодействие с машиной как указано в KB 2007298.

В этом случае они получат нотификацию о новой версии VMware Tools из трея, либо могут проверить наличие обновлений самостоятельно с помощью команд:

  • VMwareToolboxCmd.exe –v - проверка установленной версии.
  • VMwareToolboxCmd.exe upgrade status - возможность обновления для доступных апгрейдов.
  • VMwareToolboxCmd.exe upgrade start - запуск процедуры апгрейда.

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


Таги: VMware, Tools, Update, vSphere, ESXi, VMachines

Как предоставить доступ виртуальной машине в облаке VMware vCloud on AWS из сети Compute Network в сеть SDDC Management Network?


Для многих пользователей публичного облака VMware vCloud on AWS одним из первых возникает вопрос - как предоставить доступ из виртуальной машины в сети Compute Network в сеть SDDC Management Network, например, для целей управления сервисами vCenter или другими службами виртуального датацентра?

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

Естественно, что для целей обеспечения безопасности в облаке, эти две сети по умолчанию разделены. Первое, что вам нужно сделать - это понять, с каким типом решения NSX для управления сетью вы работаете (NSX-T или NSX-V). Сделать это можно с помощью вот этой статьи.

Процедура для NSX-V

В среде NSX-V вам нужно настроить IPsec VPN между компонентами Management Gateway (MGW) и Compute Gateway (CGW) перед тем, как заработает коммуникация между сетями.

Для настройки VPN для компонента Management Gateway нажимаем Add VPN в консоли VMC и вводим требующуюся информацию сетевой идентификации (публичный IP удаленного шлюза, параметры удаленной сети и ключи), что должно отражать конфигурацию Compute Gateway (остальные настройки можно оставить по умолчанию).

Далее надо настроить VPN для Compute Gateway путем выполнения тех же шагов, что и в предыдущем абзаце, только указав конфигурацию шлюза Management Gateway. После того, как настройки обеих VPN будут сохранены, начнет отображаться статус "Partially Connected". Потом нажимаем ссылку Actions в правом верхнем углу, выбираем Edit и сохраняем настройки еще раз, чтобы на обоих шлюзах показался статус "Connected":

Теперь надо настроить сетевой экран Compute Gateway Firewall, чтобы разрешить исходящие соединения в SDDC Management Network по порту 443 для требуемых ВМ (этот порт используется для vSphere Client, а также для доступа через средства OVFTool и PowerCLI).

В приведенном ниже примере машина имеет адрес 192.168.1.4, и мы хотим позволить ей общаться с сетью 10.2.0.0/16 через порт 443:

Теперь нужно добавить в фаервол Management Gateway Firewall правила для разрешения входящих соединений для vCenter Server и хостов ESXi по порту 443 от наших определенных ВМ. Здесь все точно так же - указываем IP машины 192.168.1.4, и нам нужно добавить 2 правила для входящего трафика для разрешения коммуникации со средствами управления виртуальной инфраструктурой:

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

Процедура для NSX-T

В среде NSX-T вам не нужно создавать VPN для получения функциональности маршрутизации, которая изначально заложена в маршрутизаторе T0, ведь обе сети Management и Compute Network присоединены к T0. Между тем, правила сетевого экрана добавлять, конечно же, нужно.

В решении NSX-T используются сущности Inventory Groups, чтобы сгруппировать набор виртуальных машин и/или IP-адреса/сети, которые можно использовать при создании правил сетевого экрана.

Создаем две Inventory Groups для нашей Compute Group - одну для нашей виртуальной машины и одну для того, чтобы представлять сеть Management Network. Идем в Groups и в левой части выбираем пункт "Workload Groups", где создаем 2 группы:

  • Windows10 с Member Type вида Virtual Machine и указываем ВМ из инвентаря.
  • VMC Management Network с Member Type вида IP Address и указываем сетевой диапазон 10.2.0.0/16.

Теперь нужно создать еще одну Inventory Group для нашей Management Group, которая будет отражать ВМ, для которой мы хотим сделать доступ. Чтобы это сделать, идем в Groups, выбираем "Management Groups" и создаем следующую группу:

  • Windows10 Private IP с Member Type вида IP Address и указываем частный IP-адрес ВМ (в данном случае это 192.168.1.2).

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

Теперь нужно создать правило сетевого экрана, чтобы разрешить Compute Gateway исходящие соединения к SDDC Management Network по порту 443 для нужных ВМ. Идем в Gateway Firewall и выбираем "Compute Gateway", где создаем новое правило, которое отражает группу Windows 10 как источник и группу VMC Management Network как назначение, а в качестве сервиса выбираем HTTPS (помним также про кнопку Publish).

Теперь надо создать правила на уровне Management Gateway, чтобы разрешить входящие соединения к хостам vCenter Server и ESXi по порту 443 из нужных нам ВМ. Идем в Gateway Firewall, слева выбираем "Management Gateway", затем создаем правило, которое отражает группу Windows 10 как источник, а в качестве группы назначения указываем vCenter и ESXi (сервис ставим также HTTPS):

После выполнения этой процедуры вы сможете залогиниться в ВМ Windows и использовать утилиту OVFTool для импорта/экспорта ВМ в ваш виртуальный датацентр (см. также данную процедуру здесь).

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


Таги: VMware, vCloud, VMConAWS, Cloud, Amazon, vNetwork, Networking, vSphere, ESXi, VMachines, Blogs

Ошибка в консоли клиента vSphere Client "The ramdisk 'tmp' is full" на серверах HPE ProLiant с кастомным образом ESXi и пакетом HPE Agentless Management (AMS).


Те, кто используют серверы HPE ProLiant с гипервизором VMware ESXi и пакетом управления HPE Agentless Management (AMS) для кастомизированных образов ESXi от HP, могут столкнуться со следующим сообщением об ошибке в клиенте vSphere Client:

The ramdisk 'tmp' is full

Выглядит это чаще всего вот так:

Проблема актуальна для всех версий VMware ESXi 6.0, VMware ESXi 6.5 и VMware ESXi 6.7 с пакетом Agentless Management Service (AMS) версии 11.4.0.

Если зайти в консоль ESXi и выполнить там команду vdf, то можно увидеть, что раздел /tmp заполнен на 99%:

В самом же разделе tmp есть файлик ams-bbUsg.txt, который и является источником проблем:

Для временного решения этой проблемы нужно просто удалить этот файлик, и сообщения об ошибке прекратятся. Но чтобы этого не происходило, надо обновить ваш пакет HPE Agentless Management (AMS) версии 11.4.0, где проявляется данная проблема, на версию 11.4.2. О том, как это сделать написано в статье базы знаний HP:

Advisory: VMware - VMware AMS Data File Filling Up Tmp May Cause VUM Updates to Fail On HPE Servers Running VMware ESXi 6.0/6.5/6.7 with AMS Version 11.4.0.

Сам репозиторий с обновленным AMS находится по следующей ссылке:

http://vibsdepot.hpe.com/hpe/may2019


Таги: VMware, HP, ESXi, Bug, Bugs, Storage, vSphere, Client

Ограничения Persistent Memory для виртуальных машин на платформе VMware vSphere.


В августе прошлого года мы сделали статью о новом виде памяти Persistent memory (PMEM) в VMware vSphere, которая находится на уровне между DRAM и Flash SSD с точки зрения производительности:

Надо сказать, что устройства с Persistent Memory (они же, например, девайсы с Intel Optane Memory) уже начинают рассматривать некоторые пользователи для внедрения в своей виртуальной инфраструктуре, поэтому надо помнить об их ограничениях, которые раскрыл Дункан Эппинг.

С точки зрения предоставления памяти PMEM виртуальной машине, на платформе vSphere есть 3 способа:

  • vPMEMDisk - vSphere представляет PMEM как обычный диск, подключенный к виртуальной машине через контроллер SCSI. В этом случае ничего не нужно менять для гостевой ОС или приложений. В таком режиме работают любые системы, включая старые ОС и приложения.
  • vPMEM - vSphere представляет PMEM как устройство NVDIMM для виртуальной машины. Большинство последних версий операционных систем (например, Windows Server 2016 и CentOS 7.4) поддерживают устройства NVDIMM и могут предоставлять их приложениям как блочные или байт-адресуемые устройства. Приложения могут использовать vPMEM как устройство хранения через тонкий слой файловой системы direct-access (DAX), либо замапить регион с устройства и получать к нему прямой доступ через байтовую адресацию. Такой режим может быть использован старыми или новыми приложениями, но работающими в новых версиях ОС, при этом версия Virtual Hardware должна быть не ниже 14.
  • vPMEM-aware - это то же самое, что и vPMEM, но только с дополнительными возможностями приложения понимать, что машина использует такое устройство, и пользоваться его преимуществами.

Если виртуальная машина использует такие устройства, то она имеет очень существенные ограничения, которые на данный момент препятствуют их использованию в производственной среде. Они приведены в документе "vSphere Resource Management Guide" на странице 47 внизу. А именно:

  • vSphere HA - полностью не поддерживается для машин с включенными vPMEM устройствами, вне зависимости от режима использования.
  • vSphere DRS - полностью не поддерживается для машин с включенными vPMEM устройствами (машины не включаются в рекомендации и не мигрируют через vMotion), вне зависимости от режима использования.
  • Миграция vMotion для машин с устройствами vPMEM / vPMEM-aware доступна только на хосты с устройствами PMEM.
  • Миграция vMotion машин с устройством vPMEMDISK возможна на хост без устройства PMEM.

Будем надеяться, что эта ситуация в будущем изменится.


Таги: VMware, vSphere, Memory, PMEM, Intel, VMachines, HA, DRS

Серьезная проблема с виртуальными машинами с включенной Virtualization-Based Security (VBS) на платформе VMware vSphere.


Начиная с VMware vSphere 6.7, компания VMware поддерживает технологию защищенной виртуализации Virtualization-Based Security (VBS). Это один из механизмов, который позволяет предоставлять пользователям более защищенные рабочие Windows-среды средствами технологий Device Guard и Credential Guard (последняя предназначена для изоляции пространства хранения учетных записей от потенциальной кражи вредоносным ПО). Эти функции очень важны для защиты, например, таких компонентов инфраструктуры, как серверы Active Directory.

Между тем, с виртуальными машинами, работающими с поддержкой данной технологии, была найдена серьезная проблема - они зависают или выпадают в синий экран смерти (BSOD) при загрузке. Баг проявляется при включенной технологии VBS (на скриншоте vSphere Client на базе HTML5 с Hardware Version 14):

Также этот баг актуален и для включенной поддержки технологии I/O MMU:

Возможность VBS доступна в Microsoft Windows 10/2016/2019, сам же баг стал проявляться, начиная с версии Windows Insider Build 18362. VMware говорит, что проблема находится на стороне Microsoft, но оба вендора совместно работают над выпуском патча для ОС.

Статья базы знаний VMware KB 68043 содержит вопросы, которые позволят вам определить, затрагивает ли вас проблема.

Помимо проверки настроек в интерфейсе vSphere Client, которые вы видите на скриншотах выше, можно использовать вот такой PowerCLI-скрипт для определения машин, которые затрагивает проблема:

Get-View -ViewType VirtualMachine | Where {(($_.Config.Flags.VbsEnabled -eq "True") -or ($_.Config.Flags.VvtdEnabled -eq "True")) -and ($_.Summary.Config.GuestID -like "windows9*")} | Select Name,@{Name=”VBS”; Expression={$_.Config.Flags.VbsEnabled}},@{Name=”IOMMU”; Expression={$_.Config.Flags.VvtdEnabled}}

После того, как вы найдете у себя такие ВМ, то выхода у вас два:

  • Не использовать VBS и I/O MMU для виртуальных машин.
  • Использовать workaround, который приведен в статье KB 68043.

Workaround заключается в следующем:

  • Выключаем машину и отключаем VBS и I/O MMU для нее.
  • Устанавливаем ОС на ВМ или обновляем ее до самых последних апдейтов.
  • Выключаем ВМ, выбираем в настройках "Expose hardware assisted virtualization to guest".
  • Включаем ВМ, в настройках включаем функцию (feature) "Hyper-V" в гостевой ОС, после чего перезагружаем машину.
  • Опять выключаем ВМ и включаем VBS и/или I/O MMU, после чего она уже будет нормально работать.

Помните, что такой Workaround не вечен для свежих установок, например, из образов 1903 & 19H1 DVD/ISO, так как следующее обновление потенциально может вернуть баг, который еще не пофикшен со стороны Microsoft. Имейте это в виду, когда создаете шаблоны виртуальных машин для массового развертывания. Поэтому сначала все обновляем до самой последней версии, потом уже используем Workaround выше.

Кстати, все могло бы быть и хуже) Например, уязвимость Remote Desktop Services vulnerability (CVE-2019-0708), требующая немедленного обновления не затрагивает системы с описанной проблемой выпадения в BSOD. Уязвимость с удаленным рабочим столом актуальна только для систем Windows XP, 7, Windows Server 2003, 2008 (+ R2), а баг с зависанием актуален только для более поздних Windows.

Ждем пока сделают нормальный фикс, и не надо будет плясать с Workaround'ом. А пока можете на всякий случай отключить VBS, если позволяют корпоративные политики.


Таги: VMware, vSphere, Security, VBS, Microsoft, Windows, Bug, Bugs

Новое на VMware Labs - Distributed Trust Incident Reporting.


На сайте проекта VMware Labs появилась новая интересная Open Source утилита - Distributed Trust Incident Reporting. Она предназначена для документирования инцидентов в сфере информационной безопасности, которое часто осуществляется на бумаге или в Excel даже в крупных компаниях. Некоторые системы имеют централизованную базу данных инцидентов с возможностью отслеживания ответных мер, принятых в качестве реакции на инцидент, но только на уровне собственного предприятия.

Текущие подходы по мнению VMware обладают рядом недостатков:

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

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

Утилита Distributed Trust Incident Reporting позволяет:

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

Работает это все на базе контейнеров Docker, а технологическую платформу фиксирования инцидентов предоставляют решения VMware blockchain или Ethereum blockchain.

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

Проект Distributed Trust Incident Reporting доступен для скачивания из репозитория GitHub.


Таги: VMware, Labs, Security, vSphere, Blockchain

Проверка производительности кластера VMware vSAN с помощью утилиты HCIBench.


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

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

А зачем вообще проводить тестирование кластера vSAN? Тут, как правило, есть следующие причины:

  • Понимание возможностей инфраструктуры хранения и возможность убедиться в том, что в ней нет аномалий.
  • Валидировать дизайн кластера vSAN с точки зрения приемо-сдаточных испытаний (User Acceptance Testing, UAT).
  • Получить референсные значения, с которыми можно будет сверяться при внесении существенных изменений в архитектуру vSAN.
  • Проведение тестов перед внедрением (PoC-проекты).
  • Установление базового уровня пользовательских ожиданий после развертывания приложений.

По итогу тестирования производительности хранилищ vSAN вы должны получить ответы на следующие вопросы:

  • Какого наибольшего числа операций ввода-вывода в секунду (IOPS) можно добиться?
  • Какая ожидаемая задержка выполнения операций (latency) при требуемом числе IOPS для рабочей нагрузки?
  • Какая максимальная пропускная способность операций чтения-записи (throughput)?

То есть результаты тестирования держатся на трех китах - IOPS, latency и throughput.

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

IOPS

Число выдаваемых IOPS зависит как от используемого оборудования для хостов и сетевых компонентов, так и от архитектуры системы. Актуальное число IOPS также зависит от уровня RAID в кластере vSAN, числа сетевых соединений между хостами, их загрузки и прочих факторов.

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

Latency

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

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

Throughput

Пропускная способность важна при выполнении больших операций ввода-вывода, а также при различных паттернах чтения записи (последовательный/случайный). Чем больше размер I/O, тем очевидно больше пропускная способность. С точки зрения объема передаваемых данных одна операция I/O размером 256К равна 64 операциям ввода-вывода по 4К, но вот с точки зрения throughput это будут совершенно разные значения, так как займут разное время.

Методология тестирования хорошо описана в документации по HCIBench, а также вот в этой статье на русском языке. Работа с утилитой начинается по ссылке https://<HCIBench IP address>:8443.

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

Очень важно при тестировании также задать правильный профиль рабочей нагрузки (4 варианта на картинке выше).

После выполнения теста Easy Run вы получите выходной файл с результатами вроде vdb-8vmdk-100ws-4k-70rdpct-100randompct-4threads-xxxxxxxxxx-res.txt. Из имени файла можно понять использованную тестовую конфигурацию (она также будет в самом файле):

Block size : 4k
Read/Write (%) : 70/30
Random (%) : 100
OIO (per vmdk) : 4

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

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

Полученные параметры можно считать базовым уровнем для тестирования производительности кластера. Теперь нужно увеличивать параллелизм, то есть число тредов Outstanding I/O (OIO), для выжимки оптимальной производительности. Увеличение этого параметра будет увеличивать число IOPS, а также, как следствие, будет расти Latency. Так вы сможете понять, как инфраструктура хранения ведет себя в динамике, реагируя на изменение профиля нагрузки.

Чтобы изменить параметр OIO, нужно отключить Easy Run и в профиле рабочей нагрузки нажать Add:

Также для измерения пропускной способности вы можете поэкспериментировать с размером операции ввода-вывода. Современные ОС поддерживают размер I/O в диапазоне 32K - 1 MB, но для тестирования лучше использовать I/O в диапазоне 32K – 256K.

Еще какие моменты надо учитывать при тестировании:

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

Таги: VMware, vSAN, Performance, ESXi, vSphere, HCIBench, Storage

Улучшения планировщика side-channel aware scheduler (SCA) в VMware vSphere 6.7 Update 2.


Некоторое время назад мы писали о новых возможностях недавно вышедшего обновления платформы виртуализации VMware vSphere Platinum 6.7 Update 2. Cреди новых возможностей гипервизора там есть фича "Новые возможности планировщика CPU помогают бороться с уязвимостями типа L1TF".

Оказывается, это довольно серьезное улучшение. Надо сказать, что планировщик гипервизора side-channel aware scheduler (SCA) появился еще в прошлой версии платформы. Он закрывал уязвимость L1TF (L1 Terminal Fault) в процессорах Intel за счет того, что процессы виртуальных машин запускались только в одном треде одного физического ядра. Это позволяло нивелировать вектор атаки данного типа, но приводило к существенному снижению производительности.

Особенно это чувствовалось, когда сервер ESXi был загружен по CPU полностью, и SCA первой версии в этом случае давал до 30% хуже результат, чем без него. Если же сервер был загружен, например, на 75%, то в производительность оставалась примерно той же, но без SCA нагрузка на CPU была существенно ниже.

Обо всем этом подробно описано в документе "Performance of vSphere 6.7 Scheduling Options":

Давайте вкратце посмотрим, о чем там говорится.

Итак, начиная с VMware vSphere 6.7 Update 2, появился обновленный планировщик SCAv2, который был существенно доработан по сравнению со своей предыдущей версией. Он позволяет исполнять контексты vCPU одной машины в разных гипертредах одного физического ядра процессора хоста. В этом случае атаке L1TF не подвержены взаимодействия типа VM/VM и VM/ESXi (чувствительная информация между ними не шарится в общем кэше).

В документе описано 2 типа тестов, которые проводились для планировщиков SCAv1 и SCAv2: работа хоста под максимальной нагрузкой по процессорам и под нагрузкой на уровне 75% от максимальной мощности всех CPU хоста ESXi (reduced load). В качестве базового уровня использовался планировщик без SCA (он же на картинке ниже обозначен как Default):

Если верить графикам, отражающим результаты тестирования различными бенчмарками, то планировщик SCAv2 работает существенно лучше во всех случаях, кроме очень большой (по выделенным ресурсам) виртуальной машины - Monster VM с базой Oracle и 192 vCPU, но такой кейс в реальной жизни случается весьма редко. Так что, в целом, улучшения были проведены весьма существенные (как минимум, на 11% планировщик стал более производительным по результатам тестов).

Помимо документа выше, информация об улучшениях планировщика приведена еще в KB 55806.


Таги: VMware, ESXi, Performance, Security, vSphere, vCPU, VMachines

Немного азов: через какой интерфейс VMkernel пойдет трафик VMware HA на платформе vSphere?


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

Так вот, хартбиты механизма HA пойдут через тот vmk-интерфейс, на котором в vSphere Client отмечена галочка Management, как на картинке:

Надо понимать, что этот пункт, хоть и называется Management, имеет отношение только к HA-трафику. Это означает, что если галочка не отмечена, то через этот интерфейс все равно можно будет подключиться по протоколу SSH, а также присоединить хост ESXi к серверу управления VMware vCenter, используя этот IP-адрес.

Так что Management - это не про управление, а только про HA. Это касается только обычной виртуальной инфраструктуры, а вот в кластере vSAN трафик HA идет по выделенной под vSAN сети автоматически.


Таги: VMware, vSphere, HA, ESXi

А что нового в VMware vSphere Platinum 6.7 Update 2?


Все из вас в курсе, что не так давно компания VMware выпустила обновление своей флагманской платформы виртуализации VMware vSphere 6.7 Update 2. Ну и все, наверняка, помнят, что, начиная с VMware vSphere 6.7, появилось издание Platinum, которое включает в себя функциональность продукта AppDefense (также вот тут мы рассказывали о решении VMware Service-Defined Firewall на его основе).

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

Сегодня мы расскажем о том, что нового появилось в vSphere Platinum 6.7 Update 2.

1. Диаграммы обнаружения процессов (Process Burndown Charts).

AppDefense постоянно находится в режиме обнаружения новых процессов и их взаимодействий в виртуальном датацентре (Discovery mode). Данная диаграмма показывает все новые обнаруженные взаимодействия, и если их не становится больше - то пора переводить приложение в защищаемый режим (Protected mode).

2. Статус репутации сервисов (Process Reputation Status).

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

3. Статус проверок целостности (Integrity Check Status).

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

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

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

5. Диаграммы топологии (в статусе Beta).

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

6. Интеграция VMware Tools и AppDefense.

Теперь модули AppDefense поставляются для гостевых ОС вместе с VMware Tools (по аналогии с модулями NSX introspection). Это позволяет также и создавать шаблоны виртуальных машин с уже интегрированными модулями AppDefense.

7. Улучшения vSphere Plugin.

AppDefense Plugin for vSphere Platinum 6.7 Update 2 получил много улучшений в части рабочего процесса по инсталляции в кластере, а также по апгрейду виртуального модуля AppDefense.

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

Здесь можно отметить следующие:

  • Поддержка новых механизмов современных ОС упрощает использование VBS (Virtualization-Based Security), виртуальных устройств TPMs, шифрования уровня ВМ, безопасной загрузки и других возможностей по обеспечению безопасности. После обновления со старых систем, например Windows Server 2008 R2, эти возможности включатся автоматически.
  • Улучшения Update Manager и Host Profiles в части процесса обновлений хостов ESXi.
  • Новые возможности для аудита и камплаенса - история паролей, лимит по повторному использованию паролей, улучшенный SSO, логирование всех событий vCenter и прочее. События можно отправить в сторонние системы, такие как vRealize Log Insight или другую SIEM-систему.
  • Улучшенный API по замене сертификатов ESXi, также можно сгенерировать запрос на создание сертификата средствами vCenter.
  • Новые возможности планировщика CPU помогают бороться с уязвимостями типа L1TF.

Скачать VMware vSphere Platinum 6.7 Update 2 можно по этой ссылке.


Таги: VMware, vSphere, Update

Как обновить информацию от VMware Tools о сетевых настройках гостевой ОС (пригодится для Instant Clone).


Вильям Лам написал интересную заметку про обновление информации о сетевой идентификации гостевой ОС, которую выдает VMware Tools. Она показывается на вкладке Summary клиента vSphere Client или VMware Workstation:

По умолчанию эта информация обновляется каждые 30 секунд на базе данных, предоставляемых пакетом VMware Tools из гостевой ОС. Однако если вы используете технологию создания мгновенных клонов (Instant Clone) и массово создаете виртуальные машины, то вам может потребоваться увидеть эту информацию пораньше.

Здесь есть 2 пути:

1. Принудительно обновить настройки из гостевой ОС следующими командами:

  • Windows - C:\Program Files\VMware\VMware Tools\VMwareToolboxCmd.exe info update network
  • Linux - /usr/bin/vmware-toolbox-cmd info update network
  • Mac OS - /Library/Application\ Support/VMware\ Tools/vmware-tools-cli info update network

2. Изменить интервал, по которому обновляются данные со стороны гостевой ОС (это может создать дополнительную нагрузку из-за частых обновлений). По умолчанию это 30 секунд.

Для этого в vmx-файл виртуальной машины нужно добавить следующую строчку (но не факт, что это работает сейчас):

vnet.pollInterval = XX


Таги: VMware, Tools, VMachines, vSphere, ESXi

Для чего нужна настройка Dedicated failover hosts в кластере VMware HA?


Некоторые администраторы VMware vSphere задаются вопросом, а для чего же нужна опция Dedicated failover hosts при настройке механизма Admission Control в кластере VMware HA:

Очень просто - это так называемые Spare Hosts, то есть запасные и всегда свободные хосты ESXi, которые берут на себя нагрузку по размещению виртуальных машин только в случае сбоев других серверов, обрабатываемых механизмом VMware HA.

Эти хосты в обычной жизни будут простаивать, и, если на них не удастся запустить виртуальные машины в случае сбоя, VMware HA все равно перезапустит эти ВМ на других хостах ESXi. Также эти хосты не будут браться в расчет механизмом VMware DRS, то есть он не будет мигрировать туда виртуальные машины, даже на период обслуживания других хостов (Maintenance mode).

Так для чего же такая настройка вообще существует, если выгоднее держать просто больше запаса емкости на хостах кластера HA, но использовать все серверы в нем? Вариантов может быть 2:

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

Оба этих варианта очень маловероятны, поэтому, как правило, настройку Dedicated failover hosts использовать вообще не нужно.


Таги: VMware, HA, VMachines, ESXi, vSphere

Новое на VMware Labs - MyVMware CLI.


На сайте проекта VMware Labs появилось очередное обновление - утилита/интерфейс MyVMware CLI, который позволяет взаимодействовать с порталом My VMware (my.vmware.com) посредством командной строки.

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

С помощью MyVMware CLI можно скачать любой продукт VMware, любой версии, а также загружать различные файлы. Надо понимать, что к возможностям загрузки дистрибутивов с помощью данного средства будут применяться ограничения, действующие для используемого аккаунта My VMware (поэтому выведите список всех доступных продуктов командой vmw-cli list).

MyVMware CLI протестирована и работает на Linux или MacOS. Установить интерфейс можно с помощью NodeJS (через NPM) командой:

npm install vmw-cli --global

Также MyVMware CLI можно развернуть на платформе Docker:

docker run -t --rm -e VMWUSER='<username>' -e VMWPASS='<password>' -v ${PWD}:/files apnex/vmw-cli <cmd>

MyVMware CLI доступен из репозитория GitHub, где вы также можете увидеть примеры использования различных команд по листингу и загрузке продуктов VMware. Более подробно об использовании утилиты можно почитать здесь.


Таги: VMware, Labs, CLI, vSphere

Что нового в VMware vCenter 6.7 Update 2 - еще несколько подробностей.


Недавно компания VMware выпустила новую версию платформы виртуализации VMware vSphere 6.7 Update 2. Довольно много новых возможностей появилось в функциональности управляющего сервера VMware vCenter 6.7 Update 2. Давайте посмотрим, что именно с картинками и анимированными гифками:


Таги: VMware, vCenter, Update, vSphere

На каком чипсете материнской платы работают виртуальные машины VMware vSphere?


Интересный пост Дэвида Пасека про чипсет материнской платы виртуального аппаратного обеспечения виртуальных машин на платформе VMware vSphere. Оказывается, все ВМ, независимо от версии виртуального "железа" (включая Virtual Hardware Version 14 в vSphere 6.7 Update 1), используют одну и ту же виртуальную материнскую плату на базе Intel 440BX, которая в свойствах системы называется "440BX Desktop Reference Platform" (скриншот из гостевой ОС Windows 10):

Примечательно, что этот чипсет был выпущен в апреле 1998 года - в том же году, когда была основана VMware, а через год был выпущен первый продукт компании VMware Workstation. И вот с тех пор чипсет виртуальной материнской платы не менялся! Видимо, незачем вносить туда серьезные изменения, от него ничего особо в работе виртуальной машины не зависит.

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

Get-WMIObject win32_baseboard | Select-Object Product

Это же позволит вам определить, что, например, ваш сценарий или программа работает в ВМ.

В Linux, возможно, сработает эта команда:

# dmidecode | grep -C 3 'Base Board'


Таги: VMware, VMachines, Hardware, vSphere

Как попробовать инфраструктуру VMware в облаке Amazon - VMware Cloud on AWS Evaluation Guide.


Как вы знаете, уже довольно давно компании Amazon и VMware совместно продвигают публичное облако VMware Cloud on AWS, где можно взять в аренду виртуальные машины. Недавно компания VMware выпустила документ VMware Cloud on AWS Evaluation Guide, который позволит вам понять процедуру развертывания и начать тестирование виртуальной инфраструктуры в облаке VMConAWS.

В документе представлен обзор функциональности платформы, ее основные возможности и основные шаги по ее первоначальной конфигурации. Также рассматривается опциональный вариант сопряжения облачного SDDC (Software-Defined Data Center) и онпремизной виртуальной инфраструктуры с настройкой средств катастрофоустойчивости.

Вы также научитесь строить и конфигурировать сети software defined networks в гибридном облаке, настраивать сетевые экраны, развертывать сервисы DNS, VPN, отчетности и многое другое. Лучше всего использовать данное руководство с функциональностью сервиса Get Started в облаке VMConAWS (оно под него и заточено). Для построения гибридной облачной среды вам потребуется как минимум один хост ESXi на платформе vSphere 6.0 Update 3 или более поздней в своем датацентре.

Необычно и печально то, что сервис VMware Cloud on AWS не предоставляет бесплатного триала (у всех остальных он есть), поэтому нужно быть готовым сразу платить.

Есть еще 3 полезные ссылки, помимо данного Evaluation Guide: FeaturesUse Cases и FAQ. Также всем бесплатно доступна лабораторная работа Hands-On Lab for VMware Cloud on AWS.

Кстати, вот полезный PowerCLI сценарий, который позволит вам скачать документацию по VMware Cloud on AWS, которая публично доступна вот тут:

$url = "https://docs.vmware.com/en/VMware-Cloud-on-AWS/services/vmc-on-aws-networking-security.pdf",
"https://docs.vmware.com/en/VMware-Cloud-on-AWS/services/vmc-aws-operations.pdf", 
"https://docs.vmware.com/en/VMware-Cloud-on-AWS/services/vmc-on-aws-getting-started.pdf", 
"https://docs.vmware.com/en/VMware-Cloud-on-AWS/services/vmc-aws-manage-vms.pdf",
"https://docs.vmware.com/en/VMware-Cloud-on-AWS/services/vmc-aws-manage-data-center.pdf"

$url | ForEach-Object {Invoke-WebRequest -Uri $_ -OutFile ($_ | Split-Path -Leaf)}


Таги: VMware, vCloud, Amazon, VMConAWS, ESXi, vSphere, IaaS

Весенняя серия вебинаров от VMware 2019.


Компания VMware решила вновь заняться просветительской работой в российском сегменте и с марта запустила весеннюю серию вебинаров на русском языке. Но в апреле-мае осталось еще много интересных событий:

Тема вебинара Дата и время
Из администратора инфраструктуры виртуализации в Site Reliability Engineer: vSphere и Kubernetes – сравнение архитектур и почему вместе лучше 18 апреля в 11:00 мск
Виртуальные сети и безопасность для контейнеров на базе NSX Data Center 23 апреля в 11:00 мск
Современные технологии: VMware & Blockchain 25 апреля в 11:00 мск
Построение удаленного рабочего места и управление им 14 мая в 11:00 мск
Что нового в базовой виртуализации ЦОД 16 мая в 11:00 мск
Современная и компактная филиальная инфраструктура из vSphere, vSAN, NSX и VeloCloud 21 мая в 11:00 мск
VMware SD-WAN by VeloCloud: архитектура, основные компоненты, сценарии использования 28 мая в 11:00 мск
VMware Cloud Services (CAS, VMC) 30 мая в 11:00 мск

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

На данный момент уже прошли следующие мероприятия:

Тенденция BYOD: плюсы и ... плюсы 19 марта в 11:00 
Гиперконвергентная инфраструктура как фундамент программно-определяемого ЦОДа 21 марта в 11:00 
Технологии VMware для построения частного облака 26 марта в 11:00 
Безопасность рабочего места 28 марта в 11:00
Виртуальная Облачная Сеть (Virtual Cloud Network). Основные компоненты и сценарии использования 2 апреля в 11:00
Построение удобного, адаптивного и безопасного гибридного облака на платформе VMware Cloud Foundation 4 апреля в 11:00
Мониторинг программного ЦОДа 9 апреля в 11:00
Построение катастрофоустойчивого ЦОД для непрерывной работы вашего бизнеса 11 апреля в 11:00

Регистрация на вебинары находится по этой ссылке. Приходите!


Таги: VMware, Events, Webinars, vSphere

На VMware Labs обновилась утилита HCIBench до версии 2.0 - что нового?


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

Проект HCIbecnh ("Hyper-converged Infrastructure Benchmark") является оберткой для известного open source теста VDbench, он позволяет организовать автоматизированное тестирование гиперконвергентного кластера (HCI-кластера). Гиперконвергентный кластер - это когда все его вычислительные ресурсы, системы хранения и сети виртуализованы и собраны в единую интегрированную сущность и управляются из одной точки.

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

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

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

  • В качестве генератора рабочей нагрузки добавлена модель fio (Flexible I/O).
  • Для мониторинга рабочих нагрузок в реальном времени используется решение Grafana.
  • Пользовательский интерфейс теперь сделан на визуальном фреймворке Clarity, как и другие продукты VMware (например, vSphere Client на базе HTML5).
  • Пользователь может выбрать от одного до четырех вариантов использования при выборе метода easy-run.
  • Множество исправлений ошибок.

Вот так выглядит новый UI на Grafana в части мониторинга в реальном времени:

А вот так выглядит интерфейс конфигурации продукта на базе Clarity:

Скачать HCIBench 2.0 можно по этой ссылке.


Таги: VMware, Labs, HCIBench, Update, Monitoring, vSphere, vSAN, HCI

В какой enclosure и слоте находится диск VMware vSAN, какого он типа и емкости?


Часто администраторы виртуальной инфраструктуры VMware vSphere и отказоустойчивых кластеров VMware vSAN задаются вопросом, а как найти тот или иной диск vSAN в физическом сервере?

Иногда такую информацию можно получить с помощью следующей команды:

esxcli storage core device physical get -d <device id>

Вывод будет выглядеть следующим образом:

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

Также эту информацию можно посмотреть в разделе Cluster > Configure > vSAN > Disk Management, выбрав режим показа дисков "By Disk Vendors":

Но это тоже неудобно, хотелось бы такую информацию получать через PowerCLI. Информацию о дисковых устройствах можно получить с помощью командлета Get-ScsiLun, который выдает адаптер, к которому подключен диск, а также является ли он SSD-устройством, подходит ли для vSAN и другое. Но, к сожалению, он не дает данных об enclosure для этого диска, поэтому дополнительно нужно воспользоваться командлетом Get-EsxCli, который добавит эту информацию.

Таким образом, VMware предлагает использовать вот такой сценарий PowerCLI, который выведет информацию о физических устройствах, их нахождении в enclosure и слоте, а также типе дисков и их емкости:

Сам сценарий доступен по этой ссылке: https://code.vmware.com/samples/5539 (кстати, обратите внимание, что на портале VMware Code можно найти еще много чего интересного).


Таги: VMware, vSAN, PowerCLI, vSphere, VMachines, Hardware

Еженедельные видео от VMware Russia - подписывайтесь на канал.


Интересную новость прислал Андрей Коновалов - в российском офисе VMware коллеги запустили новую инициативу на российском канале, где публикуются короткие (до 10 минут) обзорные и обучающие видео о продуктах и технологиях VMware.

Проект называется "VMware по средам". Сейчас ребята записывают серию роликов о VMware PKS, а также планируют публиковать ролики по различным интересным темам - VMware Skyline, Workspace ONE и другим. Таким образом, вместо привычного маркетингового потока сознания, на канале VMware Russia имеют шанс быть освещенными интересные технические темы.

Сейчас пока на канале 3 плейлиста, но каждую неделю будет появляться что-то новое:

Подписывайтесь на канал или следите за обновлениями тут.


Таги: VMware, Video, vSphere

Что нового в анонсированном VMware vRealize Operations 7.5?


На днях компания VMware (помимо анонса серверной платформы vSphere 6.7 Update 2) анонсировала и скорую доступность продукта VMware vRealize Operations 7.5, предназначенного для комплексного управления и мониторинга виртуальной инфраструктуры. Напомним, что о прошлой версии этого решения - vROPs 7.0 - мы писали вот тут. Давайте посмотрим, что нового появилось в vROPs версии 7.5.

1. Улучшения механики оптимизации производительности.

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

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

2. Улучшения механизма управления емкостями датацентра.

Здесь произошел возврат к модели выделенных ресурсов (allocation) взамен модели потребляемых ресурсов (demand). Последняя оказалась эффективной только для небольших инфраструктур, а планирование больших датацентров лучше делать по номинальным значениям аппаратных запросов ВМ.

При этом для администратора на дэшборде Capacity параметры Allocation и Demand приведены рядом:

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

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

Также в этой категории фичей особо можно отметить комплексную и глубокую "what-if" аналитику, которая позволяет планировать, в том числе, гиперконвергентную инфраструктуру, а также миграции рабочих нагрузок в облака AWS, Azure и другие:

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

3. Функции интеллектуального исправления конфигураций виртуальной инфраструктуры.

Здесь появилась важная новая возможность - мониторинг ОС и приложений внутри виртуальных машин. Это дает много новых инструментов для изучения поведения и производительности инфраструктуры со стороны приложений.

vROPs автоматически обнаруживает приложения в вашей виртуальной инфраструктуре и добавляет их к себе в консоль. Далее администратор может решить - стоит ли их мониторить здесь в vROPs или нужно передать их на сторону решения Wavefront от VMware, заточенного под эти задачи.

Оба этих метода мониторинга используют агенты Telegraf для сбора метрик и отчетности:

В vROPs 7.5 появилось новое представление - виджет отношений объектов. Он показывает высокоуровневую связь приложения с компонентами датацентра. В рамках этого представления можно понять, связана ли проблема с самим приложением, или она вызвана нижележащими компонентами инфраструктуры. В рамках одного представления поддерживается до 10 000 объектов:

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

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

4. Интегрированный комплаенс.

Это новое направление функционала vROPs. Оно подразумевает выполнение процедур по обеспечению соответствия таким отраслевым стандартам, как PCI, HIPAA, DISA, ISO, CIS и FISMA. Помимо готовых шаблонов, вы сможете использовать кастомные наборы политик, для которых можно проводить приведение инфраструктуры в соответствие и мониторинг отклонений от заданного уровня. Для всего этого уже из коробки есть готовые рабочие процессы (Workflows) и интеграция с решением VMware vRealize Orchestrator.

 

Также надо отметить, что vROPs без проблем может мониторить облачную инфраструктуру VMware Cloud on AWS - для него это всего лишь еще один экземпляр окружения vCenter.

На данный момент продукт VMware vRealize Operations 7.5 еще недоступен для загрузки, новости можно отслеживать на его основной странице.


Таги: VMware, vROPs, Update, Operations, vSphere, Enterprise, Monitoring, vSAN

Анонсирована платформа VMware vSphere 6.7 Update 2 - много новых возможностей.


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

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

1. Новое издание VMware vSphere ROBO Enterprise.

Теперь в издании для ROBO-сценариев (Remote or Branch Offices) появились следующие возможности уровня Enterprise:

DRS в режиме обслуживания (Maintenance Mode):

  • Доступно только для vSphere ROBO Enterprise.
  • Может быть использовано для автоматического перемещения ВМ между хостами (и обратно по окончании процесса). Для этого автоматически создаются правила VM-Host affinity (отслеживается, куда машины уехали перед миграцией, потом запомненные правила применяются - и машины приезжают обратно, где и были изначально).
  • Применяются обычные требования vMotion.
  • Никакого визуального механизма настройки DRS нет.

Шифрование машин (VM Encryption):

  • Шифрование домашней директории и файлов VMDK.
  • Требуется инфраструктура KMS.
  • Полностью безразлично к гостевой ОС.
  • Управляется через GUI или PowerCLI.

2. Обновление архитектуры vCenter Server.

Утилита PSC Converge tool теперь доступна в графическом интерфейсе. Об этом средстве мы писали вот тут, оно позволяет смигрировать внешний сервер Platform Services Controller (PSC) на простой в управлении embedded PSC.

Она дает следующие возможности:

  • Конвертация топологии external PSC в Embedded через GUI.
  • Можно выполнить шаги по выводу внешнего PSC из эксплуатации (Decomission).

  • Все это доступно в разделе System Configuration тонкого клиента vSphere Client (на базе HTML5).
  • Можно посмотреть текущую топологию PSC и vCenter в графическом или табличном виде.
  • В следующих релизах будет невозможно развернуть внешний PSC, поэтому с него надо уходить.

3. Улучшения резервного копирования и восстановления vCenter Server.

Здесь появилось 2 главных улучшения:

  • Новые протоколы, посредством которых вы можете сделать бэкап vCSA - NFS v3 и SMB.
  • Нотификации и алармы на успешное и неуспешное завершение задач РК. Эти алармы можно настроить подобно обычным алармам vSphere (послать email, SNMP trap или выполнить сценарий в случае успеха или неудачи).

4. Новые алармы и категории для vSphere Health.

  • Опция acknowledgement (заглушить) для алармов vSphere health (как и для обычных алармов).
  • Новые категории теперь включают в себя:
    • Online Availability
    • Compute
    • Network
    • Storage
  • Эти новые категории позволяют более органично охватывать проблемы сервера vCenter и упрощать управление им.

5. Улучшения Content Library.

  • Функции синхронизации шаблонов VM Template (VMTX).
  • Шаблоны виртуальных машин теперь можно синхронизировать в автоматическом режиме, как между приватными облаками с серверами vCenter, так и с публичным облаком VMware Cloud on AWS.

6. Улучшения vSphere Client.

  • В vSphere Client появилась возможность "code capture" (о ней мы писали вот тут). Теперь она позволяет вести запись пользовательских действий, которые были сделаны в рамках текущей сессии через vCenter API, и генерация соответствующего скрипта. Далее его можно использовать для автоматизации задач в инфраструктуре vSphere.
  • Функции API Explorer (доступны в разделе "Developer Center") - простая утилита по поиску в API, которая позволяет найти основные API-вызовы, включая примеры и возможность их тестирования.
7. Улучшения vSphere Update Manager.
  • Улучшения пользовательского интерфейса, включая функции attach, compliance check и remediation (все можно делать на одном экране).
  • Теперь можно привязать и сделать remediate для нескольких бейслайнов в рамках одной операции.
  • Во время remediation можно отключать removable-девайсы от виртуальных машин, включать Quickboot и пропускать проверки vSAN HealthCheck.

8. Улучшения VMware Tools.

  • Для Windows Server 2016 тулзы теперь обновляются через Windows update, а значит, что их обновления включены в общий цикл апдейта системы.
  • Версия VMware tools for Linux (в формате .TAR) больше не развивается, начиная с VMware Tools 10.3.10, так как OpenVM Tools доступны через любой package update manager.

9. Фикс Host Profiles.

Теперь при применении профиля хоста к ESXi не удаляется интерфейс VMK0, как это было раньше.

10. Улучшения безопасности.

  • Windows Server 2019 и RHEL 8 теперь полностью поддерживаются в vSphere 6.7 Update 2.
  • Можно применять лимиты для Password History и Reuse.
  • Теперь логируются дополнительные события SSO.
  • Улучшения ESXi certification API.
  • Генерация запроса vCenter Server CSR доступна через GUI клиента.
  • vSphere 6.7 Update 2 лучше обрабатывает уязвимости CPU за счет нового планировщика.
  • Доступна сертификация NIAP.

11. Улучшения производительности.

  • Поддержка 40 & 100Gb Ethernet и RDMA
  • Новая версия Virtual Hardware 15 (VM Compatibility):
    • До 256 vCPU на виртуальную машину
    • До 6 ТБ RAM на ВМ
    • Поддержка SAP HANA

На момент написания статьи обновление VMware vSphere 6.7 Update 2 было еще недоступно. Мы обновим пост, когда обновление можно будет скачать.


Таги: VMware, vSphere, Update, ESXi, vCenter, Tools, Security, VMachines

Набор сценариев vDocumentation для создания отчета о различных аспектах инфраструктуры VMware vSphere через PowerCLI.


Интересный проект доступен на GitHub - набор скриптов vDocumentation, который позволяет через PowerCLI сгенерировать отчетность в форматах CSV или XLS, посвященную различным сторонам виртуальной инфраструктуры (сеть, хосты, кластеры vSAN и т.п.). Демо этого средства было представлено на VMworld 2017:

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

  • Get-ESXInventory - генерация всех аппаратных параметров хостов ESXi и их конфигураций.
  • Get-ESXIODevice - документирование конфигурации карт HBA, NIC и других PCIe-устройств, включая PCI ID, MAC, версии микрокода и драйверов.
  • Get-ESXNetworking - конфигурация сетевого окружения, включая детали сетевых адаптеров, коммутаторов vSwitches, параметры VMKernel и прочее.
  • Get-ESXStorage - параметры инфраструктуры хранилищ, включая детали iSCSI, FibreChannel, параметры датасторов и механизма доступа по нескольким путям (Multipathing).
  • Get-ESXPatching - информация об установленных обновлениях, времени их выхода и ссылки на соответствующие статьи KB.
  • Get-vSANInfo - документирование кластеров vSAN.
  • Get-ESXSpeculativeExecution - статус серверов ESXi в отношении уязвимостей Spectre и Meltdown.
  • Get-VMSpeculativeExecution - статус виртуальных машин в отношении уязвимостей Spectre и Meltdown.

Например, вот отчет о статусе хостов ESXi в отношении уязвимостей Spectre и Meltdown:

По умолчанию данные выводятся в терминал, но можно их перенаправить с CSV или XLS файлы.

Загрузить сценарии vDocumentation можно по этой ссылке.


Таги: VMware, vSphere, Documentation, Utilities, Бесплатно, PowerCLI

Обновление утилиты RVTools 3.11 для конфигурации виртуальной инфраструктуры VMware vSphere.


В марте прошлого года мы писали о выпуске пакета RVTools 3.10, предназначенного для помощи администраторам при выполнении рутинных операций с виртуальной инфраструктурой VMware vSphere в различных аспектах. Спустя год, в начале марта этого года, вышло обновление этого средства - RVTools 3.11 (а точнее, его версия 3.11.6).

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

  • Теперь для управления используется обновленный VMware vSphere Management SDK 6.7U1.
  • Windows Authentication Framework (Waffle) больше не используется.
  • Библиотека NPOI .NET больше не используется для генерации отчетов в Excel. Вместо этого используются компоненты OpenXML и ClosedXML.
  • Как следствие прошлого пункта - улучшения производительности при экспорте данных в Excel.
  • Добавлены параметры -ExcludeCustomAnnotations и –DBColumnNames в интерфейс CLI.
  • На вкладке vInfo добавлены новые колонки: дата создания ВМ, Primary IP, контрольная сумма vmx-файла, папки с логами ВМ, ее снапшотами и suspend-файлами.
  • На вкладке dvSwitch добавлены новые колонки: имя LACP, его режим и алгоритм балансировки.
  • На вкладке vNIC добавлена колонка с именем порта аплинка.
  • На вкладке vNetwork добавлена колонка Network Adapter DirectPath I/O.
  • На вкладке vHost появились колонки Serial number и BIOS vendor.
  • При экспорте в Excel шапка таблицы теперь закреплена.
  • Первая колонка "Select" убрана из таблиц экспорта для vFloppy, vCD и vTools.
  • Добавлен новый экзешник для слияния нескольких файлов xlsx для серверов vCenter в один большой:
    • RVToolsMergeExcelFiles.exe -input c:\temp\AA.xlsx;c:\temp\BB.xlsx -output
      c:\temp\AABB.xlsx -template c:\temp\mytemplate.xlsx -verbose –overwrite
  • Сценарий примера RVToolsBatchMultipleVCs.ps1 изменился, он теперь как раз использует утилиту RVToolsMergeExcelFiles из предыдущего пункта для слияния файлов.
  • Исправлены ошибки:
    • Проблема с SSO
    • Команды ExportvSC+VMK2csv и ExportdvPort2csv теперь работают
    • На вкладке vNIC теперь отображается вся информация для Switch/dvSwitch
    • При экспорте учитывается значение Latency Sensitivity
    • Улучшено обновление данных при изменении настроек
    • Файлы VMDK из Content Libraries теперь не отображаются как "зомби-файлы"

Скачать утилиту RVTools 3.11 можно совершенно бесплатно по этой ссылке. Документация доступна здесь.


Таги: VMware, vSphere, RVTools, Update, Бесплатно, Tools

VMware объявила о выпуске первого VMware Service-defined Firewall - попробуем разобраться, что это.


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

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

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

Использовав наработки этих трех продуктов за последние годы, компания VMware на днях анонсировала новое решение - первый в отрасли Service-defined Firewall.

Это решение основано на подходе по микросегментации приложений с точки зрения защиты виртуальной среды (см. service insertion и guest introspection), что подразумевает анализ сетевой активности на уровне приложения, при этом мониторинг ведется извне гостевой ОС на уровне гипервизора (данные берутся из NSX или напрямую с серверов ESXi), что позволяет исключить манипуляции средствами обнаружения вторжений, которые могут быть выполнены программным обеспечением внутри ОС.

Но главная штука VMware Service-defined Firewall - это возможность создания политик на уровне приложений/микросервисов, а не сетевых компонентов (серверов/ОС/портов). Это существенно упрощает ввод в эксплуатацию новых сервисов с точки зрения организации их защиты, а также обслуживания при перемещении виртуальных машин внутри датацентра и между ЦОДами.

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

VMware Service-defined Firewall позволит использовать новый подход к защите сетевой инфраструктуры предприятия за счет анализа приложений внутри периметра ЦОД (internal network firewalling), где наблюдение за сервисами происходит на уровне гипервизора и на седьмом уровне модели OSI (L7 packet inspection), без агентов в гостевых ОС, при этом используется модель Zero Trust (то есть изначально нет доверия ни одному компоненту в сети, считается, что атака может прийти откуда угодно, через любое сетевое соединение).

Суть защиты заключается в наблюдении за всеми приложениями датацентра, определении их "хорошего" поведения и далее детектировании отклонений от их повседневной активности, что влечет за собой оповещение администратора, который уже предпринимает действия по устранению угроз. При этом VMware Service-defined Firewall сам способен сгенерировать нужные политики для защиты приложений.

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

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

Что интересного можно почитать на тему VMware Service-defined Firewall:

Видео про возможности NSX-T 2.4, которые будут использованы в Service-defined Firewall:

Service-defined Firewall в действии и консоль AppDefense:


Таги: VMware, Security, Networking, NSX, vRNI, AppDefense, ESXi, vSphere

Некоторые аспекты использования VMware vSphere для задач машинного обучения и технология FlexDirect от компании BitFusion.


Вы все, конечно же, в курсе, что графические карты уже давно используются не только для просчета графики в играх и требовательных к графике приложениях, но и для вычислительных задач. Сегодня процессоры GPGPU (General Purpose GPU) используются в ИТ-инфраструктурах High Performance Computing (HPC) для решения сложных задач, в том числе машинного обучения (Machine Learning, ML), глубокого обучения (Deep Learning, DL) и искусственного интеллекта (Artificial Intelligence, AI).

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

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

Вот так, если обобщить, выглядит архитектура CPU - два уровня кэша на базе каждого из ядер и общий L3-кэш для шаринга данных между ядрами:

Число ядер на CPU может достигать 32, каждое из которых работает на частоте до 3.8 ГГц в турбо-режиме.

Графическая карта имеет, как правило, только один уровень кэша на уровне вычислительных модулей, объединенных в мультипроцессоры (Streaming Multiprocessors, SM), которые, в свою очередь, объединяются в процессорные кластеры:

Также в видеокарте есть L2-кэш, который является общим для всех процессорных кластеров. Набор процессорных кластеров, имеющих собственный контроллер памяти и общую память GDDR-5 называется устройство GPU (GPU Device). Как видно, архитектура GPU имеет меньше уровней кэша (вместо транзисторов кэша на плату помещаются вычислительные блоки) и более толерантна к задержкам получения данных из памяти, что делает ее более пригодной к параллельным вычислениям, где задача локализуется на уровне отдельного вычислительного модуля.

Например, если говорить об устройствах NVIDIA, то модель Tesla V100 содержит 80 мультипроцессоров (SM), каждый из которых содержит 64 ядра, что дает в сумме 5120 ядер! Очевидно, что именно такие штуки надо использовать для задач ML/DL/AI.

Платформа VMware vSphere поддерживает технологию vGPU для реализации такого рода задач и возможности использования виртуальными машинами выделенных ВМ модулей GPU. В первую очередь, это все работает для карточек NVIDIA GRID, но и для AMD VMware также сделала поддержку, начиная с Horizon 7 (хотя и далеко не в полном объеме).

Если говорить о задачах машинного обучения, то мы уже писали о результатах тестирования Machine Learning/Deep Learning задач на платформе VMware vSphere. Все это уже сейчас используется в здравоохранении, страховании, финансах и других отраслях.

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

Обмен данными может быть организован как по TCP/IP, так и через интерфейс RDMA, который может быть организован как подключение Infiniband или RoCE (RDMA over Converged Ethernet). О результатах тестирования такого сетевого взаимодействия вы можете почитать тут.

При этом FlexDirect позволяет использовать ресурсы GPU как только одной машине, так и разделять его между несколькими. При этом администратор может выбрать, какой объем Shares выделить каждой из машин, то есть можно приоритизировать использование ресурсов GPU.

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

Более подробно о настройке FlexDirect написано здесь, а документация по продукту доступна тут.


Таги: VMware, vSphere, vGPU, NVIDIA, ML, ESXi, vSphere

Как создать алармы (Alarms) для любых событий (Events) в VMware vSphere.


Очень дельную статью написал Вильям Лам, касающуюся настройки алармов для различных событий в инфраструктуре VMware vSphere. Иногда системному администратору требуется настроить мониторинг каких-либо действий пользователей, которые вызывают генерацию событий в консоли vSphere Client.

Например, вы хотите получать аларм, когда пользователь создает папку (Folder) для виртуального окружения через vSphere Client. Для начала нам понадобится информация, которую мы будем использовать в описании аларма. Для этого мы делаем действие, генерирующее событие, вручную (в данном случае, создаем папку), а после этого идем в раздел Monitor->Tasks, где смотрим описание задачи и связанного с ней события:

Главное здесь для нас - это лейбл "Task: Create folder", по которому мы найдем этот тип событий через PowerCLI, а точнее его Description Id. Открываем консоль PowerCLI и выполняем там вот такую команду, указав лейбл нашего события, найденный в консоли vSphere Client:

$createFolderEvents = Get-VIEvent | where {$_.GetType().Name -eq "TaskEvent" -and $_.FullFormattedMessage -eq "Task: Create folder" }
$createFolderEvents[0].Info.DescriptionId

Результатом будет Description Id нашего события - это Folder.createFolder:

Далее можно создавать аларм, зная Description Id события. Выбираем тип условия Task event, а также описание в виде Description Id, тип условия end with и сам этот ID - Folder.createFolder:

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

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


Таги: VMware, vSphere, Troubleshooting, Blogs, Client, PowerCLI

1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | 31 | 32 | 33 | 34 | 35 | 36 | 37 | 38 | 39 | 40 | 41 | 42 | 43 | 44 | 45 | 46 | 47    >   >>
Реклама







Зал Славы Рекламодателя
Ближайшие события в области виртуализации:

Быстрый переход:
VMware Veeam IT-Grad StarWind PowerCLI Offtopic Gartner Citrix VSAN GDPR 5nine Hardware VeeamON Nutanix vSphere RVTools Enterprise Security Code Cisco vGate Microsoft Cloud SDRS Parallels IaaS HP VMFS VM Guru Oracle Red Hat Azure KVM VeeamOn 1cloud Docker Storage NVIDIA Partnership Dell Virtual SAN Virtualization VMTurbo vRealize VirtualBox Symantec Softline EMC Login VSI Xen Teradici Amazon NetApp VDI Linux Hyper-V IBM Google VSI Security Windows vCenter VMachines Webinar View VKernel Events Windows 7 Caravan Apple TPS Hyper9 Nicira Blogs Sun VMC Xtravirt Novell IntelVT Сравнение VirtualIron XenServer CitrixXen ESXi ESX ThinApp Books P2V Labs Tools vSAN vCloud Forum iSCSI SRM HCI App Volumes Video vROPs Workspace ONE Backup Horizon VMUG NSX vRNI HA Update Manager VCP VVols Workstation Update UEM DR Networking Cache Storage DRS VMworld Workspace DRS Fusion Lifecycle Visio Log Insight Operations Manager SDDC Virtual Appliance OpenStack PowerShell LSFS Client vCSA Datacenter Intel Agent esxtop Book Photon Cloud Computing SSD Comparison Blast Performance Nested AWS XenDesktop VSA vNetwork SSO Host Client VMDK VTL Whitepaper Appliance VUM V2V Support Обучение Web Client Mobile Automation Replication Desktop Fault Tolerance Vanguard SaaS Connector Event Free SQL Sponsorship Finance FT Containers Converter XenApp Snapshots vGPU Auto Deploy SMB RDM Mirage XenClient MP SC VMM Certification VDP Partners PCoIP RHEV vMA Award Network USB Licensing Logs Server Demo vCHS Calculator Бесплатно vExpert Beta SAN Exchange MAP ONE DaaS Monitoring VPLEX UCS SDK Poster VSPP Receiver vMotion VDI-in-a-Box Deduplication Reporter vShield ACE Go nworks iPad XCP Data Recovery Documentation Sizing Pricing VMotion Snapshot FlexPod VMsafe Enteprise Monitor vStorage Essentials Live Migration SCVMM TCO Studio AMD-V VirtualCenter NFS ThinPrint Memory CLI Helpdesk Troubleshooting VIC Upgrade VDS Bug Migration Director Stencils API Android Graphics Diagram Air Plugin DPM SIOC Flex Mac Open Source SSH VAAI Chargeback Heartbeat MSCS Ports SVMotion Bugs Composer
Интересные плакаты:

Постер VMware vSphere PowerCLI 6.3:

Постер VMware ESXi 5.1:

Постер VMware Hands-on Labs 2015:

Постер VMware Platform Services Controller 6.0:

Постер VMware vCloud Networking:

Постер VMware NSX (референсный):

Постер VMware vCloud SDK:

Постер VMware vCloud Suite:

Постер VMware vCenter Server Appliance:

Порты и соединения VMware vSphere 6:

Порты и соединения VMware Horizon 7:

Порты и соединения VMware NSX:

Управление памятью в VMware vSphere 5:

Как работает кластер VMware High Availability:

Постер VMware vSphere 5.5 ESXTOP (обзорный):

Постер Veeam Backup & Replication v8 for VMware:

Постер Microsoft Windows Server 2012 Hyper-V R2:

 

Популярные статьи:
Как установить VMware ESXi. Инструкция по установке сервера ESXi 4 из состава vSphere.

Включение поддержки технологии Intel VT на ноутбуках Sony VAIO, Toshiba, Lenovo и других.

Как настроить запуск виртуальных машин VMware Workstation и Server при старте Windows

Как работают виртуальные сети VLAN на хостах VMware ESX / ESXi.

Что такое и как работает виртуальная машина Windows XP Mode в Windows 7.

Типы виртуальных дисков vmdk виртуальных машин на VMware vSphere / ESX 4.

Сравнение Oracle VirtualBox и VMware Workstation.

Инфраструктура виртуальных десктопов VMware View 3 (VDI)

Бесплатные утилиты для виртуальных машин на базе VMware ESX / ESXi.

Как использовать возможности VMware vSphere Management Assistant (vMA).

Проектирование инфраструктуры виртуализации VMware vSphere 4.

Как поднять программный iSCSI Target на Windows 2003 Server для ESX

Работа с дисками виртуальных машин VMware.

Бесплатные программы для VMware ESX / ESXi в среде Virtual Infrastructure / vSphere (часть 2).

Новые возможности VMware vSphere 5.0 - официально.

Все ресурсы о виртуализации:
Интервью:

Alessandro Perilli
virtualization.info
Основатель

Ратмир Тимашев
Veeam Software
Президент


Купить:

VMware vSphere 6.5


Veeam Backup 9.5


Полезные ресурсы:


Видео компании VMware

Видео про Citrix Xen

Видео о виртуализации Microsoft

Утилиты для виртуальных машин Microsoft.

Книги на английском языке

Блоги на английском языке

Блоги на русском языке

Агрегация статей в твиттере VMC:


Copyright VM Guru 2006 - 2019, Александр Самойленко. Правила перепечатки материалов.