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

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

Для каждого элемента (документа или статьи KB) показывается дата его обновления. Если мы откроем конкретную статью, то помимо самого контента, внизу будет полезный раздел Related Links, откуда можно накопать еще много всего интересного.

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

Ну а вот официальный анонс бета-версии портала docs.vmware.com от его команды разработчиков:

Как знают некоторые администраторы VMware vSphere, среди интерфейсов vSphere API есть механизм взаимодействия с виртуальными машинами через VMware Tools, который называется VMware vSphere Guest API.

Утилита VMware Tools Client, написанная Pierre Laine, позволяет подключиться к виртуальной машине через этот интерфейс, загружать/скачивать с нее файлы и скрипты и исполнять их. Это может оказаться полезным, когда вы потеряли сетевой доступ к виртуальной машине (например, внутри гостевой ОС что-то отвалилось).

VMware Tools Client соединяется с сервером vCenter, получает его иерархию через vCenter Inventory Service, после чего можно работать с виртуальными машинами для следующих целей:

• Выполнение в гостевой ОС отдельных команд (например, пинг из ВМ) или скриптов
• Загрузка, сохранение и удаление скриптов на ВМ (а также любых других файлов)
• Загрузка скрипта из файла

Утилита кроссплатформенная с интерфейсом на JavaFX, поэтому может быть запущена на Linux/Windows системах. Также она не требует установки. На данный момент она находится в бете версии 0.2. В составе идет база данных SQLLite, в которой хранятся логины/пароли от vCenter и виртуальных машин. Скачать VMware Tools Client можно по этой ссылке.

В свете последних событий, связанных с WannaCry ransomware, очень актуальным становится проверка наличия того или иного установленного патча (Patch/Hotfix/KB) внутри ОС виртуальных машин. Test-VMHotfix из моего PowerCLI Vi-Module модуля быстро и эффективно проверит все ваши ВМ. Пользоваться функцией проще простого, передайте в pipeline ВМ для проверки и шаблон названия патча в параметре -KB...
Таги: VMware, PowerCLI, Security, vSphere, VMachines

Утилита Autopology на сайте VMware Labs - WYSIWYG-редактор для проектирования NSX-инфраструктуры.

Некоторые из вас знакомы с решением VMware NSX, представляющим собой комплексный продукт для виртуализации и агрегации сетей датацентра. На днях на сайте проекта VMware Labs появилось интересное средство Autopology, позволяющее в проектировать сети NSX с помощью визуального редактора:

Вот основные задачи, решаемые Autopology:

• Интерфейс drag and drop для создания графического представления логических сетей датацентра.
• Возможность создания копий секций сетевой топологии в один клик.
• Возможность вернуться к нарисованной архитектуре сети впоследствии для сверки полученного результата.
• Возможность перейти к интерфейсу NSX Manager для дальнейшей кастомизации логических сущностей сетевого взаимодействия в любой момент.
• Возможность присоединения нескольких виртуальных машин к логическим сущностям. ВМ могут работать на базе гипервизора ESXi или KVM.

Особенно решение Autopology будет полезно для новичков, которые только приступили к настройке и конфигурации NSX (что очень непросто поначалу). Вот что даст администраторам эта новая утилита:

• Единое представление логического дизайна сети, в отличие от нескольких представлений NSX.
• Интеллектуальное выставление дефолтных настроек позволяет более правильно и унифицированно сконфигурировать сеть.
• Можно быстро масштабировать сети в несколько кликов мыши.
• Единый инвентарь для рабочих нагрузок на базе разных гипервизоров.
• Представление вычислительных и сетевых ресурсов в едином пространстве.

Для работы с утилитой (запуска сервера) вам потребуется машина Ubuntu 16.04 со следующими предустановленными пакетами:

• apt-get install python-pip
• apt-get install python-libvirt
• apt-get install libssl-dev
• apt-get install python-dev
• apt-get install libffi-dev

В качестве браузера можно использовать Chrome и Firefox. Скачать Autopology можно по этой ссылке. Будем надеяться, что такой удобный интерфейс появится в следующей версии VMware NSX.

Оказывается, еще в начале мая компания HP совместно с VMware выпустила кастомизированный образ гипервизора vSphere - HPE Customized ESXi May 2017, предназначенного для установки на серверы HP.

Этот релиз для многих администраторов является важным событием, так как прошлый кастомизированный образ HPE Custom ESXi от ноября 2016 года содержал в себе некоторые проблемы, касающиеся драйверов и работы с хранилищами (в частности, наблюдалась низкая скорость записи на локальные диски). Возможно, в этом релизе данные проблемы решены, по крайней мере новый набор драйверов должен улучшить некоторые вещи.

HPE Customized ESXi May 2017 доступен для скачивания по этой ссылке. Предыдущие образы (для более ранних версий гипервизора) можно также скачать с сайта VMware по этим ссылкам:

• vSphere 6.0 U3 Feb 2017
• vSphere 6.0 U2 Dec 2016
• vSphere 6.0 U1 Jan 2016
• vSphere 6.0 July 2015
• vSphere 5.5 U3 Dec 2016
• vSphere 5.5 U2 Sept 2015
• vSphere 5.5 U1 Dec 2014
• vSphere 5.5 June 2014
• vSphere 5.1 U3 Apr 2016

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

Очередная полезность обновилась на VMware Labs - на этот раз это оптимизированный под виртуальную среду и готовый к развертыванию образ виртуального десктопа Ubuntu OVA for Horizon. С помощью этого виртуального модуля VDI-администраторы могут быстро развернуть инфраструктуру виртуальных ПК на Linux-платформе, получив уже все необходимые настройки и оптимизации в рамках OVA-пакета.

Особенности средства Ubuntu OVA for Horizon:

• Базовый образ Ubuntu версии 16.04.2 LTS.
• Виртуальное аппаратное обеспечение VMware HW v11 (для работы требуется ESXi 6.0 U2+).
• Дефолтные имя пользователя и пароль - viewadmin/viewadmin.
• Виртуальная машина включает 2 скрипта: horizon-optimizer.sh, который конфигурирует машину в соответствии с лучшими практиками документации по Horizon 7, а также linux-agent-installer.sh, который помогает с установкой агента Horizon View Agent.
• Дополнительные твики и приложения, которые могут пригодиться администраторам.
• Из-за ограничений VMware агент пока не предустановлен в этот OVA-модуль, его надо скачать вручную и запустить linux-agent-installer.sh.
• Виртуальный модуль OVA был протестирован с инфраструктурой Windows 2003, 2008, 2012 и совместим с Samba Domains.
• Для работы модуля потребуется vSphere 6.0 U2 или более поздняя версия, Horizon Connection Server 7.1 или более поздний, Horizon Client 4.4 или позднее.

