На этот раз Дункан рассказал о работе функции Federated Storage View для платформы VMware vSAN, а также для других традиционных систем хранения данных. Это представление позволит получить визуальную информацию о емкостях и производительности хранилищ, а также наглядно отобразит конфигурацию растянутого кластера (stretched cluster).
Поскольку это визуальный инструмент, Дункан записал обзорное видео, из которого вы сможете понять, как это работает:
После прошедших главных конференций года VMware Explore 2024 US и Europe Вильям Лам провел большую работу по сбору и категоризации сессий, выложив их все в открытом доступе в своем репозитории на Github. Эти презентации доступны как в виде ссылок на видеозаписи, так и в виде pdf-документов, где можно найти массу информации о новых продуктах и технологиях VMware.
Вильям Лам написал наиполезнейшую статью о сбросе/восстановлении пароля консоли сервера VMware ESXi 8 и 7 в составе платформы виртуализации VMware vSphere.
Ранее также было возможно сбросить пароль root ESXi, загрузив систему в Linux и вручную обновив файл /etc/shadow, что похоже на то, как можно сбросить пароль в системе на базе Linux. В сети можно найти множество статей в блогах, описывающих этот процесс. Однако с появлением ESXi Configuration Store данный метод больше не работает для современных версий ESXi, начиная с ESXi 7.0 Update 1 и выше.
Тем не менее, эта тема все еще часто поднимается, особенно в контексте администраторов, которые начинают работать в новой компании, где пароль root ESXi не был должным образом задокументирован, или когда администратору поручено поддерживать набор отдельных ESXi хостов без владельцев. Независимо от сценария, хотя переустановка является самым быстрым способом восстановления, конечно, было бы неплохо сохранить исходную конфигурацию, особенно если нет документации.
Хотя в сети было опубликовано множество фрагментов информации (здесь, здесь и здесь), включая информацию от самого Вильяма, было бы полезно выяснить по шагам актуальный процесс восстановления ESXi 7.x или 8.x хоста без необходимости его переустановки.
Предварительные требования:
Доступ к физическому носителю, на который установлен ESXi (USB или HDD/SSD)
Виртуальная машина Linux (Ubuntu или Photon OS)
Виртуальная машина с вложенным ESXi
Для демонстрации описанного ниже процесса восстановления Вильям установил ESXi 8.0 Update 3c на USB-устройство с базовой конфигурацией (имя хоста, сеть, SSH MOTD), чтобы убедиться в возможности восстановления системы. Затем он изменил пароль root на что-то полностью случайное и удалил этот пароль, чтобы нельзя было войти в систему. Хост ESXi, на котором он "забыл" пароль, будет называться физическим хостом ESXi, а вложенная виртуальная машина с ESXi, которая будет помогать в восстановлении, будет называться вложенным хостом (Nested ESXi).
Шаг 1 — Разверните вложенную виртуальную машину с ESXi (скачать с сайта VMware Flings), версия которой должна соответствовать версии вашего физического хоста ESXi, который вы хотите восстановить.
Шаг 2 — Скопируйте файл state.tgz с физического хоста ESXi, который вы хотите восстановить. Обязательно сделайте резервную копию на случай, если допустите ошибку.
Если ваш хост ESXi установлен на USB, отключите USB-устройство, подключите его к настольной системе и скопируйте файл с тома BOOTBANK1.
Если ваш хост ESXi установлен на HDD/SSD, вам нужно будет загрузить физическую систему с помощью Linux LiveCD (Ubuntu или Knoppix) и смонтировать раздел 5 для доступа к файлу state.tgz.
Шаг 3 — Скопируйте файл state.tgz с вашего физического хоста ESXi на вложенный хост ESXi и поместите его в /tmp/state.tgz, затем выполните следующую команду для извлечения содержимого файла:
tar -zxvf state.tgz
rm -f state.tgz
Шаг 4 — Войдите на ваш вложенный хост ESXi и выполните следующие команды для извлечения его файла state.tgz, который будет помещен в каталог /tmp/a. Затем мы используем утилиту crypto-util для расшифровки файла local.tgz.ve вложенного хоста ESXi, чтобы получить файл local.tgz, и затем просто удаляем зашифрованный файл вместе с файлом encryption.info вложенного хоста ESXi. После этого мы заменим их файлом encryption.info с нашего физического хоста ESXi и создадим модифицированную версию state.tgz, которая будет загружаться в нашей вложенной виртуальной машине ESXi. Мы используем это для расшифровки исходного файла state.tgz с нашего физического хоста ESXi.
mkdir /tmp/a
cd /tmp/a
tar xzf /bootbank/state.tgz
crypto-util envelope extract --aad ESXConfiguration local.tgz.ve local.tgz
rm -f local.tgz.ve encryption.info
cp /tmp/encryption.info /tmp/a/encryption.info
tar -cvf /tmp/state-mod.tgz encryption.info local.tgz
После успешного выполнения последней команды, нам нужно скопировать файл /tmp/state-mod.tgz на ваш рабочий стол, а затем выключить вложенную виртуальную машину ESXi.
Шаг 5 — Смонтируйте первый VMDK диск из вашей вложенной виртуальной машины ESXi на вашу виртуальную машину с Linux. В данном случае Вильм использует Photon OS, который также управляет и DNS-инфраструктурой.
Шаг 6 — Убедитесь, что VMDK вашей вложенной виртуальной машины ESXi виден в вашей системе Linux, выполнив следующую команду. Мы должны увидеть два раздела bootbank (5 и 6), как показано на скриншоте ниже:
fdisk -l
Шаг 7 — Перенесите файл state-mod.tgz, созданный на Шаге 4, на вашу виртуальную машину с Linux, затем смонтируйте оба раздела bootbank и замените файл state.tgz на нашу модифицированную версию.
Примечание: Этот шаг необходим, потому что, если вы просто скопируете модифицированный файл state.tgz напрямую на USB-устройство физического хоста ESXi, вы обнаружите, что система восстановит оригинальный файл state.tgz, даже если на обоих разделах содержится модифицированная версия.
Шаг 8 — Сделайте remove (не удаляйте) VMDK файл вложенной виртуальной машины ESXi с виртуальной машины Linux, затем включите вложенную виртуальную машину ESXi.
После успешной загрузки вложенной виртуальной машины ESXi, она теперь работает с оригинальным файлом encryption.info с нашего физического хоста ESXi, что позволит нам восстановить исходный файл state.tgz.
Шаг 9 — Скопируйте исходный файл state.tgz, созданный на Шаге 2, во вложенную виртуальную машину ESXi, поместите его в каталог /tmp/state.tgz и выполните следующую команду, которая теперь позволит нам расшифровать файл state.tgz с физического хоста ESXi, как показано на скриншоте ниже!
cd /tmp
tar -zxvf state.tgz
rm -f state.tgz
crypto-util envelope extract --aad ESXConfiguration local.tgz.ve local.tgz
rm -f local.tgz.ve
Шаг 10 — После расшифровки исходного файла state.tgz у нас должен появиться файл local.tgz, который мы извлечем локально в каталоге /tmp, выполнив следующую команду:
tar -zxvf local.tgz
Следующие три каталога: .ssh, etc/ и var/ будут размещены в /tmp, а /tmp/var/lib/vmware/configstore/backup/current-store-1 — это хранилище конфигурации ESXi для физического хоста ESXi, которое нам нужно обновить и заменить оригинальный хеш пароля root на желаемый, чтобы мы могли войти в систему.
Для непосредственного изменения хранилища конфигурации ESXi нам необходимо использовать утилиту sqlite3, так как файл хранится в виде базы данных sqlite3. Мы можем выполнить следующую команду на вложенной виртуальной машине ESXi, чтобы проверить текущий хеш пароля root:
/usr/lib/vmware/sqlite/bin/sqlite3 /tmp/var/lib/vmware/configstore/backup/current-store-1 "select * from config where Component='esx' and ConfigGroup = 'authentication' and Name = 'user_accounts' and Identifier = 'root'"
Шаг 11 — Вам потребуется новый хеш пароля в формате SHA512, где вы знаете сам пароль, после чего выполните следующую команду, заменив хеш.
/usr/lib/vmware/sqlite/bin/sqlite3 /tmp/var/lib/vmware/configstore/backup/current-store-1 "update config set UserValue='{\"name\":\"root\",\"password_hash\":\"\$6\$s6ic82Ik\$ER28x38x.1umtnQ99Hx9z0ZBOHBEuPYneedI1ekK2cwe/jIpjDcBNUHWHw0LwuRYJWhL3L2ORX3I5wFxKmyki1\",\"description\":\"Administrator\"}' where Component='esx' and ConfigGroup = 'authentication' and Name = 'user_accounts' and Identifier = 'root'"
Примечание: Вам нужно правильно экранировать любые специальные символы, например, как в приведенном выше примере, где хеш пароля содержит символ "$". Чтобы убедиться, что замена хеша выполнена правильно, вы можете выполнить вышеуказанную команду запроса, чтобы убедиться, что вывод соответствует желаемому хешу пароля, как показано на скриншоте ниже.
Шаг 12 — Теперь, когда мы обновили хранилище конфигурации ESXi с нашим желаемым паролем root, нам нужно заново создать файл state.tgz, который будет содержать наши изменения, выполнив следующие команды:
rm -f local.tgz
tar -cvf /tmp/local.tgz .ssh/ etc/ var/
tar -cvf /tmp/state-recover.tgz encryption.info local.tgz
Скопируйте файл /tmp/state-recover.tgz с вложенной виртуальной машины ESXi на вашу виртуальную машину с Linux, которая затем будет использоваться для монтирования носителя физического хоста ESXi, чтобы заменить файл state.tgz на нашу восстановленную версию.
Шаг 13 — Смонтируйте носитель физического хоста ESXi на вашу виртуальную машину с Linux. Поскольку физический хост ESXi установлен на USB, можно просто подключить USB-устройство напрямую к виртуальной машине с Linux.
Снова мы можем убедиться, что виртуальная машина с Linux видит носитель с установленным физическим хостом ESXi, выполнив команду fdisk -l, и мы должны увидеть два раздела bootbank (5 и 6), как показано на скриншоте ниже.
Шаг 14 — Теперь нам просто нужно смонтировать раздел bootbank и заменить оригинальный файл state.tgz на нашу модифицированную версию (state-recover.tgz).
Примечание: Поскольку физический хост ESXi был только что установлен, на втором разделе bootbank не было ничего для замены, но если вы найдете файл state.tgz, его также следует заменить, используя ту же команду, но указав другой номер раздела.
Шаг 15 — Последний шаг: размонтируйте носитель физического хоста ESXi с виртуальной машины Linux, затем включите ваш физический хост ESXi, и теперь вы сможете войти в систему, используя обновленный пароль root!
Блогер Дункан Эппинг записал отличное видео по теме защиты данных кластеров отказоустойчивости средствами продукта VMware vSAN Data Protection для VMware Explore в Лас-Вегасе и Барселоне. Так как ему поступали вопросы от людей по поводу защиты данных vSAN, он решил поделиться демо на YouTube и опубликовать его в своем блоге. Ранее он выпустил несколько статей о защите данных vSAN и стал замечать, что некоторые клиенты начинают тестировать эту функцию и даже использовать её в производственных средах, где это возможно. Как мы также писали ранее, решение vSAN Data Protection доступно только только в рамках архитектуры vSAN ESA, так как она использует новые возможности создания моментальных снимков (снапшотов). Также полностью новый интерфейс был представлен в средстве управления Snap Manager Appliance. Обязательно скачайте, разверните и настройте его в первую очередь.
Собственно, само демо VMware vSAN Data Protection, которое стоит посмотреть, если вы интересуетесь защитой данных в рамках виртуальной инфраструктуры VMware vSphere и vSAN:
Memory Tiering использует более дешевые устройства в качестве памяти. В Update 3 платформа vSphere использует флэш-устройства PCIe на базе NVMe в качестве второго уровня памяти, что увеличивает доступный объем памяти на хосте ESXi. Memory Tiering через NVMe оптимизирует производительность, распределяя выделение памяти виртуальных машин либо на устройства NVMe, либо на более быструю динамическую оперативную память (DRAM) на хосте. Это позволяет увеличить объем используемой памяти и повысить емкость рабочих нагрузок, одновременно снижая общую стоимость владения (TCO).
Вильям Лам написал интересный пост о выводе информации для NVMe Tiering в VMware vSphere через API. После успешного включения функции NVMe Tiering, которая была введена в vSphere 8.0 Update 3, вы можете найти полезную информацию о конфигурации NVMe Tiering, перейдя к конкретному хосту ESXi, затем выбрав "Configure" -> "Hardware" и в разделе "Memory", как показано на скриншоте ниже.
Здесь довольно много информации, поэтому давайте разберём отдельные элементы, которые полезны с точки зрения NVMe-тиринга, а также конкретные vSphere API, которые можно использовать для получения этой информации.
Memory Tiering Enabled
Поле Memory Tiering указывает, включён ли тиринг памяти на хосте ESXi, и может иметь три возможных значения: "No Tiering" (без тиринга), "Hardware Memory Tiering via Intel Optane" (аппаратный тиринг памяти с помощью технологии Intel Optane) или "Software Memory Tiering via NVMe Tiering" (программный тиринг памяти через NVMe). Мы можем получить значение этого поля, используя свойство "memoryTieringType" в vSphere API, которое имеет три перечисленных значения.
Вот небольшой фрагмент PowerCLI-кода для получения этого поля для конкретного хоста ESXi:
Поле Tier 0 представляет общий объём физической оперативной памяти (DRAM), доступной на хосте ESXi. Мы можем получить это поле, используя свойство "memoryTierInfo" в vSphere API, которое возвращает массив результатов, содержащий значения как Tier 0, так и Tier 1.
Вот небольшой фрагмент PowerCLI-кода для получения этого поля для конкретного хоста ESXi:
((Get-VMHost "esxi-01.williamlam.com").ExtensionData.Hardware.MemoryTierInfo | where {$_.Type -eq "DRAM"}).Size
Tier 1 Memory
Поле Tier 1 представляет общий объём памяти, предоставляемой NVMe-тирингом, которая доступна на хосте ESXi. Мы можем получить это поле, используя свойство "memoryTierInfo" в vSphere API, которое возвращает массив результатов, содержащий значения как Tier 0, так и Tier 1.
Примечание: Можно игнорировать термин "Unmappable" — это просто другой способ обозначения памяти, отличной от DRAM.
Вот небольшой фрагмент PowerCLI-кода для получения этого поля для конкретного хоста ESXi:
((Get-VMHost "esxi-01.williamlam.com").ExtensionData.Hardware.MemoryTierInfo | where {$_.Type -eq "NVMe"}).Size
Поле Total представляет общий объём памяти, доступный ESXi при объединении как DRAM, так и памяти NVMe-тиринга, который можно агрегировать, используя размеры Tier 0 и Tier 1 (в байтах).
Устройства NVMe для тиринга
Чтобы понять, какое устройство NVMe настроено для NVMe-тиринга, нужно перейти в раздел "Configure" -> "Storage" -> "Storage Devices", чтобы просмотреть список устройств. В столбце "Datastore" следует искать значение "Consumed for Memory Tiering", как показано на скриншоте ниже. Мы можем получить это поле, используя свойство "usedByMemoryTiering" при энумерации всех устройств хранения.
Вот небольшой фрагмент PowerCLI-кода для получения этого поля для конкретного хоста ESXi:
Отношение объёма DRAM к NVMe по умолчанию составляет 25% и настраивается с помощью следующего расширенного параметра ESXi под названием "Mem.TierNvmePct". Мы можем получить значение этого поля, используя либо vSphere API ("OptionManager"), либо через ESXCLI.
Вот небольшой фрагмент PowerCLI-кода для получения этого поля для конкретного хоста ESXi:
Вильям собрал все вышеперечисленные парметры и создал скрипт PowerCLI под названием "get-nvme-tiering-info.ps1", который предоставляет удобное резюме для всех хостов ESXi в рамках конкретного кластера Sphere (вы также можете изменить скрипт, чтобы он запрашивал конкретный хост ESXi). Это может быть полезно для быстрого получения информации о хостах, на которых NVMe-тиринг может быть настроен (или нет).
Начиная с обновления VMware vSphere 8.0 Update 2, поддержка опции "None - Stretched Cluster" в политике хранения (Storage Policy) для конфигурации vSAN Stretched Cluster была удалена. Причина этого заключается в том, что данная опция часто приводила к ситуациям, когда клиенты ошибочно ее использовали, и при сбое обнаруживали, что некоторые виртуальные машины перестали работать.
Причиной остановки работы виртуальных машин было то, что в соответствии с этой политикой все компоненты объекта размещались в одном месте, но не было гарантии, что все объекты одной виртуальной машины будут находиться на одном сайте. Таким образом, могла возникнуть ситуация, показанная ниже, когда виртуальная машина работает на сайте B, один из ее объектов данных хранится на сайте A, другой объект данных на сайте B, и, кроме того, свидетель также находится в сайте B. К сожалению, у некоторых клиентов это приводило к странному поведению, если возникали проблемы с сетью между Сайтами A и B.
Недавно вышла версия VMware Data Services Manager (DSM) v2.1.1 (о версии 2.1 мы рассказывали вот тут). В связи с этим релизом Кормак Хоган решил создать несколько коротких видеороликов, чтобы подчеркнуть некоторые улучшения, которые были внесены в продукт. Напомним, что VMware Data Services Manager (DSM) дает разработчикам средства самообслуживания, которые позволяют регулировать потребление ресурсов, обеспечить комплаенс и соответствие политикам резервного копирования компании, а также дает другие полезные инструменты.
В видео ниже демонстрируется, как начать работу с DSM v2.1.1. В нем показано, как загрузить продукт с портала поддержки, а также рассказывается об использовании плагинов клиента vSphere для развертывания DSM в вашей онпремизной инфраструктуре vSphere.
В ролике показано, как создать свою первую инфраструктурную политику для защиты ресурсов vSphere при развертывании баз данных и сервисов данных. Видео также рассказывает, как завершить настройку DSM, войдя в интерфейс и добавив объектное хранилище для резервного копирования и журналов виртуального модуля (Virtual appliance) провайдера, а также для резервных копий вашей базы данных. После завершения настроек вы будете готовы к включению и развертыванию БД.
Вильям Лам написал полезную статью о новой фиче вышедшего недавно обновления фреймворка для управления виртуальной инфраструктурой с помощью сценариев - VMware PowerCLI 13.3.
Параметры загрузки ядра (kernel boot options) в VMware ESXi можно добавить во время загрузки ESXi (нажав SHIFT+O) или обновив файл конфигурации boot.cfg, чтобы повлиять на определенные настройки и/или поведение системы.
Раньше было сложно получить полную картину по всем ESXi хостам, чтобы определить, на каких из них используются пользовательские параметры загрузки, особенно в тех случаях, когда они уже не нужны или, что хуже, если кто-то вручную добавил настройку, которую вы не планировали.
В vSphere 8.0 Update 3 добавлено новое свойство bootCommandLine в vSphere API, которое теперь предоставляет полную информацию обо всех параметрах загрузки, используемых для конкретного ESXi хоста.
На днях был выпущен релиз PowerCLI 13.3, который поддерживает последние API, представленные как в vSphere 8.0 Update 3, так и в VMware Cloud Foundation (VCF) 5.2. Вы можете легко получить доступ к этому новому свойству, выполнив следующую команду в сценарии:
Наверняка вы слышали о недавнем обновлении программного обеспечения CrowdStrike для Microsoft Windows, которое вызвало беспрецедентный глобальный сбой по всему миру (а может даже вы были непосредственно им затронуты). Несколько дней назад ИТ-администраторы работали круглосуточно, чтобы восстановить работоспособность тысяч, если не десятков тысяч систем Windows.
Текущий рекомендуемый процесс восстановления от CrowdStrike определенно болезненный, так как он требует от пользователей перехода в безопасный режим Windows для удаления проблемного файла. Большинство организаций используют Microsoft Bitlocker, что добавляет дополнительный шаг к уже и так болезненному ручному процессу восстановления, так как теперь необходимо найти ключи восстановления перед тем, как войти в систему и применить исправление.
Вильям Лам написал об этой ситуации. В течение нескольких часов после новостей от CrowdStrike он уже увидел ряд запросов от клиентов и сотрудников на предмет наличия автоматизированных решений или скриптов, которые могли бы помочь в их восстановлении, так как требование к любой организации вручную восстанавливать системы неприемлемо из-за масштабов развертываний в большинстве предприятий. Ознакомившись с шагами по восстановлению и размышляя о том, как платформа vSphere может помочь пользователям автоматизировать то, что обычно является ручной задачей, у него возникло несколько идей, которые могут быть полезны.
Скрипты, предоставленные в этой статье, являются примерами. Пожалуйста, тестируйте и адаптируйте их в соответствии с вашей собственной средой, так как они не были протестированы официально, и их поведение может варьироваться в зависимости от среды. Используйте их на свой страх и риск.
Платформа vSphere обладает одной полезной возможностью, которая до сих пор не всем известна, позволяющей пользователям автоматизировать отправку нажатий клавиш в виртуальную машину (VM), что не требует наличия VMware Tools или даже запущенной гостевой операционной системы.
Чтобы продемонстрировать, как может выглядеть автоматизированное решение для устранения проблемы CrowdStrike, Вильям создал прототип PowerCLI-скрипта под названием crowdstrike-example-prototype-remediation-script.ps1, который зависит от функции Set-VMKeystrokes. В настройке автора работает Windows Server 2019 с включенным Bitlocker, и он "смоделировал" директорию и конфигурационный файл CrowdStrike, которые должны быть удалены в рамках процесса восстановления. Вместо загрузки в безопасный режим, что немного сложнее, автор решил просто загрузиться в установщик Windows Server 2019 и перейти в режим восстановления, что позволило ему применить тот же процесс восстановления.
Ниже представлено видео, демонстрирующее автоматизацию и шаги, происходящие между PowerCLI-скриптом и тем, что происходит в консоли виртуальной машины. Вручную никакие действия не выполнялись:
В зависимости от вашей среды и масштаба, вам может потребоваться настроить различные значения задержек, и это следует делать в тестовой или разработческой среде перед развертыванием поэтапно.
В качестве альтернативы, автор также рекомендует и немного другой подход. Один из клиентов создал кастомный WindowsPE ISO, который содержал скрипт для удаления проблемного файла CrowdStrike, и всё, что им нужно было сделать, это смонтировать ISO, изменить порядок загрузки с жесткого диска на CDROM, после чего ISO автоматически выполнил бы процесс восстановления, вместо использования безопасного режима, что является довольно умным решением.
В любом случае, вот пример фрагмента PowerCLI-кода, который реконфигурирует виртуальную машину (поддерживается, когда ВМ выключена) для монтирования нужного ISO из хранилища vSphere и обновляет порядок загрузки так, чтобы машина автоматически загружалась с ISO, а не с жесткого диска.
$vmName = "CrowdStrike-VM"
$isoPath = "[nfs-datastore-synology] ISO/en_windows_server_version_1903_x64_dvd_58ddff4b.iso"
$primaryDisk = "Hard disk 1"
$vm = Get-VM $vmName
$vmDevices = $vm.ExtensionData.Config.Hardware.Device
$cdromDevice = $vmDevices | where {$_.getType().name -eq "VirtualCdrom"}
$bootDevice = $vmDevices | where {$_.getType().name -eq "VirtualDisk" -and $_.DeviceInfo.Label -eq $primaryDisk}
# Configure Boot Order to boot from ISO and then Hard Disk
$cdromBootDevice = New-Object VMware.Vim.VirtualMachineBootOptionsBootableCdromDevice
$diskBootDevice = New-Object VMware.Vim.VirtualMachineBootOptionsBootableDiskDevice
$diskBootDevice.DeviceKey = $bootDevice.key
$bootOptions = New-Object VMware.Vim.VirtualMachineBootOptions
$bootOptions.bootOrder = @($cdromBootDevice,$diskBootDevice)
# Mount ISO from vSphere Datastore
$cdromBacking = New-Object VMware.Vim.VirtualCdromIsoBackingInfo
$cdromBacking.FileName = $isoPath
$deviceChange = New-Object VMware.Vim.VirtualDeviceConfigSpec
$deviceChange.operation = "edit"
$deviceChange.device = $cdromDevice
$deviceChange.device.Backing = $cdromBacking
$deviceChange.device.Connectable.StartConnected = $true
$deviceChange.device.Connectable.Connected = $true
$spec = New-Object VMware.Vim.VirtualMachineConfigSpec
$spec.deviceChange = @($deviceChange)
$spec.bootOptions = $bootOptions
$task = $vm.ExtensionData.ReconfigVM_Task($spec)
$task1 = Get-Task -Id ("Task-$($task.value)")
$task1 | Wait-Task | Out-Null
Чтобы подтвердить, что изменения были успешно применены, вы можете использовать интерфейс vSphere или следующий фрагмент PowerCLI-кода:
Остается только запустить виртуальную машину, а затем, после завершения восстановления, можно отменить операцию, размонтировав ISO и удалив конфигурацию порядка загрузки, чтобы вернуть исходное поведение виртуальной машины.
После неудачного развертывания VCF 5.0 у автора блога vronin.nl остался vSAN Datastore на первом хосте в кластере, что блокировало повторную попытку развертывания.
В этом состоянии vSAN Datastore не может быть удален. Если попытаться его удалить через ESXi Host Client, опция будет неактивна:
Чтобы удалить хранилище данных vSAN и разделы дисков, сначала нужно подключиться по SSH к хосту и получить Sub-Cluster Master UUID кластера:
Далее копируем этот Sub-Cluster Master UUID в следующую команду:
В ESXi Host Client будет показываться, что датастора больше нет:
Для двойной проверки выполняем следующие команды в консоли ESXi:
esxcli vsan cluster list
esxcli vsan storage list
По результатам вывода команд, на хосте не настроены кластеры или хранилища vSAN. После этого повторная попытка развертывания кластера управления VCF будет успешной.
Автор сайта virten.net сделал интересную и полезную страницу, где вы можете отслеживать выход свежих релизов продуктов VMware, включая VMware vSphere / ESXi / vCenter, NSX, Aria и другие. Называется эта штука VMware Product Release Tracker (vTracker):
Ссылки, которые позволят вам это использовать в удобном формате:
Надо сказать, что информация тут обновляется только про финальные релизы, доступные на сайте Broadcom в режиме General Availability (GA), поэтому если вам нужны бета-версии различных решений - отслеживать их нужно отдельно.
Дункан Эппинг опубликовал интересный пост, касающийся изменений в интерфейсе vSAN Data Protection, произошедших в новой версии пакета обновлений VMware vSphere 8 Update 3.
Впервые развернув vSphere/vSAN 8.0 U3, он сразу же начал искать интерфейс vSAN Data Protection. Он не смог его найти, но подумал, что это из-за использования какой-то странной альфа-версии продукта. Теперь, когда продукт вышел, эта функция должна быть доступна из коробки, верно?
Нет, не так. Вам нужно развернуть виртуальный модуль (Virtual Appliance), чтобы эта функция появилась в интерфейсе. Этот модуль можно найти в разделе «Drivers and Tools» в разделе загрузок vSphere Hypervisor, который находится по основными ссылками на дистрибутивы vSphere. Он называется «VMware vSAN Snapshot Service Appliance». Текущая версия называется «snapservice_appliance-8.0.3.0-24057802_OVF10.ova». Вам нужно развернуть этот OVA, при это настоятельно рекомендуется запросить для него DNS-имя и правильно зарегистрировать его. Автор возился с файлом hosts на VCSA и забыл добавить имя в локальный файл hosts на своем ноутбуке, из-за чего возникли странные проблемы.
Еще одна вещь, на которую стоит обратить внимание: документация предлагает загрузить сертификаты и скопировать текст для модуля. Это не то, что большинство из нас делает ежедневно. Вы можете просто открыть веб-браузер и использовать следующий URL «https://<имя вашего сервера vCenter>/certs/download.zip», чтобы загрузить сертификаты, а затем распаковать загруженный файл. Более подробную информацию можно найти здесь.
Внутри будут сертификаты, и если вы откроете сертификат в подходящем текстовом редакторе, вы сможете скопировать/вставить его в экран развертывания для OVA.
Теперь, когда вы развернули OVA и все правильно настроено, вы должны увидеть успешное выполнение задачи, а точнее две: загрузка плагина и развертывание плагина, как показано на следующем скриншоте.
Если вы получите сообщение об ошибке «error downloading plug-in», вероятно, это связано с одной из двух причин:
Файлы DNS / Hosts настроены некорректно, в результате чего URL недоступен. Убедитесь, что вы можете разрешить URL.
Отпечаток (thumbprint) сертификата был неправильно скопирован/вставлен. Здесь есть целый раздел по устранению этой проблемы.
На прошлой неделе блогер Дункан Эппинг получил вопрос о vSAN Stretched Cluster, который заставил его задуматься. Человек, задавший этот вопрос, рассматривал несколько сценариев отказа, некоторые из которых Дункан уже рассматривал ранее. Вопрос, который ему задали, заключается в том, что должно произойти в следующем сценарии, показанном на диаграмме, когда разрывается связь между предпочтительным сайтом (Site A) и сайтом свидетеля (Witness):
Ответ, по крайней мере, он так думал, был прост: все виртуальные машины продолжат работать, или, иначе говоря, не будет никакого воздействия на работу vSAN. Во время теста, действительно, результат, который он зафиксировал, а также документированный в Stretched Clustering Guide и PoC Guide, был таким же: виртуальные машины продолжали работать. Однако, он обратил внимание, что когда эта ситуация происходит, и действительно связь между сайтом А и Witness теряется, свидетель почему-то больше не является частью кластера, что не то, что ожидалось. Причина, по которой он не ожидал этого, заключается в том, что если произойдет второй сбой, и, например, связь между сайтом А и сайтом B пропадет, это напрямую повлияет на все виртуальные машины. По крайней мере, так он думал.
Однако, когда был вызван этот второй сбой и отключена связь между сайтом А и сайтом В, Дункан увидел, что Witness снова появляется в кластере сразу же, а объекты свидетеля переходят из состояния «absent» в состояние «active», и, что более важно, все виртуальные машины продолжают работать. Причина, по которой это происходит, довольно проста: при запуске такой конфигурации у vSAN есть «leader» и «backup», и они каждый работают в отдельном домене отказа. И лидер, и резерв должны иметь возможность общаться с Witness для корректного функционирования. Если связь между сайтом А и Witness пропадает, то либо лидер, либо резерв больше не могут общаться со свидетелем, и свидетель исключается из кластера.
Так почему же свидетель возвращается к работе, когда вызывается второй сбой? Когда вызывается второй сбой, лидер перезапускается на сайте В (так как сайт А считается потерянным), а резерв уже работает на сайте В. Поскольку и лидер, и резерв снова могут общаться со свидетелем, свидетель возвращается к работе, и все компоненты кластера автоматически и мгновенно восстанавливаются. Это означает, что даже если связь между сайтом А и сайтом В прервана после того, как свидетель был исключен из кластера, все виртуальные машины остаются доступными, так как свидетель снова включается в работу кластера для обеспечения доступности рабочей нагрузки.
Известный блоггер Эрика Слуф опубликовал интересное видео, посвященное обеспечению высокой доступности и восстановлению после сбоя в кластере NSX-T Management Cluster.
В этом видео Эрик демонстрирует эти концепции в действии, рассматривая различные сценарии отказов и подробно обсуждая стратегии аварийного восстановления. Вы можете получить копию оригинального файла Excalidraw и презентационные слайды в форматах PDF и PowerPoint на GitHub.
Введение
Поддержание доступности кластера управления NSX-T критически важно для обеспечения стабильности и производительности вашей виртуализованной сетевой среды. Далее будут рассмотрены стратегии обеспечения высокой доступности (HA) управляющих компонентов NSX-T, а также описан процесс восстановления при сбоях и лучшие практики для аварийного восстановления.
Обзор кластера управления NSX-T
Кластер управления NSX-T обычно состоит из трех узлов. Такая конфигурация обеспечивает избыточность и отказоустойчивость. В случае отказа одного узла кластер сохраняет кворум, и нормальная работа продолжается. Однако отказ двух узлов может нарушить работу управления, требуя оперативных действий по восстановлению.
Высокая доступность в кластере управления NSX-T
1. Поддержание кворума
Для поддержания кворума кластер управления должен иметь как минимум два из трех узлов в рабочем состоянии. Это обеспечивает доступность интерфейса NSX Manager и связанных сервисов. Если один узел выходит из строя, оставшиеся два узла могут продолжать общение и управление средой, предотвращая простой.
2. Отказы узлов и их влияние
Отказ одного узла: кластер продолжает работать нормально с двумя узлами.
Отказ двух узлов: кластер теряет кворум, интерфейс NSX Manager становится недоступным. Управление через CLI и API также будет невозможно.
Стратегии восстановления
Когда большинство узлов выходит из строя, требуются оперативные действия для восстановления кластера до функционального состояния.
1. Развертывание нового управляющего узла
Разверните новый управляющий узел как четвертый член существующего кластера.
Используйте команду CLI detach node <node-uuid> или API-метод /api/v1/cluster/<node-uuid>?action=remove_node для удаления неисправного узла из кластера.
Эту команду следует выполнять с одного из здоровых узлов.
2. Деактивация кластера (по желанию)
Выполните команду deactivate cluster на активном узле для формирования кластера из одного узла.
Добавьте новые узлы для восстановления кластера до конфигурации из трех узлов.
Лучшие практики для аварийного восстановления
1. Регулярные резервные копии
Планируйте регулярные резервные копии конфигураций NSX Manager для быстрой восстановления.
Храните резервные копии в безопасном месте и обеспечьте их доступность в случае аварийного восстановления.
2. Географическая избыточность
Развертывайте NSX Manager на нескольких площадках для обеспечения географической избыточности.
В случае отказа одной площадки другая может взять на себя операции управления с минимальными перебоями.
Проактивный мониторинг
Используйте встроенные инструменты мониторинга NSX-T и интегрируйте их с решениями сторонних производителей для постоянного мониторинга состояния кластера управления.
Раннее обнаружение проблем может предотвратить серьезные сбои и уменьшить время простоя.
Площадка аварийного восстановления
Подготовьте площадку для аварийного восстановления с резервными NSX Manager, настроенными для восстановления из резервных копий.
Такая настройка позволяет быстро восстановить и обеспечить непрерывность работы в случае отказа основной площадки.
Заключение
Обеспечение высокой доступности и аварийного восстановления вашего кластера управления NSX-T необходимо для поддержания надежной и устойчивой виртуальной сетевой среды. Следуя лучшим практикам управления узлами, развертывания географически избыточной конфигурации и регулярного создания резервных копий, вы можете минимизировать время простоя и обеспечить быстрое восстановление после сбоев.
Для более детального изучения технических деталей ознакомьтесь с следующими ресурсами:
Недавно Дункан Эппинг выступал с докладом на конференции VMUG в Бельгии, где была тема «Инновации в VMware от Broadcom». В ходе доклада он кратко изложил процесс и различные типы инноваций, а также то, к чему это может привести. Во время сессии он рассмотрел три проекта, а именно vSAN ESA, Distributed Services Engine и проект, над которым сейчас работают, под названием Memory Tiering.
Memory Tiering — это очень интересная концепция, которая впервые была публично представлена на конференции VMware Explore несколько лет назад как потенциальная будущая фича гипервизора. Вы можете задаться вопросом, зачем кому-то захочется ранжировать память, ведь влияние этого процесса на производительность может быть значительным. Существует несколько причин для этого, одна из которых — стоимость памяти. Еще одна проблема, с которой сталкивается индустрия, заключается в том, что емкость (и производительность) памяти не росли такими же темпами, как емкость CPU, что привело к тому, что во многих средах память стала узким местом. Иными словами, дисбаланс между процессором и памятью значительно увеличился. Именно поэтому VMware запустила проект Capitola.
Когда обсуждался проект Capitola, большинство внимания было уделено Intel Optane, и большинство интересующихся знает, что с этим случилось. Некоторые думали, что это также приведет к закрытию проекта Capitola, а также технологий ранжирования и объединения памяти. Но это совершенно не так: VMware продолжает активно работать над проектом и публично обсуждает прогресс, хотя нужно знать, где искать эту информацию. Если вы посмотрите эту сессию, станет ясно, что существует множество усилий, которые позволят клиентам ранжировать память различными способами, одним из которых, конечно, являются различные решения на базе CXL, которые скоро появятся на рынке.
Один из способов — это Memory Tiering с помощью карты ускорителя CXL, по сути, это FPGA, предназначенная исключительно для увеличения емкости памяти, аппаратной разгрузки техник ранжирования памяти и ускорения определенных функций, где память имеет ключевое значение, таких как, например, vMotion. Как упоминалось в сессии SNIA, использование карты ускорителя может привести к сокращению времени миграции на 30%. Такая карта ускорителя также открывает другие возможности, например, memory pooling, чего клиенты просили с тех пор, как в VMware создали концепцию кластера.
Также это открывает возможности совместного использования вычислительных ресурсов между хостами. Только представьте, ваша виртуальная машина может использовать емкость памяти, доступную на другом хосте, без необходимости перемещать саму виртуальную машину. Понятное дело, что это может оказать значительное влияние на производительность.
Именно здесь вступают в игру технологии VMware. На VMworld в 2021 году, когда был представлен проект Capitola, команда VMware также поделилась результатами последних тестов производительности, и было показано, что снижение производительности составило около 10% при использовании 50% оперативной памяти (DRAM) и 50% памяти Optane. Эта демонстрация показывает истинную мощь VMware vSphere, а также техник ранжирования памяти и ускорения (проект Peaberry).
В среднем снижение производительности составило около 10%, при этом примерно 40% виртуальной памяти было доступно через ускоритель Peaberry. Обратите внимание, что tiering полностью прозрачен для приложения, поэтому это работает для всех типов рабочих нагрузок. Важно понимать, что поскольку гипервизор уже отвечает за управление памятью, он знает, какие страницы являются "горячими", а какие "холодными", а это значит, что он может определить, какие страницы можно переместить на другой уровень, сохраняя при этом производительность.
В общем, ждем больше интересной информации от VMware на эту тему!
Вильям Лам написал интересную статью о том, как можно редактировать настройки SMBIOS для вложенного/виртуального (Nested) VMware ESXi в части hardware manufacturer и vendor.
Nested ESXi продолжает оставаться полезным ресурсом, который часто используется администраторами: от прототипирования решений, воспроизведения проблем клиентов до автоматизированных развертываний лабораторий, поддерживающих как VMware Cloud Foundation (VCF), так и VMware vSphere Foundation (VVF).
Хотя с помощью Nested ESXi можно сделать почти все, но имитировать или симулировать конкретные аппаратные свойства, такие как производитель или поставщик (hardware manufacturer и vendor), не совсем возможно или, по крайней мере, очень сложно. Коллега Вильяма Люк Хакаба нашел хитрый трюк, играя с настройками загрузочных ROM виртуальной машины по умолчанию, которые поставляются с ESXi и VMware Desktop Hypervisors (платформы Workstation/Fusion).
Виртуальная машина vSphere может загружаться, используя либо BIOS, либо EFI прошивку, поэтому в зависимости от желаемого типа прошивки вам нужно будет изменить либо файл BIOS.440.ROM, либо EFI64.ROM. Эти файлы ROM можно найти в следующих каталогах для соответствующих гипервизоров VMware:
Примечание: не редактируйте файлы ROM по умолчанию, которые поставляются с гипервизором VMware, сделайте их копию и используйте измененную версию, которую могут использовать виртуальные машины в VMware vSphere, Fusion или Workstation. Кроме того, хотя эта статья посвящена виртуальной машине Nested ESXi, это также должно работать и на других гостевых операционных системах для отображения информации SMBIOS.
Редактирование BIOS
Шаг 1 - Скачайте и установите Phoenix BIOS Editor. Установщик Phoenix BIOS Editor имеет проблемы при запуске на системе Windows Server 2019, и единственным способом завершить установку - это изменить совместимость приложения на Windows 8, что позволит успешно завершить установку.
Шаг 2 - Скачайте и откройте файл BIOS.440.ROM с помощью Phoenix BIOS Editor, затем перейдите на панель DMI Strings для изменения нужных полей.
Когда вы закончите вносить все изменения, перейдите в меню "Файл" и нажмите "Собрать BIOS" (Build BIOS), чтобы создать новый файл ROM. В данном примере это файл BIOS.440.CUSTOM.ROM.
Шаг 3 - Скопируйте новый файл ROM в хранилище вашего физического хоста ESXi. Вы можете сохранить его в общей папке, чтобы использовать с несколькими виртуальными машинами Nested ESXi, ИЛИ вы можете сохранить его непосредственно в папке отдельной виртуальной машины Nested ESXi. Второй вариант позволит вам повторно использовать один и тот же кастомный файл ROM в нескольких виртуальных машинах, поэтому, с точки зрения тестирования, возможно, вам захочется создать несколько файлов ROM в зависимости от ваших нужд и просто перенастроить виртуальную машину для использования нужного файла ROM.
Шаг 4 - Чтобы кастомный файл ROM мог быть использован нашей виртуальной машиной Nested ESXi, нам нужно добавить следующую дополнительную настройку (Advanced Setting) виртуальной машины, которая указывает путь к нашему кастомному файлу ROM:
bios440.filename = "BIOS.440.CUSTOM.ROM"
Шаг 5 - Наконец, мы можем включить нашу виртуальную машину Nested ESXi, и теперь мы должны увидеть кастомную информацию SMBIOS, как показано на скриншоте ниже.
Редактирование EFI
Шаг 1 - Скачайте и установите HEX-редактор, который может редактировать файл EFI ROM. Например, ImHex - довольно удобный с точки зрения редактирования, но поиск определенных строк с помощью этого инструмента является нетривиальной задачей.
Шаг 2 - Скачайте и откройте файл EFI64.ROM с помощью редактора ImHex и найдите строку "VMware7,1". Как только вы найдете расположение этой строки, вам нужно аккуратно отредактировать значения hex, чтобы получить желаемые ASCII строки.
Кроме того, вы можете использовать UEFITool (версия 28 позволяет модифицировать ROM), который имеет гораздо более удобный и функциональный поиск, а также позволяет извлекать часть файла ROM для редактирования с помощью HEX-редактора. В этой утилите можно использовать поиск (CTRL+F), и как только он находит нужный раздел, двойным щелчком по результату переходите к точному месту в файле ROM. Чтобы извлечь раздел для редактирования, щелкните правой кнопкой мыши и выберите "Extract as is" и сохраните файл на рабочий стол.
Затем вы можете открыть конкретный раздел с помощью ImHex, чтобы внести свои изменения.
После того как вы сохранили свои изменения, не теряйте указатель в UEFITool. Теперь мы просто заменим раздел нашим измененным файлом, щелкнув правой кнопкой мыши и выбрав "Replace as is", указав измененный раздел. Вы можете подтвердить, что изменения были успешными, просто найдя строку, которую вы заменили. Затем перейдите в меню "Файл" и выберите "Сохранить образ файла" (Save image file), чтобы создать новый файл ROM. В данном случае - это файл EFI64.CUSTOM.ROM.
Шаг 3 - Скопируйте новый файл ROM в хранилище вашего физического хоста ESXi. Вы можете сохранить его в общей папке, чтобы использовать с несколькими виртуальными машинами Nested ESXi, ИЛИ вы можете сохранить его непосредственно в папке отдельной виртуальной машины Nested ESXi.
Шаг 4 - Чтобы наш кастомный файл ROM мог быть использован виртуальной машиной Nested ESXi, нам нужно добавить следующую дополнительную настройку ВМ в файл vmx, которая указывает путь к нашему кастомному файлу ROM:
efi64.filename = "EFI64.CUSTOM.ROM"
Шаг 5 - Наконец, мы можем включить виртуальную машину Nested ESXi, и теперь мы должны увидеть кастомную информацию SMBIOS.
Как видно на скриншоте, Вильяму удалось изменить только модель оборудования, но не значение вендора.
Примечание: хотя автору и удалось найти строку "VMware, Inc." для вендора, изменение значения не оказало никакого эффекта, как показано на скриншоте выше, что, вероятно, указывает на то, что эта информация может храниться в другом месте или содержаться в каком-то встроенном файле.
Оказывается у сетевого адаптера виртуальной машины vmnic есть свойство, определяющее, будет ли он автоматически присоединяться к виртуальной машине при ее запуске. Свойство это называется StartConnected, оно может быть не установлено по каким-то причинам, что может привести к проблемам.
Как написал Farnky, проверить это свойство у всех виртуальных машин в окружении vCenter можно следующей командой:
6 мая 2024 года завершился переходный этап "Day-2", в ходе которого бэкенд-система VMware была полностью смигрирована на бэкенд-систему Broadcom. На эту тему почитайте наш пост о переезде сообществ VMware в Broadcom Community (а также о переезде Flings из раздела VMware Labs).
Однако может потребоваться еще несколько недель, чтобы все новые сервисы полностью стабилизировались после такого масштабного проекта переезда. Также запланированы некоторые обновления после миграции для некоторых веб-ресурсов, так что к концу месяца можно ожидать дополнительных обновлений.
В связи с изменениями в большом количестве веб-сайтов VMware, включая прекращение поддержки некоторых из них или полное сохранение без изменений, Вильям Лам собрал различные ссылки, которые могут быть полезны для клиентов, партнеров и сотрудников VMware. Вильям продолжит обновлять эту страницу по мере поступления новой или обновленной информации, поэтому не забудьте добавить ее в закладки, чтобы быть в курсе последних новостей.
Примечание: для некоторых загрузок потребуются права доступа к контенту (например, вы участвуете в бета-программе), в то время как для других будет достаточно учетной записи. Вы можете проверить это позже на этой неделе, так как не все загрузки могут быть доступны сразу.
Интересный пост от John Nicholson о размещении сервера VMware vCenter в растянутом кластере vSAN Stretched Cluster. В идеальном мире у вас есть управляющий кластер, который содержит ваш сервер vCenter, а вы управляете каждым кластером из него. Но, к сожалению, в реальном мире всё сложнее:
Необходимо тоже как-то управлять управляющим кластером.
Иногда нужно, чтобы кластер был полностью автономным.
Можно ли запустить сервер vCenter на управляемом им кластере?
Надо сказать, что всегда полностью поддерживался запуск сервера vCenter на управляемом им кластере. Высокая доступность (HA) в этом случае всё равно будет работать. Если вам нужно более подробно изучить этот вопрос, этот короткий видеоролик ответит на ваш вопрос.
Итак, какой лучший совет при размещении vCenter?
Используйте ephemeral port groups для всех управляющих сетей. Это предотвратит проблемы chicken-egg с виртуальными распределенными коммутаторами (vDS), которые раздражают, но с которыми можно справиться.
Автор предпочитает использовать правила DRS типа "SHOULD", чтобы vCenter "как правило" находился на узле с наименьшим номером или IP-адресом в кластере. Это полезно в ситуации, когда vCenter работает с ошибками и службы управления не запускаются, так как это упрощает поиск узла, на котором он работает. Обязательно избегайте использования правил "MUST" для этого, так как это не позволит vCenter запуститься в другом месте в случае сбоя данного узла.
А как насчет распределенного кластера? Например, у вас есть отдельный хост для запуска сервера Witness, стоит ли размещать его там?
Вот такое делать не рекомендуется. Всегда предпочтительнее запускать сервер vCenter там, где он будет защищен с помощью высокой доступности (HA), и ему не потребуется выключение для обновления хоста. Растянутые кластеры vSAN всегда поддерживают операции active/active, и многие клиенты часто настраивают их так, чтобы большинство рабочих нагрузок выполнялись в предпочтительном датацентре (preferred site). Если вы используете эту конфигурацию, рекомендуется запускать сервер vCenter во вторичном (secondary) местоположении по нескольким причинам:
В случае сбоя основного сайта, вы не останетесь «операционно слепым», поскольку HA со стороны vCenter будет активирована и восстановит рабочие нагрузки. Это снизит любые операционные простои, которые могли бы произойти в течение нескольких минут, пока сервер vCenter запустится на резервном узле основного сайта.
Он будет действовать как указатель на состояние здоровья вторичного датацентра. В целом полезно иметь какую-то рабочую нагрузку на вторичном сайте, чтобы понимать, как будут работать эти хосты, даже если это будет относительно легкая нагрузка.
Блоггер Yahya Zahedi планирует написать интересную серию постов об утилитах для траблшутинга кластеров VMware vSAN. Сейчас самыми полезными для этих целей являются следующие средства:
vSAN Skyline Health
vSAN Cluster Level Monitoring
vSAN Host Monitoring
vSAN VM Monitoring
В этом посте мы приведем его рассказ о самом функциональном продукте - vSAN Skyline Health.
Skyline Health — это средство самостоятельной диагностики, предназначенное для обнаружения и устранения проблем в средах vSphere и vSAN. Важно отметить, что хотя эта утилита часто ассоциируется с vSAN, она также доступна и для vSphere. Таким образом, она не является эксклюзивной для vSAN, ее можно и нужно использовать для vSphere.
Сегодня мы посмотрим, как использовать Skyline Health для vSAN. Вы можете получить доступ к этому средству, перейдя к кластеру vSAN, затем выбрав вкладку "Monitor" и выбрав Skyline Health в разделе vSAN. Здесь, в разделе "Overview", вы найдете две карточки: "Cluster Health Score", которая работает на основе недавних файндингов по здоровью, и "Health Score Trend", которая показывает тренд оценки здоровья за последние 24 часа. Этот тренд можно настроить, указав конкретный временной промежуток.
В разделе файндингов по здоровью есть четыре категории: Unhealthy, Healthy, Info, Silenced, которые вы можете использовать для диагностики проблем, устранения неполадок и траблшутинга. Давайте начнем с первой категории файндингов.
Находки категории Unhealthy относятся к важным проблемам, которые требуют внимания. Например, в данном случае используется не сертифицированное VMware устройство хранения данных, и если вы посмотрите на зону воздействия этой проблемы, в описании вы увидите Compliance, что означает, что устройства хранения не соответствуют списку совместимости оборудования VMware HCL.
Как вы можете видеть, есть три опции:
Silence Alert - заглушает предупреждение и перемещает карточку в категорию Silenced.
Troubleshoot - показывает новую карточку с инструкциями по решению проблемы.
View History Details - отображает историю проблемы.
Нажмем на View History Details:
Будет показана новая карточка, предоставляющая историческую информацию об этой конкретной проблеме. Вы сможете увидеть, сколько раз она произошла и в какие дни.
Если вы нажмете на "Troubleshoot", появится новая карточка, предоставляющая информацию о проблеме и основной причине для облегчения ее решения. В разделе "Why is the issue occurring?" вы найдете детали о причинах. В разделе "How to troubleshoot and fix" вы узнаете дополнительные сведения, в данном случае - какие устройства испытывают проблемы совместимости оборудования, а также рекомендуемые действия для эффективного решения.
Вторая категория — Healthy, которая относится к файндингам без каких-либо проблем, следовательно, не требующим дополнительного внимания. Все функционирует гладко, что указывает зеленый статус. Наша основная цель — обеспечить, чтобы все файндинги попадали в эту категорию, оставляя другие категории пустыми.
Третья категория — Info, она относится к находкам, которые могут не влиять напрямую на состояние vSAN, но важны для повышения общего здоровья и эффективности кластера vSAN. Эта категория включает в себя некоторые передовые методы и рекомендации, направленные на оптимизацию производительности и стабильности кластера vSAN.
Четвертая категория — Silenced. Если вы заглушите любые файндинги из других категорий, они появятся здесь. Если у вас есть проблемы, которые вы активно решаете в течение длительного времени, или по какой-либо другой причине предпочитаете не отображать их в категории Unhealthy или других категориях, вы можете нажать на Silence Alert, чтобы переместить их в эту категорию.
В следующем посте автор рассмотрит утилиту vSAN Cluster Monitoring.
Многие администраторы часто добавляют новые хосты ESXi, но довольно редко обсуждается вопрос о том, как правильно выводить из эксплуатации хост VMware ESXi. Об этом интересную статью написал Stephen Wagner.
Многих может удивить, что нельзя просто выключить хост ESXi и удалить его из окружения сервера vCenter, так как необходимо выполнить ряд шагов заранее, чтобы обеспечить успешный вывод из эксплуатации (decomission). Правильное списание хоста ESXi предотвращает появление изолированных объектов в базе данных vCenter, которые иногда могут вызывать проблемы в будущем.
Итак, процесс: как списать хост ESXi
Предполагается, что вы уже перенесли все ваши виртуальные машины, шаблоны и файлы с хоста, и он не содержит данных, которые требуют резервного копирования или миграции. Если вы этого не сделали - проверьте все еще раз, на хосте могут оказаться, например, кастомные скрипты, которые вы не сохраняли в другом месте.
Вкратце процесс выглядит так:
Перевод ESXi в режим обслуживания (Maintenance Mode)
Удаление хоста из распределенного коммутатора vSphere Distributed Switch (vDS)
Отключение и размонтирование томов iSCSI LUN
Перемещение хоста из кластера в датацентр как отдельного хоста
Удаление хоста из инвентаря (Inventory)
Выполнение расширенных процедур
Вход в режим обслуживания
Мы переходим в режим обслуживания, чтобы убедиться, что на хосте не запущены виртуальные машины. Вы можете просто щелкнуть правой кнопкой мыши по хосту и войти в режим обслуживания (Enter Maintenance Mode):
Если хост ESXi входит в состав кластера VMware vSAN, то вам будут предложены опции того, что нужно сделать с данными на нем хранящимися:
Удаление хоста из окружения vSphere Distributed Switch (vDS)
Необходимо аккуратно удалить хост из любых распределенных коммутаторов vDS (VMware Distributed Switches) перед удалением хоста из сервера vCenter.
Вы можете создать стандартный vSwitch и мигрировать адаптеры vmk (VMware Kernel) с vDS на обычный vSwitch, чтобы поддерживать связь с сервером vCenter и другими сетями.
Обратите внимание, что если вы используете коммутаторы vDS для подключений iSCSI, необходимо заранее разработать план по этому поводу, либо размонтировать/отключить iSCSI LUN на vDS перед удалением хоста, либо аккуратно мигрировать адаптеры vmk на стандартный vSwitch, используя MPIO для предотвращения потери связи во время выполнения процесса.
Размонтирование и отключение iSCSI LUN
Теперь вы можете приступить к размонтированию и отключению iSCSI LUN с выбранного хоста ESXi:
Размонтируйте тома iSCSI LUN с хоста
Отключите эти iSCSI LUN
Нужно размонтировать LUN только на выводимом из эксплуатации хосте, а затем отключить LUN также только на списываемом хосте.
Перемещение хоста из кластера в датацентр как отдельного хоста
Хотя это может быть необязательным, это полезно, чтобы позволить службам кластера vSphere (HA/DRS) адаптироваться к удалению хоста, а также обработать реконфигурацию агента HA на хосте ESXi. Для этого вы можете просто переместить хост из кластера на уровень родительского дата-центра.
Удаление хоста из инвентаря
После перемещения хоста и прошествия некоторого времени, вы теперь можете приступить к его удалению из Inventory. Пока хост включен и все еще подключен к vCenter, щелкните правой кнопкой мыши по хосту и выберите «Remove from Inventory». Это позволит аккуратно удалить объекты из vCenter, а также удалить агент HA с хоста ESXi.
Повторное использование хоста
Начиная с этого момента, вы можете войти напрямую на хост ESXi с помощью локального пароля root и выключить хост. Сделать этого можно также с помощью обновленного VMware Host Client.
Некоторые пользователи, применяющие архитектуру VMware HCI Mesh для подключения емкостей удаленных кластеров в архитектуру VMware vSAN Express Storage Architecture (ESA) спрашивают - а можно ли таким образом подключить и емкости кластеров OSA (Original Storage Architecture)?
Напомним, что технология HCI Mesh появилась в VMware vSphere 7 Update 1, она позволяет смонтировать датасторы удаленного кластера vSAN (который выступает в роли "сервера" для кластеров-клиентов).
Мы уже касались этого вопроса здесь и указали на то, что это на данный момент не поддерживается. Дункан Эппинг вот тут рассказал о том, что это не только не сейчас поддерживается, но и невозможно.
Делов в том, что vSAN HCI Mesh (она же технология Datastore Sharing) использует проприетарный протокол vSAN, который называется Reliable Datagram Transport (RDT). При использовании vSAN OSA применяется другая версия протокола RDT, чем та, что используется в vSAN ESA, и в данный момент эти протоколы несовместимы. В итоге, нельзя использовать vSAN Datastore Sharing для предоставления емкости кластеров OSA в ESA или наоборот.
В будущем планируется исправить эту ситуацию, но в данный момент обходного пути нет.
Дункан Эппинг опубликовал интересный пост о том, как предотвратить исполнение виртуальных машин vCLS на VMware vSphere HA Failover Host. Напомним, что vSphere Clustering Service (vCLS) - это служба, которая позволяет организовать мониторинг доступности хостов кластера vSphere, без необходимости зависеть от служб vCenter. Она реализуется тремя агентскими виртуальными машинами в кластере, где 3 или более хостов, и двумя, если в кластере два хоста ESXi. Три машины нужны, чтобы обеспечивать кворум (2 против 1) в случае принятия решения о разделении кластера.
Для тех, кто не знает, сервер vSphere HA Failover Host — это хост, который используется, когда происходит сбой и vSphere HA должен перезапустить виртуальные машины. В некоторых случаях клиенты (обычно партнеры в облачных решениях) хотят предотвратить использование этих хостов для любых рабочих нагрузок, поскольку это может повлиять на стоимость использования платформы.
К сожалению, в пользовательском интерфейсе вы не можете указать, что машины vCLS не могут работать на определенных хостах, вы можете ограничить работу ВМ vCLS рядом с другими виртуальными машинами, но не хостами. Однако есть возможность указать, на каких хранилищах данных могут находиться виртуальные машины, и это может быть потенциальным способом ограничения хостов, на которых могут работать эти ВМ. Как?
Если вы создадите хранилище данных, которое недоступно назначенному Failover-хосту vSphere HA, то машины vCLS не смогут работать на этом хосте, так как хост не сможет получить доступ к датастору. Это обходной путь для решения проблемы, вы можете узнать больше о механизме размещения хранилищ данных для vCLS в этом документе. Обратите внимание, что если остальная часть кластера выйдет из строя и останется только Failover-хост, виртуальные машины vCLS не будут включены. Это означает, что механизм балансировки нагрузки VMware DRS также не будет функционировать, пока эти ВМ недоступны.
Таги: VMware, vSphere, HA, vCLS, VMachines, DRS, Blogs
Не секрет, что решение ChatGPT прочно вошло в ежедневный набор инструментов ИТ-специалистов, особенно разработчиков ПО. Администраторы VMware vSphere - не исключение, ведь им часто приходится разрабатывать сценарии на базе различных фреймворков и SDK, что часто включает в себя шаблонные задачи, которые вполне можно автоматизировать средствами ChatGPT.
Эрик Слуф недавно занялся этим вопросом. Начал он со следующего промта:
Could you develop a Python script for VMware vCenter to retrieve the virtual machines and allow the user to control their power states? The server details are: host name 'vc.ntpro.local', username 'administrator@ntpro.local', password 'VMware1!' Please ignore certificate errors and use tls.
Ответ ChatGPT оказался продуктивным, с рекомендацией использовать библиотеку pyvmomi для взаимодействия с VMware vCenter. Он дал совет установить библиотеку pyvmomi через pip, если это еще не сделано. Полный код на Python можно найти по этой ссылке.
Для управления проектами на Python можно использовать PyCharm Community Edition. Модуль pyvmomi важен для подобных задач и может быть удобно установлен через терминал с помощью команды pip install pyvmomi. PyCharm также предлагает графический интерфейс для работы с пакетами Python.
После создания нового файла Python вставьте скрипт, предоставленный ChatGPT, в редактор PyCharm. Для выполнения могут потребоваться некоторые корректировки, такие как обновление версий TLS. Если возникнут ошибки, ChatGPT можно использовать для устранения неполадок и поиска новых решений. Как только усовершенствованный скрипт будет реализован, он сможет успешно извлекать и управлять состояниями питания виртуальных машин из vCenter.
На следующем этапе Эрик попросил ChatGPT интегрировать базовый графический интерфейс в скрипт, используя предустановленный модуль TKInter из Python3. Полученный интерфейс отображает список виртуальных машин с функциональными элементами управления питанием. Несмотря на небольшую проблему с "задачей ожидания" во время демонстрации, основная функциональность осталась неизменной.
Помните, что повторные запросы не обязательно приведут к одинаковым результатам при запросе кода у ChatGPT. Точность ваших вопросов повышает способность ChatGPT генерировать эффективный код. Если в вашем сценарии возникают проблемы, ChatGPT может помочь в отладке и даже подробно объяснить принципы работы скрипта.
Есть несколько потенциальных комбинаций растянутого кластера и перечисленных возможностей, на момент релиза VMware vSAN 8.0 Update 2 поддержка возможностей выглядит следующим образом:
Датастор vSAN Stretched Cluster, расшаренный с vSAN Cluster (не stretched) –>Поддерживается
Датастор vSAN Stretched Cluster, расшаренный с Compute Only Cluster (не stretched) –>Поддерживается
Датастор vSAN Stretched Cluster, расшаренный с Compute Only Cluster (stretched, symmetric) –>Поддерживается
Датастор vSAN Stretched Cluster, расшаренный с Compute Only Cluster (stretched, asymmetric) –> Не поддерживается
В чем разница между симметричным и асимметричным растянутым кластером? На следующем изображении, взятом из конфигурации vSAN Stretched Cluster, это лучше всего объяснено:
Если вы используете растянутый кластер vSAN и растянутый Compute Only, то обычно используется Asymmetric-конфигурация, поэтому шаринг датасторов в этом случае не поддерживается.
Florian Grehl на сайте virten.net опубликовал полезную статью о том, как включить аутентификацию Active Directory / LDAP / LDAPS в инфраструктуре VMware vSphere 8. Приводим ниже ее перевод.
Эта статья описывает, как интегрировать VMware vCenter Server в вашу инфраструктуру аутентификации. Источниками идентификации могут быть развертывания Microsoft Active Directory или протокола OpenLDAP.
В комплекте с управляющим сервером vCenter Server идет внутренняя база данных пользователей, которая позволяет добавлять и управлять пользователями из пользовательского интерфейса. Управление пользователями и единый вход предоставляются встроенным компонентом Platform Service Controller. В большой среде вы, возможно, захотите подключить вашу инфраструктуру виртуализации к централизованно управляемому провайдеру идентификации.
Обратите внимание, что VMware объявила о прекращении поддержки Integrated Windows Authentication (IWA). IWA был методом аутентификации, при котором вы присоединяли vCenter Server к вашему домену Active Directory. Несмотря на то, что Active Directory все еще поддерживается для аутентификации, рекомендуется использовать AD через LDAP или идентификацию с помощью ADFS. Для дополнительной информации см. KB78506.
1. Получение сертификата LDAPS
В связи с рисками безопасности, LDAPS заменяет LDAP как новый протокол каталога. Настоятельно рекомендуется использовать LDAPS, который использует SSL для установления безопасного соединения между клиентом и сервером перед обменом любыми данными. В настоящее время в пользовательском интерфейсе vCenter нет функции получения сертификата, поэтому сертификат нужно загрузить самостоятельно.
Подключитесь к vCenter Server Appliance (или любой системе с установленным OpenSSL CLI) с помощью SSH и войдите как root. Выполните следующую команду, чтобы показать сертификат LDAP:
Эта команда отображает цепочку сертификатов и информацию о сессии SSL. Вы можете использовать либо сертификат CA, либо сертификат сервера. Использование сертификата CA имеет преимущество в том, что вам не нужно перенастраивать провайдер идентификации, когда сертификат LDAPS заменяется.
Копируем содержимое между строчками -----BEGIN CERTIFICATE----- и -----END CERTIFICATE----- в текстовый файл.
После этого сохраните полученный файл с расширением .crt.
2. Добавление провайдера идентификации
Откройте vSphere Client.
Войдите как Single Sign-On Administrator.
Перейдите к Administration > Single Sign On > Configuration.
На вкладке провайдера идентификации откройте Identity Sources.
Нажмите ADD.
Измените Identity Source Type на Active Directory over LDAP.
Заполните остальные поля следующим образом:
Identity source name: Метка для идентификации (нужно указать имя домена)
Base distinguished name for users: Уникальное имя Distinguished Name (DN) начальной точки для поиска на сервере каталогов. Пример: Если ваше имя домена - virten.lab, то DN для всего каталога - "DC=virten,DC=lab".
Base distinguished name for groups: Уникальное имя (DN) начальной точки для поиска на сервере каталогов.
Domain name: Ваше имя домена. Пример: "virten.lab".
Domain alias: Ваше имя NetBIOS. Пример: "virten".
Username: Пользователь домена как минимум с правами просмотра.
Если вы получаете ошибку "Invalid DN syntax.", попробуйте ввести пользователя в формате DN: "uid=administrator,cn=users,dc=virten,dc=lab".
Password: Пароль пользователя домена.
Connect to: Выберите "Connect to any domain controller in the domain", если вы хотите использовать DNS для идентификации контроллеров домена или настроить статические основные и вторичные URL. При использовании статических записей вы можете либо запрашивать локальный каталог (порт 636), либо глобальный каталог (порт 3269). (Для устаревших незащищенных подключений используйте 389/3268). Пример: "ldap://dc.virten.lab:636".
Нажмите "Browse" рядом с сертификатом (для LDAPS).
Выберите файл .crt, полученный ранее от сервера LDAP.
Нажмите "ADD" и завершите мастер настройки.
В источниках идентификации ваш LDAP должен появиться в списке, и с этого момента вы можете назначать разрешения vCenter пользователям и группам из вашего каталога Active Directory.
Выберите ваш AD и нажмите кнопку "SET AS DEFAULT", чтобы сделать его доменом по умолчанию для аутентификации в вашем vCenter, что означает, что каждый, кто не указывает имя домена для входа, автоматически аутентифицируется в этом домене.
Для входа с пользователями AD вам нужно установить разрешения. Чтобы добавить пользователя/группу AD в качестве глобального администратора, перейдите к Administration > Access Control > Global Permissions.
Нажмите "ADD".
Выберите домен и начните вводить в поле поиска User/Group, чтобы выбрать Domain entity.
Нажмите "OK".
Теперь вы должны иметь возможность входить с помощью учетной записи Active Directory. Чтобы решать проблемы, связанные с аутентификацией, проверьте файлы журнала на vCenter Server Appliance в папке /var/log/vmware/sso.
Дункан Эппинг опубликовал интересную статью, касающуюся проблем, возникающих в растянутом кластере VMware vSAN при различных сценариях отказов в нем.
В некоторых из приведенных ниже сценариев Дункан обсуждает сценарии разделения кластера. Под разделением подразумевается ситуация, когда и L3-соединение с компонентом Witness, и ISL-соединение с другим сайтом недоступны для одного из сайтов. Так, на примере приведенной выше диаграммы, если говорится, что сайт B изолирован - это означает, что сайт A все еще может общаться со свидетелем, но сайт B не может общаться ни со свидетелем, ни с сайтом A.
Во всех следующих сценариях действуют следующие условия: сайт A является предпочтительным местоположением, а сайт B - второстепенным. Что касается таблицы ниже, то первые два столбца относятся к настройке политики для виртуальной машины, как показано на скриншоте:
Третий столбец относится к местоположению, откуда виртуальная машина работает с точки зрения вычислительных ресурсов (хоста ESXi). Четвертый описывает тип сбоя, а пятый и шестой столбцы детализируют наблюдаемое в этом случае поведение.
Site Disaster Tolerance
Failures to Tolerate
VM Location
Failure
vSAN behavior
HA behavior
None Preferred
No data redundancy
Site A or B
Host failure Site A
Objects are inaccessible if failed host contained one or more components of objects
VM cannot be restarted as object is inaccessible
None Preferred
RAID-1/5/6
Site A or B
Host failure Site A
Objects are accessible as there's site local resiliency
VM does not need to be restarted, unless VM was running on failed host
None Preferred
No data redundancy / RAID-1/5/6
Site A
Full failure Site A
Objects are inaccessible as full site failed
VM cannot be restarted in Site B, as all objects reside in Site A
None Preferred
No data redundancy / RAID-1/5/6
Site B
Full failure Site B
Objects are accessible, as only Site A contains objects
VM can be restarted in Site A, as that is where all objects reside
None Preferred
No data redundancy / RAID-1/5/6
Site A
Partition Site A
Objects are accessible as all objects reside in Site A
VM does not need to be restarted
None Preferred
No data redundancy / RAID-1/5/6
Site B
Partition Site B
Objects are accessible in Site A, objects are not accessible in Site B as network is down
VM is restarted in Site A, and killed by vSAN in Site B
None Secondary
No data redundancy / RAID-1/5/6
Site B
Partition Site B
Objects are accessible in Site B
VM resides in Site B, does not need to be restarted
None Preferred
No data redundancy / RAID-1/5/6
Site A
Witness Host Failure
No impact, witness host is not used as data is not replicated
No impact
None Secondary
No data redundancy / RAID-1/5/6
Site B
Witness Host Failure
No impact, witness host is not used as data is not replicated
No impact
Site Mirroring
No data redundancy
Site A or B
Host failure Site A or B
Components on failed hosts inaccessible, read and write IO across ISL as no redundancy locally, rebuild across ISL
VM does not need to be restarted, unless VM was running on failed host
Site Mirroring
RAID-1/5/6
Site A or B
Host failure Site A or B
Components on failed hosts inaccessible, read IO locally due to RAID, rebuild locally
VM does not need to be restarted, unless VM was running on failed host
Site Mirroring
No data redundancy / RAID-1/5/6
Site A
Full failure Site A
Objects are inaccessible in Site A as full site failed
VM restarted in Site B
Site Mirroring
No data redundancy / RAID-1/5/6
Site A
Partition Site A
Objects are inaccessible in Site A as full site is partitioned and quorum is lost
VM restarted in Site B
Site Mirroring
No data redundancy / RAID-1/5/6
Site A
Witness Host Failure
Witness object inaccessible, VM remains accessible
VM does not need to be restarted
Site Mirroring
No data redundancy / RAID-1/5/6
Site B
Full failure Site A
Objects are inaccessible in Site A as full site failed
VM does not need to be restarted as it resides in Site B
Site Mirroring
No data redundancy / RAID-1/5/6
Site B
Partition Site A
Objects are inaccessible in Site A as full site is partitioned and quorum is lost
VM does not need to be restarted as it resides in Site B
Site Mirroring
No data redundancy / RAID-1/5/6
Site B
Witness Host Failure
Witness object inaccessible, VM remains accessible
VM does not need to be restarted
Site Mirroring
No data redundancy / RAID-1/5/6
Site A
Network failure between Site A and B (ISL down)
Site A binds with witness, objects in Site B becomes inaccessible
VM does not need to be restarted
Site Mirroring
No data redundancy / RAID-1/5/6
Site B
Network failure between Site A and B (ISL down)
Site A binds with witness, objects in Site B becomes inaccessible
VM restarted in Site A
Site Mirroring
No data redundancy / RAID-1/5/6
Site A or Site B
Network failure between Witness and Site A/B
Witness object inaccessible, VM remains accessible
VM does not need to be restarted
Site Mirroring
No data redundancy / RAID-1/5/6
Site A
Full failure Site A, and simultaneous Witness Host Failure
Objects are inaccessible in Site A and Site B due to quorum being lost
VM cannot be restarted
Site Mirroring
No data redundancy / RAID-1/5/6
Site A
Full failure Site A, followed by Witness Host Failure a few minutes later
Pre vSAN 7.0 U3: Objects are inaccessible in Site A and Site B due to quorum being lost
VM cannot be restarted
Site Mirroring
No data redundancy / RAID-1/5/6
Site A
Full failure Site A, followed by Witness Host Failure a few minutes later
Post vSAN 7.0 U3: Objects are inaccessible in Site A, but accessible in Site B as votes have been recounted
VM restarted in Site B
Site Mirroring
No data redundancy / RAID-1/5/6
Site B
Full failure Site B, followed by Witness Host Failure a few minutes later
Post vSAN 7.0 U3: Objects are inaccessible in Site B, but accessible in Site A as votes have been recounted
VM restarted in Site A
Site Mirroring
No data redundancy
Site A
Full failure Site A, and simultaneous host failure in Site B
Objects are inaccessible in Site A, if components reside on failed host then object is inaccessible in Site B
VM cannot be restarted
Site Mirroring
No data redundancy
Site A
Full failure Site A, and simultaneous host failure in Site B
Objects are inaccessible in Site A, if components do not reside on failed host then object is accessible in Site B
VM restarted in Site B
Site Mirroring
RAID-1/5/6
Site A
Full failure Site A, and simultaneous host failure in Site B
Objects are inaccessible in Site A, accessible in Site B as there's site local resiliency
VM restarted in Site B
Таги: VMware, vSAN, Troubleshooting, HA, DR, Blogs
Вильям Лам опубликовал интересную статью о шаблонах виртуальных машин (VM Templates), разъясняющую некоторые возможности по их использованию в библиотеках контента.
Часто неправильно понимаемой возможностью библиотеки контента vSphere является управление и распространение шаблонов виртуальных машин (VM Templates), которая была представлена в vSphere 6.7 Update 2.
Для библиотек контента в vSphere 5.0 контент распространялся с использованием репликации на основе запроса, при которой на клиентском vCenter Server настраивалась подписка на контент сервера-издателя vCenter Server, а затем контент скачивался на сервер подписчика, как показано на рисунке ниже.
Эта первоначальная архитектура библиотеки контента vSphere упрощала любому vCenter Server, независимо от его домена Single Sign-On, создание подписки и загрузку контента (файлы ISO, OVF/OVA и другие) из vSphere Content Library сервера-издателя.
Создание подписки на библиотеку контента vSphere полностью управлялось подписывающимся vCenter Server, если он знал URL подписки и учетные данные для подключения к серверу-издателю vCenter Server. Хотя это упрощало подписку на контент из библиотеки контента vSphere для всех, это также означало, что для больших организаций с множеством серверов vCenter Server требовалась дополнительная задача по настройке каждого подписывающегося vCenter Server.
После того как контент был синхронизирован с подписчиком vCenter Server, не было простого способа контролировать, какие пользователи могут развертывать определенные OVF/OVA из библиотеки контента vSphere, что может быть проблемой для организаций, которые требуют тонкого контроля доступа к развертыванию рабочих нагрузок. Как гарантировать, что конкретные пользователи/группы развертывают подходящие или последние образы?
Когда возможность управления шаблонами VMTX была добавлена в библиотеку контента vSphere, это не только ввело новую функцию Check-In/Check-Out для шаблонов виртуальных машин, но и добавило новый метод управления распространением образов виртуальных машин через несколько серверов vCenter с использованием новой репликации на основе push, которая исходит от сервера-издателя vCenter Server.
Вместо того чтобы идти на каждый подписывающийся vCenter Server для создания подписки на библиотеку контента vSphere, теперь вы можете управлять всеми подписками непосредственно с сервера-издателя vCenter Server. Этот дополнительный метод репликации библиотеки контента vSphere требует, чтобы все серверы vCenter Server, которые хотят подписаться на образы VMTX, участвовали либо в Enhanced Linked Mode (ELM), либо в Hybrid Linked Mode (HLM), где онпремизный vCenter Server публикует контент на vCenter Server VMware Cloud на AWS (в обратную сторону пока не поддерживается).
Поскольку подписка на библиотеку контента vSphere управляется и настраивается на сервере-издателе vCenter Server, должно существовать доверие между сервером-издателем и сервером-подписчиком vCenter Server, чтобы иметь возможность создавать подписку с сервера-издателя vCenter Server, и именно поэтому требуется один из вариантов Linked-режимов, чтобы иметь возможность использовать новую возможность синхронизации VTMX.
Имея такое сопряжение, чтобы управлять и создавать подписки на ваши серверы-подписчики vCenter Server, включая образы VMTX, вам нужно выбрать желаемую библиотеку контента vSphere на вашем сервере-издателе vCenter Server и в новой вкладке "Subscriptions", как показано на скриншоте ниже.
Хотя при использовании новой функции VMTX в библиотеке контента vSphere есть некоторые узкие места, есть и большие преимущества перед управлением традиционными образами OVF/OVA. Некоторые администраторы знают, что нет способа контролировать, каким пользователям разрешено развертывать из конкретных образов OVF/OVA из библиотеки контента vSphere.
С VMTX у вас на самом деле есть возможность назначать детализированные права пользователям и группам, которые определяют, кто может видеть и развертывать конкретные образы VMTX, что является результатом того, что образ VMTX является частью инвентаря vSphere, что означает, что вы получаете преимущества от механизма прав vCenter Server.
Ниже приведен пример, где есть два образа VMTX: Photon-3.0 и Photon-4.0 в одной библиотеке контента vSphere, и права назначаются таким образом, что они соответственно отображаются на пользователя lob1-user и lob2-user, которым затем разрешено развертывать на основе прав, которые усатновлены на образы VMTX.
Кроме того, мы можем также ограничить, какой контент должен видеть конкретный подписывающийся vCenter Server, особенно если у ваших развертываний vCenter Server есть различные требования по контенту. С моделью на основе pull, все пользователи в подписывающихся серверах vCenter Server смогут видеть только все OVF/OVA из опубликованной библиотеки контента vSphere, и это может быть или не быть желаемым результатом в зависимости от потребностей вашей организации.
Альтернативный подход к ограничению доступа к OVF/OVA заключается в создании нескольких библиотек контента vSphere с сервера-издателя vCenter Server, но это может привести к дублированию контента, который должен быть в нескольких библиотеках, что потребляет дополнительное место хранения и добавляет дополнительную сложность.
С новым же подходом вы можете управлять одной библиотекой контента vSphere со всеми желаемыми VMTX, а затем использовать права vSphere для предоставления дополнительного контроля доступа в каждом подписывающемся vCenter Server. Наконец, чтобы гарантировать, что каждый подписывающийся vCenter Server не загружает ненужные образы VMTX, которые не могут быть использованы, вы всегда должны рассматривать возможность включения настройки "Загрузка контента библиотеки по мере необходимости" и предварительно загружать только тот контент, который, как вы знаете, может или будет использоваться подписывающимся vCenter Server.
Сам гипервизор ESXi присутствует на рынке уже более 15 лет (раньше он назывался ESX и был построен поверх ОС Linux), и его состав и занимаемый объем на диске менялся со временем. Напомним, что в восьмой версии гипервизора VMware добавила компоненты esxio, обеспечивающие функционирование технологии Project Monterey и SmartNIC, а также составляющие поддержки архитектуры ARM.
Давайте посмотрим, как менялся объем гипервизора, входившего в установочный ISO-образ ESXi, от версии к версии:
ESXi 3.5 - 46,01 MB
ESXi 4.0 - 59,99 MB
ESXi 4.1 - 85,19 MB
ESXi 5.0 - 132,75 MB
ESXi 5.1 - 125,85 MB
ESXi 5.5 - 151,98 MB
ESXi 6.0 - 154,90 MB
ESXi 6.5 - 135,39 MB
ESXi 6.7 - 129,51 MB
ESXi 7.0 - 149,40 MB
ESXi 8.0 - 226,62 MB
Визуализация этих цифр выгладит так:
Надо сказать, что это только размер самого гипервизора, но помимо него в установочном образе содержатся и другие элементы, такие как драйверы устройств, образы VMware Tools и другие вспомогательные библиотеки и системные компоненты.
Если посмотреть на ISO-образ VMware ESXi 8.0, то там будут следующие составные части:
Визуализация этого выглядит так:
Сейчас установочный ISO-образ весит 600-650 МБ, в зависимости от содержащихся в нем апдейтов:
Также если вы перейдете на страницу загрузки VMware ESXi, то увидите, что там есть и Offline Bundle, который занимает значительно больше места на диске, а поставляется он в формате ZIP-архива:
Этот бандл нужен в качестве источника для обновлений VMware Lifecycle Manager - он содержит не только сами компоненты ISO-образа, но и все необходимые апдейты, которые можно накатить на уже установленный гипервизор, чтобы получить актуальную версию платформы.
RSS
