Многие пользователи применяют сценарии PowerCLI (недавно, кстати, вышла 13-я версия этого пакета) для автоматизации виртуальной инфраструктуры VMware vSphere на базе фреймворка PowerShell.
При этом для скриптов часто встает вопрос безопасного хранения данных учетных записей (логин-пароль), чтобы не указывать их прямым текстом в исходниках сценариев. Компонент PowerCLI credential store использует хранилище учетных записей, которое, в свою очередь, использует Windows data protection API для шифрования данных учетных записей и хранения их в файле. Поэтому PowerCLI credential store доступен только в Windows и не является кроссплатформенным. А что насчет пользователей Linux и MacOS?
Некоторое время назад Microsoft выпустила два полезных кроссплатформенных модуля SecretManagement и SecretStore (подробнее об этом тут). SecretManagement предоставляет командлеты, которые позволяют пользователям управлять паролями в различных хранилищах, а SecretStore - это, собственно, само хранилище и есть. Эти два модуля можно использовать вместо стандартного хранилища VICredential. Чтобы проиллюстрировать, как работать с ними, в VMware сделали пример модуля с разными версиями командлетов VICredential.
Первый шаг - это регистрация и конфигурация защищенного хранилища. В примере использования модуля, упомянутом выше, можно использовать Initialize-VISecret, который реализует эту процедуру - регистрирует SecretStore как хранилище по умолчанию и настраивает окружение так, чтобы пароль не запрашивался при доступе к хранилищу.
function Initialize-VISecret {
[CmdletBinding()]
param(
[string]$Vault = "VMwareSecretStore"
)
Этот режим по пользовательскому опыту близок к VICredentialStore, так как пароли хранятся в зашифрованном виде, но сам пароль при доступе к нему не запрашивается. В примере используется SecretStore по умолчанию, но можно изменить хранилище на любое по вашему выбору, а именно:
Чтобы сохранить креды в хранилище, нужно использовать командлет Set-Secret модуля SecretManagement. Сами креды в этом командлете идентифицируются по имени, но в примере ниже креды описываются двумя идентификаторами - имя пользователя и сервер, к которому нужно получить доступ. Такими образом, командлет New-VISecret склеивает строки "VISecret", сервер и имя пользователя в один идентификатор, который и используется для получения пароля.
Если вы хотите сохранить креды более чем для одного продукта, вы можете изменить функцию так, чтобы заменить VISecret на другую специфичную для продукта строку, чтобы создать идентификатор, например, "VMCSecret" для VMware Cloud. Можно передавать пароль простым текстом или в виде защищенной строки.
Также вы можете удалить креды из хранилища, используя командлет Remove-VISecret, который создает идентификатор и вызывает функцию Remove-Secret для удаления кредов. Если вы используете SecretStore в качестве хранилища, вы можете очистить его полностью с помощью функции Reset-SecretStore.
Создание нового идентификатора выглядит так:
function New-VISecret {
[CmdletBinding()]
[Alias("Set-VISecret")]
param (
[Parameter(Mandatory=$true)]
[string]$Server,
[Parameter(Mandatory=$true)]
[string]$User,
[string]$Password,
[securestring]$SecureStringPassword,
[string]$Vault
)
begin {
if ([string]::IsNullOrWhiteSpace($password) -and (-not $secureStringPassword)) {
Throw "Either Password or SecureStringPassword parameter needs to be specified"
}
if (-not [string]::IsNullOrWhiteSpace($password) -and $secureStringPassword) {
Throw "Password and SecureStringPassword parameters cannot be both specified at the same time"
}
}
process {
$params = @{
"Name" = "VISecret|"+$server+"|"+$User
}
if ($password) {
$params += @{"Secret" = $password}
} elseif ($secureStringPassword) {
$params += @{"SecureStringSecret" = $secureStringPassword}
} elseif ($Vault) {
$params += @{"Vault" = $Vault}
}
Set-Secret @params
}
}
Последний командлет в примере - это Connect-VIServerWithSecret. Он сочетает в себе оба командлета, приведенных выше, что дает интегрированный инструмент для работы по аналогии с командлетом Connect-VIServer для VICredentialStore. Вы можете вызвать Connect-VIServerWithSecret с логином и паролем, но использовать параметр -SaveCredentials для сохранения кредов в хранилище.
После этого вы можете опускать параметры учетной записи, а Connect-VIServerWithSecret будет автоматически получать пароль из хранилища и соединяться с сервером vCenter. При использовании VICredentialStore, если у вас сохранены креды только к одному серверу, вы можете соединяться с ним через Connect-VIServer без указания имени пользователя. А для использования функции Get-Secret параметр -Username является обязательным, так как не проверяется, что в хранилище сохранена только одна учетная запись. Чтобы упростить жизнь в этом случае есть глобальная переменная $global:defaultUser, значение которой и будет использоваться в Connect-VIServerWithSecret.
Иногда при работе администратора с виртуальными машинами VMware vSphere происходит ошибка при работе с дескрипторными файлами дисков VMDK, которая проявляет себя следующим образом:
Диск ВМ показывается в Datastore Browser, но иконка для него отсутствует
При включении ВМ вы получаете ошибку " File not found"
Сам файл ВМ вида <имя ВМ>-flat.vmdk есть в директории с машиной, но файла <имя ВМ>.vmdk вы не видите
Сам файл <имя ВМ>.vmdk отсутствует, либо он есть, но его содержимое повреждено
Эти симптомы могут возникать по разным причинам, но суть их одна - дескрипторный файл ВМ поврежден или отсутствует. Ситуация поправима, если у вас есть основный диск с данными - <имя ВМ>-flat.vmdk, и он сохранился в целости.
В 2012 году мы писали о том, как быть, если у вас возникла проблема с дескрипторным файлом виртуальной машины в среде VMware vSphere. В целом, с тех времен ничего особо не поменялось. Процесс этот довольно простой и описан в KB 1002511, также он детально разобран в видео ниже:
Часть 1 - восстановление основного VMDK виртуальной машины
Перед выполнением операций ниже обязательно сохраните полную копию папки виртуальной машины, и только после этого проводите все описанные ниже операции. Если у вас есть резервная копия виртуальной машины, и ее восстановление вас устраивает - то лучше сделать эту операцию вместо описанной ниже процедуры исправления дисков, так как вероятность ошибиться в ней велика.
Если вкратце, то для восстановления вам нужно выполнить следующие шаги:
1. Соединяемся с хостом VMware ESXi по SSH как root. Либо операции можно проводить непосредственно в консоли DCUI.
2. Переходим в папку с ВМ и определяем геометрию основного диска VMDK с данными <имя ВМ>-flat.vmdk
Делается это командой:
# ls -l <имя диска>-flat.vmdk
На выходе мы получим размер диска в байтах. Вывод будет выглядеть примерно так:
-rw------- 1 root root 4294967296 Oct 11 12:30 vmdisk0-flat.vmdk
3. Теперь нужно пересоздать заголовочный файл VMDK (<имя ВМ>.vmdk), чтобы он соответствовал диску с данными, используя тот же размер диска, полученный на предыдущем шаге:
# vmkfstools -c 4294967296 -a lsilogic -d thin temp.vmdk
После этого переименовываем дескрипторный VMDK-файл созданного диска в тот файл, который нам нужен для исходного диска. Затем удаляем только что созданный пустой диск данных нового диска, который уже не нужен (temp-flat.vmdk).
Если у изначальной машины диск был не растущим по мере наполнения (thin disk), то последнюю строчку, выделенную красным, можно не добавлять.
Вы также можете поменять тип адаптера ddb.adapterType = lsilogic на ddb.adapterType = pvscsi, если вы использовали паравиртуализованный SCSI-контроллер для исходной ВМ.
Консистентность виртуальной машины можно проверить командой:
vmkfstools -e filename.vmdk
Если все в порядке, то в ответе команды вы получите вот такую строчку:
Disk chain is consistent.
Если же исправить ситуацию не получилось, то будет вот такой текст:
Disk chain is not consistent : The parent virtual disk has been modified since the child was created. The content ID of the parent virtual disk does not match the corresponding parent content ID in the child (18).
После этого можно запускать виртуальную машину, добавив ее повторно в окружение vSphere Client.
Часть 2 - исправление дескрипторов файлов снапшотов ВМ (delta-файлы)
Ситуация усложняется, когда у исходной виртуальной машины были снапшоты, тогда папка с ней выглядит следующим образом (красным выделены важные для нас в дальнейших шагах файлы):
drwxr-xr-x 1 root root 1400 Aug 16 09:39 .
drwxr-xr-t 1 root root 2520 Aug 16 09:32 ..
-rw------- 1 root root 32768 Aug 17 19:11 examplevm-000002-delta.vmdk
-rw------- 1 root root 32768 Aug 17 19:11 examplevm-000002.vmdk
-rw------- 1 root root 32768 Aug 16 14:39 examplevm-000001-delta.vmdk
-rw------- 1 root root 32768 Aug 16 14:39 examplevm-000001.vmdk
-rw------- 1 root root 16106127360 Aug 16 09:32 examplevm-flat.vmdk
-rw------- 1 root root 469 Aug 16 09:32 examplevm.vmdk
-rw------- 1 root root 18396 Aug 16 14:39 examplevm-Snapshot1.vmsn
-rw------- 1 root root 18396 Aug 17 19:11 examplevm-Snapshot2.vmsn
-rw------- 1 root root 397 Aug 16 09:39 examplevm.vmsn
-rwxr-xr-x 1 root root 1626 Aug 16 09:39 examplevm.vmx
-rw------- 1 root root 259 Aug 16 09:36 examplevm.vmxf
Основной порядок действий в этой ситуации приведен в KB 1026353, здесь же мы опишем его вкратце (кстати, напомним про необходимость сделать полный бэкап всех файлов ВМ перед любыми операциями):
1. Определяем нужные нам файлы
Итак, заголовочные файлы снапшотов ВМ хранятся в так называемых файлах типа vmfsSparse, они же работают в связке с так называемым delta extent file, который непосредственно содержит данные (выше это, например, examplevm-000001-delta.vmdk).
Таким образом, опираясь на пример выше, нам интересны заголовочные файлы снапшотов examplevm-000001.vmdk и examplevm-000002.vmdk. Помните также, что диски и их снапшоты могут находиться в разных папках на разных датасторах, поэтому сначала вам нужно понять, где и что у вас хранится. Если у вас есть сомнения касательно имен нужных вам файлов, вы можете заглянуть в лог-файл vmware.log, чтобы увидеть там нужные пути к датасторам.
2. Создаем новый дескриптор снапшота
Итак, представим теперь, что файл examplevm-000001.vmdk у нас поврежден или отсутствует. Создадим новый дескриптор снапшота из исходного заголовочного файла examplevm.vmdk простым его копированием:
# cp examplevm.vmdk examplevm-000001.vmdk
3. Меняем указатели на файл с данными для снапшота
Теперь нужно открыть созданный файл в текстовом редакторе и начать его исправлять. Пусть он выглядит вот так:
# Disk DescriptorFile
version=1
encoding="UTF-8" CID=19741890
parentCID=ffffffff
createType="vmfs"
Красным мы выделили то, что будем в этом файле изменять, а синим - то, что будем удалять.
С данным файлом нужно сделать следующие манипуляции:
Строчку CID=19741890 заменяем на случайное восьмизначное значение (это идентификатор диска)
Строчку parentCID=ffffffff заменяем на parentCID=19741890 (идентификатор родительского диска, им может быть не только родительский основной диск, но и родительский снапшот, то есть его дескриптор)
Строчку createType="vmfs" заменяем на createType="vmfsSparse"
Строчку RW 31457280 VMFS "examplevm-flat.vmdk" заменяем на RW 31457280 VMFSSPARSE "examplevm-000001-delta.vmdk" (обратите внимание, что номер 31457280 остается тем же - он должен быть тем же самым для всей цепочки дочерних дисков)
4. Добавляем данные специфичные для снапшота
Теперь нам надо добавить в указатель снапшота кое-что новое:
Под строчкой createType="vmfsSparse" добавляем строчку
parentFileNameHint="examplevm.vmdk"
Ну и теперь надо убрать лишнее. Удаляем из файла следующие строчки, которые нужны только для основного родительского диска:
После этого вы можете попробовать запустить машину с дочерним снапшотом. Но перед этим также проверьте интеграцию дескриптора командой:
vmkfstools -e filename.vmdk
Ну и помните, что все эти действия по цепочке вы можете провернуть для следующих уровней дочерних снапшотов, если их диски с данными в порядке. Главное - не забывайте делать резервные копии перед любыми операциями!
На днях обновилась известная многим администраторам виртуальной инфраструктуры утилита RVTools до версии 4.4.1. Напомним, что она предназначена для помощи пользователю VMware vSphere в различных аспектах при выполнении рутинных операций в виртуальной среде серверов ESXi и виртуальных машин. В прошлый раз об RVTools 4.3.1 мы писали вот тут.
Давайте посмотрим, что нового появилось в RVTools 4.4.1:
Теперь утилита разрабатывается на Visual Studio 2022.
RVTools использует обновленный VMware vSphere Management SDK 8.0.
Log4net обновлен до версии 2.0.15.
Компонент RVToolsPasswordEncryption теперь использует mac-адрес вместо фиксированной строки для шифрования пароля.
Новые колонки на странице vInfo: емкость диска в MiB, Folder ID, роль Fault tolerance, операции Reboot/Poweroff, опция EFI Secure boot, SMBIOS UUID.
Новая колонка на странице vCPU - Numa Hotadd Exposed. Это булевое значение, показывающее работает ли NUMA-топология при включенном CPU hotadd.
Новые колонки на странице vDisk: Disk UUID и Disk sharing mode.
На всех страницах, относящихся к ВМ, колонка с тэгами поставлена перед колонкой Datacenter. Также изменен текст тултипа VM UUID на "VirtualCenter-specific 128-bit UUID of a virtual machine".
Новые колонки на странице vSource: version, patch level и VI SDK Server.
На странице vHealth путь /storage/archive исключен из проверки free disk capacity, так как этот раздел может быть заполнен изначально в нормальной конфигурации (подробнее тут).
Исправлена ошибка с некорректным отображением колонки Primary IP Address на странице vInfo.
Решена проблема на странице vNetwork, когда нельзя было понять, является ли IP-адрес типом ipv4 или ipv6.
Скачать новую версию RVTools 4.4.1 можно по этой ссылке. Описание отображаемых параметров находится тут.
Многие администраторы и разработчики, вовлеченные в управление виртуальной инфраструктурой VMware vSphere и использующие ее компоненты, а также другие решения VMware, часто планируют разработку сценариев и программ для автоматизации различных операций в виртуальной среде. Для этого VMware предоставляет комплект пакетов разработки (Software Development Kits, SDK), которые стандартизируют разработку сторонних решений на различных языках (Java, .NET, Perl, Python, Ruby и других).
Вторая страница - это комплект SDK, в том числе от партнеров и в рамках различных программ для разработчиков. Находится она здесь.
Что касается специальных программ для разработчиков (например, партнеров по программе Technology Alliance Partner, TAP), то информация о них доступна на этой странице (так называемые Gated SDK).
Кроме того, некоторые SDK, до выхода vSphere 8, были доступны только в соответствующих репозиториях на GitHub. Теперь их перенесли в единый центр загрузки. Вот их новые страницы:
На днях наш ценный читатель (и подсказыватель правильных вещей) Сергей заметил, что мы давно не упоминали об обновлениях средства SexiGraf для мониторинга виртуальной инфраструктуры VMware vSphere. В последний раз мы писали о нем осенью 2018 года вот тут (это был релиз White Forest).
Напомним, что это средство было сделано энтузиастами (Raphael Schitz и Frederic Martin) в качестве альтернативы платным продуктам для мониторинга серверов ESXi и виртуальных машин. Представления SexiPanels для большого числа метрик в различных разрезах есть не только для VMware vSphere и vSAN, но и для ОС Windows и FreeNAS.
C 2018 года вышло 4 больших релиза SexiGraf, давайте рассмотрим их возможности вкратце.
Вот что появилось в релизе Traptown:
SuperStats - новые метрики уровня кластера, включающие в себя такие объекты, как hba, network, storage, power
vCenter Bad Events - возможность отслеживания "плохих" событий в инфраструктуре на уровне vCenter
Полный список всех обновлений SexiGraf и обзор новых функций можно найти на этой странице. Скачать виртуальный модуль в формате OVA можно по этой ссылке. Однако, как было отмечено, из России он не качается, поэтому перед скачиванием нужно включить VPN.
Традиционно документ разбит на 4 больших блока, касающихся оборудования, самой платформы vSphere и серверов ESXi, виртуальных машин, их гостевых систем и средств управления виртуальной инфраструктурой:
Hardware for Use with VMware vSphere
ESXi and Virtual Machines
Guest Operating Systems
Virtual Infrastructure Management
Подразделы этих глав содержат очень много конкретных пунктов про различные аспекты оптимизации виртуальных датацентров и объектов, работающих в их рамках. В основном, документ повторяет рекомендации, которые приводились для прошлых версий платформы, но есть и пункты, касающиеся непосредственно vSphere 8 и ESXi 8:
Документ очень полезный, состоит ровно из ста страниц и дает просто огромное количество полезной информации для администраторов, одной из главных задач которых является поддержание требуемого уровня производительности виртуальной среды.
Скачать Performance Best Practices for VMware vSphere 8.0 можно по этой ссылке.
Как написали коллеги с сайта virten.net, при установке платформы VMware ESXi 7 или 8 на сервер с процессорами Intel Core 12 поколения возникает розовый экран смерти (PSOD), содержащий следующие сообщения:
HW feature incompatibility detected; cannot start
Fatal CPU mismatch on feature "Hyperthreads per core" Fatal CPU mismatch on feature "Cores per package" Fatal CPU mismatch on feature "Cores per die"
Проблема здесь заключается в том, что новая архитектура процессоров Intel идет с ядрами двух типов - Performance-cores и Efficient-cores. Начиная с vSphere 7.0 Update 2, в ядро гипервизора был добавлен параметр cpuUniformityHardCheckPanic для того, чтобы избежать подобной проблемы, которая проявляется в следующих версиях платформы виртуализации:
vSphere / ESXi 8.0 или более поздние
vSphere / ESXi 7.0 Update 2 или более поздние
1. Итак, в самом начале установки ESXi нажимаете SHIFT+O, чтобы изменить параметры загрузки. Далее в появившейся строке вводите:
cpuUniformityHardCheckPanic=FALSE
2. После этого нажимаете Enter и дожидаетесь окончания установки.
3. Затем во время первой загрузки опять нажимаете SHIFT+O и вводите ту же самую строчку.
4. А уже когда гипервизор загрузится, нужно добавить следующую строчку в параметры ядра, чтобы отключить проверку, а ESXi не вылетал в розовый экран при каждой загрузке:
# esxcli system settings kernel set -s cpuUniformityHardCheckPanic -v FALSE
Также есть метод, описанный для установки через механизм автоматизированного развертывания Kickstart:
1. Создаем флэшку USB с ISO-образом ESXi, как написано здесь.
2. Открываем файл /efi/boot/boot.cfg в редакторе и добавляем следующую опцию в строчку kernelopt= параметров ядра:
ks=usb:/KS.CFG cpuUniformityHardCheckPanic=FALSE
3. Далее вам надо создать файл /KS.CFG для конфигурации Kickstart и в секциях %post (пост-параметры установки, но до первой загрузки) и %firstboot (первая загрузка) добавить следующее:
# NTP
esxcli system ntp set -s pool.ntp.org
esxcli system ntp set -e 1
4. Далее можете провести установку с USB-флэшки, а через пару минут вы уже сможете получить доступ к ESXi через консоль или по SSH.
5. Если вы используете механизм Secure Boot, то обычно секция %firstboot не применяется (так работает по умолчанию на большинстве систем). Поэтому вам потребоваться ввести команды этой секции вручную или отключить Secure Boot. С командами раздела %post все будет в порядке.
6. По окончании установки через Kickstart все будет работать:
Как вы знаете, главным релизом этого года стала новая версия платформы VMware vSphere 8, где появилось множество новых возможностей и улучшений уже существующих технологий. Одной из интересных функций стала vSphere Virtual Topology.
Для виртуальных машин с Hardware version 20 теперь доступно простое конфигурирование vNUMA-топологии для виртуальных машин:
Для виртуальных машин теперь доступна информационная панелька CPU Topology с конфигурацией vNUMA:
Недавно компания VMware выпустила документ "vSphere 8.0 Virtual Topology Performance Study", где рассматриваются аспекты производительности новой технологии, которую назвали vTopology. Виртуальная топология CPU включает в себя такие техники, как virtual sockets, узлы virtual non-uniform memory access (vNUMA), а также механизм кэширования virtual last-level caches (LLC).
До vSphere 8.0 дефолтной конфигурацией виртуальных машин было одно виртуальное ядро на сокет - это в некоторых случаях создавало затыки в производительности и неэффективность использования ресурсов. Теперь же ESXi автоматически подстраивает число виртуальных ядер на сокет для заданного числа vCPU.
На картинке ниже показана высокоуровневая архитектура компонентов двухсокетной системы. Каждый сокет соединен с локальным узлом памяти (memory bank) и образует с ним NUMA-узел. Каждый сокет имеет 4 ядра (он имеет кэши L1 и L2), а ядра шарят между собой общий кэш last-level cache (LLC).
Когда создается виртуальная машина с четырьмя vCPU, в vSphere она конфигурируется на одном сокете, вместо четырех, как это было ранее:
Так это выглядит в выводе команды CoreInfo для двух рассмотренных топологий:
Слева - это старая конфигурация, где был один vCPU на сокет, а справа - 4 vCPU (виртуальных ядер ВМ) на один сокет.
В указанном документе VMware проводит различных конфигураций (от 8 до 51 vCPU на машину) для разных нагрузок с помощью бенчмарков и утилит DVD Store 3.5, Login VSI, VMmark, Iometer, Fio и Netperf в операционных системах Windows и Linux. Забегая вперед, скажем, что для нагрузок Oracle прирост производительности составил 14%, а для Microsoft SQL server - 17%.
Итак, результаты теста DVD Store для БД Oracle:
Статистики NUMA hits NUMA misses для гостевой ОС Linux:
Результаты тестов для Microsoft SQL server:
Результаты тестирования хранилищ с помощью IOmeter:
Производительность в разрезе метрики CPU cycles per I/O (CPIO):
На прошедшей осенью этого года главной конференции о виртуализации Explore 2022 компания VMware сделала немало интересных анонсов, главным из которых стал выпуск новых версий платформ vSphere 8 и vSAN 8. На американской и европейской конференциях много говорили о будущих новых продуктах и технологиях VMware, но несколько незамеченным остался переход VMware на новую схему релизов платформы vSphere...
За релизами платформы VMware vSphere 8, у которой недавно состоялся выпуск General Availability, многие забыли о том, что большинство пользователей в производственной среде используют еще VMware vSphere 7. Недавно компания VMware выпустила обновления компонентов этой версии платформы - ESXi 7.0 Update 3i (на 13 декабря почему-то недоступен для скачивания) и vCenter 7.0 Update 3i. Напомним, что об обновлении VMware vSphere 7 Update 3f мы писали вот тут (а здесь - о возможностях Update 3), с тех пор вышел еще апдейт 3g, а сегодня мы расскажем об очередном пакете - 3i.
Давайте посмотрим, что нового в ESXi 7.0 Update 3i:
Поддержка функций vSphere Quick Boot для сервера HPE ProLiant MicroServer Gen10 Plus v2
Исправления для уязвимостей CVE-2022-31696 и CVE-2022-31699, описанных в статье VMSA-2022-0030
В VMware vCenter 7.0 Update 3i появились следующие улучшения:
Исправления для уязвимостей CVE-2022-31697 и CVE-2022-31698, описанных в статье VMSA-2022-0030
Исправление для уязвимости CVE-2021-22048, описанное в статье VMSA-2021-0025
Обновление решения VMware vSphere with Tanzu (подробнее - в Release Notes)
Обновление Photon OS (подробнее тут, в основном патчи безопасности)
Как мы видим, обновления чисто косметические, но исправлены некоторые актуальные проблемы безопасности, поэтому обновиться стоит. Очевидно, что новый функционал в vSphere 7 добавляться уже не будет, так как идет работа над обновлением vSphere 8.
Скачать VMware ESXi 7.0 Update 3i и VMware vCenter 7.0 Update 3i можно по этой ссылке.
По итогам конференции Explore 2022 компания VMware представила линейку продуктов Aria, пришедшую на смену семейству vRealize. В нее вошло онпремизное решение Aria Operations 8.10, а также облачное Aria Operations Cloud. Оба они предназначены для комплексного управления и мониторинга виртуальной облачной инфраструктуры в различных аспектах.
Одной из главных возможностей Aria Operations являются дэшборды, которые показывают различные метрики виртуальной инфраструктуры, собираемые как напрямую, так и с помощью менеджмент-паков. Сегодня мы посмотрим на интересный дэшборд CPU Core, который предоставляет информацию об используемых ядрах CPU на уровне разных объектов - от датацентров до хостов VMware ESXi.
В рамках анонсированной недавно подписки vSphere+ и решения vRealize Cloud Subscription Manager появилась возможность лицензировать компоненты виртуальной инфраструктуры vSphere и Aria на базе ядер процессоров (CPU Cores). Ниже мы посмотрим, как можно с помощью Aria Operations визуализовать распределение процессоров, чтобы оптимизировать потребление лицензий. Об этом рассказал Karthic Kumar в блоге VMware.
Дэшборд - это мощный функционал Aria Operations, который дает администратору коллекцию виджетов и связанную информацию об объектах датацентра. Мы создадим суперметрики (super metrics) и представления (Views), которые предоставляют данные для дэшборда Core distribution. Чтобы упростить процесс, используем шаблон, в котором есть следующие файлы:
Super Metrics (supermetrics.json)
Views (views.zip)
Dashboard(dashboard.zip)
Итак, скачиваем файл шаблона и заходим в консоль Aria / vRealize Operations под аккаунтом администратора. Нам надо импортировать суперметрики из JSON-файла, для этого идем в Configure –> Super Metrics –> Import и выбираем Supermetric.json:
После импорта у нас в списке появится суперметрика CorePerSocket. Выбираем для нее пункт Edit и включаем ее в политике по умолчанию, чтобы она применилась:
Далее нужно импортировать представления (Views), которые забирают данные суперметрик. Идем в Visualize –> Views –> Manage–> Import и выбираем файл views.zip:
После этого мы увидим импортированные представления в списке:
Теперь пришло время импортировать сам дэшборд. Идем в Visualize –> Dashboards –> Manage–> Import и выбираем файл Dashboard.zip:
Теперь можно кликнуть на Core Distribution в списке дэшбордов. Чтобы данные актуализировались может пройти до 15 минут (если вы видите надпись "No data available"):
В отображаемых данных вы увидите распределение ядре по датацентрам и хостам. Эти виджеты позволят вам получить информацию о соответствии использования лицензий по разным объектам вашей гибридной инфраструктуры. Ну а вы всегда сможете кастомизировать этот дэшборд, чтобы он соответствовал вашим требованиям.
Все из вас, я думаю, знают о продукте Veeam Backup and Replication, ставшем уже стандартом де-факто для резервного копирования виртуальной инфраструктуры VMware vSphere и обеспечения доступности виртуальных датацентров.
Вы также, конечно же, в курсе, что недавно компания VMware объявила о финальной доступности (General Availability) своей обновленной платформы виртуализации VMware vSphere 8. Очевидно, сразу же встал вопрос резервного копирования виртуальных машин на этой платформе.
Компания Veeam недавно выпустила статью KB 2443 о поддержке резервного копирования ВМ на VMware vSphere 8 продуктом Veeam Backup and Replication 11a (билд 11.0.1.1261 P20220302). Суть ее в том, что в целом сейчас обеспечивается работоспособность процесса бэкапа для серверов VMware ESXi 8.0 (это протестировали инженеры Veeam), но с некоторыми ограничениями:
Как вы знаете, недавно компания VMware сделала публично доступной для всех обновленную версию платформу виртуализации VMware vSphere 8 в рамках релиза General Availability (ранее состоялся выпуск продукта на этапе Initial Availability).
Администраторы, которые давно следят за выпусками платформы vSphere, знают, что при первоначальном выпуске гипервизора в официальном списке совместимости HCL (Hardware Compatibility List) не все серверные системы приводятся как сертифицированные для последнего релиза vSphere. Например, некоторые могут заметить, что многие серверы различных производителей, которые поддерживались в vSphere 7 Update 3, пока отсутствуют в HCL.
На это обратил внимание Florian Grehl, автор сайта virten.net. Причина такого факта проста - при первоначальном выпуске новой версии ESXi не все серверные системы успевают должным образом протестировать и сертифицировать.
Именно такой список и приводит Флориан, он довольно большой, поэтому лучше всего посмотреть его тут. Список официально несертифицированного оборудования становится все короче, поэтому на virten.net публикуются его обновления (последнее доступное - от 14 ноября). В списке пока представлены только серверы от Cisco, DELL, Fujitsu, Hewlett Packard Enterprise, Hitachi, IBM, Lenovo, Inspur, Huawei и Supermicro.
При клике на выбранный сервер откроется его карточка в VMware HCL:
Надо понимать, что тот факт, что система не сертифицирована, не означает, что VMware vSphere / ESXi на ней работать не будет. Просто вендоры самостоятельно занимаются сертификацией, а значит делают это каждый в своем темпе. Поэтому, если ваш сервер есть в списке, то лучше всего спросить о его сертификации у вендора напрямую.
Недавно мы писали о новой схеме релизов VMware vSphere, согласно которой теперь есть два уровня доступности платформы - IA/GA (Initial Availability/General Availability), которая позволяет выровнять схему релизов с продуктами облачной линейки Cloud Services в рамках доступной пользователям подписки vSphere+.
О новых возможностях VMware vSphere 8, анонсированных на конференции Explore 2022 мы писали вот тут, а в этой статье мы рассказывали о релизе vSphere 8 Initial Availability, который состоялся ровно месяц назад. Согласно планам VMware, с момента релиза Initial Availability до General Availability проходит до двух месяцев, но VMware vSphere 8 General Availability (GA) уже готов для загрузки - так что его можно уже скачивать и постепенно тестировать.
С того времени, как было объявлено об Initial Availability, платформа vSphere 8 была скачана более 18 тысяч раз:
Кстати, отметим, что General Availability не сопровождается каким-то отдельным билдом или релизом - это просто отмашка со стороны VMware, что все работает нормально, и критических багов не было обнаружено. Скачивать вы будете те же самые образы, что стали доступны 11 октября:
Второй важный момент схемы IA/GA - это трекинг найденных проблем, с которыми столкнулись пользователи, и воркэраундов, которые вам могут пригодиться при обходе нестандартных ситуаций. Все это публикуется в KB 90026. Обязательно загляните туда перед развертыванием vSphere 8 в производственной среде. Сейчас эта статья пуста - это означает, что критических проблем в работе продукта пока не выявлено.
VMware рекомендует не ждать пакета обновлений Update 1, а установить vSphere 8 GA уже сейчас, так как данный релиз уже прошел проверку в больших инфраструктурах крупных компаний (и по заявлениям VMware получился вполне удачным).
Как вы знаете, на прошедшей конференции Explore 2022 компания VMware анонсировала новые версии платформы виртуализации vSphere 8 и решения для создания отказоустойчивых хранилищ vSAN 8. Недавно эти решения стали доступны для скачивания как Initial Availability (IA), поэтому сейчас самое время развертывать их в своих тестовых окружениях для проверки перед большим апгрейдом.
Начать можно с виртуальной тестовой лаборатории, то есть инсталляции в рамках одного сервера или рабочей станции, где сервисы ESXi, vCenter и vSAN поднимаются в виртуальных машинах.
Для этой цели известный блоггер и инженер VMware Вильям Ламм создал на PowerCLI специальный сценарий Automated vSphere & vSAN 8 Lab Deployment, который автоматизирует развертывание компонентов виртуальной лаборатории на базе vSphere и vSAN восьмой версии.
Как видно на картинке, скрипт предназначен, чтобы развернуть три виртуальных сервера ESXi, создать на их базе кластер vSAN, а также развернуть виртуальный модуль управления vCenter Server Appliance (vCSA).
Итак для этого вам понадобятся:
Действующий vCenter Server не ниже седьмой версии
Компьютер Windows, Mac или Linux с установленным PowerShell Core и фреймворком PowerCLI 12.1 Core
Перед исполнением сценария вам нужно заполнить все его параметры, относящиеся к вашей текущей инфраструктуре и к создаваемой тестовой лаборатории, а также распаковать содержимое ISO-образа виртуального сервера vCSA.
Пример исполнения сценария показан ниже:
В итоге процесс будет выполняться пошагово до его завершения с информацией о каждом шаге:
Ну и после всего этого в vSphere Client вы увидите вашу созданную виртуальную тестовую лабораторию с тремя хостами ESXi и сервером управления vCenter / vCSA:
Скачать сценарий Automated vSphere & vSAN 8 Lab Deployment можно по этой ссылке, там же есть более подробная информация о том, как его использовать.
Вчера мы писали о том, что решение VMware vSphere 8 стало доступным для загрузки (Initial Availability). Анонсированная на конференции Explore 2022 платформа приобрела не только новые функции клиента vSphere Client, предназначенного для управления инфраструктурой на базе vCenter, но и получила новую версию хостового клиента для отдельных серверов ESXi Host Client 2, который удобно использовать, когда vCenter недоступен.
Напомним, что в прошлый раз о этом клиенте мы писали вот тут, тогда VMware планировала выпустить его второе поколение в конце 2021 года. Теперь Host Client 2 поддерживает не только управление инфраструктурой vSphere 8, но и серверы виртуализации vSphere 7.0 Update 6 (обновление пока не вышло).
Итак, что же нового в VMware ESXi Host Client 2:
1. Обновленная иконка приложения
Самое главное:)
2. Новый дизайн интерфейса на базе фреймворка Clarity
Многие из вас в курсе, что VMware перевела почти все свои интерфейсы на собственный open source фреймворк Clarity, и хостовый клиент стал очередным продуктом, который также был на него переведен. Рабочие процессы теперь выглядят более опрятно, а шаги мастеров - более организованно:
Браузер датасторов теперь дает больше информативности, а сами надписи и информационные лейблы стали более читаемыми. Файлы теперь можно загружать в параллельном режиме в фоне, а колонки позволяют обеспечивать видимость глубокой структуры каталогов:
3. Улучшенные иконки
Теперь в качестве визуальных элементов используется более 100 иконок, которые соответствуют таковым из конвенционального vSphere Client. Все иконки стали монохромными, чтобы не нагружать интерфейс и глаза.
Вот так выглядят портлеты свойств:
А вот так - действий:
4. Специальные возможности
Теперь для слабовидящих людей есть приятные улучшения. Элементы попадают в обводку:
Для полей ввода есть выделение (можно переключаться между ними по Tab или Shift+Tab), а на вкладках четко видны активные элементы:
5. Выбор светлой или темной темы
Тему можно выбрать в разделе Help > About > UI Preferences Theme:
На выбор есть 3 темы. Стандартная - это светлые цвета и мягкий контраст:
Классическая - для привыкших к стандартному белому фону:
И темная - для чувствительных к свету и любителей работать по ночам:
Но вообще по кнопке Customize можно настроить различные цвета для визуальных групп:
6. Кастомизабельный стартовый экран
В файле /etc/vmware/welcome можно редактировать иконку и приветственное сообщение, которые могут быть индивидуальными для каждой компании:
Таблица поддерживаемых браузеров сейчас выглядит так:
Клиент ESXi Host Client 2 в обновленной платформе VMware vSphere 8 доступен администраторам по ссылке в браузере:
Недавно мы писали о новой схеме релизов платформы VMware vSphere. Согласно ей, вводится два типа выпусков - IA (Initial Availability) и GA (General Availability), которые позволяет выровнять схему релизов с продуктами облачной линейки Cloud Services в рамках доступной пользователям подписки vSphere+.
Вчера VMware объявила о доступности vSphere 8 Initial Availability - продукт можно скачать по этой ссылке. О возможностях новой версии платформы мы писали вот тут.
IA-релиз - это полностью Enterprise-ready продукт, который соответствует всем промышленным стандартам VMware уровня релиза GA, но доступен он, как правило, на 4-6 недель раньше, чтобы собрать условия его применения от клиентов (и, конечно же, критичные для инфраструктуры баги). В этот промежуток времени будут публиковаться все найденные важные проблемы.
Ставить этот релиз в производственной среде вы можете, но это не рекомендуется. Пока его лучше обкатывать на тестовых серверах и смотреть, как все работает (особенно новый функционал платформы). После выхода vSphere 8 General Availability можно смело устанавливать продукт на свои производственные серверы, так как все критичные проблемы первоначального релиза будут уже решены.
На прошедшей конференции Explore 2022 компания VMware представила новую версию платформы виртуализации VMware vSphere 8. Там появилось довольно много всего нового с точки зрения функциональности и производительности, но сегодня мы поговорим еще об одном нововведении - новой схеме релизов vSphere 8.
Итак, компания VMware вводит новую модель IA/GA (Initial Availability/General Availability), которая позволяет выровнять схему релизов с продуктами облачной линейки Cloud Services в рамках доступной пользователям подписки vSphere+.
IA-релиз это полностью Enterprise-ready продукт, который соответствует всем промышленным стандартам VMware уровня релиза GA, но доступен он будет, как правило, на 4-6 недель раньше, чтобы собрать условия его применения от клиентов (и, конечно же, критичные для инфраструктуры баги). В этот промежуток времени будут публиковаться все найденные важные проблемы.
Одна из причин такого перехода - это то, что раньше релиз мажорной версии многие пользователи пропускали, ожидая хотя бы Update 1, который часто исправлял некоторые проблемы первоначального релиза новой версии платформы. Теперь у пользователей будет достаточно времени, чтобы оценить - произошло ли за эти 1-2 месяца что-то критичное, и можно ли обновлять свои хост-серверы. Такая схема должна работать эффективнее, так как до очередного пакета Update X проходит в среднем полгода.
Таким образом, общая схема выпусков IA/GA для VMware vSphere теперь выглядит так:
Вчера мы писали о важном нововведении технологии горячей миграции виртуальных машин vMotion Notifications, появившемся в обновленной версии VMware vSphere 8, представленной на конференции Explore 2022. Она позволяет оповещать приложение гостевой ОС о скором начале миграции, чтобы оно могло подготовиться к ней и выполнить процедуры по приостановке сервисов или переключению на резервную систему для кластеризованных приложений.
Второе важное нововведение vMotion в ESXi 8 - это технология Unified Data Transport.
Для миграции включенных виртуальных машин используется протокол vMotion, который оптимизируют уже много лет - он многопоточный и асинхронный, что позволяет минимизировать время перемещения виртуальной машины между хостами ESXi. Этот же протокол использует и технология миграции хранилищ Storage vMotion. В то же время, если вам нужно переместить выключенную виртуальную машину (холодная миграция), то это может занять значительное время, так как в этом случае используется протокол Network File Copy (NFC).
Приведем ниже сравнительные характеристики обоих протоколов (реальная скорость миграции будет зависеть от параметров вашего окружения):
Network File Copy (NFC)
vSphere vMotion
Процесс в один поток
Глубоко оптимизированный многопоточный процесс
Синхронный ввод-вывод
Асинхронный ввод-вывод
Пиковая производительность 1.3 Gbps
Пиковая производительность 80 Gbps
Чтобы привести все к единому уровню производительности, VMware представила технологию Unified Data Transport (UDT) в платформе vSphere 8, которая комбинирует лучшие моменты обеих технологий NFC и vMotion.
Unified Data Transport (UDT) использует NFC как протокол для управления миграцией, а вот сама передача данных идет через протокол vSphere vMotion. Для того, чтобы эта технология работала, вам нужно активировать сервис "Provisioning" для интерфейса VMkernel (это может быть как новый, так и уже существующий интерфейс):
Если вы используете выделенный стек TCP/IP для vMotion, вы не сможете активировать службу "Provisioning" на этом же интерфейсе, в этом случае можно просто создать еще один интерфейс.
Посмотреть вживую, насколько хорошо работает технология Unified Data Transport для холодной миграции виртуальных машин, вы можете в видео ниже:
По итогам прошедшей конференции Explore 2022 компания VMware анонсировала платформу виртуализации vSphere 8. В прошлой версии платформы в технологии горячей миграции vMotion появилось очень много всего нового (например, вот, тут, тут, тут и тут). В этой версии также были сделаны некоторые улучшения vMotion, давайте на них посмотрим.
vSphere vMotion Notifications
Как вы знаете, переключение с одного процесса ВМ на другой целевого хоста ESXi занимает очень мало времени, и для большинства приложений это незаметно. Однако есть очень небольшое количество приложений, которые не могут пережить малые задержки (latency), поскольку очень интенсивно используют ресурсы CPU и хранилищ. Таких случаев буквально единицы, но VMware решила позаботиться и о них.
Теперь приложения могут быть написаны таким образом, чтобы они могли получить оповещение о предстоящей миграции vMotion и подготовиться к ней. Такие действия могут включать в себя остановку сервисов, заморозку приложения (quiescing), переключение на резервный инстанс в случае кластеризованного приложения, а также выполнение других операций.
Приложение может отложить миграцию vMotion на заданный таймаут, но не может отклонить и остановить ее. Вот как это работает (кликните на картинку для открытия анимации):
Приложение, через механизм VMware Tools, может быть оповещено о начале задачи vMotion. На полученную нотификацию оно реагирует согласно своей логике, после чего отсылает подтверждение платформе ESXi о том, что миграцию можно начинать. Виртуальная машина затем перемещается с помощью vMotion, после чего приложение получает оповещение о завершении миграции, чтобы оно могло также выполнить необходимые шаги, учитывая действия, совершенные на этапе подготовки.
Механизм vMotion Notifications не включен по умолчанию. Чтобы это работало, надо в расширенных настройках виртуальной машины установить параметр vmOpNotificationToAppEnabled:
После этого нужно установить host-level timeout, который будет определять максимальное время, которое есть у виртуальной машины для завершения подготовки к миграции. Для этого нужно через vSphere API установить параметр vmOpNotificationToApp.Timeout со значением большим 0. Значение устанавливается в секундах (то есть, чтобы дать приложению 5 минут, нужно установить значение 300).
Для установки данного параметра используйте ConfigManager API (см. документацию).
Приложение должно использовать утилиту командной строки vmtoolsd пакета VMware Tools для регистрации оповещений. Вот какие команды ему доступны:
Вчера мы писали о новых возможностях поддержки vVols в платформе VMware vSphere 8, анонсированные на конференции VMware Explore 2022. В то же время, с точки зрения хранилищ в платформе VMware vSphere 8 появилось еще несколько улучшений, о которых мы сегодня расскажем.
1. Улучшения возврата емкостей в хранилище (Space Reclamation)
Теперь минимально доступная скорость возврата (reclamation rate) уменьшена до 10 MBPS. Еще в vSphere 6.7 появилась функция регулировки скорости возврата (Space Reclamation, он же UNMAP) емкостей от платформы vSphere на сторону хранилища. Но даже на минимальной скорости 25 MBPS при одновременном выполнении команд доступа хостов к хранилищам происходили сбои из-за нагрузки и падение производительности, поэтому администраторам дали возможность снизить ее до 10 MBPS на уровне датастора.
Также теперь появилась выделенная очередь исполнения команд UNMAP для выскоприоритетных операций ввода-вывода метаданных VMFS. Это сделано для того, чтобы важные и первоочередные операции не затерялись в общем трафике UNMAP-команд.
2. Контейнерные хранилища CNS/CSI
Теперь для хранилищ CNS/Tanzu
доступны политики хранилищ SPBM - EZT, LZT или Thin provisioning. Это позволит движку SPBM поддерживать создание и изменение правил политик, чтобы определить опции выделения томов. Также это упростит проверки комплаенса политик SPBM в отношении правил выделения томов.
Для виртуальных дисков поддерживаются следующие операции: create, reconfigure, clone и relocate
Для FCD-устройств поддерживаются: create, update storage policy, clone и relocate
3. Улучшения работы с NFS-хранилищами
Здесь были добавлены следующие функции для повышения надежности и стабильности:
Повторная попытка монтирования томов при сбоях (Retry NFS mounts on failure)
Валидация правильности монтирования томов (NFS mount validation)
Более подробно о нововведениях VMware vSphere 8 в плане хранилищ рассказано вот в этой статье.
На конференции Explore 2022 компания VMware объявила о выпуске новой версии платформы VMware vSphere 8, о возможностях которой мы уже писали. Сегодня мы посмотрим, что нового появилось в механизме работы томов vVols, которые позволяют более гибко подходить к хранению объектов виртуальных машин за счет передачи некоторых функций работы с их данными на сторону хранилищ.
Сегодня мы поговорим о нововведениях, которые появились в технологии vVols для восьмой версии платформы.
1. Поддержка технологии NVMe-oF
Это большое нововведение означает поддержку томами vVols на платформе vSphere 8 технологии NVMe-oF. В новой спецификации vVols появились определения vSphere API для механики работы с хранилищами VASA (vSphere Storage APIs for Storage Awareness) 4.0.
Напомним, что NVMe-oF - это реализация технологии RDMA, которая позволяет не использовать CPU для удаленного доступа к памяти и пропускать к хранилищу основной поток управляющих команд и команд доступа к данным напрямую, минуя процессоры серверов и ядро операционной системы. Еще один его плюс - это то, что он обратно совместим с такими технологиями, как InfiniBand, RoCE и iWARP. Для всего этого нужна поддержка RDMA со стороны HBA-адаптера хоста ESXi.
NVMe-oF имеет преимущество в виде меньших задержек (latency) над традиционным интерфейсом SCSI. Эта технология изначально предназначена для флэш-памяти и позволяет подключать all-flash NVMe дисковые массивы с очень высокой производительностью.
В рамках технологии NVMe-oF vVols каждый объект vVol становится пространством имен NVMe Namespace. Эти пространства имен группируются в ANA group (Asymmetrical Namespace Access). Многие команды проходят как In-Band для более эффективной коммуникации между хостами ESXi и дисковыми массивами.
Также упростилась настройка томов, в том числе NVMe с технологией vVols. При развертывании NVMe в vCenter, когда зарегистрирован VASA-провайдер, оставшаяся установка происходит в фоновом режиме, а обнаружение NVMe-контроллеров происходит автоматически. Как только создается датастор, объекты vPE (virtual Protocol Endpoints) и само соединение подхватываются и обрабатываются автоматически.
2. Дополнительные улучшения vVols NVMe-oF
Они включают в себя следующее:
Поддержка до 256 пространств имен и 2000 путей
Расширенная поддержка механизма резерваций для устройств NVMe - это позволит поддерживать функцию Clustered VMDK для кластеризованных приложений, таких как Microsoft WSFC на базе хранилищ NVMe-oF
Функции автообнаружения в механизме NVMe Discovery Services для ESXi при использовании NVMe-TCP для обнаружения контроллеров NVMe
3. Прочие улучшения
Улучшение VM swap - уменьшенное время при включении и выключении для обеспечения лучшего быстродействия vMotion
Улучшенная производительность компонента config-vVol - убраны задержки при обращения виртуальных машин к платформе ESXi
В рамках событий первого дня проходящей сейчас конференции VMware Explore 2022 была анонсировала платформа виртуализации VMware vSphere 8. Это событие очень ждали многие администраторы и менеджеры датацентров, так как с момента релиза прошлой мажорной версии платформы VMware vSphere 7 прошло уже два с половиной года. Давайте посмотрим, что нового в VMware vSphere 8...
Компания VMware на днях выпустила два обновления своей платформы виртуализации vSphere 7 - ESXi 7 Update 3f и vCenter 7 Update 3f. Напомним, что об обновлении vSphere 7 Update 3d мы писали вот тут.
Давайте посмотрим, что в них появилось нового.
VMware ESXi 7 Update 3f:
Данный релиз исправляет уязвимости, описанные в бюллетенях CVE-2022-23816, CVE-2022-23825, CVE-2022-28693 и CVE-2022-29901. Для подробной информации об этих проблемах вы можете обратиться к статье VMSA-2022-0020.
Добавлена поддержка vSphere Quick Boot для следующих серверов:
Исправления уязвимостей CVE-2022-22982 (подробнее тут) и CVE-2021-22048 (подробнее тут)
Улучшения масштабируемости архитектуры VMware HCI Mesh - теперь один кластер vSAN может обслуживать локальные датасторы до 10 клиентских кластеров vSAN
Улучшения компонентов vSphere Client - исправлены некоторые проблемы с дата-гридами, инвентарем (более компактное представление), Related Objects и Global Inventory Lists. Ну и в целом улучшено юзабилити клиента.
Обновление инфраструктуры VMware vSphere with Tanzu (подробнее тут)
Как вы знаете, через интерфейс esxcli на сервере VMware ESXi можно устанавливать расширенные настройки (Advanced Settings). Список таких доступных настроек можно вывести командой:
esxcli system settings advanced list
При этом не все пространства имен (namespaces) доступны через этот интерфейс командной строки. Эти настройки, в таком случае, как правило, доступны через интерфейс vSphere Client, но вам может понадобиться заскриптовать их. Об этом рассказал Дункан Эппинг.
Некоторые администраторы vSphere знают, что есть также такой интерфейс vim-cmd, который уже не рекомендуется использовать, но, тем не менее, его еще можно применять для установки некоторых настроек. Среди них, например, есть настройка Config.HostAgent.ssl.keyStore.allowSelfSigned для разрешения самоподписанных сертификатов на хостах ESXi.
В этом случае вы можете использовать команды в следующем формате:
vim-cmd hostsvc/advopt/update name.option type value
Для самоподписанных сертификатов нужная команда выглядит так:
Как известно, компания VMware предлагает пользователям онпремизных инфраструктур несколько иной набор инструментов, чем таковые доступны в облачной инфраструктуре на базе VMware Cloud. Да, в случае организации гибридной инфраструктуры (то есть комбинации собственной площадки и облачной) спектр этих инструментов существенно расширяется, как, например, для решения VMware Cloud Availability, но пользователи все еще не могут использовать все доступные решения. Между тем, многие клиенты VMware хотели бы организовать полноценную облачную инфраструктуру, сохраняя все рабочие нагрузки в собственном датацентре - таковы, зачастую, требования комплаенса.
Именно для таких клиентов VMware недавно запустила программу vSphere+, которая сочетает в себе возможности платформы виртуализации на базе издания VMware vSphere Enterprise Plus, а также облачные средства, такие как VMware Cloud Console для создания единой точки контроля и управления внутренним облаком.
Надо отметить, что сюда входят средства для поддержания инфраструктуры на базе контейнеризованных приложений Kubernetes, чтобы в компании могли организовать полноценное SaaS-облако (это обеспечивается продуктами Tanzu Standard Runtime и Tanzu Mission Control Essentials).
В рамках vSphere+ у клиента остаются хосты ESXi и серверы управления vCenter, но они подключаются к облачному сервису Cloud Console через VMware Cloud Gateway. Администраторы могут выполнять глобальные операции по управлению и оркестрации среды виртуальных машин и контейнеров, опционально имея в своем распоряжении инструменты для создания гибридной среды.
Используя vSphere+ совместно с vSAN+, пользователи могут создавать масштабируемые сервисы, надежно защищенные от сбоев вычислительных ресурсов и хранилищ, а гибкие планы подписки позволяют платить на базе потребляемых ресурсов и функциональности облака.
С помощью Cloud Console пользователи могут централизовать большой объем задач, выполняемых компонентами разных продуктовых линеек VMware в рамках собственного датацентра, которые обычно управляются из разных инстансов vCenter.
Администратор в этой консоли может выполнять следующие задачи:
Управление жизненным циклом сервисов vCenter, включая обновления для группы серверов (кнопка Update Now), обеспечивая окно обновления всего в несколько минут и возможность отката к прошлой версии.
Глобальный инвентарь сервисов с возможностью визуализации ресурсов по всем кластерам, хостам и виртуальным машинам, с доступом к ресурсам CPU, памяти и хранилищ.
Просмотр всех событий и алертов, происходящих в облачной среде - это ускоряет поиск причин проблем в разы.
Проверка на безопасность и комплаенс всей инфраструктуры vSphere, с возможностью обнаружения проблем, таких как незакрытые SSH-сессии, устаревшие SSL-протоколы и прочее, а также предпринятие действий по их устранению.
Развертывание виртуальных машин в рамках всей инфраструктуры, без необходимости переключаться между инстансами vCenter.
Средства поддержки единой конфигурации серверов vCenter в соответствии с внутренними стандартами компании.
Помимо административных утилит, подписка vSphere+ дает множество возможностей для разработчиков, работающих с кластерами Kubernetes:
Сервис Tanzu Kubernetes Grid, позволяющий исполнять контейнеризованные приложения в сертифицированной среде Kubernetes, тесно интегрированной с инфраструктурой vSphere, используя знакомый набор средств управления для разработчиков в онпремизном окружении.
VM service - это возможности развертывания ВМ с помощью команд и API, что позволяет создавать комбинации из ВМ и контейнеров в единой среде.
Network service - средства для создания виртуальных коммутаторов, балансировщиков нагрузки и правил сетевого экрана для ВМ и кластеров Kubernetes.
Storage service - возможность управления персистентными дисками для контейнеров и ВМ. Также можно использовать существующие блочные и файловые хранилища для поддержки контейнеров.
Tanzu integrated services - это набор утилит для развертывания и управления локальными кластерами Kubernetes с возможностями логирования, реестра приложений, мониторинга и другими тулами для быстрого создания производственных Kubernetes-окружений.
Tanzu Mission Control Essentials - это решение дает разработчикам и командам DevOps возможность централизовать операции и управлять всем окружением Kubernetes на глобальном уровне, устраняя проблемы мониторинга и решения проблем. Этот сервис пока не готов и будет доступен в третьем квартале этого года.
Подписка vSphere+ доступна как для новых пользователей VMware, так и для существующих инфраструктур как апгрейд. Хосты vCenter и ESXi текущих версий можно соединить с облаком VMware Cloud, при этом никакие производственные нагрузки перенесены туда не будут.
С помощью сотрудников VMware вы можете перевести свои "вечные" лицензии на подписочную модель vSphere+ и платить в рамках годовых контрактов, не заботясь об управлении лицензионными ключами и продлении SnS. Все действующие подписки вы сможете отслеживать в единой консоли:
Также нужно упомянуть и возможности добавления аддонов в облачную инфраструктуру в рамках расширения подписки - первым таким решением станет VMware Cloud Disaster Recovery.
Больше подробностей о VMware vSphere+ вы можете узнать из вот этого видео:
Также более детальная техническая информация приведена вот в этой статье. Сам сервис vSphere+ доступен по этой ссылке.
Мы довольно часто пишем о максимальных параметрах виртуальной инфраструктуры VMware vSphere и ее компонентов, в частности VMware vCenter (например, тут и тут). Сегодня мы немного освежим эти данные на примере последней версии сервера управления vCenter и приведем несколько примеров. Для начала напомним, что актуальные данные по максимальным конфигурациям продуктов VMware можно найти по адресу: https://configmax.vmware.com, а также в официальной документации.
Кроме того, у VMware есть отличное видео, посвященное лимитам vCenter и правилам выполнения одновременных операций в виртуальной среде:
Итак, лимиты можно разделить на 2 категории:
Глобальные лимиты для инфраструктуры (виртуальный датацентр).
Лимиты на уровне хоста и его компонентов (например, сетевые адаптеры).
Если говорить о глобальных параметрах, то значения тут следующие:
Вы можете запустить до 640 одновременных операций в vCenter, пока они не начнут становиться в очередь.
Всего можно запустить до 2000 одновременных операций на один сервер vCenter.
На уровне хостов ESXi есть следующие механизмы работы и ограничения:
Хосты ESXi 6 и 7 версий имеют 16 слотов для выполнения операций в единицу времени:
Любая операция с виртуальными машинами потребляет какое-то количество слотов на источнике и целевом хосте.
Операция Storage vMotion стоит 8 слотов на хост. Если вы меняете только датастор у виртуальной машины, оставляя тот же хост, то потребляются эти 8 слотов, то вы можете сделать 2 одновременных миграции. Ранее это работало несколько иначе - смотрите наш пост вот тут.
Операция Linked clone потребляет 1 слот, но для этого у вас уже должен быть создан снапшот. Если у вас его нет, то он сначала создается - это может замедлить создание первого связанного клона. Также снапшот требуется и при клонировании включенной ВМ, где требуется уже 2 слота (то есть одновременно можно делать 8 таких операций для данной пары хостов).
Операции Clone, Relocate и vMotion стоят 2 слота каждая на каждом хосте - то есть и на источнике, и на целевом (суммарно получается потребляется 4 слота на двух хостах). Это же работает и при клонировании ВМ на том же самом хосте - на нем в этот момент потребляется 4 слота (то есть одновременно на хосте можно делать 4 таких операции).
Для датасторов также есть слоты и ограничения на одновременные операции:
У одного датастора есть 128 слотов.
Операция vMotion стоит 1 слот, то есть на одном датасторе может проходить до 128 одновременных миграций vMotion.
Операция Storage vMotion стоит 16 слотов, то есть на одном датасторе может проходить до 8 одновременных миграций vMotion.
Это же работает и для датасторов vSAN, где часто встречаются конфигурации с одним датастором - это надо иметь в виду.
Лимиты для сетевых адаптеров сейчас следующие (помните, что для vMotion лучше иметь отдельный адаптер или выделенную пару портов на нем):
У 1Gb NIC есть 4 слота, то есть можно делать до 4 одновременных миграций vMotion через этот адаптер.
У 10Gb и 25Gb NIC есть 8 слотов, то есть можно делать до 8 одновременных миграций vMotion через такие адаптеры.
Более подробно об организации адаптеров для vMotion вы можете прочитать в KB 2108824.
Некоторое время назад мы писали о службах VMware vSphere Cluster Services (ранее они назывались Clustering Services), которые появились в VMware vSphere 7 Update 1. Они позволяют организовать мониторинг доступности хостов кластера vSphere, без необходимости зависеть от служб vCenter. Для этого VMware придумала такую штуку - сажать на хосты кластера 3 служебных агентских виртуальных машины, составляющих vCLS Control Plane, которые отвечают за доступность кластера в целом:
Надо отметить, что эти службы обязательны для функционирования механизма динамической балансировки нагрузки в кластере VMware DRS. Если вы выключите одну из виртуальных машин vCLS, то увидите предупреждение о том, что DRS перестанет функционировать:
Иногда требуется отключить службы Cluster Services, что может оказаться необходимым в следующих случаях:
Вам нужно правильно удалить кластер HA/DRS и выполнить корректную последовательность по выводу его из эксплуатации
Требуется удалить / пересоздать дисковые группы VMware vSAN, на хранилищах которых размещены виртуальные машины vCLS
Вам не требуется использовать DRS, и вы хотите отключить эти службы. В этом случае помните, что механизм обеспечения отказоустойчивости VMware HA также будет функционировать некорректно. Он зависит механизма балансировки нагрузки при восстановлении инфраструктуры после сбоя - именно на DRS он полагается при выборе оптимальных хостов для восстанавливаемых виртуальных машин.
Режим, в котором службы Cluster Services отключены, называется Retreat Mode. Итак, заходим в vSphere Client и выбираем кластер, в котором мы хотим ввести Retreat Mode. В строке браузера нам нужна строка вида:
domain ID domain-c<number>
Скопировав эту часть строчки, идем в Advanced Setting сервера vCenter и нажимаем Edit Settings:
Далее создаем там параметр со следующим именем и значением false:
config.vcls.clusters.domain-cxxx.enabled
Где cxxx - это идентификатор домена, который вы скопировали на прошлом шаге:
После этого нажимаем кнопку Save. В консоли vSphere Client в разделе vCLS для кластера мы увидим, что этих виртуальных машин больше нет:
На вкладке Summary мы увидим предупреждение о том, что vSphere Cluster Services больше не работает, а службы DRS вследствие этого также не функционируют корректно:
Чтобы вернуть все как было, нужно просто удалить добавленный параметр из Advanced Settings сервера vCenter.
Недавно компания VMware провела действительно полезный вебинар для администраторов и менеджеров датацентров, в котором рассказала о самых последних лучших практиках по эксплуатации и обслуживанию виртуальной инфраструктуры VMware vSphere 7:
В целом, это видео не только для администраторов, но и для всех тех, кто продает, использует, развертывает, настраивает и управляет решениями VMware на ежедневной основе. В рамках вебинара вы узнаете о некоторых нетривиальных возможностях из богатого набора VMware vSphere 7.x, которые появились после релиза первоначальной версии 7.0.
Например, в видео рассказывается о функциях vSphere Cluster Services (vCLS), переработанных механизмах vMotion и DRS, новых возможностях поддержки GPU для требовательных к графике и CUDA-приложений, а также многих других нововведениях.
В целом, вы узнаете о лучших практиках в следующих сферах:
Проектирование виртуальной архитектуры
Развертывание vSphere
Тюнинг производительности
Использование средств управления
Масштабирование инфраструктуры
Обеспечение отказоустойчивости компонентов виртуальной среды
В ESXi 7 Update 3d появилась поддержка технологии vSphere Quick Boot для следующих платформ:
Dell Inc. C6420 vSAN Ready Node
Dell Inc. MX740C vSAN Ready Node
Dell Inc. MX750C vSAN Ready Node
Dell Inc. PowerEdge R750xa
Dell Inc. PowerEdge R750xs
Dell Inc. PowerEdge T550
Dell Inc. R650 vSAN Ready Node
Dell Inc. R6515 vSAN Ready Node
Dell Inc. R740 vSAN Ready Node
Dell Inc. R750 vSAN Ready Node
Dell Inc. R7515 vSAN Ready Node
Dell Inc. R840 vSAN Ready Node
Dell Inc. VxRail E660
Dell Inc. VxRail E660F
Dell Inc. VxRail E660N
Dell Inc. VxRail E665
Dell Inc. VxRail E665F
Dell Inc. VxRail E665N
Dell Inc. VxRail G560
Dell Inc. VxRail G560F
Dell Inc. VxRail P580N
Dell Inc. VxRail P670F
Dell Inc. VxRail P670N
Dell Inc. VxRail P675F
Dell Inc. VxRail P675N
Dell Inc. VxRail S670
Dell Inc. VxRail V670F
В VMware vCenter 7.0 Update 3d появились следующие улучшения:
Исправление проблемы безопасности CVE-2022-22948. Более подробно об этом рассказано тут.
Множество исправлений ошибок, полный список которых приведен тут. Решены проблемы с развертыванием ВМ из OVF-шаблонов, исправлены ошибки с накатыванием инкрементальных патчей vCenter, а также проблема с сообщением о невозможности подключения к серверу Single Sign-On.
Обновлены компоненты VMware vSphere with Tanzu, подробнее об этом рассказано тут.
Обновлены компоненты Photon OS, подробнее об этом рассказано тут.
Скачать компоненты VMware vSphere 7.0 Update 3d можно по этой ссылке. Release Notes доступны тут:
RSS