Это уже версия 1.1 данного модуля (о первой версии мы писали вот тут). Вот что добавилось за последние 2 месяца:

• Релиз только на основе оболочки MATE (GNOME больше не включают)
• Увеличенная vRAM до 128 MB вместо Automatic по умолчанию
• Удалено аудио-устройство (большинству не нужно)
• Сетевая карта VMXNET3 по умолчанию
• Обновленный репозиторий для open-vm-tools на Ubuntu repo
• Добавлены зависимости Horizon 7.1 Agent
• Обновленные пакеты зависимостей для Ubuntu 16.04 on Horizon 7.1
• Обновлен установщик и ссылки для Horizon 7.1
• Обновлены пакеты медиа-кодеков для Ubuntu 16.04
• Обновлены пакеты MATE на Xenial
• Более надежное присоединение к домену
• Опциональная смена пароля
• Опциональное задание таймзоны
• Опционально ставятся десктоп-аддоны
• Добавлены попытки повторного выполнения wget для конфиг-файлов smb и krb5
• horizon-linux-installer.sh переименован в linux-agent-installer.sh

Скачать Ubuntu OVA for Horizon можно по этой ссылке.

Недавно на сайте проекта VMware Labs появилась интересная утилита - Host Profiles CLI. Она позволяет администраторам VMware vSphere из командной строки выполнять те операции, которые недоступны в графическом интерфейсе механизма настройки хостов ESXi Host Profiles или доступны ограниченно (без средств автоматизации). Особо стоит отметить возможность совместного использования механизмов Auto Deploy и Host Profiles CLI.

Напомним, что профили хостов (Host Profiles) - это средство конфигурации серверов ESXi таким образом, что единый "золотой" профиль применялся к всем хостам, настраивая их единообразно, что уменьшает риски ошибок конфигурации, а также улучшает управляемость/обслуживание инфраструктуры и ее безопасность.

С помощью Host Profiles CLI из командной строки можно делать следующее:

• Кастомизация stateless-хостов Auto Deploy до их загрузки и присоединения к vCenter Server.
• Импорт/экспорт профилей хостов из локальных файлов.
• Привязка профиля к существующему кластеру.
• Установка единого рутового пароля в профиле или настройка профиля таким образом, чтобы использовать уникальные пароли root для каждого из хостов.
• Настройка системного кэша (stateless, cached или stateful install).
• Просмотр всех профилей хостов, доступных на vCenter Server.

Напомним, что начиная с vSphere 6.5, для механизма Host Profiles можно указывать параметры кастомизации отдельных хостов (IP-адреса, пароли и прочее) в CSV-файле. Но это можно делать только для хостов, которые были уже добавлены в Inventory сервера vCenter. С помощью Host Profiles CLI можно сделать прекастомизацию хостов через файлы CSV, которые будут развернуты через Auto Deploy (то есть, самих хостов пока еще нет в vCenter).

Ну и вот так можно делать импорт и экспорт профилей хостов (не пытайтесь делать импорт профиля для окружения с другим оборудованием хост-серверов):

# hostprofilescli hostprofile --profile esxi65-nfs-gen8 export --file esxi65-nfs-gen8.vpf

# hostprofilescli hostprofile --profile esxi65-nfs-gen8 import --file esxi65-nfs-gen8.vpf

А вот так можно установить пароль root для всех хостов один или свой для каждого:

hostprofilescli hostprofile --profile esxi65-nfs-gen8 useraccount-password set --type allhosts

hostprofilescli hostprofile --profile esxi65-nfs-gen8 useraccount-password set --type perhost

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

hostprofilescli hostprofile --profile esxi65-nfs-gen8 attach --entity dbcluster

Также посредством Host Profiles CLI можно установить тип развертывания хостов через Auto Deploy - Stateless caching (когда хост в случае массового сбоя и недоступности PXE-сервисов грузится из локальной кэшированной копии) или Stateful install (когда хост грузится с диска и уже больше не зависит от Auto Deploy). Вот как это делается:

hostprofilescli hostprofile --profile esxi65-nfs-gen8 system-image host set \

--type stateful-install --firstdisk_arguments localesx,local --ignore_ssd --overwrite_vmfs

Более подробная информация об использовании Host Profiles CLI приведена в документации. Загрузить этот интерфейс можно по этой ссылке.

Чтобы сделать бэкап всего сервера VMware vCenter Server или VMware vCenter Server Appliance (vCSA), вы можете воспользоваться продуктом Veeam Backup and Replication, либо сделать резервную копию встроенными средствами (например, через Management Interface - VAMI). Но это забэкапит весь сервер в целом, а иногда требуется создать резервную копию только базы данных vPostgres, чтобы впоследствии можно было быстро восстановить ее.

Для решения этой задачи была сделана KB 2091961, в которой описываются методы бэкапа и восстановления БД vCenter и vCSA. Приведем их здесь вкратце.

Бэкап и восстановление БД VMware vCenter Server:

Резервное копирование:

1. Заходим как администратор на Windows-машину с vCenter и находим файл vcdb.properties в директории %VMWARE_CFG_DIR%\vmware-vpx\, далее открываем его в редакторе.
2. Находим там пароль пользователя БД vCenter и сохраняем его.
3. Скачиваем пакет windows_backup_restore.zip по ссылке в конце статьи VMware KB и распаковываем его.
4. В командной строке идем в папку %VMWARE_CIS_HOME%\Python\ и запускаем сценарий backup_win.py, где вводим пароль для пользователя БД, сохраненный на шаге 2, и путь к каталогу бэкапа.

Например, если вы хотите захотите сделать бэкап в C:\backup_VCDB.bak, выполните следующую команду (s_PJmbGzC83QRYlp - это пароль):

python.exe c:\backup_win.py -p "s_PJmbGzC83QRYlp" -f c:\backup_VCDB.bak 

Восстановление работает так:

1. Заходим под администратором на vCenter и останавливаем службы vCenter Server и VMware Content Library. Для этого: 
   
   
   1. Идем в Start > Administrative Tools > Services.
   2. Нажимаем правой кнопкой на VMware VirtualCenter Server и выбираем Stop.
   3. Нажимаем правой кнопкой на VMware Content Library Service и нажимаем Stop. 
      
      
2. Открываем файл vcdb.properties в каталоге  %VMWARE_CFG_DIR%\vmware-vpx\, находим там пароль пользователя БД vCenter и сохраняем его.
3. Скачиваем пакет windows_backup_restore.zip по ссылке в конце статьи VMware KB и распаковываем его.
4. В командной строке идем в папку %VMWARE_CIS_HOME%\Python\ и запускаем сценарий restore_win.py, где вводим пароль для пользователя БД, сохраненный на шаге 2, и путь к файлу бэкапа.
   
   Если, например, вы сохранили бэкап в C:\backup_VCDB.bak, то выполните следующую команду (s_PJmbGzC83QRYlp - это пароль):
   
   python.exe c:\restore_win.py -p "s_PJmbGzC83QRYlp" -f c:\backup_VCDB.bak
   
   
5. Запустите служюы vCenter Server и VMware Content Library.

Бэкап и восстановление БД VMware vCenter Server Appliance:

Резервное копирование:

1. Заходим в консоль vCenter Server Appliance как root.
2. Скачиваем пакет 2091961_linux_backup_restore.zip по ссылке в конце статьи VMware KB и распаковываем его.
3. Делаем скрипт backup_lin.py исполняемым. 
   
   Например, такой командой:
   
   chmod 700 /tmp/backup_lin.py
   
   
4. Выполняем скрипт backup_lin.py, указав размещение бэкап-файла: 
   
   python /tmp/backup_lin.py -f /tmp/backup_VCDB.bak

Восстановление работает так:

1. Заходим в консоль vCenter Server Appliance как root.
2. Скачиваем пакет 2091961_linux_backup_restore.zip по ссылке в конце статьи VMware KB и распаковываем его.
3. Делаем скрипт restore_lin.py исполняемым. 
   
   Например, такой командой:
   
   chmod 700 /tmp/restore_lin.py
   
   
4. Останавливаем службы vmware-vpxd и vmware-vdcs services следующими командами: 
   
   service vmware-vpxd stop
service vmware-vdcs stop
   
   
5. Выполняем скрипт restore_lin.py, указав размещение бэкап-файла::
   
python /tmp/restore_lin.py -f /tmp/backup_VCDB.bak
   
   
6. Запускаем службы vmware-vpxd и vmware-vdcs services следующими командами: 
   
   service vmware-vpxd start
service vmware-vdcs start

В начале мая компания VMware выпустила очередное обновление своего основного средства для управления инфраструктурой VMware vSphere - vSphere Client 3.13. Три недели назад мы писали о нововведениях версий 3.10 и 3.11, а сегодня расскажем о новых возможностях обновлений 3.12 и 3.13.

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

• Перекрывающие настройки распределения вычислительной нагрузки (VDRS) и нагрузки на хранилища (SDRS) могут быть теперь заданы.
• Для виртуальных машин появилась настройка кластеров непрерывной доступности Fault Tolerance.
• Стали доступны возможности Cross vCenter Server vMotion.
• В списке хостов можно выбрать столбец с версией ESXi (по умолчанию не выбран).
• Версия виртуального модуля видна в меню Help -> About VMware vSphere.
• Доступна настройка VM Compliance для механизма политик хранилищ (Storage Policies).
• Для распределенного коммутатора появились возможности добавления хостов и управления ими.
• Появилось действие Check Policy compliance для политик хранения машины (VM Storage Policy).
• Возможность создания новой виртуальной машины с кастомными VMware Tools и опциями загрузки (устанавливаются на странице Customize Hardware > VM Options).
• Улучшения для пользователей с ограниченными пермиссиями при конфигурации ВМ.

Загрузить VMware vSphere Client 3.13 можно по этой ссылке.

На сайте проекта VMware Labs появился интересный PowerCLI-скрипт vCenter Cluster Performance Tool, с помощью которого можно получить информацию о производительности кластера за счет агрегации данных, поступающих от хостов VMware ESXi.

Это уже вторая версия сценария, переработанная на базе механизма модулей PowerCLI 6.0 (ранее она была построена на снипетах).

Для работы сценария понадобится указать 2 следующих параметра:

• Интервал от 20 до 300 секунд. По умолчанию это 20 секунд, что соответствует сбору статистики в близкому к реальном времени, а значение 300 даст пятиминутный интервал между сборами, чтобы не создавать лишнюю нагрузку.
• Специальный флаг для получения списка уникальных идентификаторов счетчиков производительности, доступных на vCenter Server (нужно указать -1 в качестве аргумента для получения списка). Далее можно использовать один из полученных идентификаторов для вывода соответствующей метрики для кластера.

Возможности скрипта vCenter Cluster Performance Tool:

• Сбор всех данных в указанном интервале, которые доступны на каждом хосте заданного кластера.
• Простой способ запуска сценария.
• Данные сохраняются в файл CSV, которые можно подставить в любое средство визуализации.
• Также генерируется график в формате картинки PNG (как показано выше).

Для работы скрипта потребуется VMware vCenter Server 5.0 или более поздний, а также Microsoft Chart Controls для Microsoft .NET Framework 3.5. Скачать vCenter Cluster Performance Tool можно по этой ссылке.

Некоторые из вас помнят, что в VMware vSphere 6.5 одной из новых возможностей гипервизора ESXi 6.5 стала функция его безопасной загрузки (Secure Boot). Об этом мы уже упоминали в посте с видеороликами о новых возможностях vSphere 6.5:

Суть механизма безопасной загрузки в vSphere 6.5 заключается в том, что загрузка подписанного кода гипервизора ESXi контролируется со стороны UEFI firmware, а также не разрешается исполнение неподписанных пакетов.

UEFI (Unified Extensible Firmware Interface) - это замена традиционному BIOS в серверах и настольных ПК. Механизм Secure Boot - это один из "протоколов" UEFI, который предоставляет возможности контроля загрузки подписанного кода за счет хранения цифровых сертификатов, которые хранятся в микрокоде (firmware) компьютера (signature database). Это все позволяет убедиться в том, что некий root kit не будет присутствовать в составе загружаемых компонентов и не предоставит доступ злоумышленнику на самом низком уровне.

Большинство UEFI содержит набор сертификатов по умолчанию типа x509 Microsoft UEFI Public CA, а также позволяет устанавливать собственные сертификаты дополнительно. Надо отметить, что эти сертификаты поставляются производителем серверов и обновляются вместе с его микрокодом.

Для обеспечения безопасной загрузки используются следующие компоненты:

• Загрузчик ESXi (boot loader) - он убеждается в том, что цифровая сигнатура кода не была изменена. Загрузчик подписан сертификатом Microsoft UEFI Public CA. Он также содержит VMware public key, с помощью которого проверяются компоненты VM Kernel, Secure Boot Verifier, а также пакеты VIB.
• Ядро VM Kernel - это также подписанная часть кода. Первое, что делает VM Kernel, это запускает Secure Boot Verifier.
• Secure Boot Verifier - он также хранит VMware public key и проверяет аутентичность всех VIB-пакетов, которые загружаются во время загрузки ESXi.
• VIB-пакеты (vSphere Installation Bundles) - эти пакеты, помимо реализуемых ими сервисов, содержат файл XML descriptor и файл цифровой подписи (digital signature file). Во время загрузки ESXi в памяти создается "карта" содержимого каждого из VIB-пакетов, соответственно не требуется проверять каждый из его файлов, а достаточно проверить подпись пакета целиком (это быстрее работает).

Вот как выглядит процесс загрузки хоста ESXi с точки зрения Secure Boot:

• Включение питания.
• UEFI Firmware валидирует загрузчик ESXi Boot Loader на предмет соответствия сертификату Microsoft внутри микрокода UEFI.
• ESXi Boot Loader валидирует компонент VM Kernel на предмет соответствия сертификату в Boot Loader.
• VM Kernel запускает компонент Secure Boot Verifier.
• Secure Boot Verifier валидирует каждый VIB-пакет на соответствие сертификату VMware, который находится в хранилище Secure Boot Verifier.
• Запускаются необходимые сервисы управления (DCUI, hostd и т.п.).

При апгрейде VMware ESXi прошлых версий с помощью ESXCLI происходит обновление сигнатур VIB-пакетов, но Boot Loader остается прежним, поэтому когда вы включите Secure Boot - возникнет ошибка. Как следствие - нужно будет переустановить ESXi.

Если вы обновляете ESXi из ISO-образа, то для некоторых старых VIB-пакетов сигнатуры могут не обновиться (например, кастомные драйвера, которые вы устанавливали отдельно), что приведет к неудаче при безопасной загрузке. То есть для нормального обновления из ISO нужно, чтобы все VIB-пакеты в этом образе обновили все предыдущие VIB. Надо отметить, что VIB-пакеты уровня Community supported не поддерживаются для безопасной загрузки (так как они не подписаны).

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

Сначала надо проверить, что серверы поддерживают UEFI secure boot. Далее надо убедиться, что все ваши VIB-пакеты имеют хотя бы уровень Partner Supported, и у вас нет Community Supported пакетов.

Если вы обновили хост на ESXi 6.5, то можно выполнить следующий скрипт для проверки возможности включения Secure Boot:

/usr/lib/vmware/secureboot/bin/secureBoot.py -c

Результатом будет строчка "Secure Boot can be enabled" или "Secure boot CANNOT be enabled".

Если вы включите Secure Boot в микрокоде сервера, но у вас есть неподписанные пакеты, то при загрузке сервера вы увидите розовый экран и сообщение о том, что нельзя проверить подписи VIB-пакетов:

Чтобы выйти из этой ситуации, надо выключить безопасную загрузку, удалить неподписанные VIB-пакеты и снова включить ее.

Еще одна фишка включенной функции Secure Boot - это то, что вы не сможете установить неподписанные VIB-пакеты с опцией force подобным образом:

"esxcli install software –d /drive/badvib.zip –force –<b>no</b>-sig-check"

Если говорить о модуле TPM, то он тут не участвует, и мало того - TPM 2.0 вообще не поддерживается со стороны VMware vSphere 6.5.

Ну и последнее. Если вы хотите использовать Secure Boot вместе с механизмом vSphere Auto Deploy, то вы должны добавить сертификат VMware в список UEFI firmware whitelist (DB). Это требуется потому, что только ESXi Boot Loader подписан сертификатом Microsoft, а часть кода PXE-загрузчика, которая грузится до Boot Loader, подписана сертификатом VMware. Более подробно об этом написано в KB 2148532.

Мы уже писали о новых возможностях последней версии продукта для создания кластеров хранилищ VMware vSAN 6.6, а также давали ссылки на пару полезных технических видео и документ.

Хорошим дополнением к этому будет видео ниже, в котором в течение 80 минут рассказывается о тонкостях возможностей продукта с технической стороны (правда там нет обзора фич последних версий 6.5/6.6).

Видео предназначено для тех, кто хочет понять, как работает кластер vSAN, что такое Disk Object, Storage Policies, как работает флэш-кэш, растянутый кластер и другие штуки. Если вас не раздражает индусский английский, то видео вполне интересное.

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

Ну и не забывайте про плейлист о VMware vSAN на ютубе.

Интересный пост написал Cormac Hogan, касающийся конфигурации растянутых кластеров VMware vSphere Stretched Clusters и размещения компонентов Witness VM для них. Если у вас есть 2 площадки и два растянутых кластера VMware vSAN между ними, то сама собой напрашивается следующая конфигурация:

Но так делать, конечно же, нельзя - и вот почему. Допустим у вас отказал сайт 2, на котором не было Witness-машин. Только в этом случае у вас будет все хорошо - для каждого из кластеров будет кворум (Witness VM+узел), и они продолжат нормальную работу.

Но если у вас откажет сайт 1, то вы лишитесь сразу двух Witness VM (и WA, и WB), узлы на площадке 2 окажутся изолированными, и все виртуальные машины на них будут недоступны (нет кворума):

А что для случая, если машины Witness VM разместить на разных площадках?

Да тоже ничего хорошего - откажет сайт 1, вследствие чего виртуальные машины выжившего сайта 2 кластера A будут недоступны (не будет кворума, ведь WA, присматривающий за эти узлом умер на первой площадке). Ну а поскольку WB является как раз виртуальной машиной, данного узла кластера A ставшего недоступным, то и у выжившего узла кластера B также не будет кворума. В итоге и виртуальные машины кластера B при данном сбое будут недоступны.

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

Начиная с VMware vSphere 6.0, компания VMware предлагает администраторам очень удобный механизм для назначения прав доступа на самом высоком уровне при наличии нескольких серверов VMware vCenter - глобальные пермиссии (global permissions).

Для тех, кто использует режим vCenter Enhanced Linked Mode (ELM) с несколькими географически разделенными площадками и разнородными инфраструктурами, глобальные пермиссии - это отличное решение, так как они создаются один раз, после чего распространяются и (что самое главное) поддерживаются в согласованном состоянии на всех серверах vCenter связанной инфраструктуры в рамках одного домена Single Sign-On (SSO).

Вильям Лам, известный своими сценариями для автоматизации инфраструктуры vSphere, написал удобный скрипт GlobalPermissions.ps1, позволяющий добавлять и удалять глобальные пермиссии. Он содержит методы New-GlobalPermission и Remove-GlobalPermission, для которых можно задавать следующие параметры:

• vc_server - хост сервера vCenter
• vc_username - имя пользователя vCenter
• vc_password - пароль пользователя vCenter
• vc_user - пользователь vCenter, которому будут назначаться пермиссии
• vc_role_id - идентификатор Role ID, который связан с ролью vSphere на данном vCenter Server
• propagate - значение true или false для распространения пермиссий вниз по уровням иерархии

Чтобы получить параметр vc_role_id, нужно соединиться с vCenter Server и указать имя роли, выполнив сниппет ниже. В данном примере мы получаем ID административной роли с именем Admin:

(Get-VIRole -Name Admin).ExtensionData.RoleId

Вот пример создания новой глобальной пермиссии для одного из пользователей:

$vc_server = "192.168.1.51"

$vc_username = "administrator@vsphere.local"

$vc_password = "VMware1!"

$vc_role_id = "-1"

$vc_user = "VGHETTO\lamw"

$propagate = "true"

New-GlobalPermission -vc_server $vc_server -vc_username $vc_username -vc_password $vc_password -vc_user $vc_user -vc_role_id $vc_role_id -propagate $propagate

А вот появление соответствующей пермиссии в интерфейсе vSphere Web Client как результат работы сценария выше:

Ну а вот так удаляется глобальная пермиссия:

Remove-GlobalPermission -vc_server $vc_server -vc_username $vc_username -vc_password $vc_password -vc_user $vc_user

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

Гостевой пост компании ИТ-ГРАД. В статьях «Подключение к корпоративному облаку» и «vCloud Director: как создать безопасное подключение между двумя организациями» мы затрагивали тему сетевой связности и возможности реализации каналов передачи данных. Сегодня поговорим о типах сетей vCloud Networks, доступных для создания в vCloud Director...

В апреле компания VMware выпустила интересный документ, касающийся улучшений в плане производительности различных компонентов последней версии платформы виртуализации - "What's New in Performance? VMware vSphere 6.5".

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

Итак, посмотрим на количественные оценки улучшений. Вот так улучшилось число операций в минуту, которое может выдавать VMware vCenter 6.5:

А вот на столько уменьшилось время этих операций в VMware vSphere Web Client:

Кроме того, как вы знаете, в vSphere 6.5 есть HTML 5 Client (он сейчас называется просто vSphere Client). Основные операции он выполняет намного производительнее своего предшественника - Web Client:

Шифрование vMotion практически не влияет на время этой операции:

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

При шифровании дисков виртуальных машин производительность в IOPS также падает для обычных HDD-дисков, но это практически незаметно для SSD-дисков:

Ну и уменьшение Latency (задержки) при использовании технологии Direct Path I/O для сетевого адаптера, очень близко к нативной производительности:

Скачать документ "What's New in Performance? VMware vSphere 6.5" можно по этой ссылке.

Эта статья предназначена в помощь администраторам VDI, которые обновили свои хосты ESXi, оснащенные картами GRID vGPU, до vSphere версии 6.5. Как сказано Джереми Майном в этом форуме NVIDIA, vSphere 6.5 и драйвер GRID от ноября 2016 требует изменения режима GPU с «Shared» (vSGA) на «Shared Direct» (vGPU) через веб-клиент для включения поддержки режима vGPU виртуальными машинами...

На сайте проекта VMware Labs появилась очередная полезность для виртуальной инфраструктуры VMware vSphere - ESXi Learnswitch. Эта штука представляет собой реализацию механизмов MAC Learning и Filtering, работающая как обертка для виртуального коммутатора ESXi (при этом обязательно требуется Distributed Virtual Switch).

ESXi Learnswitch поддерживает несколько MAC-адресов виртуальных сетевых адаптеров (vNIC) и фильтрацию пакетов, исходящих из некорректных портов, на основе алгоритма поиска MAC-адреса получателя. Это позволяет повысить производительность работы сети для вложенных гипервизоров ESXi (которые генерируют множество MAC-адресов ВМ) и использования технологии контейнеров на базе виртуальных машин.

Вот какие возможности предоставляет ESXi Learnswitch:

• Техники learning и filtering на основе оверлейных сетей (Overlay Network).
• Техника обнаружения MAC Address learning на основе VLAN ID или VXLAN ID на аплинке и оконечных портах (leaf port).
• Фильтрация пакета на аплинке/оконечном порту, если MAC-адрес обнаружился на другом порту.
• Выводимая таблица адресов размером 32к на одну систему.
• Поддержка устаревания MAC-адреса (MAC Address aging) с дефолтным временем жизни 5 минут (настраивается).
• Сбрасывание неизвестных юникастовых пакетов.
• Отдельный модуль доступный как VIB-пакет для установки.
• Интерфейс командной строки net-learnswitch CLI для отображения таблицы MAC-адресов, конфигураций и статистики.

Загрузить ESXi Learnswitch можно по этой ссылке. Отличная статья о данном средстве располагается вот тут.

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

Напомним, что для этого теперь есть 2 политики: Primary level of failures to tolerate (PFTT) и Secondary level of failures to tolerate (SFTT). Для растянутого кластера PFTT определяет защиту между площадками, реализуемую по схеме RAID-1. А политика SFTT для растянутого кластера определяет защиту на уровне локального сайта, которая может быть реализована по схеме RAID-1 (на обычных дисках), а также RAID-5 или RAID-6 (для архитектуры All-Flash).

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

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

Традиционно, до введения политик избыточности на уровне каждой из площадок, планирование емкости было простым - надо было просто удвоить исходную емкость одной площадки. В vSAN 6.2 появилась не только защита RIAD-1 (mirroring), но и RIAD-5/6 (erasure coding), что позволяет в рамках растянутых кластеров организовать различные схемы размещения данных. Отметим, что алгоритм erasure coding между площадками пока не реализуем ввиду ограничений на уровне домена отказа (Fault Domain). Поэтому между площадками - только Mirroring.

Учитывая все это, в VMware сделали единую табличку, которая поможет вам при планировании емкостей инфраструктуры vSAN как для растянутого кластера, так и для кластера в рамках одной площадки:

В поле PFTT для растянутых кластеров мы видим 1, а для обычных 0. FTM (Failure Tolerance Mode) - это режим обеспечения отказоустойчивости на уровне каждого из сайтов. Напомним, что для обычных дисков он может быть только Mirroring, а для All-Flash архитектур - Mirroring или Erasure Coding.

SFTT определяет число отказов дисковых объектов внутри площадки, которое сможет перенести каждая из площадок вашего растянутого кластера.

Таким образом, если вы организуете растянутый кластер хранилищ на базе архитектуры All-Flash со средствами защиты Erasure Coding в рамках площадки и Mirroring между площадками, то вам потребуется 266% исходной дисковой емкости виртуальных машин (ее можно скорректировать на экономию от Thin Provisioning).

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

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

Вслед за снятием с продаж продукта VMware vSphere Data Protection, компания VMware напомнила нам о том, что вскоре прекратится выпуск продукта VMware vSphere Management Assistant (vMA), который пока еще доступен для скачивания (версия 6.5, которая вышла вместе с vSphere 6.5). Об этом было объявлено еще в мае прошлого года при выпуске обновления vSphere 6.0:

Напомним, что этот продукт позволяет централизованно управлять хост-серверами VMware ESXi за счет автоматизации операций системных администраторов. По-сути, vSphere Management Assistant представляет собой "вынесенную" за пределы серверов ESXi сервисную консоль (консольную ОС), которая для виртуальной инфраструктуры присутствует в единственном экземпляре, но централизованно исполняет сценарии на хостах, используя различные интерфейсы VMware vSphere.

Теперь вместо vMA предлагается использовать интерфейсы vCLI и PowerCLI. В целом, этот подход выглядит достаточно логичным - большинство функций удаленного управления платформой взяли на себя эти фреймворки, а сами ESXi и vCenter отлично управляются через стандартные средства и API.

Сама VMware предлагает использовать интерфейс vSphere Command Line Interface (vCLI) в качестве альтернативы vMA. Между тем, она заявляет о том, что команды esxcfg- и vicfg- также будут выведены из эксплуатации (deprecated). Поэтому администраторам vSphere стоит проверить, не используются ли эти две команды в старых скриптах для управления виртуальной инфраструктурой (подробнее о заменах для этих команд - тут).

Вот какие еще предлагаются альтернативы интерфейсу vCLI и устаревшему модулю vMA:

• Фреймворк PowerCLI и средство кроссплатформенного использования PowerCLI Core.
• Docker Container с VMware Tools внутри и интегрированными в него нужными административными интерфейсами. Эта штука называется vmware-utils и содержит в себе множество зашитых интерфейсов, а именно:
  • vSphere CLI 6.5
  • PowerCLI Core 1.0
  • vSphere Management SDK 6.5
  • vSphere SDK for Perl 6.5
  • vSphere SDK for Ruby (rbvmomi)
  • vSphere SDK for Python (pyvmomi)
  • vSphere Automation SDK for Ruby 6.5
  • vSphere Automation SDK for Python 6.5
  • vSphere Automation SDK for Perl 6.5
  • vSphere Automation SDK for Java 6.5
  • VSAN Management SDK for Ruby 6.5
  • VSAN Management SDK for Python 6.5
  • VSAN Management SDK for Java 6.5
  • VSAN Management SDK for Perl 6.5
  • Virtual Disk Development Kit (VDDK) 6.5
  • OVFTool 4.2
  • PowerCLI Community Repository
  • PowerCLI Core Docker Container Samples
  • William Lam's vGhetto Script Repository
  • Pyvmomi Community Samples
  • Docker Client v1.12.3
  • Docker Compose v1.8.1

Подробнее о vmware-utils можно почитать вот тут.

Ну а пока VMware vSphere Management Assistant все еще доступен для скачивания по этой ссылке.

Возможно не все из вас в курсе, что у VMware есть удобное средство для скачивания продуктов линейки VMware vSphere и других решений для создания виртуального датацентра - VMware Software Manager. Эта штука позволяет после аутентификации через MyVMware скачивать VMware vSphere, vCenter Converter, vRealize Automation и другие продукты компании:

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

А открыв пункт VMware vSphere, можно увидеть все компоненты инфраструктуры виртуализации, доступные для скачивания:

VMware Software Manager - Download Service может даже скачивать сам себя!

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

Форум по продукту находится здесь, а скачать VMware Software Manager - Download Service можно по этой ссылке.

Как знают все администраторы vSphere, в инфраструктуре виртуализации есть основной пароль компонента Single Sign-On (SSO), являющегося частью служб Platform Service Controller (PSC). SSO отвечает за предоставление токена авторизации пользователю, который соединяется с vCenter и использует остальные решения, которые с ним интегрированы.

Если вы забыли пароль SSO, то никак не сможете администрировать основные службы PSC и vCenter. Также вы не сможете никаким способом повысить одного из пользователей с любой ролью до администратора SSO.

Но есть способ восстановить/сбросить пароль Single Sign-On, если вы используете vCenter Server Appliance (vCSA). Для этого нужно зайти на vCSA под пользователем root (его же вы не забыли, правда?):

После чего ввести команду для доступа к шеллу:

shell.set --enabled true

После этого напишите shell и нажмите Enter:

Далее запустите VDC админ-тул, и вы увидите вот такой результат:

Нажмите клавишу <3>, после чего у вас попросят ввести аккаунт (Account UPN), для которого будет сгенерирован временный пароль. Введите administrator@vsphere.local:

После этого с данным паролем войдите в vCenter Single Sign-On:

Ну а там уже перейдите в Administration>Single Sign On > Users и выберите Edit для пользователя Administrator. Там можно сменить пароль:

Это, кстати, говорит о том, что пароль root для vCenter Server Appliance нужно хранить особенно внимательно и не забывать.

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

Обратите внимание, что VMware Horizon 7.1 уже поддерживает VMware vSAN 6.6.

Напомним также, что совсем недавно выходил апдейт VMware vCenter 6.5c, в котором была исправлена уязвимость компонента Apache BlazeDS. Что касается обновления ESXi 6.5d, то оно включает в себя поддержку vSAN 6.6, исправления некоторых ошибок а также отображения статусов VMware vSAN health checks в интерфейсе клиента ESXi Host Client (он же Embedded Host Client).

Загрузить VMware vSAN 6.6 в составе платформы VMware vSphere 6.5 и ее компонентов можно по этой ссылке.

Ну и одновременно с этими релизами была выпущена также обновленная версия платформы VMware vSphere Integrated Containers 1.1.

Давайте посмотрим на новые возможности VIC 1.1:

• Унифицированный OVA-установщик для всех трех компонентов решения.
• Возможность апгрейда с версии 1.0.
• Официальная поддержка vSphere Integrated Containers Management Portal.
• Унифицированный пользовательский интерфейс для vSphere Integrated Containers Registry и vSphere Integrated Containers Management Portal.
• Отдельный плагин для HTML5 vSphere Client (он же vSphere Client теперь).
• Поддержка Docker Client 1.13 и Docker API версии 1.25.
• Поддержка использования компонента Notary совместно с vSphere Integrated Containers Registry.
• Поддержка дополнительных команд Docker, которые можно найти в документации.

Загрузить VMware vSphere Integrated Containers 1.1 можно по этой ссылке.

На прошлой неделе мы писали о том, что компания VMware выпустила релиз-кандидат своего основного документа по обеспечению безопасности виртуальной инфраструктуры. Ну а на днях вышла окончательная версия VMware vSphere 6.5 Security Configuration Guide (ранее он назывался Hardening Guide).

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

Удаленные настройки

С каждым релизом vSphere команда инженеров VMware проводит аудит каждой настройки и сверяет ее актуальность в отношении текущего функционала vSphere. Например, были удалены рекомендации относительно настройки VM.disable-VMTools-autoinstall, которая подразумевала, что можно примонтировать некорректную исошку с тулзами, автоинстал которой поселит вредоносное ПО в вашу госетвую ОС. Но в vSphere 6.5 монтируются только подписанные исошки с VMware Tools, а значит эта опасность ушла. Ну и к тому же, дефолтная политика обновления ESXi подразумевает ручное обновление тулзов, а значит указанная настройка не вполне актуальна.

Второй пример - это настройка vCenter.verify-nfc-ssl, которая была удалена, поскольку VMware больше не поддерживает "толстый" C#-клиент. Ранее этот клиент не использовал SSL для транзакций копирования файлов (Network File Copy), хотя отдельной настройкой шифрование можно было включить. Сейчас это стало неактуально.

Ну а вот полный список удаленных настроек:

• VM.disable-VMtools-autoinstall
• VM.disable-unexposed-features-biosbbs
• VM.disable-unexposed-features-getcreds
• VM.disable-unexposed-features-toporequest
• VM.disable-unexposed-features-trashfolderstate
• VM.disable-vix-messages
• VM.prevent-device-interaction-connect
• VM.prevent-device-interaction-edit
• vCenter.verify-nfc-ssl

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

Добавленные настройки

Во-первых, в документ были добавлены новые колонки. Это DISA STIG ID (ссылка на соответствующие гайдлайны правительства США), а также "Hardening" и "Site Specific Setting". Колонка Hardening указывает на то, что это действительно настройка, которой нужно уделить внимание при конфигурации, а Site Specific Setting говорит о том, что задать конфигурацию должен сам пользователь, в зависимости от его окружения.

Также была добавлена колонка "Audit Setting", которая говорит о том, что вам необходимо время от времени проверять эту настройку, чтобы убедиться, что значение по умолчанию не было изменено администратором необоснованно. В то же время, они могут быть изменены осознанно в соответствии с корпоративными политиками, и в этом нет ничего плохого (например, настройка *timeout).

Например, настройка, которая была добавлена - это ESXi.Audit-SSH-Disable. По умолчанию доступ по SSH отключен для хостов ESXi, но иногда администраторы могут включать его для решения своих задач. Поэтому эта настройка и помечена как "Audit Setting".

Также появились настройки VM.Enable-VGA-Only-Mode и VM.disable-non-essential-3d-features. Первая отключает функциональность SVGA для виртуальной машины. Эта настройка помечена как Site Specific, то есть администратор с параноидальным уровнем отношения к безопасности может отключить SVGA-драйвер для консольных гостевых ОС, но эта настройка, конечно же, не помечена как Hardening, чтобы все повально не стали отключать SVGA-драйверы, а потом писали письма в поддержку с вопросом о том, чего это не работает гостевая ОС.

Настройка disable 3D по умолчанию отключена, но помечена как "Audit Setting", чтобы время от времени просматривать, не включил ли ее зачем-то администратор.

Отметим, что никаких значительных изменений с момента релиз-кандидата документа не произошло. Скачать финальную версию VMware vSphere 6.5 Security Configuration Guide можно по этой ссылке (там же находятся и остальные руководства по безопасности от VMware).

На днях компания VMware выпустила версию 3.11 своего клиента для управления виртуальной инфраструктурой на базе технологии HTML 5 - vSphere Client. Совсем скоро он заменит собой старый клиент vSphere Web Client, в котором пока еще шире функциональность, но vSphere Client уже стремительно наверстывает разрыв.

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

• Консолидация снапшотов виртуальных машин.
• Перемещение ВМ в пределах хостов и кластеров.
• Перемещение ВМ из датастора в кластер датасторов драг энд дропом.
• Расширенные графики производительности теперь могут отображаться как составные графики (несколько составляющих одного параметра - как на картинке выше).
• Появился контент в разделе VM Storage Policy.
• Добавились операции import, export, duplicate и delete для спецификации настройки ВМ (customization specification).
• Появились параметры Host CPU и Host Memory в списке ВМ.
• Возможность клонирования ВМ или шаблонов между серверами vCenter на датастор кластера хранилищ.
• Добавление существующего VMDK-диска как нового для новой виртуальной машины.
• Действие для смены политики хранилищ по умолчанию.
• Графики производительности можно экспортировать в картинки или файлы CSV.

Скачать VMware vSphere Client 3.11 можно по этой ссылке.

Пару дней назад мы писали о новых возможностях последней версии решения для создания отказоустойчивых кластеров хранилищ VMware vSAN 6.6. А совсем недавно известный блоггер Дункан Эппинг выпустил два интересных видео, посвященных данному продукту.

Первое - это общий обзор VMware vSAN 6.6, в котором Дункан проходится по основным нововведениям, наглядно демонстрируя их в интерфейсе:

Во втором видео Дункан подробно останавливается на технологии шифрования vSAN 6.6, показывая ее в деле:

Ну и в довершение - интересный документ с детальным рассмотрением технических особенностей новой версии VMware vSAN 6.6 (уже не от Дункана, но очень подробный и полезный для администраторов решения):

Осенью прошлого года компания VMware на конференции VMworld Europe 2016 представила новую версию продукта VMware Virtual SAN 6.5, которая была приведена в соответствие с версией vSphere 6.5. На днях, спустя полгода после этого релиза, была представлена обновленная версия этого продукта для создания кластеров хранилищ - VMware vSAN 6.6 (обратите внимание, что он теперь называется не Virtual SAN, а vSAN).

Несмотря на малое продвижение версии, в VMware vSAN 6.6 появилось весьма много новых возможностей:

1. Шифрование.

В vSAN 6.6 появился механизм DARE – Data At Rest Encryption. Несмотря на то, что для ВМ на платформе vSphere 6.5 есть собственное шифрование, ранее для такого сценария не были доступны дедупликация и компрессия. Теперь за счет того, что шифрование vSAN работает на более позднем уровне - эти механизмы экономии дискового пространства теперь поддерживаются.

Кроме того, эта возможность использует механизм AESNI (Advanced Encryption Standard Native Instruction), который есть во всех современных процессорах, что увеличивает производительность. Также появились новые healthchecks касающиеся того, что сервер KMS доступен (не забудьте обеспечить его резервирование), а также хосты поддерживают AESNI.

2. Механизм локальной защиты для растянутых кластеров (vSAN Stretched Clusters).

Теперь средствами политик можно определить уровень защиты как на уровне локального сайта, так и на уровне межсайтового кластера. Для этого теперь есть 2 политики: Primary level of failures to tolerate (PFTT) и Secondary level of failures to tolerate (SFTT). Для растянутого кластера PFTT определяет защиту между площадками, реализуемую по схеме RAID-1. А политика SFTT для растянутого кластера определяет защиту на уровне локального сайта, которая может быть реализована по схеме RAID-1, RAID-5 или RAID-6.

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

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

3. Возможность Site Affinity для растянутых кластеров.

Теперь машину можно привязать к определенной площадке для растянутого кластера, но только в том случае, если у нее установлено Primary level of failures to tolerate в значение 0 (то есть она не защищена на уровне кластера vSAN, а администратор сам заботится о средствах ее защиты).

4. Режим Unicast Mode.

Теперь вместо мультикаста используется юникаст для коммуникации между узлами кластера. Как только вы обновите все хосты кластера vSAN да версии 6.6 - он сам переключится на режим Unicast:

Вот этой командой можно проверить режим Ubnicast на узлах кластера:

[root@esxi-dell-j:~] esxcli vsan cluster unicastagent list

NodeUuid                              IsWitness  Supports Unicast  IP Address     Port  Iface Name

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

58d29c9e-e01d-eeea-ac6b-246e962f4ab0          0              true  172.4.0.121   12321

58d8ef12-bda6-e864-9400-246e962c23f0          0              true  172.3.0.123   12321

58d8ef61-a37d-4590-db1d-246e962f4978          0              true  172.3.0.124   12321

00000000-0000-0000-0000-000000000000          1              true  147.80.0.222  12321

[root@esxi-dell-j:~]

5. Больше информации об объектах в интерфейсе.

Если раньше можно было просматривать только объекты VMDK и VM Home, то теперь добавился Swap и объекты дельта-дисков ВМ для снапшотов (см., например, диск с именем Hard disk 9 -vcsa-06.rainpole.com_8.vmdk):

6. Возможности Smart Rebuilds.

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

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

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

7. Механизм Partial Repairs.

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

8. Функция Resync Throttling.

Это давно ожидаемая фича - она позволяет задать ширину канала для ресинхронизации в Mbps:

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

9. Новые пречеки для режима обслуживания.

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

10. Новые пречеки для удаления дисковых групп и дисков.

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

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

11. Новый помощник установки и развертывания.

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

А для проверки конфигурации кластера vSAN появилась утилита "Configuration Assist", которая позволяет убедиться, что все настроено правильно:

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

Теперь за счет механизма CEIP (Customer Experience Improvement Program) информация о кластере vSAN посылается в VMware, облачные системы которой могут выдавать предварительные предупреждения о возможных проблемах в инфраструктуре хранилищ и рекомендации по их настройке.

13. Интеграция с HTML5 Host Client.

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

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

14. Новые команды ESXCLI.

Были добавлены следующие пространства команд для управления кластером vSAN и его новыми фичами:

• esxcli vsan debug
• esxcli vsan health cluster
• esxcli vsan resync bandwidth
• esxcli vsan resync throttle

15. Возможность заменить компонент Witness прямо из GUI.

Теперь в интерфейсе для этого появилась специальная кнопка:

Скачать VMware vSAN 6.6 можно по этой ссылке.

Все администраторы платформы VMware vSphere знают, что такое параметры Shares и Reservation, но не все понимают, как именно они работают для виртуальных машин и пулов ресурсов. Мы уже затрагивали эту тему для виртуальных машин, не погружаясь в распределение ресурсов между пулами (хотя там все работает точно так же).

Основным источником знаний о Reservation и Shares является документ "Resource Management Guide", однако он большой и нудный, а на днях VMware выпустила более простую версию, сфокусированную на управлении кластером DRS с точки зрения резерваций и шар - "DRS Cluster Management with Reservation and Shares".

Именно из этого документа лучше узнать, как работают Shares (распределение ресурсов) и Reservations (гарантирование ресурсов) в рамках отдельных виртуальных машин, пулов ресурсов в рамках кластера DRS с учетом возможности заимствования ресурсов из родительского пула (expandable reservation).

Конечно же, если вы администратор платформы VMware vSphere, то вы должны были разобраться с этим всем еще в самом начале, но если какие-то аспекты работы механизмов гарантирования и распределения ресурсов вам остались непонятными, обязательно пробегитесь по документу "DRS Cluster Management with Reservation and Shares".

Компания VMware на днях выпустила Release Candidate версию своего основного руководства по обеспечению безопасности виртуальной среды серверной виртуализации - vSphere 6.5 Security Configuration Guide (ранее он назывался Hardening Guide).

Традиционно Hardening Guide представляет собой Excel-табличку с необходимыми конфигурациями серверов ESXi, виртуальных машин, сетей и т.п. для обеспечения безопасной работы виртуальной инфраструктуры на различных уровнях (от легкой до параноидальной защиты):

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

Здесь раздел "Non-Hardening" означает, что рекомендуемые с точки зрения безопасности настройки либо уже выставлены по умолчанию, либо задаются пользователем (например, IP-адрес сервера NTP). Оставшиеся 35% настроек как раз могут быть изменены администратором vSphere, чтобы сделать инфраструктуру более защищенной.

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

Пока в документе всего 68 настроек, но не исключено, что их количество будет увеличено. Соответственно, как Hardening предполагается всего 24 настройки.

18 из этих настроек - это настройки раздела VM.disable-unexposed-features.*, которые касаются скрытых/недокументированных возможностей ВМ, а остальные 6 настроек касаются следующего:

• 3 штуки - это настройки стандартного vSwitch из значений accept в reject (эти рекомендации есть еще со времен самого первого Hardening Guide).
• 1 настройка - это BPDU filter.
• 1 штука - это просто рекомендация своевременно патчить хосты ("Apply your ESXi patches").
• 1 настройка - это "Disable TLS 1.0/1.1", то есть отключение старых версий протокола TLS, у которых есть проблемы с безопасностью (более подробно смотрите тут).

TLS 1.0/1.1 не отключен по умолчанию, так как некоторые системы продолжают использовать его, соответственно отключение может привести к различным проблемам, поэтому делать это нужно осознанно.

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

VM.disable-VMtools-autoinstall

 VM.disable-unexposed-features-biosbbs

 VM.disable-unexposed-features-getcreds

 VM.disable-unexposed-features-toporequest

 VM.disable-unexposed-features-trashfolderstate

 VM.disable-vix-messages

 VM.prevent-device-interaction-connect

 VM.prevent-device-interaction-edit

vCenter.verify-nfc-ssl

Скачать документ VMware vSphere 6.5 Security Configuration Guide и оставить фидбэк по нему можно по этой ссылке. Финальная версия ожидается 13 апреля.

Некоторое время назад мы писали о новых возможностях платформы виртуализации и доставки физических и виртуальных ПК предприятия VMware Horizon 7.1. А из видео ниже вы можете узнать некоторые технические детали этих новых функций, о которых VMware подробно рассказывает в течение десяти минут:

Также появилось интересное видео с общей информацией о новинках платформы VMware Horizon 7.1:

Ну и, конечно же, многим будет интересно узнать о нововведениях клиентов - Horizon Clients 4.4:

Улучшения протокола Blast Extreme в Horizon 7.1 (мы писали об этом тут):

Ну и напоследок - что нового в Horizon 7.1 для Linux: