Рубрики
VMware: Гайды по развороту и настройке

Задачи администрирования vSphere 8.0

В наших последних двух материалах «Инсталляция vSphere 8.0 с нуля» и «Обновление VMware vSphere до версии 8.0» мы учились разворачивать нашу среду в базовом своем исполнении, делать самые необходимые начальные настройки и обновляться до последней актуальной версии vSphere, чтобы иметь возможность пользоваться всеми новыми функциями и преимуществами, заботливо подготовленными для нас вендором. О том, что именно в этом смысле обещает VMware можно, в свою очередь, почитать в новости «Что изменилось в VMware vSphere 8.0?».

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

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

Пользовательские интерфейсы vSphere

Для взаимодействия с нашей средой можем пользоваться такими интерфейсами:

  • vSphere Client,
  • PowerCLI,
  • VMware Host Client,
  • vSphere ESXi Shell,
  • ESXCLI:

Главное внимание сегодня уделим GUI клиента самой «сферы», хоста, а некоторые операции будут требовать от нас работы с интерфейсом vCenter Server Management. Другие методы взаимодействия со средой эпизодически будут использоваться в некоторых задачах ниже, если они лучше подходят или будут единственно возможными, но отдельно их выделять не будем.

GUI vSphere Client

Зайти в клиент «сферы» можно, введя в строке браузера «https://<vCenter_FQDN_or_IP_address>/ui»:

Нас попросят предоставить данные учетной записи администратора, после чего попадем в сам GUI. Возле названия есть главное меню («три горизонтальные черточки»), пользуясь которым можно управлять инвентарем системы vCenter, средой инфраструктуры и исполнять разнообразные задачи по администрированию:

Навигационная панель работы с инвентарем vCenter расположена слева:

В этом боковом меню присутствуют четыре вкладки:

  1. Хосты и кластеры (Hosts and Clusters):
  2. Виртуальные машины и шаблоны (VMs and Templates):
  3. Хранилища (информация о датасторах в дата-центре) (Storage):
  4. Сети (все порт-группы на стандартных и распределенных свитчах) (Networking):

Замечание. Объекты со всех четырех вкладок (любое направление инвентаря) можно организовать в папки и подкаталоги для удобства:

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

В рабочей части интерфейса правее расположено меню вкладок и собственное боковое меню – для каждого типа объекта инвентаря (см. выше) свое. Обычно, на этих вкладках можно найти, например, Summary (общая информация об объекте, статус, конфигурация), Monitor (элементы мониторинга, оповещения и предупреждения), Configure (возможности настройки), Permissions (управление разрешениями, доступна только пользователям с привилегиями администратора), Updates (совместимость и информация о существующих обновлениях) и другие, специфические для связанных объектов.

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

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

Контроль удаленного доступа к ESXi-хосту

При помощи vSphere Client можно настроить необходимые параметры безопасности, которые контролируют удаленный доступ у ESXi-хосту (как вообще его включить, мы рассматривали вот здесь).

Файервол ESXi активировано по дефолту – он блокирует входящий и исходящий трафик, за исключением того, что активирован в настройках файервола хоста:

Важно! Такие ключевые и фундаментальные для безопасности сервисы, как NTP и SSH клиенты, управляются пользователем с привилегиями администратора (насчет аккаунтов пользователей поговорим ниже в соответствующем подразделе).

Режим Lockdown предотвращает удаленный доступ пользователей ко входу на хост напрямую – хост доступен только через DCUI или из vCenter. Еще можно использовать START, STOP и RESTART, чтобы изменить статус сервиса временно. Альтернативно, можно изменить политику запуска, чтобы служба запускалась с использованием хоста или порта. Для некоторых служб можно указывать ІР-адреса, их диапазоны или целые подсети, с которых разрешено соединение.

Делается все это на вкладке Configure под System у Firewall и других разделах ниже, посвященных безопасности.

Настройка входящего сообщения

К странице входа в vSphere Client можно добавить сообщение, которое будет демонстрироваться пользователю. Для этого:

  1. Из меню Home выбираем Administration и под Single Sign On кликаем на Configuration;
  2. Проходим на вкладку Login Message;
  3. Жмем на Edit и включаем Show login message, чтобы разрешить его показ;
  4. В поле Login message задаем заголовок сообщения (если в поле Consent checkbox – расположено ниже — стоит галочка, то дефолтный текст сообщения будет «I agree to Terms and Conditions» и при желании фразу «Terms and Conditions» можно будет изменить на свою. Если же галочки там нет, появится «Login message», вместо которого просто пишем собственный вариант);
  5. В Consent checkbox ставим галочку, если хотим, чтобы при каждом входе пользователь должен был поставить значок в чекбоксе, соглашаясь с нашим сообщением (без этого выбора сообщение показываться тоже будет, но взаимодействия с пользователем не потребует);
  6. В Details of login message пишем «тело» нашего сообщения;
  7. Сохраняем настройки кнопкой Save.

Настройка таймаута клиента vSphere

По умолчанию, vSphere Client закрывается через 120 минут простоя и пользователю приходится снова делать вход, чтобы клиент возобновил работу. Отредактировать это значение можно как непосредственно в файле «webclient.properties», так и в самом клиенте.

В первом случае проходим в папку «/etc/vmware/vsphere-ui» и открываем на редактирование файл «webclient.properties». Находим там строку session.timeout = <custom_value>, где <custom_value> — это значение в минутах (если это – первое изменение таймаута, то будут стоять 120). Если хотим, чтобы клиент никогда не отключался, ставим значение 0 или отрицательное. Сохраняем файл и перезапускаем клиент.

Если меняем в самом vSphere Client:

  1. Проходим в Home > Administration и под Deployment выбираем Client Configuration;
  2. На панели, что откроется, кликаем Edit – появится диалоговое окно Edit client configuration;
  3. Вводим желаемое значение в минутах в текстовое поле;
  4. Сохраняемся по Save и перезапускаем клиент.

Управление клиентскими плагинами

В vSphere Client клиентские плагины можно увидеть в панели Recent Tasks или Task Console (прогресс активностей, развертывания, сбои, обновления, инсталляции и деинсталляции) и в Administration > Solutions > Client Plugins. В последней панели с плагинами можно делать всяческие действия, с добавлением новых и удалением, включительно. Добавление происходит после нажатия здесь на Add – появится помощник Install new solution:

  1. В пункте Select an OVF template указываем локацию, откуда брать OVF плагина (URL или Local file, во втором случае придется кликнуть на Upload files, чтобы выбрать нужные). Next;
  2. В пункте Select a name and folder вводим уникальное имя ВМ и локацию развертывания, Next;
  3. В пункте Select a compute resource выбираем ресурс, где будет запускаться наш клиентский плагин, Next;
  4. На странице Review details просматриваем сделанные настройки и кликаем Next;
  5. На странице License agreement ставим галочку и жмем Next;
  6. На странице Select storage выбираем, где и как будет храниться наш плагин. Можно выбрать политику и, опционально, поставить галочку в Disable Storage DRS for this virtual machine, если не хотим, чтобы для этой ВМ работал Storage DRS;
  7. На странице Select networks выбираем исходящую сеть и сопоставляем ее с сетью назначения, Next;
  8. Опционально, на странице Customize template можем просмотреть настройки в режиме только для чтения и кликнуть Next;
  9. На странице Associate vCenter Servers выбираем инстансы vCenter Server, на которых будет разворачиваться плагин, Next;
  10. На Ready to complete окончательно просматриваем все заданное и запускаем развертывание кнопкой Finish.

Чтобы удалить ненужный плагин, в этой же панели жмем на него в списке – откроются подробности об этом плагине. Там ставим галочку на инстансах, которые хотим удалить, кликаем Remove и подтверждаем намерение в диалоговом окне кнопкой Yes.

Запуск, остановка и перезапуск сервисов в vSphere Client

Ниже, когда будем учиться работать с vCenter Server Management Interface, рассмотрим как выполнять действия непосредственно из него в плане разнообразных сервисов среды. Однако, это можно сделать и из клиента vSphere, если пройти в Administration > System Configuration и кликнуть на соответствующую ноду из списка. В верхнем меню при этом увидим действия Restart, Start и Stop для перезапуска, запуска или остановки сервисов, соответственно.

Прикрепление файлов к запросу сервиса

Если мы формируем запрос к VMware Service Requests (случилась проблема, которую не можем решить собственными силами, например), можем прикрепить к нему файлы – скриншоты или файлы логов. Для этого на боковой панели vSphere Client кликаем на Administration и под Support – на Upload File to Service Request и еще раз на одноименную кнопку. Далее вводим Service Request ID, кликаем на Browse, выбираем нужный файл, и окончательно на Upload.

Внесение задач в расписание

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

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

  • Добавление хоста к указанному дата-центру или кластеру,
  • Изменение состояния питания ВМ (рower on, power off, suspend, reset),
  • Изменение параметров питания кластера (активировать или деактивировать DPM для хостов в кластере),
  • Изменение параметров ресурсов ресурс-пулу или ВМ (для CPU и Memory — Shares, Reservation, Limit),
  • Проверка соответствия профиля (совпадает ли конфигурация хоста с конфигурацией профиля хоста),
  • Клонирование ВМ с размещением в указанном хосте или кластере,
  • Создание новой ВМ на указанном хосте,
  • Развертывание ВМ из шаблона на указанном хосте или кластере,
  • Миграция ВМ на указанный хост или датастор с vMotion или без него,
  • Снепшотирование ВМ,
  • Сканирование на доступные обновления шаблонов, ВМ, хостов (при наличии vSphere Lifecycle Manager),
  • Исправление путем инсталляции пропущенных патчей (при наличии vSphere Lifecycle Manager).

В панель расписания задач можно попасть, если встать на нужном объекте в клиенте vSphere и на вкладке Configure выбрать Scheduled Tasks. Чтобы внести новую задачу в расписание, клацаем на New Scheduled Task и:

  1. Из выпадающего меню New Scheduled Task выбираем задачу, которую хотим внести в расписание – откроется соответствующий помощник;
  2. Вводим имя и описание задачи;
  3. Выбираем частоту ее исполнения: Once (запустить раз в выбранное время и все), After vCenter startup (каждый раз после запуска vCenter Server через указанный промежуток времени в минутах), Hourly (вводим частоту, дату начала и конца), Daily (вводим частоту, дату начала и конца), Weekly (день недели, вводим частоту, дату начала и конца), Monthly (вводим частоту, и либо конкретный день месяца и количество месяцев, либо выбираем first, second, third, fourth или last и день недели и количество месяцев);
  4. Кликаем на Schedule the task.

В уже созданное расписание можно внести изменения, если в Scheduled Tasks встать на искомую задачу со списка слева и выбрать Edit, отредактировать желаемым образом и кликнуть на Save. Удалить внесенную в расписание задачу можно, если там же выбрать задачу и кликнуть на Remove.

Настройка хостов из клиента vSphere

В разделах ниже будем учиться задавать настройки хоста с VMware Host Client, а кое-что по этой теме даже рассматривалось в разрезе использования DCUI в неоднократно упомянутой здесь статье о greenfield-инсталляции. Но некоторую конфигурацию можно устроить и из vSphere Client – прямо из его раздела инвентаря Hosts and Clusters.

Например, если мы хотим настроить загрузочное устройство на ESXi-хосте, выбираем нужный хост в инвентаре и кликаем на вкладку Configure. Под Hardware выбираем Overview и нажимаем на кнопку Boot Options, определяем загрузочное устройство из выпадающего меню. Если хотим, чтобы хост сразу же перезагрузился с указанного нами устройства, выбираем Apply and Reboot on OK. Если этого не сделать, настройка применится при следующей перезагрузке хоста. Жмем на ОК, чтобы сохранить новую конфигурацию.

GUI VMware Host Client

Замечание. VMware Host Client – интерфейс, который управляет одиночными хостами. Он удобен в чрезвычайных ситуациях, когда vCenter Server не доступен, работает с административными задачами и базовым траблшутингом.

VMware Host Client очень отличается от клиента vSphere. Однако по единственному хосту ESXi обладает довольно исчерпывающим функционалом:

  • Базовые операции виртуализации, включая развертывание и настройку ВМ разной сложности;
  • Создание и управление сетей и хранилищ данных;
  • Имеет расширенную настройку параметров уровня хоста для улучшения производительности.

Чтобы зайти в VMware Host Client, в веб-браузере вводим имя или ІР-адрес целевого хоста в формате: «https://host-name/ui» или «https://host-IP-address/ui». На экране логина вводим имя пользователя и пароль и кликаем на Login – появится страница VMware Customer Experience Improvement Program (CEIP), чтобы можно было определиться, хотим ли присоединиться к программе, где жмем ОК.

В vSphere 8.0 появились некоторые опции кастомизации и брендирования VMware Host Client UI и настройки способа демонстрации контента. В частности, можно выбрать одну из трех тем — light, dark и classic, следующим образом: в панели инструментов кликаем на Help и на About, из выпадающего меню UI Preferences Theme выбираем желаемую тему. Если хотим более гранулированной настройки, жмем на кнопку Customize:

В поле Theme name вводим имя нашей новой темы, а после всех сделанных выборов жмем на Enable. Если хотим вернуться к дефолтной палитре – на Reset.

Замечание. Чтобы переключиться с VMware Host Client на vSphere Client, получить полный спектр возможностей и функций траблшутинга ESXi-хоста, если он должен остаться standalone-объектом и мы не против его присоединения к товариществу, нужно сделать следующее в VMware Host Client:

  1. ПКМ на Host в инвентаре и выбираем из выпадающего меню Manage with vCenter Server – откроется страница логина в vCenter Server в новом окне;
  2. Вводим данные своей учетной записи и кликаем на Login.

Аналогичным образом можно отключиться от системы vCenter Server при необходимости (бывает полезно, когда она дала сбой, а нужно сделать определенные экстренные действия с хостом):

  1. ПКМ на Host в инвентаре VMware Host Client и выбираем Disconnect from vCenter Server из появившегося меню;
  2. Кликаем на Disconnect from vCenter Server.

Настройка баннера логина в VMware Host Client UI

Можно настроить баннер на экране логина для демонстрации каких-то предупреждений, анонсов. Для этого редактируем файл /etc/vmware/welcome прямо на хосте. Синтаксис:

  • Каждая новая строка начинается с # (от 1 до 6 – задает уровень заголовка), если это должен быть заголовок;
  • Начиная новую строку вводим минимум 3 тире – генерирует тег правила <hr /> у HTML, выглядит как сплошная горизонтальная линия;
  • Новую строку начинаем с трех одиночных обратных ` и таким же знаком закрываем блок – покажет неформатированный простой текст между этими знаками:

«`

My content — — —

*Login Secure* >_

Read the policy

«`

  • Чтобы написать что-то жирным, помещаем текст в ** вида:

**important message**

  • Чтобы написать что-то курсивом, помещаем текст в * вида:

*A named document*

  • Вставка ссылки:

[My link](https://www.example.com?search=virtual)

Поддерживаемые переменные:

{hostname} — FQDN или IP-адрес

{esxversion} – версия ESXi через точки (8.0.0)

{esxproduct} – полное имя ESXi с версией и билдом (VMware ESXi 7.0.0 build-16324942)

{client-current-date} — текущая дата для машины пользователя (Tuesday, August 30, 2022)

{client-current-time} – текущее время для машины пользователя (08:00 AM)

Пример баннера:

## Warning: Authorized Users Only

Управление параметрами системы в VMware Host Client

В VMware Host Client можем изменить настройку хоста таким образом:

  1. Кликаем на Manage в инвентаре, после чего на System;
  2. Жмем на Advanced settings;
  3. ПКМ на искомый объект в списке и выбираем Edit option из выпадающего меню – появится соответствующее диалоговое окно;
  4. Редактируем значение и кликаем Save, чтобы применить изменения.

По желанию можем вернуться к начальным настройкам, ПКМ на искомый объект и выбрав Reset to default.

Создание приветствия в Direct Console User Interface и VMware Host Client

Кликаем на Manage в инвентаре и на Advanced Settings. А далее для:

  • Приветственного сообщения к логину в DCUI и VMware Host Client: в текстовое поле Search вводим WelcomeMessage и жмем на иконку поиска, ПКМ на Annotations.WelcomeMessage и выбираем из выпадающего меню Edit option – появится диалоговое окно, где в текстовом поле New value вводим текст приветствия, кликаем Save;
  • Приветственного сообщения после входа в VMware Host Client: в текстовое поле Search вводим HostClientWelcomeMessage и кликаем на иконку поиска, ПКМ на UserVars.HostClientWelcomeMessageи выбираем Edit option из выпадающего меню – появится диалоговое окно, где в текстовом поле New value вводим свой текст, кликаем Save.

Чтобы активировать наше сообщение, ищем по аналогии с действиями выше UserVars.HostClientEnableMOTDNotification и в поле значения вписываем 1. Если поставить 0 сообщение деактивируется. Также можно вернуться к дефолтным значениям, выбрав действие Reset to default.

Настройка таймаута пользовательского сеанса VMware Host Client

По умолчанию, сеанс пользователя VMware Host Client закрывается через 15 минут (900с) при не активности. Это значение можно изменить двумя способами.

Из Advanced Settings:

  1. Кликаем на Manage в инвентаре и на Advanced Settings;
  2. Вводим в текстовое поле SearchHostClientSessionTimeout и кликаем на иконку поиска;
  3. ПКМ на HostClientSessionTimeout и выбираем Edit option из выпадающего меню – появится диалоговое окно;
  4. В текстовом поле New value вводим свое значение в секундах;
  5. Кликаем Save.

Чтобы восстановить дефолтное значение, выбираем Reset to default.

Из выпадающего меню User Settings:

  1. Кликаем на имя пользователя вверху и выбираем Settings > Application timeout;
  2. Выбираем время. Чтобы деактивировать выход из сеанса при не активности выбираем Off.

Настройка качества паролей и политики блокировки аккаунта в VMware Host Client

Далее ко всем настройкам в отношении паролей и блокировки аккаунта будем добираться через Manage — Advanced Settings в инвентаре клиента, введя в текстовое поле Search нужную характеристику и нажав на иконку поиска, а дальше ПКМ на эту опцию и выбираем Edit option из выпадающего меню – откроется диалоговое окно, в котором в поле New value вводим желаемое значение и кликаем Save. Доступные опции для настройки:

  • Требований по длине пароля, классу знаков и разрешению на фразы пароля: PasswordQualityControl
  • Количества паролей для запоминания на каждого пользователя: PasswordHistory
  • Количество дней, после которого пароль изменится: PasswordMaxDays
  • Количество неправильных попыток ввести пароль до блокировки аккаунта: AccountLockFailures
  • Время, после которого аккаунт пользователя будет разблокировано: AccountUnlockTime

Замечание. Блокировка аккаунта после определенного количества неудачных попыток ввести пароль по дефолту случается через 5 попыток подряд – через 3 минуты с автоматическим разблокированием через 15.

Настройка расширенных опций TLS/SSL ключа

Чтобы настроить протоколы безопасности и криптографические алгоритмы, которые используются в зашифрованной связи с ESXi-хостом, необходимо:

  1. Кликаем на Manage в инвентаре и на Advanced Settings;
  2. Вводим в текстовом поле Search искомый ключ безопасности (см. перечень ниже) и нажимаем на иконку поиска;
  3. ПКМ на ключ и выбираем Edit option из выпадающего меню – появится диалоговое окно;
  4. В поле New value вводим значение и кликаем на Save.

Список доступных ключей безопасности:

  • ESXiVPsAllowedCiphers (дефолтное значение — !aNULL:kECDH+AESGCM:ECDH+AESGCM:RSA+AESGCM:kECDH+AES:ECDH+AES:RSA+AES) – дефолтная контрольная строка шифра
  • HostAgent.ssl.keyStore.allowAny (дефолтное значение — False) – можно добавить любой сертификат к ESXi CA trust store
  • HostAgent.ssl.keyStore.allowSelfSigned (дефолтное значение — False) – можно добавить не CA самоподписанные сертификаты к ESXi CA trust store
  • HostAgent.ssl.keyStore.discardLeaf (дефолтное значение — True) – отбрасывает конечные сертификаты, добавленные к ESXi CA trust store.

Настройка обнуления памяти

В VMware Host Client можно воспользоваться расширенной опцией Mem.MemEagerZero, чтобы определить, как обнуляются страницы для ВМ и приложений пространства пользователя. Чтобы обнулить все выделенные ВМ и приложениям пространства пользователя страницы, нужно выставить ее значение на 1. Если память повторно не используется, этот параметр предотвращает раскрытие информации с ВМ или приложений другим клиентам, сохраняя предыдущий контент в памяти. Пока опция установлена на 1, страницы обнуляются, пока существует приложение пространства пользователя.

Для ВМ такие страницы обнуляются, если ВМ выключена, страницы ВМ смигрированы, ESXi восстанавливает память ВМ. Чтобы настроить это, делаем точно так же через Manage — Advanced Settings, а в строке поиска вбиваем Mem.MemEagerZero. Вызываем по нему Edit option и выставляем желаемое значение (дефолтное — 0). Потом сохраняем настройки кнопкой Save.

Настройка опций автозапуска в VMware Host Client

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

  1. Кликаем на Manage в инвентаре и на System;
  2. Кликаем на Autostart — Edit settings;
  3. Выбираем Yes, чтобы позволить замену конфигурации автостарта и выставляем желаемые значения по следующим опциям:

Start delay — после того, как запустится хост ESXi, он начнет включать ВМ, настроенные на автоматический запуск. Когда он включит первую ВМ, хост ждет указанное время задержки до включения следующей.

Stop delay – это максимальное время ожидания хостом ESXi завершения команды окончания работы. Порядок, в котором ВМ включаются, является обратным порядку их запуска. После того, как хост ESXi выключит первую ВМ, на протяжении указанного времени хост выключит следующую. Если ВМ не выключается на протяжении указанного времени задержки, хост запускает команду выключения, а потом начинает выключать следующую. Хост ESXi выключается только после завершения работы всех ВМ.

Stop action – выбирается действие выключения, которое будет применено к ВМ на хосте, когда хост выключается:

  • System default
  • Power off
  • Suspend
  • Shut down

Wait for heartbeat – выбираем Yes. Этот параметр может использоваться, если в гостевой ОС ВМ установлено VMware Tools. После того, как хост ESXi включит первую ВМ, он тут же включает следующую. Порядок запуска, в котором включаются ВМ, продолжается после того, как ВМ получит первый heartbeat.

Управление сервисами в VMware Host Client

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

  1. Кликаем на Manage в инвентаре и на Services;
  2. Из списка сервисов выбираем нужный;
  3. Из выпадающего меню Actions выбираем действие: Restart, Start или Stop;
  4. Опционально, из выпадающего меню Actions можем выбрать Policy и опцию для сервиса из меню: Start and stop with firewall ports / Start and stop with host / Start and stop manually.

GUI vCenter Server Management Interface

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

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

Чтобы зайти в этот GUI, придется вбить в браузере https://appliance-IP-address-or-FQDN:5480 и ввести данные учетной записи root (дефолтный пароль – это тот, что задавали, когда разворачивали vCenter Server).

Выключить или перезагрузить vCenter Server можем, если кликнем в GUI на Summary и из верхнего меню раскроем меню Actions, где выберем действие Shutdown или Reboot, соответственно. В диалоговом окне подтверждения кликаем на Yes.

Включить или выключить доступ по SSH и vCenter Server Bash оболочке можно, если в GUI кликнуть на Access, а потом на Edit, где будут следующие настройки: Enable SSH login, Enable DCUI, Enable Console CLI, Enable Bash Shell. После чего жмем на ОК, чтобы сохранить их.

Изменить пароль пользователя root и дату его истечения можно так:

  1. Кликаем на Administration;
  2. В секции Password жмем Change;
  3. Вводим текущий пароль и новый и кликаем Save;
  4. Переходим в секцию Password expiration settings, кликаем на Edit и выбираем политику истечения срока действия пароля: Yes (нужно будет отметить Root password validity (days) – к-во дней срока действия пароля и Email for expiration warning – электронный адрес, на который выслать предупреждение о приближении даты истечения) или No (никогда не истечет);
  5. Кликаем Save для сохранения.

Настройка системной временной зоны и параметров синхронизации времени

В статье «Инсталляция vSphere 8.0 с нуля» в последних разделах, посвященных первичным настройкам нашей новоустановленной среды, мы рассматривали, как при помощи клиента хоста установить синхронизацию времени между хостами. Но кое-что в этом направлении обязательно нужно сделать и в интерфейсе управления нашим vCenter. А именно:

  1. Кликаем в GUI на Time;
  2. В панели Time zoneкликаем на Edit и из выпадающего меню Time zone выбираем локацию или временную зону, после чего сохраняем настройки кнопкой Save;
  3. В панели Time synchronization кликаем на Edit и из выпадающего меню Mode выбираем метод синхронизации времени: Disabled (без синхронизации времени – будет использоваться системная временная зона), Host (включает синхронизацию времени VMware Tools – будет синхронизироваться со временем ESXi-хоста), NTP (включает NTP-синхронизацию – нужно ввести ІР-адрес или FQDN одного или более NTP-серверов);
  4. Сохраняемся по Save.

Запуск, остановка и перезапуск служб vCenter Server 

Из vCenter Server Management Interface можем наблюдать за статусом компонентов vCenter Server и делать с ними различные действия. Для этого нам нужно пройти на Services – продемонстрирует страницу с проинсталлированными службами, отсортированными по имени, типу запуска, работоспособностью и статусом. Здесь просто выбираем нужный сервис и можем:

  • Для настройки автоматического или запуска вручную жмем на SET STARTUP TYPEManual/Automatic;
  • Для запуска сервиса – кликаем на START;
  • Для остановки – на STOP;
  • Для перезапуска – на RESTART,

и подтверждаем свое действие кнопкой ОК.

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

Как непосредственно обновляться, мы рассматривали в подразделе «Процедура обновления vCenter Server» статьи «Обновление VMware vSphere до версии 8.0». Но чтобы на будущее удобно настроить процессы патчирования и ознакомления с доступностью новых версий, а также самих обновлений, в vCenter Server Management Interface можно пройти в Update и выбрать Settings, где:

  • Поставить галочку в соответствующий чекбокс, чтобы осуществляло автоматическую проверку на апдейты;
  • Выбрать дефолтный или пользовательский репозиторий, откуда можно забирать обновление (во втором случае обязательно вводим соответствующий URL и, опционально, имя пользователя с паролем, чтобы этой функцией не смог воспользоваться никто, кроме нас).

Все настройки сохраняются кнопочкой Save.

Кстати, тут же можно в любой момент и вручную проверить наличие обновлений, кликнув на Check Updates из выпадающего меню, и выбрав CD-ROM или CD-ROM + URL.

Настройка сети в vCenter Server Management Interface

Когда мы в прошлый раз разворачивали appliance нашего vCenter, мы задавали первичные настройки сети, и тогда говорили, что потом к конфигурированию можно будет возвратиться позднее – при помощи vCenter Server Management Interface. Для этого в соответствующем GUI есть целая специальная панель – Networking, на которой, если нажать на Edit, можно:

  • Настроить DNS – раскрываем секцию Hostname and DNS, можем выбрать Obtain DNS settings automatically, чтобы получать настройки DNS из сети автоматически, или Enter DNS settings manually – в этом случае придется вручную ввести IP-адрес желаемого DNS-сервера и, опционально, альтернативного;
  • Настроить шлюз – раскрываем секцию NIC0;
  • Отредактировать параметры IPv4-адреса — Enable or Disable IPv4 settings, Obtain IPv4 settings automatically или Enter IPv4 settings manually (автоматически получать IPv4-адреса для appliance из сети или вручную его вводить, предоставив IP-адрес, длину префикса подсети и дефолтный шлюз);
  • Отредактировать параметры IPv6-адреса — Enable or Disable IPv6 settings, Obtain IPv6 settings automatically through DHCP или Obtain IPv6 settings automatically through router advertisement (получать IPv6-адреса для appliance автоматически из сети через DHCP или за представлением роутера), а также можно задать Use static IPv6 addresses – для ручного ввода статического IPv6-адреса после отметки галочкой соответствующего блока;
  • Настроить прокси-сервер в секции Proxy Settings кнопкой Edit – здесь включаем нужную опцию: HTTPS, FTP или HTTP.

М, наконец, можем ввести имя хоста для сервера или IP-адрес, порт и, опционально, имя пользователя и пароль. После чего вся измененная конфигурация сохраняется кнопкой Save.

В панели Networking действием Edit еще можем изменить FQDN, IP или PNID управляющей сети vCenter Server.

Замечание. Системное имя используется как первичный сетевой идентификатор (PNID). Если при первичной инсталляции мы когда-то идентифицировали наш vCenter Server по IP-адресу, позднее можем изменить PNID на FQDN.

Важно! Если у нас уже есть работающий vCenter High Availability (HA), перед изменением PNID его следует выключить.

Следовательно:

  1. Проходим в нужную NIC и кликаем на Next;
  2. На пункте Edit Settings меняем имя хоста и предоставляем новый IP-адрес. Next;
  3. В пункте SSO Credentials отмечаем данные учетной записи администратора SSO (administrator@<domain_name>);
  4. В пункте Ready to Complete просматриваем настройки и ставим галочку в том, что осведомлены в необходимости сделать бекап, после чего кликаем на Finish.

Теперь на Networking увидим новое имя хоста и новый IP-адрес.

Настройка файервола

В vCenter Server Management Interface можем редактировать параметры файервола vCenter Server и создавать его правила, чтобы, например, позволять или блокировать трафик между vCenter Server и определенными серверами, хостами или ВМ. Однако, заметьте, что блокируем мы именно весь трафик – не указанные порты!

В GUI проходим в Firewall и:

  • Чтобы создать правило файервола, кликаем на Add (выбираем сетевой интерфейс ВМ, вводим IP-адрес сети, к которой нужно применить это правило, длину префикса подсети, а из выпадающего меню Action выбираем нужное действие — Accept, Ignore, Reject или Return). Сохраняем настройки кнопкой Save;
  • Чтобы отредактировать существующее правило – выбираем правило, которое интересует, и жмем на Edit, меняем настройки и сохраняемся по Save;
  • Чтобы удалить правило – выбираем его в списке и кликаем на Delete. И еще раз в окне подтверждения;
  • Чтобы изменить порядок применения правил – выбираем нужное правило и кликаем на Reorder, в соответствующей панели выбираем правило и кликаем на Move Up или Move Down, чтобы переместить его выше или ниже по списку. Сохраняемся кнопкой Save.

Управление объектами инвентаря vCenter

Большие среды vSphere могут содержать несколько виртуальных дата-центров со сложным упорядочением хостов, кластеров, пулов ресурсов и сетей. Причем таких систем vCenter может быть намного больше одной. Поэтому очень важно придирчиво и комплексно подходить к задачам организации и заполнения инвентаря. В общем случае они выглядят так:

  1. Создаем дата-центры;
  2. Создаем кластеры для консолидации ресурсов многих хостов и ВМ;
  3. Добавляем хосты к кластерам или дата-центрам;
  4. Организовываем объекты инвентаря в папки;
  5. Настраиваем сеть, используя стандартные свитчи vSphere или vSphere distributed switch;
  6. Настраиваем системы хранилищ и создаем объекты инвентаря датастора, чтобы предоставлять логические контейнеры для устройств хранилища в инвентаре.

Объекты – это сущности, с которыми могут выполняться определенные действия. Они включают дата-центры, папки, кластеры, хосты, датасторы, сети и ВМ.

Работа с дата-центрами и папками

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

Папки, как мы уже отмечали выше, позволяют группировать объекты одинакового типа для облегчения управления.

Создание дата-центра и папок

Чтобы добавить дата-центр или папку нужно в клиенте vSphere ПКМ на существующую систему vCenter и в действиях выбрать соответствующий шаг:

Можно создать папку и в существующем дата-центре – точно так же ПКМ на него в инвентаре и выбираем действие New Folder:

Оба действия можно делать на любом объекте vCenter Server, однако с дата-центрами работаем на вкладке Hosts and Clusters, а вот папки можно создавать и в Network, и в Storage, а также в VM and Template.

Добавление хоста к папке или дата-центру

Чтобы добавить хост ESXi к системе vCenter, нужно ПКМ на папку (если есть) или напрямую на дата-центр и выбрать в действиях Add Host, после чего пробежаться простеньким помощником, как показано на скриншоте:

Создание категорий тегов и тегов для объектов инвентаря

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

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

  1. Проходим в Tags & Custom Attributes из главного меню клиента;
  2. Кликаем на вкладку Tags и на Categories и выбираем нужное действие: или кликаем на New и тогда будем создавать новую категорию, или на Edit, выбрав нужную категорию, чтобы отредактировать уже существующую;
  3. Задаем имя категории (уникальное для выбранной системы vCenter Server), описание, выбираем нужное в Tags Per Object (если выбрать One Tag, можно будет применять только один тег из этой категории к объекту, а если Many tags – больше одного).

Важно! После выбора Tags Per Object можно менять One Tag на Many Tags, но не наоборот.

В Associable Object Types выбираем, хоти ли, чтобы теги из этой категории применялись ко всем объектам, или только к указанному типу объектов.

Важно! Если выбрали один тип объектов, позднее можно будет изменить применение на «ко всем», но если изначально выбрали «ко всем», ограничение далее задать будет невозможно.

  1. Кликаем на Createили Save, в зависимости от того, создаем ли новую категорию, или редактируем существующую.

Чтобы удалить существующую категорию на нашей вкладке Categories выбираем категорию из списка и кликаем на Delete – откроется диалоговое окно Delete Category, где жмем на Delete.

Чтобы создать новый или отредактировать старый тег, проходим в Tags & Custom Attributes – вкладка Tags и кликаем на Tags, и далее:

  1. Если хотим создать новый тег, кликаем на New, если отредактировать – выбираем соответствующий и на Edit;
  2. В диалоговом окне вводим имя тега (до 256 знаков);
  3. Вводим описание;
  4. Указываем категорию, если создаем новый, выбрав существующую из выпадающего меню Category, или кликаем на Create New Category – проделываем все, о чем говорилось выше, и затем выбираем здесь уже ее;
  5. Жмем на Createили Save, в зависимости от того, создаем ли, или редактируем.

Удалить ненужный тег можно там же, если выбрать его в списке (можно сразу несколько) и нажать на Delete, а потом еще раз на Delete в окне подтверждения.

Присвоить тег объекту из инвентаря можно, ПКМ на него и в действиях выбрав пункт Tags&Custom Attributes:

Разрешения для работы с тегами и категориями тегов

Процедура предоставления разрешений пользователям для работы с тегами и категориями тегов идентична. К ней можно приступить как на этапе создания тега/категории, так и позднее, отредактировав соответствующее. Делается это на вкладке Tags в Tags & Custom Attributes, где жмем Tags или Categories, в зависимости от того, к чему хотим предоставить разрешение. В списке выбираем нужный объект и кликаем на Add Permission – появится диалоговое окно, в котором выбираем домен из выпадающего меню и далее пользователя или группу, и, наконец, роль из выпадающего меню. Если хотим распространить разрешение на дочерние объекты, ставим галочку в Propagate to children. Сохраняем настройку кнопкой ОК.

Управление хостами ESXi через VMware Host Client

Все базовые операции с ESXi-хостами можно делать через VMware Host Client. Это актуально не только для «одиноких» хостов вне системы vCenter, но и для тех, что управляются им, ведь не всегда у нас есть доступ к клиенту vSphere по определенным причинам, с недоступностью vCenter Server включительно. Разберем их чаще всего употребляемые экземпляры.

Погружение хоста в режим maintenance

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

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

Для осуществления операции просто ПКМ на искомый хост и выбираем Enter maintenance mode. Чтобы выйти из режима maintenance, делаем то же, только выбираем Exit maintenance mode.

Перезапуск или выключение ESXi-хоста

Для перезагрузки или выключения хоста нужны привилегии Host.Configuration.Maintenance и Global.Log event.

Важно! До выключения или перезапуска хоста обязательно выключите все ВМ на нем и поместите его в режим maintenance.

Делается это очень просто:

  1. ПКМ на хост и выбираем Shut down hostили Reboot host, в зависимости от нужного действия;
  2. Кликаем на Shut downили Reboot для запуска процедуры.

Управление хостами ESXi через vSphere Client

Выше мы учились выполнять базовые операции с хостами через VMware Host Client, но если они не standalone и есть доступ к нашему vCenter Server, конечно же, удобнее и проще все с ними делать через обычный клиент vSphere. Пробежимся этими операциями быстренько.

Отключение, переподключение, перезагрузка и выключение хоста

Чтобы отключить хост, что управляется vCenter Server, идем в инвентаре вкладку Hosts and Clusters, ищем нужный хост, ПКМ на него и выбираем Connection > Disconnect из меню, что показалось. Появится окно подтверждения, где жмем на ОК.

Чтобы снова подключить хост, делаем то же самое, но в меню, что появилось, вместо Disconnect выбираем, естественно, Connect.

Чтобы перезагрузить или выключить хост, в Hosts and Clusters выбираем его и из меню Actions жмем на Power, а далее на нужную операцию – или Reboot, или Shut Down, соответственно. Жмем ОК после предоставления причины, из-за чего к этому прибегли.

Перемещение хоста

Чтобы переместить хост в другую локацию в инвентаре vSphere:

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

  1. Проходим в Hosts and Clusters и выбираем нужный хост. Если он является частью кластера, погружаем его в режим техобслуживания — ПКМ на него и выбираем Maintenance Mode > Enter Maintenance Mode. Опционально, если хост является частью DRS-кластера, эвакуируем или обозначаем как suspended ВМ, поставив галочку в Move powered-off and suspended virtual machines to other hosts in the cluster. Подтверждаем наше намерение в диалоговом окне, кликнув на ОК;
  2. Зажимаем мышкой наш хост в инвентаре и перетаскиваем его в новую локацию;
  3. ПКМ на хост и выбираем Maintenance Mode > Exit Maintenance Mode;
  4. Опционально, можно включить выключенные ВМ.

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

Удаление хоста из vCenter Server

Чтобы удалить управляемый vCenter Server хост из его системы и остановить его мониторинг и управление, необходимо:

  1. В Hosts and Clusters выбираем нужный хост и, опционально, уводим его в режим maintenance (см. операцию выше);
  2. ПКМ на хост и выбираем Remove from Inventory из меню, что показалось;
  3. В окне подтверждения жмем на Yes.

Замечание. Вместе с хостом из vCenter Server удалятся и все ассоциированные с ним ВМ. Ассоциированный процессор и лицензии миграции вернутся в статус доступных.

Управление аккаунтами пользователей

Аккаунты пользователей необходимы для доступа к ESXi-хостим или системам vCenter. С точки зрения безопасности при их назначении следует учитывать такие советы:

  • Строго контролируйте доступ root к хостам ESXi;
  • Создавайте надежные пароли учетных записей root, с минимум восьмью знаками, учитывая спецсимволы, буквы как большие, так и маленькие, цифры. Периодически меняйте их;
  • Управляйте хостами ESXi централизованно через vCenter Server с помощью клиента vSphere;
  • Сведите к минимуму использование локальных пользователей на хостах ESXi. Лучше всего будет добавить хосты ESXi к домену и ввести соответствующих администраторов в группу домена ESX Admins. Пользователи в группе домена обладают всеми привилегиями root на хостах ESXi.

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

Привилегии – это действия, которые могут быть предприняты.

Роль – это набор привилегий.

Пользователь/группа пользователей – индикация лица/лиц, которые могут выполнять действие.

Разрешение – предоставление пользователю/группе пользователей роли (набора привилегий) для выбранного объекта.

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

Работа с ролями

В главном меню клиента vSphere («три черточки», левый верхний угол интерфейса) в блоке Access Control есть пункт Roles. Если встать на него в рабочей панели появится список существующих ролей с четырьмя функциональными кнопками сверху: NEW, CLONE, EDIT и DELETE. Если кликнем по какой-то роли, справа будут показаны три вкладки с информацией по этой роли (DESCRIPTION, USAGE, PRIVILEDGES):

Вкладка USAGE показывает, какие пользователи назначены выбранной роли по конкретному объекту:

Несколько ролей являются системными и менять их запрещено. Это:

  • Administrator (полные разрешения на объект сов семи действиями и просмотром),
  • Read-only (только просмотр статуса и информации по объекту),
  • Noaccess (запрещено просмотр и действия по объекту),
  • Nocryptographyadministrator (то же самое, что и Administrator, но без операций категории Cryptographic).

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

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

Все роли являются независимыми друг от друга, не существует иерархии ролей или наследственности между ними.

Важно! Для улучшения безопасности и контроля над средой, определение роли должно содержать минимально возможное количество привилегий.

Работа с разрешениями

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

Чтобы назначить разрешения какому-то объекту, нужно нажать ниже вкладок кнопку ADD и в появившемся окне выбрать домен (Domain), пользователя/группу (User/Group) и роль (Role):

Опционально, можно поставить галочку в Propagate to children, чтобы распространить разрешение на дочерние объекты. Если ее не поставить, разрешение коснется лишь указанного объекта. Что касается применения разрешений, на практике, возможны несколько сценариев:

  1. Мы распространили разрешение с высшего объекта в иерархии инвентаря, но на определенном нижнем объекте перезаписали разрешения так, чтобы они отличались (например, по всему дата-центру у пользователя разрешение Read-only, а вот на одной из виртуалок в нем — Administrator);
  2. Мы назначили объединение привилегий группе для определенного объекта, но пользователь является членом нескольких групп с разрешениями на этом объекте (например, если один пользователь является членом Group1 и Group2, он сможет делать все отмеченные в роли действия для всех объектов дата-центра, когда дата-центру назначены оба разрешения);
  3. Мы применили одинаковые разрешения к каждому объекту, на который группа имеет разрешения, таким образом, как непосредственно предоставили бы их пользователю, который входит в несколько групп с разрешениями на разные объекты (например, если мы Group1 назначаем роль Administrator на дата-центре, а Group2 — Read-only на определенной машине, а разрешение для Group1 настроили так, чтобы оно распространялось и на дочерние объекты, то пользователь-член обеих групп будет иметь роль Administrator для всего дата-центра, за исключением той ВМ);
  4. Мы определяем разрешения явно для пользователя на объекте, что имеет приоритет над всеми групповыми разрешениями на этом объекте, независимо от того, что пользователь является членом тех групп. То есть пользователю/группе предоставляется только одна роль для любого данного объекта.

Глобальные разрешения

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

Доступ к глобальным разрешениям получаем из того же главного меню vSphere Client: в Access Control вторым пунктом идет Global Permissions.

Управление пользователями и безопасностью для хоста ESXi при помощи VMware Host Client

Когда мы напрямую подключаемся к ESXi-хосту через VMware Host Client, аккаунты root и vpxuser имеют одинаковые права доступа, как любой пользователь с ролью Administrator для всех объектов. Все прочие пользователи не имеют никаких разрешений при первом контакте со средой, то есть не могут делать никаких действий с объектами, но Administrator может предоставить им разрешения для того, чтобы начать настраивать и расстраивать систему.

Назначение разрешений пользователю для ESXi-хоста

  1. ПКМ на Hostв инвентаре VMware Host Client и кликаем на Permissions – появится окно Manage Permissions;
  2. Кликаем на Add user;
  3. Из текстового поля Select a user выбираем нужного пользователя;
  4. Кликаем на стрелочку рядом с текстовым полем Select a role и выбираем роль из списка;
  5. Опционально, можно выбрать Propagate to all children(чтобы роль распространилась на все дочерние объекты) или Add as group;
  6. Кликаем на Add user, а затем на Close.

Удаление разрешения пользователя для ESXi-хоста

  1. ПКМ на Hostв инвентаре VMware Host Client и на Permissions – откроется окно Manage permissions;
  2. Выбираем нужного пользователя из списка и кликаем на Remove user;
  3. Нажимаем Close.

Назначение разрешений пользователю для ВМ

  1. Кликаем Virtual Machines в инвентаре VMware Host Client;
  2. ПКМ на ВМ из списка и выбираем Permissions – появится окно Manage permissions;
  3. Кликаем на Add user;
  4. Жмем на стрелочку рядом с текстовым полем Select a user и выбираем пользователя;
  5. Кликаем на стрелочку рядом с текстовым полем Select a role и выбираем роль из списка;
  6. Опционально, можно выбрать Propagate to all children, чтобы разрешение распространилось на дата-центры, папки, кластеры, хосты, ВМ и похожие объекты в инстансе vCenter Server;
  7. Кликаем на Add user, а затем на Close.

Удаление разрешений пользователя для ВМ

  1. Кликаем на Virtual Machinesв инвентаре VMware Host Client;
  2. ПКМ на ВМ из списка и выбираем Permissions – откроется окно Manage permissions;
  3. Выбираем пользователя из списка и кликаем Remove user;
  4. Кликаем на Close.

Аутентификация в vSphere

Необходимые теоретические знания по технологиям аутентификации в vSphere можно взять из подраздела «Сервисы аутентификации vCenter» упомянутого материала. А сейчас пробежимся главными операциями, которые нам придется предпринимать как администратору среды в отношении управления сертификатами и  vCenter Single Sign-On.

Операции с сертификатами безопасности vSphere

Управлять сертификатами безопасности vSphere можно из клиента vSphere, при помощи vSphere Automation API, утилиты Certificate Management (инструмент командной строки, который поддерживает генерацию Certificate Signing Request (CSR) и замещение сертификатов) и CLI. Далее работать будем с GUI и CLI как самыми доступными и наглядными даже для новичков.

Управление сертификатами vCenter при помощи vSphere Client

Из клиента vSphere заходим на vCenter Server как пользователь с привилегиями администратора в локальном домене vCenter Single Sign-On (дефолтный домен — vsphere.local). Если в Administration под Certificates кликнуть на Certificate Management, откроется панель управления сертификатами, где можно выполнять с ними различные действия, обновлять SSL-сертификаты машин, добавлять сертификат Trusted Root, в том числе. Здесь можно просматривать информацию по всем сертификатам, что содержатся в определенном хранилище, и детали каждого, если выбрать его в списке, если выбрать его в списке и кликнуть на View Details.

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

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

  1. Заходим на Configure и кликаем на Advanced Settings;
  2. Нажимаем Edit Settings и фильтруем вывод по «threshold»;
  3. Меняем значение cert.threshold на желаемое и кликаем на Save.

Обновить VMCA-подписанные сертификаты означает заместить VMCA-подписанный сертификат аналогичным новым. Для этого (нужно зайти под администратором из группы vCenter Single Sign-On):

  1. Как описано выше проходим на Certificate Management;
  2. Вводим данные учетной записи, если системы запросит;
  3. Из блока Machine SSL Certificate кликаем на Actions > Renew;
  4. Указываем в днях срок действия сертификата;
  5. Кликаем на Renew.

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

Заместить сертификаты пользовательскими можно после их создания для каждой машины. Рассмотрим все возможные акции, которые будут сопровождать наш путь к этому результату (все делается в Certificate Management, где вводим данные учетной записи для нашего vCenter Server и…):

  • Генерация запроса на подпись сертификата для машинного SSL-сертификата. Под плашкой Machine SSL Certificate кликаем на Actions > Generate Certificate Signing Request (CSR), вводим информация о нашем сертификате и кликаем Next, копируем или загружаем CSR, жмем на Finish и представляем новый CSR нашему СА.
  • Добавление доверенного корневого сертификата к хранилищу сертификатов. Под Trusted Root Certificates кликаем на Add, потом – на Browse, чтобы выбрать местоположение цепочки сертификата (можно воспользоваться файлами типа CER, PEM или CRT), далее кликаем на Add.
  • Добавление пользовательских сертификатов. Под плашкой Machine SSL Certificate кликаем на Actions > Import and Replace Certificate, и выбираем одну из трех опций, что подходит нашему случаю (Replace with VMCA – создать сгенерированный VMCA CSR для замещения текущего / Replace with certificate generated from vCenter Server – использовать созданный vCenter Server / Replace with external CA certificate (requires private key) – внешним СА-подписанным), вводим информацию CSR или загружаем соответствующий сертификат и жмем на Replace.

Управление сертификатами vCenter через CLI

В отношении метода через CLI, вот перечень команд, что касаются работы с сертификатами и доменом SSO (кстати, он справится с задачами, которые не поддерживаются GUI клиента, а также с ними можно создавать для удобства и автоматизации рутинных дел собственные скрипты для среды):

  • сertool – создать и управлять сертификатами и ключами. Часть VMware Certificate Authority (VMCA). Команда генерации Certificate Signing Request (CSR) — PKCS10–файла и приватного ключа может иметь вид:

certool —gencsr —privkey=<filename> —pubkey=<filename> —csrfile=<filename>

где –-gencsr требуется для генерации CSR, —privkey <key_file> — имя файла приватного ключа, —pubkey <key_file> — имя файла публичного ключа, а —csrfile <csr_file> — имя файла для файла CSR для посылки CA-провайдеру. Еще может быть опция —config <config_file> — опциональное имя для конфигурационного файла (дефолтное — certool.cfg).

Для создания самоподписанного сертификата и предоставления VMCA-серверу с самоподписанным корневым СА можно написать что-то вроде такого:

machine-70-59:/usr/lib/vmware-vmca/bin # ./certool —predate=2280  —selfca —server= 192.0.2.24 —srp-upn=administrator@vsphere.local

где –-selfca – требуется для генерации самоподписанного сертификата, —predate <number_of_minutes> позволяет устанавливать поле Valid Not Before корневого сертификата на указанное кол-во минут к текущему времени (полезно для решения потенциальных проблем с временными зонами, максимум – 3 дня), —config <config_file> — опциональное имя для конфигурационного файла (дефолтное — certool.cfg), —server <server> — опциональное имя для сервера VMCA (по дефолту используется localhost).

Для импорта корневого сертификата используется команда certool –-rootca, например, вот так:

certool —rootca —cert=root.cert —privkey=privatekey.pem

где опция –-rootca как раз и отвечает за импорт, —cert <certfile> — это имя файла сертификата, —privkey <key_file> — имя файла приватного ключа (в PEM-закодированном формате), а —server <server> — опциональное имя VMCA-сервера (дефолтное — localhost).

Возвращает дефолтное доменное имя, которое используется vmdir команда certool –-getdc (опциональное можно добавить —server <server> та —port <port_num> для имени VMCA-сервера и номер порта, дефолтный — 389).

Также можно попросить систему подождать, пока VMware Directory Service работает, или VMCA-сервис, что полезно для внесения в расписание задач, командами

certool —waitVMDIR —wait 5

или

certool —waitVMCA –selfca

И, наконец, команда certool —publish-roots силовым методом обновляет корневые сертификаты (привилегии администратора), и к ней опционально можно добавить имя VMCA-сервера: certool —publish-roots

Также полезными будут команды:

    • Генерация приватного и публичного ключей (certool –-genkey):

certool —genkey —privkey=<filename> —pubkey=<filename>

    • Генерация сертификата с VMCA-сервера (certool —gencert):

certool —gencert —privkey=<filename> —cert=<filename>

    • Вывести на печать текущий СА-сертификат в читабельном для человека формате (certool —getrootca) – вывод не годен к сертификату:

certool —getrootca —server=remoteserver

    • Распечатать все поля сертификата в читабельном формате (certool —viewcert):

certool —viewcert —cert=<filename>

    • Вывести списком все сертификаты, о которых знает VMCA-сервер, можно ввести опцию фильтра, чтобы задать all или active (certool —enumcert):

certool —enumcert —filter=active

    • Послать указанный сертификат на VMCA-сервер, чтобы проверить, аннулирован ли сертификат (certool —status). Вывод будет содержать «Certificate: REVOKED» или «Certificate: ACTIVE»:

certool —status —cert=<filename>

    • Сгенерировать самоподписанный сертификат, опираясь на значения конфигурационного файла (создает на 3 дня раньше, чтобы избежать проблем с часовыми поясами) (certool —genselfcacert):

certool —genselfcert —privkey=<filename> —cert=<filename>

  • vecs-cli – управляет инстансами VMware Certificate Store (VECS). Вместе с certool (см. выше) и dir-cli (далее будет) дает полный спектр действий для управления инфраструктурой сертификатов и сервисов аутентификации. Команды этого семейства:
    • Создать хранилище сертификатов (vecs-cli store create), можно с опцией —server <server-name>, если нужно указать имя сервера при подключении к удаленному инстансу VECS:

vecs-cli store create —name <store>

    • Удалить хранилище сертификатов (vecs-cli store delete):

vecs-cli store delete —name <store>

    • Вывести список хранилищ сертификатов:

vecs-cli store list

    • Предоставляет или отменяет разрешения к хранилищу сертификатов в зависимости от добавления опции —grantили –-revoke, соответственно (vecs-cli store permissions):

vecs-cli get-permissions —name <store-name>

и чтобы предоставить разрешения определенному пользователю добавляем опцию —user <username> и —grant [read|write] – именно на чтение или на запись

    • Чтобы получить текущие настройки разрешений для хранилища:

vecs-cli store get-permissions

    • Создать запись в VECS – используется для добавления приватного ключа или сертификата к хранилищу:

vecs-cli entry create

используется с опциями: —store <NameOfStore>, —cert <certificate_file_path>, —key <key-file-path>, —password <password> (опционально), —server <server-name> и —upn <user-name>

    • Выводит списком все записи в указанном хранилище:

vecs-cli entry list

    • Получает сертификат из VECS – можно послать его на файл вывода или показать как читабельный текст:

vecs-cli entry getcert

с опциями —store <NameOfStore>, —output <output_file_path> (вывод в файл), —text (вывод в читабельный текст), —server <server-name>, —upn <user-name>

    • Получает ключ, что хранится в VECS – можно послать в файл или показать как читабельный текст:

vecs-cli entry getkey

    • Удалить запись в хранилище сертификатов:

vecs-cli entry delete

    • Принудительно обновить VECS:

vecs-cli force-refresh

  • dir-cli – поддерживает создание и обновление пользователей решения, управления аккаунтами и управление сертификатами и паролями в VMware Directory Service (vmdir). Полезные команды:
    • Вывод списком всех систем vCenter Server, подключенных в enhanced linked mode:

dir-cli nodes list

с опциями —login <admin_user_id>, —password <admin_password> и —server <psc_ip_or_fqdn> (для подключения к другому vCenter Server, чтобы увидеть его партнеров по репликации)

    • Сбросить пароль машинного аккаунта в домене:

dir-cli computer password-reset

с опциями —login <admin_user_id>, —password <admin_password> и —live-dc-hostname <server name> (текущее имя инстанса vCenter Server)

    • Создать пользователя решения:

dir-cli service create

с опциями —name <name>, —cert <cert file>, —ssogroups <comma-separated-groupnames> (сделать генерируемого пользователя членом указанных групп), —wstrustrole <ActAsUser> (членом встроенной группы администраторов или пользователей – буде тли он обладать привилегиями администратора), —ssoadminrole <Administrator/User> (простым пользователем), —login <admin_user_id>, —password <admin_password>

    • Вывод списком пользователей решения (с заданием логина и пароля администратора SSO):

dir-cli service list

    • Удалить пользователя решения в vmdir (с указанием -–name и учетных данных администратора):

dir-cli service delete

    • Обновить сертификат для указанного пользователя решения (после этой команды нужно запустить vecs-cli entry create, чтобы обновить запись сертификата в VECS):

dir-cli service update

    • Создать обычного пользователя внутри vmdir:

dir-cli user create

с опциями —account <name>, —user-password <password>, —first-name <name>, —last-name <name>, данные учетной записи администратора

    • Изменить указанного пользователя внутри vmdir:

dir-cli user modify

с опциями —account <name>, —password-never-expires или —password-expires и данными учетной записи администратора

    • Удалить указанного пользователя внутри vmdir:

dir-cli user delete

    • Найти пользователя внутри vmdir по имени. Указывается —level <info level 0|1|2>, где Level 0 – аккаунт и UPN, Level 1 – то, что в level 0 + фамилия с именем, Level 2 — это level 0 + флажки в Account deactivated, Account locked, Password never expires, password expired и password expiry. Дефолтный уровень – 0:

dir-cli user find-by-name

    • Добавить пользователя или группу к существующей группе:

dir-cli group modify

с опциями —name <name>, —add <user_or_group_name> и данными учетной записи администратора

    • Вывод списком указанной группы vmdir:

dir-cli group list

    • Создать группу внутри локального домена (дефолтный — local):

dir-cli ssogroup create

с опциями —name <name>, —description <description> и данными учетной записи администратора

    • Опубликовать доверенный корневой сертификат к vmdir (VECS подхватит изменения через минуту, можно ли его обновить принудительно, как показывали выше):

dir-cli trustedcert publish

с опциями —cert <file> (путь к файлу сертификата) и учетными данными администратора SSO

    • Отменить публикацию доверенного корневого сертификата:

dir-cli trustedcert unpublish

    • Вывести списком доверенные корневые сертификаты и их соответствующие ID:

dir-cli trustedcert list

    • Получить доверенный корневой сертификат из vmdir и записать его в указанный файл:

dir-cli trustedcert get

с опциями —id <cert_ID>, —outcert <path> (путь к файлу, куда нужно записать), учетные данные админа

    • Создать произвольный пароль, что удовлетворяет требованиям:

dir-cli password create

    • Сбросить пароль пользователя. Если это делает администратор, то вводим команду:

dir-cli password reset

если пользователь без привилегий администратора, то dir-cli password change, с опциями –account, —new (новый пароль) и учетными данными администратора (для первого случая), и во втором случае перед новым паролем нужно будет указать -–current – текущий.

  • sso-config – обновляет сертификаты Security Token Service (STS), ниже о ней поговорим.
  • service-control – команда для запуска, остановки и вывода списком сервисов. Ее следует запускать перед тем, как запускать другие команды CLI.

Управление аутентификацией при помощи vCenter Single Sign-On

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

Добавление источников идентификации к домену

Чтобы добавить источник аутентификации Active Directory к vCenter Server, необходимо присоединить vCenter Server к домену Active Directory. Для этого:

  1. Из клиента vSphere заходим на vCenter Server под администратором в локальном домене vCenter Single Sign-On (vsphere.local по умолчанию);
  2. Выбираем Administration;
  3. Раскрываем Single Sign On и кликаем на Configuration;
  4. Под вкладкой Identity Provider кликаем на Active Directory Domain;
  5. Нажимаем Join AD, вводим домен, опционально организационный юнит, имя пользователя и пароль и кликаем на Join;
  6. Перегружаем vCenter Server.

Теперь добавляем источник идентификации vCenter Single Sign-On (там же потом можно будет и редактировать при необходимости):

  1. На вкладке Identity Provider (см. алгоритм перед этим) кликаем на Identity Sources и на Add;
  2. Выбираем источник идентификации и вводим его параметры (Active Directory (Integrated Windows Authentication) / Active Directory over LDAP / OpenLDAP);
  3. Жмем на Add.

Заметьте, что в случае Active Directory over LDAP и OpenLDAP нам необходимо будет ввести следующие параметры сервера:

  • Name — имя,
  • Base DN for users — базовое DN (Distinguished Name) для пользователей (пример: cn=Users,dc=myCorp,dc=com),
  • Base DN for groups — базовое DN для групп (например,  cn=Groups,dc=myCorp,dc=com),
  • Domain name — имя домена,
  • Domain alias — псевдо домена,
  • User name – имя пользователя (ID пользователя домена с минимум на чтение привилегиями к базовому DN для пользователей и групп; может быть в формате UPN (user@domain.com), NetBIOS (DOMAIN\user), DN (cn=user,cn=Users,dc=domain,dc=com)),
  • Password – пароль,
  • Connect to – домен-контроллер, к которому должны подключиться,
  • Primary Server URL – первичный LDAP-сервер домен-контроллера для домена (имя хоста или ІР-адрес, например, ldap://hostname_or_IPaddress:port или ldaps://hostname_or_IPaddress:port, 389 порт в первом случае и 636, обычно, для второго),
  • Secondary server URL – адрес вторичного домен-контроллера LDAP-сервера, которая используется, когда первичный не доступен,
  • Certificates (for LDAPS) – здесь можно нажать на Browse, чтобы выбрать сертификат, что был экспортирован из домен-контроллера, указанного в LDAPS URL, если хотим использовать LDAPS с нашим Active Directory LDAP Server или источником идентификации OpenLDAP Server.

А для Active Directory (Integrated Windows Authentication):

  • Domain name – FQDN имени домена (например, com – не ІР-адрес!). Должен быть разрешимым с DNS системой vCenter Server,
  • Use machine account – ставим галочку, чтобы использовать локальный аккаунт машины как SPN (если не планируем переименовывать машину в будущем – другие опции пропадут автоматически, задаем в таком случае только имя домена),

Use Service Principal Name (SPN) – выбираем эту опцию, если машина потом будет иметь другое имя. При этом придется ввести дальше Service Principal Name (SPN) и User Principal Name (UPN) с паролем. SPN помогает Kerberos идентифицировать сервис Active Directory. Включаем домен в имя, например, STS/example.com.

vCenter Server Identity Provider Federation

Когда мы приступаем к настройке vCenter Server Identity Provider Federation, то есть к интеграции AD FS с нашим vCenter Server, мы идем по такому плану:

А именно (с разбивкой по зонам ответственности):

  1. Администратор AD FS настраивает AD FS OAuth Application для vCenter Server;
  2. Администратор vCenter Server заходит на vCenter Server через клиент vSphere и добавляет провайдер идентификации (как именно – см. выше алгоритм) и информацию о домене Active Directory;
  3. Администратор vCenter Server настраивает разрешения авторизации в vCenter Server для пользователей AD FS;
  4. AD FS Provider запрашивает VcIdentityProviders API, чтобы получить информацию о подключении LDAP для источника Active Directory и ищет Active Directory для предоставленных пользователей и групп для завершения конфигурации авторизации.

Перед, собственно, настройкой, необходимо, чтобы был развернут AD FS for Windows Server 2016 или более свежий и подключен к Active Directory, у AD FS должна быть создана Application Group для vCenter Server (см. КБ), и группа администраторов vCenter Server в AD FS, содержащая пользователей с привилегиями администратора и к vCenter Server тоже. И, наконец, нам нужно добавить сертификат сервера AD FS (или CA, или промежуточный), к Trusted Root Certificates Store. Быстренько расскажем, как сделать последнее, перед тем, как перейти непосредственно к интеграции.

Для этого заходим в клиенте vSphere на vCenter Server, и далее – в Administration > Certificates > Certificate Management, рядом с Trusted Root Certificates кликаем на Add, ищем нужный корневой сертификат AD FS и жмем Add. Теперь этот сертификат можно будет увидеть в панели под Trusted Root Certificates.

А теперь выбираем в меню Home – Administration и под Single Sign On кликаем на Configuration. Далее:

  1. На вкладке Identity Provider получаем Redirect URI, кликнув на информационную иконку «i» рядом с ссылкой Change identity provider – во всплывающем баннере покажутся два Redirect URI. Копируем оба в файл или просто записываем, и закрываем баннер;
  2. Создаем конфигурацию OpenID Connect в AD FS и настраиваем ее для vCenter Server (как это сделать рассказывается здесь);
  3. Создаем провайдер идентификации на vCenter Server. Возвращаемся на вкладку Identity Provider, кликаем на ссылку Change identity provider – появится помощник Configure Main Identity Provider. Выбираем в нем Microsoft ADFS и кликаем Next, вводим в текстовых полях информацию об идентификаторе клиента, Shared Secret, адрес OpenID сервера AD FS, опять Next. Вводим информацию о пользователе и группе для подключения Active Directory over LDAP для поиска пользователей и групп (см. подраздел выше о LDAP), жмем Next, просматриваем информацию и окончательно жмем на Finish, чтобы завершить работу с этим помощником;
  4. Возвращаемся в Home-меню – выбираем Administration и под Single Sign On кликаем на Users and Groups;
  5. Настраиваем членство в группе vCenter Server для AD FS авторизации. Кликаем на вкладку Groups, далее – на группу Administrators и на Add Members. Выбираем домен из выпадающего меню, в текстовом поле под ним вводим первые символы группы AD FS, которую хотим добавить – появится раскрывающаяся подсказка, из которой выбираем нужную группу и кликаем на Save.

Окончательно осталось проверить, совершается ли вход в vCenter Server пользователем Active Directory.

Управление пользователями, группами и политиками

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

Политики vCenter Single Sign-On

Политики vCenter Single Sign-On применяют правила безопасности для локальных аккаунтов и токенов, в целом. Можно просматривать и редактировать дефолтные политики по паролированию, блокировке и токенах.

Редактирование политики паролирования (определения формата пароля и его истечения – по дефолту, это 90 дней, — применяются только к пользователям в домене vCenter Single Sign-On — vsphere.local):

  1. Заходим на vCenter Server в клиенте vSphere под пользователем с правами администратора vCenter Single Sign-On;
  2. Проходим из меню Home в Administration и далее под Single Sign On – на Configuration;
  3. Проходим на вкладку Local Accounts и кликаем на Edit по строке Password Policy;
  4. Редактируем желаемым образом опции Description (описание), Maximum lifetime (кол-во дней существования до смены, значение «0» — никогда не истечет, значение 999999999 — максимальное), Restrict reuse (кол-во предыдущих паролей, которые нельзя использовать снова – если введем, например, 6, последние шесть паролей нельзя считать текущими), Maximum length, Minimum length, Character requirements (минимальное количество разных типов символов, можно указать кол-во по каждому типу – спецсимволы, алфавит, большие буквы, маленькие буквы, цифры, Identical Adjacent);
  5. Кликаем на Save.

Редактирование политики блокировки (заблокировать аккаунт через определенное количество сделанных пользователем неудачных попыток ввести пароль – потом автоматически разблокируется при определенных обстоятельствах – это тоже настраивается):

  1. Проходим на ту же вкладку Local Accounts (см. выше по паролям) и кликаем на Edit по строке Lockout Policy (чтобы его увидеть, скроллим вниз);
  2. Редактируем параметры: Description (описание), Maximum number of failed login attempts (кол-во неправильных попыток введения пароля до блокировки), Time interval between failures (время, через которое фейл вызовет блок), Unlock time (время, которое аккаунт должен оставаться заблокированным до автоматической разблокировки; если ввести 0, то разблокировать можно будет только вручную администратору);
  3. Кликаем на Save.

Редактирование политики токенов (указываются свойства токенов, например, временная толерантность, количество обновлений):

  1. На той же вкладке Local Accounts (см. выше, как к ней добраться) кликаем Editпо строке Token Trustworthiness;
  2. Редактируем параметры, а именно: Clock Tolerance (разница во времени, которую толерирует vCenter Single Sign-On, между клиентскими часами и часами домен-контроллера, если указанное значение будет превышено, vCenter Single Sign-On будет считать токен невалидным), Maximum Token Renewal Count (максимальное количество разрешенных обновлений токена – при превышении указанного будет требоваться новый токен безопасности), Maximum Token Delegation Count (токены собственника ключа можно делегировать службам в vSphere; значение указывает, сколько раз можно делегировать один токен), Maximum Bearer Token Lifetime (продолжительность жизни токена-носителя до того, как токен нужно будет выпустить повторно), Maximum Holder-of-Key Token Lifetime (время жизни токена собственника ключа до того, как он будет обозначен недействительным);
  3. Кликаем на Save.
Пользователи и группы в vCenter Single Sign-On

Для всех перечисленных ниже операций нам, сначала, понадобится выбрать в меню Home – Administration и под Single Sign On кликнуть на Users and Groups, а далее, чтобы…

Добавить пользователей vCenter Single Sign-On:

  1. Если в панели текущий выбранный домен не vsphere.local, то из выпадающего меню перевыбираем нужный (к другим доменам пользователей добавлять запрещено!);
  2. На вкладке Users кликаем на Add;
  3. Вводим имя и пароль нового пользователя (максимальная длина имени – 300 знаков);
  4. Опционально, вводим фамилию и имя, электронный адрес и описание пользователя;
  5. Кликаем на Add.

Активировать/деактивировать пользователей vCenter Single Sign-On:

  1. Выбираем нужное имя в списке и кликаем на More;
  2. Если нужно деактивировать, выбираем Disable, если наоборот – Enable;
  3. Жмем ОК.

Удалить пользователя vCenter Single Sign-On:

  1. На вкладке Users выбираем домен vsphere.local из выпадающего меню;
  2. Выбираем пользователя из списка;
  3. Кликаем на Delete, ждем выполнения;
  4. Жмем Remove.

Отредактировать пользователя vCenter Single Sign-On:

  1. На вкладке Users выбираем нужного пользователя и жмем Edit;
  2. Меняем настройки, как необходимо (имя поменять нельзя!);
  3. Кликаем на Save.

Добавить группу vCenter Single Sign-On:

  1. На вкладке Groups кликаем на Add;
  2. Вводим имя (максимально 300 знаков) и описание группы;
  3. Из выпадающего меню Add Members выбираем источник идентификации, что содержит членов, которых нужно добавить к группе. Если внешний провайдер идентификации настроен как AD FS, его домен также будет доступен в этом выпадающем меню;
  4. Вводим термин для поиска;
  5. Выбираем члена – можно более одного;
  6. Кликаем на Add.

Добавить членов к группе vCenter Single Sign-On:

  1. На вкладке Groupsкликаем на нужную группу;
  2. Из выпадающего меню Add Members выбираем источник идентификации, что содержит членов, которых хотим добавить к группе (при настроенном AD FS его домен также будет в этом выпадающем меню);
  3. Вводим термин для поиска;
  4. Выбираем член (можно более одного);
  5. Кликаем на Save.

Удалить членов из группы vCenter Single Sign-On (удаляется из группы, но не из системы!):

  1. На вкладке Groups кликаем на нужную группу;
  2. В списке ее членов выбираем искомого пользователя и кликаем на иконку «вертикальных точек»;
  3. Выбираем Remove Member;
  4. Жмем на Remove.

Двухфакторная идентификация

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

Для нее нужно будет подсоединить кард-ридер под пластиковые карточки с интегрированным чипом (например, Common Access Card (CAC)) к компьютеру. Обычно, способные на такое машины уже имеют предварительно проинсталлированные драйверы, что управляют смарт-картами. Сам же процесс входа при этом выглядит так:

  1. Пользователь вставляет смарт-карту в ридер, браузер считывает сертификаты на карте;
  2. Браузер предлагает пользователю выбрать сертификат, а затем – ввести PIN для него;
  3. vCenter Single Sign-On проверяет, знает ли об этом сертификате со смарт-карты, а потом – не тли отмены насчет него;
  4. Если все хорошо, пользователь аутентифицируется и может выполнять свои задачи, для которых у него есть разрешения.

Чтобы все это заработало, сделаем некоторые настройки. Сначала сконфигурируем vCenter Server, чтобы запрашивал клиентские сертификаты (будет использовать порт 3128 – устанавливается и открывается автоматически на vCenter Server):

  1. Заходим в оболочку vCenter Server как root;
  2. Создаем доверенное хранилище клиентских СА на vCenter Server, используя точный путь и PEM-имя (/usr/lib/vmware-sso/vmware-sts/conf/clienttrustCA.pem): переходим в директорию /usr/lib/vmware-sso/:

cd /usr/lib/vmware-sso/

Создаем хранилище доверенных клиентских СА:

openssl x509 -inform PEM -in xyzCompanySmartCardSigningCA.cer > /usr/lib/vmware-sso/vmware-sts/conf/clienttrustCA.pem

Результатом будет создание файла «clienttrustCA.pem» из доверенного подписанного сертификата xyzCompanySmartCardSigningCA.cer. Если запустим эту команду еще раз с «>>», сможем добавить дополнительный сертификат;

  1. Валидируем, содержит ли контент файла clienttrustCA.pem доверенные СА, которые подписали сертификаты смарт-карты, командой:

keytool -printcert -file /usr/lib/vmware-sso/vmware-sts/conf/clienttrustCA.pem | grep -i «owner\|sha1\|issuer:\|valid»

  1. Проверяем, отвечают ли имена СА — Smart Card User Certificate Chain, командой:

sso-config.sh -get_authn_policy -t vsphere.local | grep trusted

  1. Перезапускаем сервис STS:

service-control —restart sts

Далее должны активировать конфигурацию смарт-карты и настроить проверку аннулирования сертификата. Активировать аутентификацию смарт-картой можно как с помощью vSphere Client, так и CLI. В обоих случаях предварительно нужно убедиться, что у нас установлен корпоративный Public Key Infrastructure (PKI) и User Principal Name (UPN) отвечает аккаунту Active Directory в расширении Subject Alternative Name (SAN), а сам сертификат указывает Client Authentication в поле Application Policy или Extended Key Usage или браузер не показывает сертификат. Далее получаем сертификаты и копируем их в папку, которую видит утилита sso-config, при помощи консоли vCenter Server или напрямую через SSH, деактивировав оболочку:

shell

chsh -s «/bin/bash» root

csh -s «bin/appliance/sh» root

И воспользовавшись WinSCP или похожей утилитой, копируем сертификаты в директорию /usr/lib/vmware-sso/vmware-sts/conf на vCenter Server. После этого, с клиентом vSphere:

  1. Заходим на vCenter Server с привилегиями администратора;
  2. Проходим из меню Home в Administration и под Single Sign On кликаем на Configuration;
  3. На вкладке Identity Provider кликаем на Smart Card Authentication и на Edit;
  4. Выбираем, снимаем ли выборы с методов аутентификации, после чего жмем на Save – появится Trusted CA certificates;
  5. На вкладке Trusted CA certificates кликаем на Add и на Browse;
  6. Выбираем все сертификаты из доверенных СА, после чего окончательно жмем на Add.

Если отдаем предпочтение командной строке, активируем аутентификацию смарт-картой:

sso-config.sh -set_authn_policy -certAuthn true -cacerts first_trusted_cert.cer,second_trusted_cert.cer  -t tenant

Если у нас несколько сертификатов, отделяем их в команде запятыми, но не пробелами!

Чтобы активировать или деактивировать другие методы аутентификации:

sso-config.sh -set_authn_policy -pwdAuthn false -t vsphere.local

sso-config.sh -set_authn_policy -winAuthn false -t vsphere.local

sso-config.sh -set_authn_policy -securIDAuthn false -t vsphere.local

Опционально, можем установить список разрешений по политикам сертификатов:

sso-config.sh -set_authn_policy -certPolicies policies

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

Опционально, можем включить и настроить проверку отмены при помощи OCSP:

sso-config.sh  -set_authn_policy -t tenantName  -useOcsp true

Опционально, можем вывести конфигурационную информацию:

sso-config.sh -get_authn_policy -t tenantName

И, наконец, нам нужно установить политики отмены для аутентификации смарт-картой. Для этого:

  1. Из меню Home выбираем Administration и под Single Sign On кликаем на Configuration;
  2. На вкладке Identity Provider кликаем на Smart Card Authentication;
  3. Кликаем на Certificate revocation – Edit, чтобы активировать или деактивировать проверку на отмену.

Если политики сертификатов действуют в нашей среде, можем добавить политику в панели Certificate policies.

Лицензирование в vSphere

Сравнение функционала существующих на данный момент лицензий vSphere можно найти здесь.

Немного о сервисе лицензирования мы вспоминали в подразделе «Сервис лицензирования» статьи «Инсталляция vSphere 8.0 с нуля». Давайте это обговорим более подробно.

vSphere License Service работает на vCenter и предлагает следующие функции:

  • Предоставление централизованного управления лицензиями;
  • Содержание инвентаря лицензий;
  • Управление назначением лицензий продуктам, интегрированным с vSphere. В том числе ESXi-хостам, системам vCenter и кластерам с активированным vSAN.

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

Создание новой лицензии

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

  1. Проходим в Menu > Administration;
  2. Раскрываем Licensing и кликаем на Licenses;
  3. На вкладке Licenses кликаем на Add New Licenses;
  4. На странице Enter licenses keys вводим по одному ключу (25-символьная строка букв и цифр в формате XXXXX-XXXXX-XXXXX-XXXXX-XXXXX) на каждую строку и кликаем Next;
  5. На странице Edit license names переназываем новые лицензии, как хотим, и жмем Next;
  6. На странице Ready to complete просматриваем настройки и кликаем на Finish.

Добавление лицензионных ключей к vCenter

Когда мы впервые ставим vCenter, он по умолчанию начинает работать с 60-дневным ознакомительным периодом. До его окончания мы должны назначить лицензию нашему vCenter (25-значный ключ).

Важно! На протяжении evaluation-режима лицензии ПО является полностью функциональным и все функции доступны в полном объеме. По его окончанию вы не сможете в полном объеме пользоваться функционалом vCenter и ESXi, в частности, включать или перезапускать ВМ, а все хосты будут отключены от системы vCenter.

Для этого в главном меню vSphere Client выбираем Administration > Licenses – откроется первая вкладка Licenses, где жмем на ADD и в новом окне вводим все данные согласно подсказок мини-помощника:

Просматривать информацию о лицензии можно по:

  • Продукту (лицензия на использование программного компонента или функции vSphere. Пример: «vSphere Enterprise Plus»);
  • Лицензионному ключу (серийный номер, что соответствует продукту);
  • Объекту (компоненту, которому назначено лицензию на продукт. Чтобы объект мог легально запускать определенное ПО, он должен иметь лицензию).

Назначение лицензии компоненту vSphere

Определенному объекту можно назначить лицензию, если в клиенте vSphere под Administration > Licenses пройти на вкладку Asset – увидим несколько смысловых групп компонентов. Например, нам нужно уже существующий лицензионный ключ назначить нашему инстансу vCenter. Для этого кликаем на VCENTER SERVER SYSTEMS – откроется табличка соответствующих объектов, ставим галочку на нужный и кликаем выше таблички на ASSIGN LICENSE. Откроется окно, в котором можно выбрать либо уже существующую лицензию, либо добавить новую:

Назначение лицензии нескольким активам

Активы в vSphere, как мы знаем, это, в целом, наши системы vCenter Server, ESXi-хосты, кластеры vSAN, Supervisor и другие интегрированные со «сферой» продукты. Иногда очень тяжело работать с лицензированием каждого по отдельности, и тогда пригождается функция пакетного назначения лицензий нескольким активам сразу.

Для этого:

  1. Проходим в Menu> Administration;
  2. Раскрываем Licensing и кликаем на Licenses;
  3. Выбираем вкладку Assets и кликаем на вкладку vCenter Server systems, Hosts, vSAN Clusters, Supervisor Clusters илиSolutions;
  4. Выбираем актив для лицензирования (клик с Shift для выбора нескольких сразу);
  5. Жмем на Assign License;
  6. В диалоговом окне Assign License выбираем задачу: либо Select an existing license (выбрать лицензию из списка и кликнуть ОК), либо Select a newly created license (если то, что мы делали выше в подразделе «Создание новой лицензии», пропустили – появится окно создания новой лицензии, заполняем его соответствующим образом и снова жмем на ОК).

Удаление лицензий

Все не назначенные лицензии (те, что не используются из-за деления, объединения или обновления в Customer Connect) по best practice необходимо своевременно удалять из инвентаря. Для этого проходим на нашу вкладку Licenses, как рассказывалось выше, пользуемся фильтрами для удобства выбора не назначенных лицензий (кликаем на иконку фильтра в колонке State – покажется текстовое поле, где выбираем unassigned), выбираем конкретную лицензию, или с Ctrl+A удаляем все, и кликаем на Remove Licenses. Появится сообщение подтверждения, в котором жмем на Yes.

Просмотр функций лицензии

Кроме операций по добавлению и назначению лицензий в клиенте vSphere, можно управлять ими и соответствующими функциями прямо из инвентаря vCenter. Для этого встаем на нужный объект в боковом правом меню, в левой части экрана проходим на вкладку Configure и под System кликаем на Licensing:

Соответствующая панель продемонстрирует тип лицензии, срок ее окончания и доступные функции.

Также можно экспортировать информацию по лицензиям. Для этого выбираем объект для экспорта (со вкладки Licenses, Products или Assets, в зависимости от того, что именно хотим экспортировать – сами лицензии, продукт или актив в виде инстансов vCenter Server, хостов, кластеров или решений, чье лицензирование нас интересует). Если ничего не выбрать – экспортируется абсолютно все. Далее кликаем на Export и выбираем Selected Rows или All Rows, в зависимости от предыдущего выбора, или вообще ничего не указываем, если не выбрали до этого никаких объектов. Информацию будет выгружено в файл CSV, который система предложит нам где-то сохранить после завершения его подготовки.

Лицензирование ESXi-хостов в VMware Host Client

ESXi-хосты лицензируются лицензиями vSphere, и каждая из них обладает определенной емкостью, которая может применяться к нескольким физическим CPU на хостах ESXi. Когда лицензия назначается хосту, объем потребляемой емкости определяется количеством физических CPU на хосте и количеством ядер на каждом физическом CPU. Как и в случае vCenter, имеем evaluation-период, после которого (или раньше) лицензию нужно назначить. Также это обязательно нужно предпринять после обновления наших хостов, если перешли на новую мажорную версию.

Просмотреть доступные лицензии с датами истечения их срока, лицензионным ключом и разными функциями, а также доступными продуктами и объектами можно, если кликнуть на Manage в инвентаре VMware Host Client, а далее – на Licensing.

Назначение лицензии хосту

Через VMware Host Client можно назначить существующий или новый лицензионный ключ ESXi-хосту.

Важно! Для работы с лицензиями в VMware Host Client необходимы привилегии Global.Licenses.

Для этого:

  1. Кликаем на Manage в инвентаре и на Licensing;
  2. Кликаем на Assign license, вводим лицензионный ключ в формате «XXXXX-XXXXX-XXXXX-XXXXX-XXXXX» и жмем Check license;
  3. Кликаем на Assign license, чтобы сохранить изменения.

Удаление лицензии с ESXi-хоста

Чтобы придерживаться соответствия лицензионной модели продуктов, которые используются с vSphere, хорошей практикой считается удаление не назначенных лицензий из инвентаря. Для этого кликаем на Manage в инвентаре VMware Host Client и на Licensing, выбираем нужное и кликаем на Remove license, а затем – на ОК.

Управление ресурсами vSphere

Насчет виртуализации ресурсов много было разъяснено в материале «Инсталляция vSphere 8.0 с нуля». Теперь разберемся на практике, как ими управлять в нашей среде, и какие существуют техники контроля над ними и оптимизации.

Технологии улучшения работы памяти, CPU и дисков

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

Чтобы улучшить использование памяти, хост ESXi высвобождает память у неактивных ВМ для распределения между теми, которые нуждаются в большем. Ее можно заменить на файл подкачки «.vswp», а накладные расходы памяти – на файл подкачки «vmx-*.vswp»:

ESXi-хост использует следующие техники переиспользования памяти во избежание этих проблем (работает с ними VMkernel):

  • Прозрачный общий доступ к страницам памяти. При этом убираются лишние копии страниц, так как страницы с идентичным содержимым кладутся на хранение лишь единожды.
  • Балунинг (Ballooning). Используется драйвер balloon VMware Tools для снятия выделения памяти с ВМ. Название очень красноречиво: раздутие используется ESXi-хостом для уменьшения требований к памяти ВМ, что приблизилась к целевой память при довольно малом остатке памяти хоста. При этом модуль vmmemctl, который устанавливается в гостевую ОС как часть VMware Tools, принуждает ОС отказаться от страниц памяти, которые считаются наименее ценными. Балунинг обеспечивает производительность, почти такую же, как и нативной системы при аналогичных ограничениях в памяти. Для его использования система должна быть настроена с достаточным пространством свопа.
  • Сжатие памяти. Уменьшает количество страниц памяти, которые необходимо выкачать. Поскольку задержка декомпрессии намного меньшая, чем задержка подкачки, сжатие имеет значительно меньшее влияние на производительность, чем замена страниц. Фактически, происходит переход к хранению памяти в сжатом формате.
  • SSD-свопинг на уровне хоста. Переход к кешу хоста – это дополнительная техника восстановления памяти, что использует локальное флеш-хранилище для кеширования страниц памяти ВМ. Используя локальное флеш-хранилище машина избегает задержки, связанной с сетью хранилища, которой можно воспользоваться, если изменены страницы памяти на виртуальный своп-файл (.vswp).
  • Подкачка памяти ВМ на диск. Регулярная подкачка памяти на уровне хоста срабатывает, когда нагрузка на память становится сильной и гипервизор должен заменить ее страницы на диск, тогда он переключается на кеш подкачки хоста, а не на файл «.vswp». Когда на хосте заканчивается место в кеше, кеш-память ВМ переносится в обычный файл «.vswp» ВМ. Для каждого хоста нужно настраивать собственный кеш свопа. Это, так сказать, последний бастион, ведь производительность этой техники крайне низкая.

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

Первой из них стоит вспомнить мульти-ядерные ВМ. Дело в том, что количество vCPU, настроенное для ВМ, зависит не только от физической конфигурации хоста, а и от гостевой ОС, нужд и ограничений масштабирования приложений и конкретного способа использования самой ВМ. У VMkernel есть планировщик CPU, который динамически планирует vCPU на физических CPU системы хоста. Он учитывает топологию сокет-ядро-поток во время принятия своих решений. Процессоры Intel и AMD комбинируют несколько ядер процессора в одну интегральную схему, которая называется сокетом. Сокет – это отдельный пакет с одним или несколькими физическими CPU. Каждое ядро имеет один или более логических CPU (LCPU) или потоков. С LCPU ядро может планировать один поток выполнения. Когда vCPU с одно-vCPU или мульти-vCPU ВМ должен быть поставлен расписание, VMkernel сопоставляет vCPU с доступным логическим процессором:

Вторая интересная технология – Hyperthreading. С гиперпотоковостью ядро может выполнять два потока или набор инструкций одновременно. Она дает больше логических CPU, на которых могут быть запланированы vCPU, и активирована по умолчанию, если система хоста поддерживает эту технологию, в BIOS (обратитесь к вендору hardware, поддерживается ли – у некоторых этот параметр называется Logical Processor, у других — Enable Hyperthreading), и явно включена на хосте (убедиться можно в клиенте vSphere, вкладка Summary, где  нужно выбрать CPUs под Hardware):

Недостатком гиперпотоковости является то, что она не удваивает мощность ядра, потому, что оба потока выполнения требуют одинаковых ресурсов на чипы одновременно, один из них должен подождать. Но все равно в системах с ней наблюдается увеличение производительности. Хост с гиперпотоковостью ведет себя почти так же, как и стандартная система. Логические процессоры на одном ядре пронумерованы по порядку: на первом ядре логические процессоры 0 и 1, на втором – 2 и 3 и т. д.

Балансировка нагрузки CPU. VMkernel балансирует процессорное время, чтобы гарантировать плавное распределение нагрузки между его ядрами в системе. Планировщик CPU может использовать каждый логический процессор независимо от использования ВМ, обеспечивая возможности, подобные традиционным симметричным многопроцессорным системам (SMP). Каждые 2-40мс (в зависимости от топологии сокет-ядро-поток) VMkernel пытается перенести vCPU с одного логического процессора на другой, чтобы сохранить баланс нагрузки. Он делает все возможное для планирования ВМ с несколькими vCPU на двух разных ядрах, а не на двух логических процессорах на одном ядре. Но при необходимости, VMkernel может сопоставить два vCPU с одной и той же машины к потокам на том же ядре.

Если логический процессор не работает, он переходит в состояние остановки (halted). Это действие освобождает ресурсы выполнения, и ВМ, которая работает на другом логическом процессоре на том же ядре, может пользоваться всеми ресурсами выполнения ядра. Поскольку планировщик VMkernel учитывает это время остановки, ВМ, что работает с полными ресурсами ядра, имеет стоимость, более дорогую, чем та, что работает на половине. Такой подход к управлению процессором гарантирует, что сервер не нарушит правила распределения ресурсов ESXi:

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

Контроль над ресурсами: резервирование, ограничение и совместное использование

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

  • Резервирование. Определение гарантированного минимального выделения для ВМ;
  • Лимитирование. Определение верхней границы CPU и памяти, которые могут быть выделены ВМ;
  • Совместное пользование. Определение относительного приоритета или важности доступа ВМ к данному ресурсу.

Все это конфигурируется в настройках ВМ, вкладка Virtual Hardware:

Просмотреть параметры выделения ресурсов ВМ (резервирование, ограничение и совместное использование) можно для всех ВМ в кластере на вкладке Monitor под Resource Allocation бокового меню рабочей части, выбрав интересный для вас именно сейчас конкретный ресурс:

Резервирование ресурсов ВМ

Резервирование выделения RAM, гарантирует, что эта память никогда не подвергнется свопу или балунингу. Если ESXi-хост не имеет достаточно незарезервированной памяти для поддержки ВМ с резервированием, ВМ не включится:

Кроме того ему необходим и некоторый объем служебной памяти для включения машин. Например, ВМ с 4ГБ RAM и двумя vCPU запросит 53МБ дополнительной памяти. Резервирование рекомендуется настраивать для критичных ВМ, для которых крайне важно поддерживать наивысший уровень производительности.

Замечание. Во время резервирования памяти можно поставить галочку в Reserve all guest memory (All locked), чтобы вся память ВМ была зарезервирована, даже если будет изменен общий объем памяти для машины. Резервирование памяти немедленно регулируется, когда изменяется конфигурация памяти ВМ.

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

Ограничение ресурсов ВМ

При ограничении RAM ВМ никогда не будут употреблять больше физической памяти, чем определено ограничением (то же самое касаемо ограничения по CPU). Если гостевая ОС будет пытаться употребить больше оперативной памяти, чем определено ограничением, ВМ воспользуются механизмом подкачки (.vswp).

При ограничении CPU его потоки помещаются в состояние готовности, если гостевая ОС пытается запланировать их быстрее, чем позволяет ограничение:

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

Использование ограничений имеет такие преимущества и недостатки:

  • Назначение лимитов полезно, когда вы начинаете с нескольких ВМ и хотите управлять ожиданиями пользователей. Чем больше добавляется машин, тем хуже становится производительность, и тогда можно имитировать наличие меньшего количества ВМ, указав ограничения;
  • При ограничение можно утратить неактивные ресурсы. Система не позволит ВМ воспользоваться большим их количеством, чем указано в лимите, даже если она используется совсем не полностью и в наличии неактивные ресурсы.

Совместное пользование выделенными ресурсами

Совместное пользование выделенными ресурсами определяет соответствующую важность ВМ. Если у машины вдвое больше общих ресурсов, чем у другой, она будет иметь право употреблять вдвое больше этого ресурса, когда обе за него конкурируют. Однако, если ESXi-хост терпит конкуренцию за ресурс, значения совместного использования не применяются. Можно установить значение общего использования на высокий, нормальный или низкий уровень (high/normal/low):

Параметр Значение совместного использования CPU, на vCPU Значение совместного использования памяти, на МБ настроенной памяти ВМ
High 2 000 20
Normal 1 000 10
Low 500 5

Также можно выбрать специальную настройку, чтобы назначить определенное количество общих ресурсов для каждой ВМ. Параметры high/normal/low представляют значение совместного использования в соотношении 4:2:1. Пользовательское определение значения совместного использования назначает указанное число совместных использований (что выражает пропорциональный вес) каждой ВМ.

Управление аппаратным обеспечением ESXi-хоста при помощи VMware Host Client

При помощи VMware Host Client можно управлять PCI-устройствами и настраивать параметры управления питанием.

Политики управления питанием хоста

Список политик управления питанием CPU:

  • High Performance – не использовать никаких функций управления питанием,
  • Balanced (Default) – уменьшить употребление энергии с минимальным компромиссом для производительности,
  • Low Power – уменьшить употребление энергии с риском для минимальной производительности,
  • Custom – определяется пользователем (становится возможным задать желаемое в расширенных настройках).

Изменить политику управления питанием можно так:

  1. Кликаем на Manage в инвентаре VMware Host Client и на Hardware;
  2. Кликаем Power Management — Change policy – покажет доступные политики питания;
  3. Выбираем нужную политику и жмем ОК.

Изменение метки hardware в VMware Host Client

Можно изменить метку аппаратного обеспечения всех доступных устройств прохождения PCI на ВМ. Используются аппаратные метки, чтобы ограничить размещение ВМ указанными инстансами hardware. К ВМ можно добавить все доступные устройства с одинаковой меткой аппаратного обеспечения или с пустой.

Для этого:

  1. Кликаем на Manage в инвентаре VMware Host Client;
  2. На вкладке Hardware кликаем на Hardware label (должно быть активным для выбранного устройства) – появится диалоговое окно Edit Hardware Label;
  3. Редактируем метку и сохраняем настройку кнопкой Save.

Новая метка аппаратного обеспечения появится в соответствующей колонке.

Управление ресурсами CPU при помощи VMware Host Client

При подключении при помощи VMware Host Client к ESXi-хосту получаем доступ к ограниченному количеству опций управления ресурсами. Например, можно просматривать информацию о CPU (тип физических процессоров и количество логических), если кликнуть на хост в инвентаре VMware Host Client, раскрыть Hardware, а затем – CPU.

Также можно назначать ВМ указанному CPU (при выключенной ВМ!):

  1. ПКМ на ВМ в инвентаре VMware Host Client и выбираем Edit settings;
  2. Под Virtual Hardware раскрываемCPU;
  3. Под Scheduling Affinity выбираем affinity физического процессора для ВМ (используем дефис для обозначения диапазонов и разделяем значения запятыми);
  4. Кликаем на Save для сохранения изменений.

Остальные рекомендации по планированию, управлению и наблюдению за выделением и использованием ресурсов приведем ниже в разделе «Мониторинг…».

Настройка сети vSphere

Грамотная настройка сети ESXi позволяет виртуальным машинам общаться с другими машинами, как физическими, так и виртуальными. А кроме того VMkernel сможет эффективно оперировать удаленным управлением хостом и хранилищем на базе IP.

За подключение ВМ к физической сети, между машинами на одном хосте или на разных отвечают виртуальные свитчи. При этом обеспечивается поддержка служб VMkernel, в частности, миграция vSphere vMotion, iSCSI, NFS и доступ к management-сети. У каждого виртуального свитча выделяют несколько специфических типов подключений:

  • порты ВМ,
  • порты VMkernel (ІР-хранилища, миграции vMotion, vSphere Fault Tolerance, vSAN, vSphere Replication и management-сети ESXi),
  • порты аплинков.

Первые два типа существуют в порт-группах:

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

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

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

ESXi предоставляет поддержку VLAN путем назначения VLAN ID порт-группе и работает с 802.1Q VLAN-тегированием. Тегирование виртуального свитча – это одна из поддерживаемых политик тегирования:

  • Фреймы с ВМ тегируются как только выходят из виртуального свитча;
  • Тегированные фреймы приходят на виртуальный свитч и тегирование снимается до того, как они будут посланы на ВМ назначения – этим занимается VMkernel;
  • Минимальное воздействие на производительность благодаря ограничению широковещательного трафика подмножеством портов свитча.

При этом порты физических свитчей должны быть настроены как статические транк-порты. Транк-порт – это порт на физическом свитче Ethernet, настроенный на посылку и получение пакетов, отмеченных VLAN ID. На ВМ конфигурировать VLAN не нужно – она вообще не осознает, что подключена к VLAN:

Порты ВМ и VMkernel подключаются к внешнему миру через физические Ethernet-адаптеры, подсоединенные к портам аплинкам виртуальных свитчей.

Важно! Поскольку физические NIC назначаются на уровне виртуального свитча, все порты и порт-группы, определенные для конкретного свитча, должны пользоваться одинаковым аппаратным обеспечением.

Порт management-сети ESXi — это VMkernel-порт, который подключается к сети или удаленным сервисам, с vpxd на vCenter и VMware Host Client, включительно.

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

В vSphere используются два типа виртуальных свитчей:

  • vSphere Standard Switch,
  • vSphere Distributed Switch,

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

Standard Switch – это виртуальный свитч, настроенный для единственного хоста.

Distributed switch – виртуальный свитч, настроенный для всего дата-центра, который может присоединить к себе до 2 000 хостов, обеспечивая постоянство конфигурации. Однако, в этом случае требуется уровень лицензирования Enterprise Plus или хосты должны принадлежать кластеру vSAN. Он централизует администрирование виртуальной сети и упрощает администрирование дата-центра, в целом. Порты распределенного свитча статически назначаются vCenter и обеспечивают более гранулированный контроль над сетевой статистикой и политиками:

Работа со Standard Switch

Если в клиенте vSphere на вкладке Configure по выбранному элементу инвентаря выбрать Virtual Switches в блоке Networking бокового меню рабочего поля, можем увидеть конфигурацию стандартного свитча:

По дефолту, инсталляция ESXi создает порт-группу ВМ, названную VM Network, и порт-группу с именем Management Network, что содержит порт VMkernel для management-трафика. Мы можем создавать дополнительные порт-группы для ВМ и портов VMkernel. Например, порт-группу IP Storage, которая будет содержать порт VMkernel для доступа к хранилищу iSCSI.

Важно! Для максимизации безопасности и производительности необходимо удалить порт-группу виртуальной машины VM Network и держать сети ВМ и management раздельно на разных физических сетях или VLAN.

Добавление Standard Switch

Новый Standard Switch можно добавить к ESXi-хосту, или перенастроить существующий, пользуясь vSphere Client или VMware Host Client. Для этого:

  1. Выбираем в инвентаре нужный объект;
  2. В правой части интерфейса проходим на вкладку Configure;
  3. В боковом меню рабочего поля под Networking кликаем на Virtual Switches;
  4. Сверху жмем на функциональную надпись ADD NETWORKING – откроется мини-помощник, всеми пунктами которого проходим последовательно, задавая нужные настройки:

Соответственно, если необходимо отредактировать конфигурацию существующего свитча, жмем на EDIT.

Свойства VMkernel Adapter

Второй пункт бокового меню рабочего поля в Networking (на искомый элемент инвентаря – вкладка Configure) называется VMkernel adapters, и показывает информацию по интерфейсам VMkernel (его имя, свитч, на котором он расположен, IP-адрес и включенные сервисы):

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

  • vMotion – позволяет VMkernel адаптеру сообщать о себе как о сетевом подключении другому хосту, куда послан трафик vSphere vMotion;
  • Provisioning – обрабатывает данные, перетрансференные для клонирования, холодной миграции и миграции снепшота;
  • Fault Tolerance logging – активирует журналирование логов Fault Tolerance на хосте;
  • Management – активирует management-трафик для хоста и vCenter
  • vSphere Replication – обрабатывает исходящие данные репликации, посланные из источника ESXi-хоста на сервер vSphere Replication;
  • vSphere Replication NFC – обрабатывает входящие данные репликации на целевом сайте репликации;
  • vSAN – активирует vSAN-трафик на хосте;
  • vSphere Backup NFC – настройка порта VMkernel для связанного трафика бекапирования NFC;
  • NVMe over TCP — настройка порта VMkernel для связанного трафика хранилища NVMe по TCP. Трафик хранилища NVMe по TCP идет через VMkernel Adapter, когда включен адаптер NVMe over TCP;
  • NVMe over RDMA – настройка порта VMkernel для связанного трафика хранилища NVMe по RDMA. Трафик хранилища NVMe по RDMA идет через VMkernel Adapter, когда включен адаптер NVMe over RDMA.

Добавить нужные сервисы можно в соответствующем окошке редактированием адаптера:

Свойства физического адаптера

На панель Physical adapters можно попасть из клиента vSphere на той же вкладке Configure под Networking:

Она демонстрирует информацию о скорости, дуплексе и сетям.

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

Сетевые политики виртуального свитча

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

Тип виртуального свитча Дефолтная политика устанавливается на уровне… Перезапись дефолтной политики на уровне…
vSphere Standard Switch Стандартного свитча Порт-группы
vSphere Distributed Switch Distributed порт-группы Индивидуального порта

Политика сетевой безопасности обеспечивает защиту от подмены МАС-адреса и нежелательного сканирования портов. Политика шейпирования трафика полезна, когда нужно ограничить объем трафика к ВМ или группе ВМ. Политика тиминга и восстановления после отказа отвечает на следующие вопросы:

  • Как сетевой трафик ВМ и VMkernel адаптеров, подключенных к свитчу распределяется между физическими адаптерами?
  • Как следует перенаправлять трафик в случае сбоя адаптера?

Настройка политик безопасности

Политики безопасности можно определять и на уровне стандартного свитча, и на уровне порт-группы. Делается это в карточке искомого виртуального свитча (см. выше, как на него попасть), если нажать на «три точки» в ней – появится окно EDIT SETTINGS, пункт меню Security. Доступны такие настройки:

  • Promiscuous mode – разрешать или не разрешать всему трафику пересылаться, независимо от назначения;
  • MAC address changes – Принять или отбросить входящий трафик, когда МАС-адрес изменен гостем;
  • Forged transmits – Принять или отбросить исходящий трафик, когда МАС-адрес изменен гостем:

В большинстве случаев рекомендовано оставить дефолтное значение Reject. Но, например, в случае, когда нужно использовать приложение в ВМ, которое анализирует или снифит пакеты, такой как сетевую систему выявления вторжений, нужно выставить Promiscuous mode на Accept. Или когда ваши приложения меняют сопоставленные МАС-адреса, как, например, делают некоторые файерволы гостевых ОС, то MAC address changes и Forged transmits тоже нужно выставить на Accept.

Настройка политик шейпирования трафика

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

Параметры применяются к каждой виртуальной NIC на стандартном свитче. Если мы говорим о  стандартном свитче, шейпирование трафика контролирует только входящий трафик, что следует из ВМ к виртуальному свитчу и наружу на физическую сеть. Настраивается оно в той же карточке искомого виртуального свитча (см. выше, как на него попасть), если нажать на «три точки» в ней – появится окно EDIT SETTINGS, пункт меню Traffic shaping:

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

Настройка NIC-тиминга и поведения в случае отказа

Последний пункт настроек виртуального свитча — Teaming and Failover (карточка искомого виртуального свитча (см. выше, как на него попасть) — «три точки» – окно EDIT SETTINGS) – выглядит так:

NIC-тиминг увеличивает сетевую пропускную способность свитча и обеспечивает резервирование. В группу включаются два или более NIC.

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

Порядок восстановления после отказа (failover) определяет, какие линки активны во время обычных операций, а какие – в случае отказа. Можно настроить следующие адаптеры в списке порядка восстановления после отказа:

  • Active – NIC из этой группы будут использоваться каждый раз, когда NIC-подключение поднято и активно;
  • Standby — NIC из этой группы будут использоваться, если один из NIC упадет;
  • Unused – эти NIC не будут использоваться никогда. Помещаются в эту группу, чтобы зарезервировать их для чрезвычайной ситуации. Отсюда в любое время можно перенести в Active, при необходимости.
Настройка выявления и устранения сбоя сети

Сбой сети отслеживается и выявляется VMkernel (ошибки конфигурации не отслеживаются!). VMkernel осуществляет мониторинг состояния линков и выполняет проверку маяков (смотря что выбрано) с одно-секундными интервалами, чтобы убедиться, что сеть работает без перебоев. Настроить это поведение можно в упомянутом выше подразделе «Настройка NIC-тиминга и поведения в случае сбоя» пункте настроек виртуального свитча Teaming and failover в блоке Network failure detection, если выбрать Beacon probing (второй вариант):

Замечание. Проверка маяков состоит в отсылке пробного пакета (62 байта) на каждый физический NIC, являющийся членом группы. Такая техника выявляет проблемы, которые даже мониторинг статуса связи не способен сделать самостоятельно. Чтобы подобное зондирование на маяках сработало, необходима определенная топология сети. Проконсультируйтесь с вашим вендором свитча, чтобы узнать, поддерживается ли она в вашей среде. Больше почитать об этом можно в КБ.

Если VMkernel определит сетевой сбой, он оповестит физические свитчи про изменения в физическом размещении МАС-адреса (выставляется в Notify switchesYes/No). Вообще же, отметить здесь Yes является полезной практикой, ведь иначе ВМ будут страдать от больших задержек в случае восстановления после отказа операций vSphere vMotion.

Важно! Не делайте настройку Yes в Notify switches, если подключенные к порт-группе ВМ запускают Microsoft Network Load Balancing (NLB) в одноадресном режиме. Больше узнать об этом случае можно в КБ.

Имплементированный VMkernel порядок переключения при отказе опирается на параметры, которые можно настроить (см. скриншот выше):

  • Failback – определяется, как физический адаптер возвращается к активному дежурству после восстановления в случае сбоя (значение Yes/No). Если Yes – как только адаптер вернется к работе, он заменит адаптер в статусе ожидания (Standby), который занял его место в момент падения). Если No, адаптер после восстановления своей работоспособности не станет активным – только когда другой текущий адаптер упадет, он займет его место;
  • Load-balancing – рекомендуется употреблять Use explicit failover order.

Важно! Всегда используйте аплинк vmnic на самом верху списка активных адаптеров.

Работа с vSphere Distributed Switch

Распределенный свитч перемещает компоненты управления сетью на уровень дата-центра. Его архитектура состоит из уровня контроля и уровня ввода/вывода. Уровень контроля находится на vCenter и настраивает распределенные свитчи, распределенные порт-группы, распределенные порты, аплинки, NIC-тиминг в том числе. Он к тому же координирует миграцию портов и отвечает за настройку свитча. Уровень ввода/вывода (I/O) внедрен как скрытый виртуальный свитч в VMkernel каждого хоста ESXi, управляет устройствами ввода/вывода на хосте и отвечает за пересылку пакетов. vCenter контролирует создание этих скрытых виртуальных свитчей. Архитектура Distributed Switch:

Каждый распределенный свитч содержит распределенные порты. Можно подключать любую сетевую сущность, в частности ВМ или интерфейс VMkernel, к распределенному порту. vCenter хранит состояние распределенных портов в своей базе данных. Распределенная порт-группа позволяет логически группировать распределенные порты для упрощения настройки. Она указывает опции конфигурации портов для каждого своего члена на распределенном свитче. Порты также могут иметь собственную уникальную конфигурацию. Аплинки – это абстракция vmnics с множества хостов к единому распределенному свитчу. Для распределенного свитча они – то же, что и vmnic для стандартного. Две ВМ на разных хостах могут общаться между собой только, когда обе имеют аплинки в одном широковещательном домен.

Так же как и Standard Switch, Distributed Switches имеет VLAN-сегментацию и 802.1Q тегирование, поддерживает как IPv4, так и IPv6, есть функция NIC-тиминга и шейпирования исходящего трафика А вот список того, что Distributed Switches умеет, а стандартный – нет:

  • Шейпирование входящего трафика,
  • Бекапирование и восстановление конфигурации,
  • Приватные VLAN,
  • Link Aggregation Control Protocol,
  • Миграция vSphere vMotion состояния сети,
  • Network I/O Control,
  • Настройка политики по каждому порту,
  • Мониторинг состояния порта,
  • NetFlow,
  • Порт-мирроринг,
  • Поддержка NSX.

Конфигурацию распределенного свитча можно увидеть по дата-центру на вкладке Configure под Settings в пункте Topology:

Настройка протоколов выявления свитчей

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

  • CiscoDiscoveryProtocol (CDP) – для стандартных или распределенных свитчей vSphere, подсоединенных к физическим свитчам Cisco,
  • LinkLayerDiscoveryProtocol (LLDP) – нейтральный к вендору протокол только для распределенных свитчей.

Как видим, Standard switch может быть настроен на использование только CDP, а вот Distributed switch – или CDP, или LLDP.

Настройка CDP или LLDP производится в карточке распределенного свитча (см. скриншот предыдущего подраздела), если нажать на «три точки» вверху возле ACTIONSEdit Settings, на вкладке Advanced открывшегося окошка, в блоке Discovery protocol:

Там можно выбрать тип протокола (CDP/LLDP) и режимы действия:

  • Listen – (по дефолту) информация получается с физических свитчей (информация о виртуальном свитче не доступна администратору физического свитча),
  • Advertise – информация посылается на физические свитчи (наоборот, предоставляется информация о виртуальном свитче администратору физического, однако нет данных о физическом свитче),
  • Both – информация и получается, и посылается на физические свитчи.

Настройка распределенной порт-группы

Делается в карточке порт-группы (см. предпоследний скриншот, Topology), если нажать на «три точки» по ней.

Настройка Port Binding

Port Binding определяет, когда и как виртуальная NIC ВМ назначается порту виртуального свитча. Он настраивается на уровне распределенной порт-группы, в пункте бокового меню General, и доступны для выбора такие опции:

  • Static binding (дефолтная) – vCenter назначает постоянный порт для интерфейса VMkernel или ВМ;
  • Ephemeral – ESXi (не vCenter!) назначает порт ВМ. Назначенный порт меняется, когда машина перезагружается.

Также можно настроить варианты размещения порта для статической привязки:

  • Elastic (дефолтный) – когда все порты назначены, создается новый набор из восьми портов;
  • Fixed – никакие дополнительные порты не создаются, когда все порты назначены:

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

А вот если у нас временная привязка, порт создается и назначается, когда ВМ включена и ее NIC подключена. Соответственно, когда машина выключается, а NIC отсоединяется, порт удаляется. Временные порты полезны, когда vCenter не работает, а нужно изменить сетевые подключения ВМ. Но, падение vCenter не влияет на сетевой трафик, независимо от типа привязки. Поэтому Ephemeral-порты рекомендуется использовать только с целью восстановления, если нужно предоставить порты непосредственно на ESXi-хосте, обходя vCenter, и только в таком случае.

Настройка шейпирования трафика

Распределенные свитчи поддерживают шейпирование входящего и исходящего трафика. Эти настройки доступны в пункте Traffic shaping бокового меню конфигурации распределенной порт-группы:

Ingress (исходящему) трафику посвящен верхний блок рабочего поля настроек, а Egress (входящему) – нижний. Причем, функция шейпирования доступна для первого только для распределенных свитчей, а второго – и стандартных, и распределенных. В соответствующих блоках, как показано на скриншоте, можно включать или выключать функцию шейпирования и задавать среднюю и пиковую пропускную способность (Кбит/с), а также граничный размер пакета.

Настройка NIC-тимингу и поведения при переключении в случае отказа

В пункте меню Teaming and failover можно задавать метод балансировки нагрузок как нагрузки физической NIC, для чего в пункте Load balancing рабочего поля из выпадающего меню следует выбрать Route based on physical NIC load:

Этот метод поддерживается только распределенными свитчами и является рекомендованной политикой для распределенных порт-групп. Балансировка нагрузки на нагрузке физической NIC гарантирует оптимизацию емкости этой физической NIC в группе NIC. Функция работает так:

  • Потоки вводов/выводов перемещаются между аплинками;
  • Поток перемещается только тогда, когда среднее использование посылки или получения аплинка достигает 75% емкости на протяжении 30-секундного периода.

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

Важно! Недостатком выбора Route based on physical NIC load считается то, что пропускная способность, доступная ВМ, лимитирована аплинками, подключенными к распределенному свитчу.

Политика фильтрации и маркировки трафика

Политика фильтрации и маркировки трафика для vSphere distributed switch защищает виртуальную сеть от нежелательного трафика и атак, помогает управлять сетевым трафиком с SLA-целями. Функции этой политики:

  • Разрешение или запрет указанных типов трафика;
  • Применение тегов QoS для маркировки определенного типа трафика.

Это такой себе эквивалент функции списка контроля доступа на физических свитчах.

Для ее реализации нужно создать правила сетевого трафика, связанного с ВМ или физическими адаптерами:

Согласно иллюстрации, в Action можем выбирать Allow/Drop/Tag, а в поле Traffic directionIngress, Egress или Ingress/Egress. Ниже, в блоке Traffic Qualifiers, переключаемся нужными вкладками и задаем конкретику трафика, например, вот так:

Маркировка трафика не менее важна, чем возможность разрешить или запретить определенный его тип. Можно, например, назначить теги приоритета для повышенных нужд сети в пропускной способности, снижения задержки, чтобы вообще не сбрасывались ее пакеты при конкуренции. На L2 маркируем Class of Service (CoS), а на L3 — Differentiated Serviced Code Point (DSCP).

Использование Network I/O Control в распределенных свитчах

Network I/O Control – инструмент для выделения пропускной способности для разнообразных типов системного трафика и ВМ, бизнес-критических приложений. Интересная методика, которая помогает улучшить производительность, в целом:

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

Посмотреть, как именно используется функция Network I/O Control для системного трафика (ВМ, Management, vSphere vMotion, NFS, vSphere Fault Tolerance, iSCSI, vSphere Replication, vSAN, vSphere Data Protection) можно здесь (по дата-центру вкладка Configure, под Resource Allocation — System traffic):

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

  • Low (25),
  • Normal (50),
  • High (100),
  • Custom (пользовательское значение от 1 до 100).

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

Резервирование пропускной способности – это минимальная пропускная способность в Мбит/с, что гарантированно выделяется одному физическому адаптеру. Зарезервировать можно не более 75% пропускной способности физического сетевого адаптера:

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

Сетевые ресурс-пулы

Сетевой ресурс-пул представляет часть агрегированной пропускной способности, которая была зарезервирована для системного трафика ВМ на всех физических адаптерах, подключенных к распределенному свитчу. По умолчанию, распределенные порт-группы назначены сетевому ресурс-пулу, названном дефолтным, где никаких квот не настроено: *264*

Чтобы использовать Network I/O Control для включения пропускной способности для ВМ, нужно настроить системный трафик ВМ. Резервирование пропускной способности для ВМ также используется в admission control: когда мы включаем ВМ, admission control проверяет, доступно ли достаточно пропускной способности.

После того, как мы настроили резервирование для типа трафика ВМ, можно создавать сетевые ресурс-пулы. Делается это по карточке распределенного свитча, вкладка Configure, в Network resource pools, если нажать на кнопку ADD:

Бекапирование и восстановление конфигурации сетевых компонентов

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

Экспорт конфигураций распределенных свитчей

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

Пригодятся такие командлеты:

Export-VDSwitch (экспортирует конфигурацию указанного распределенного свитча в ZIP-файл)

Export-VDPortGroup (экспортирует конфигурацию указанной распределенной порт-группы в ZIP-файл).

Восстановление и импорт конфигураций распределенного свитча

Восстановление сбрасывает конфигурацию текущего распределенного свитча и замещает ее экспортированной из ZIP-файла. Импорт создает распределенный свитч (новый!) из экспортированного конфигурационного файла. Первое полезно, когда нужно вернуть в нормальное состояние поврежденный vDS, а второе помогает создать новый с такими же настройками, например, в другой системе vCenter.

Откат и восстановление управляющей сети хоста

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

  • Автоматический,
  • С применением DCUI.

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

Замечание. По дефолту, автоматический откат включено.

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

  1. Жмем F2 в DCUI, если попросит, вводим нужные данные учетной записи;
  2. Стрелочками скроллимся до Network Restore Options и жмем Enter;
  3. Под Network Restore Options выбираем Restore vDS, чтобы инициировать откат (здесь можно или восстановить дефолтные заблокированные параметры, или политику тиминга по умолчанию – выбираем нужное и жмем Enter).

Мульти-хоуминг в vCenter Server Appliance

Multi-homing позволяет настраивать несколько NIC с целью управления сетевым трафиком:

Функция поддерживает до 4 NIC. Настройки будут сохраняться на протяжении будущих апгрейдов, создания резервных копий или процессов восстановления.

Настройка хранилища vSphere

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

Что нужно знать о хранилищах данных?

Датастор (хранилище данных) – это, в общем смысле, контейнер, что содержит файлы и объекты. В vSphere – это логическое хранилище, которое может пользоваться одним или большим количеством устройств физического хранилища. Это, такой себе, аналог файловой системы, что предлагает унифицированную модель хранения файлов виртуальных машин, шаблонов и ISO-образов.

vSphere поддерживает такие типы датасторов:

  • VMFS,
  • NFS,
  • vSAN,
  • vSphere Virtual Volumes.

Ниже будет о каждом из них подробно. Можно вывести все доступные на хосте датасторы и проанализировать их свойства.

Датасторы хранят и имеют доступ к данным в качестве блоков или файлов и, соответственно, бывают таких типов:

  • Хранилище на основе блоков. Хранят данные как блоки – последовательность байтов, свойственные локальным хранилищам, используются в Storage Area Networks (SANs) и доступ к ним происходит через iSCSI или Fibre Channel. Именно к такому типу принадлежат датасторы VMFS, vSAN и vSphere Virtual Volumes;
  • Хранилище на основе файлов. Хранят данные иерархически в файлах и папках, свойственны присоединенным к сети хранилищам (NAS). К этому типу относятся NFS и vSphere Virtual Volumes.

В зависимости от типа хранилища, его содержимое может храниться в форм-факторе файлов или объектов:

  • Датасторы на базе файлов. В таких хранилищах ВМ состоят из набора файлов, каждая имеет свою собственную директорию. И вот, например, VMFS и NFS держат именно такие файлы;
  • Датасторы на базе объектов. Здесь ВМ состоит из набора контейнеров данных, что называются объектами. К этому типу принадлежат vSAN и vSphere Virtual Volumes.

В зависимости от желаемого типа хранилища, датасторы могут быть форматированы с VMFS или NFS.

ESXi-хосты можно настроить с общим доступом к датасторам:

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

  • Напрямую прикрепленное хранилище (DAS) – внутренние или внешние диски или массивы, подключенные к хосту через прямое соединение вместо сетевого;
  • Fibre Channel (FC) – высокоскоростной транспортный протокол, что использует SAN. Инкапсулирует команды SCSI, которые передаются между нодами Fibre Channel. В целом, нода Fibre Channel – это сервер, система хранения или ленточный. Свитч Fibre Channel соединяет между собой несколько нод, создавая структуру своей сети;
  • FCoE – трафик Fibre Channel инкапсулируется во фреймы Fibre Channel over Ethernet (FCoE). Эти фреймы конвергируются с другими типами трафика в сети Ethernet;
  • iSCSI – транспортный протокол SCSI, который обеспечивает доступ к устройствам хранения данных и кабельное подключение через стандартные сети TCP/IP. iSCSI отображает блочное хранилище SCSI через TCP/IP. Инициаторы, такие как адаптер шины хоста iSCSI (HBA) в хосте ESXi, посылают команды SCSI к целям, расположенным в системах хранения iSCSI;
  • NAS – хранилище, которое используется через стандартные TCP/IP на уровне файловой системы. Хранилище NAS используется, чтобы держать датасторы NFS. Протокол NFS не поддерживает команды SCSI.

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

Вот удобная сравнительная таблица протоколов хранилища:

Тип датастора Протокол хранилища Поддержка загрузки с SAN Поддержка vSphere vMotion Поддержка vSphere HA Поддержка vSphere DRS
VMFS Fibre Channel + + + +
FCoE + + + +
iSCSI + + + +
iSER/NVMe-oF (RDMA) + + +
DAS (SAS, SATA, NVMe) N/A +*
NFS NFS + + +
vSphere Virtual Volumes FC/Ethernet (iSCSI, NFS) + + +
vSAN Datastore vSAN + + +

*Замечание. DAS поддерживает vSphere vMotion, когда комбинировано с vSphere Storage vMotion.

DAS и SAN-хранилища

DAS противопоставляется SAN-хранилищу, и много администраторов отдают ему предпочтение для инсталляции ESXi. Оно идеально для небольших сред, ведь, в отличие от SAN, намного дешевле в приобретении и проще в администрировании. Однако с ним утрачиваются некоторые функции виртуализации, например, балансировка нагрузки на указанном ESXi-хосте. Но для хранения некритических данных, в частности декомиссованных машин, шаблонов ВМ, оно весьма целесообразно.

Что же касается SAN-хранилища, его LUN распространяются и находятся в общем пользовании всех ESXi-хостов, которые имеют к нему доступ. Для такого общего хранилища можно пользоваться vSphere vMotion, vSphere HA, vSphere DRS, оно создает центральный репозиторий для файлов ВМ и шаблонов, позволяет кластеризацию ВМ по всем ESXi-хостам и может размещать большие объемы в терабайтах.

iSCSI

iSCSI SAN состоит из системы хранения iSCSI, что содержит LUN и процессоры хранилища. Связь между хостом и массивом хранилища происходит по сети Ethernet:

В этом случае ESXi-хост настраивается как инициатор iSCSI, который может опираться на аппаратное обеспечение, где он – это iSCSI HBA, или на программном. Этот инициатор передает команды SCSI по IP-сети, а цель их таким же точно образом, соответственно, получает. При этом цель находится на массиве хранилища, которое поддерживается  ESXi-хостом. Сеть iSCSI может включать много инициаторов и целей. Чтобы ограничить доступ с хостов к целям, массивы iSCSI пользуются многими механизмами, включая ІР-адреса, подсети и требования к аутентификации.

Адресация iSCSI:

Выявление целей iSCSI адаптером – это процесс нахождения ресурсов хранилища в сети и определение, которые из них сейчас являются доступными. Это может быть статичное или динамическое (SendTargets) определение. При статичном методе инициатор не может выполнять выявление самостоятельно – он заранее знает все цели, с которыми может контактировать, и использует их ІР-адреса и доменные имена для связи. А вот при динамическом инициатор каждый раз делает запрос SendTargets на указанный сервер iSCSI, и ответ последнего возвращает IQN и все доступные IP-адреса, которые в клиенте vSphere отображаются, как статичные цели. Можно вручную удалить статичную цель, которая добавлена динамическим выявлением, однако, при повторном сканировании, она может вернуться в список, или когда хост перезагружается либо сбрасывается HBA:

Сетевая конфигурация для iSCSI

До включения программного инициатора iSCSI нужно создать соответствующий VMkernel порт на виртуальном свитче.

Важно! Для оптимизации сети vSphere рекомендуется разделить сети iSCSI и сети NAS или NFS. Преимущество должно даваться физическому разделению, но, если подобное недоступно, можно воспользоваться VLAN.

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

Активация программного адаптера iSCSI

Для того, чтобы ESXi-хост мог работать с хранилищем iSCSI, нужно установить ПО или аппаратное обеспечение iSCSI адаптеров:

Чтобы добавить программный iSCSI-адаптер:

  1. Выбираем хост и кликаем на вкладку Configure;
  2. Выбираем Storage Adapters в секции Storage и кликаем на выпадающее меню сверху слева ADD SOFTWARE ADAPTER и выбираем Add iSCSI adapter:
Безопасность iSCSI и использование CHAP

Инициаторы iSCSI используют CHAP для аутентификации, но по умолчанию CHAP не настроен. Это может быть как однонаправленная, так и двунаправленная аутентификации, или вообще по каждой цели отдельно. Настроить это можно здесь:

Привязка VMkernel портов к инициатору iSCSI

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

Расширение iSCSI для RDMA (iSER)

iSCSI Extensions for RDMA (iSER) предоставляют высокопродуктивное подключение iSCSI для стандартных RDMA NIC, поддерживаемое ESXi, начиная с vSphere 7.0. При этом требуется наличие устройств с включенным RoCE, а целевой массив должен поддерживать iSER на RoCE.

При настройке iSER на ESXi-хосте, фреймворк iSCSI на хосте сможет использовать транспортный протокол Remote Direct Memory Access (RDMA) вместо TCP/IP. Чтобы это сконфигурировать:

  1. Включаем адаптер VMware iSER при помощи команд esxcli:

esxcli rdma iser add

  1. Изменяем общие свойства для адаптеров iSCSI или iSER (можно даже дефолтное имя и alias);
  2. Настраиваем привязку порта для iSCSI или iSER (нужно создать сетевые подключения для привязки механизма iSER и совместимого с RDMA сетевого адаптера);
  3. Настраиваем динамическое или статичное открытие для iSCSI и iSER (динамическое открытие означает, что каждый раз, когда инициатор будет контактировать с указанной системой хранилища iSER, он будет посылать запрос SendTargets к системе. Со статичным открытием придется вручную вводить информацию по целям);
  4. Устанавливаем CHAP для iSCSI или iSER (необходимо только при использовании вашей средой CHAP);
  5. Включаем джамбо-фреймы для сети (если поддерживаются).

Важно! iSER не поддерживает NIC-тиминг. При конфигурировании порт-биндинга используйте только один RDMA-адаптер на каждый виртуальный свитч.

Fibre Channel

Fibre Channel SAN – это специальная высокоскоростная сеть, что подключает хосты к высокопроизводительным устройствам хранения. Чтобы подсоединиться к этой сети, на хосте должны быть Fibre Channel (HBA). Можно использовать прямое подключение Fibre Channel к хранилищу, или держать свитчи Fibre Channel для маршрутизации трафика хранилища. Если у хоста есть FCoE-адаптер, к общим устройствам Fibre Channel можно подключиться через сеть Ethernet. При этом хост подключится к фабрике SAN, что состоит из свитчей Fibre Channel и массивов хранилища, при помощи адаптера Fibre Channel. LUN с массива хранилища станут доступны на хосте, и тогда можно будет создавать датасторы для нужд собственного хранилища, которые будут использовать VMFS-формат. Альтернативно, можно получить доступ к массиву хранилища, которое поддерживает vSphere Virtual Volumes, и создать датасторы vSphere Virtual Volumes на контейнерах массива хранилища. Компоненты Fibre Channel SAN и их взаимосвязи:

Адресация Fibre Channel и контроль доступа:

В Fibre Channel может быть реализован мультипасинг:

Он обеспечивает движение от хоста к LUN по более чем одному пути, благодаря чему, даже если выйдет из строя аппаратное обеспечение, доступ к SAN LUN будет и далее, и внедрена балансировка нагрузки.

vSphere Virtual Volumes

vSphere Virtual Volumes виртуализирует устройства SAN и NAS путем абстрагирования ресурсов физического аппаратного обеспечения до логических пулом емкости. С ним стоимость хранения снижается, как и траты на управление средой, масштабируемость впечатляет, и вообще это решение прекрасно отвечает требованиям аналитики и доступа к данным:

Функции vSphere Virtual Volumes:

  • Нативное отображение VMDK на SAN/NAS – никакого управления томами или LUN;
  • Работает с существующими SAN/NAS-системами;
  • Новый путь управления операциями с данными на уровне ВМ и VMDK;
  • Снепшоты, репликации и другие операции на уровне ВМ на внешнем хранилище;
  • Автоматизирует контроль уровней сервисов по каждой ВМ при помощи политик хранения;
  • Стандартный доступ к хранилищу через vSphere API для конечной точки протокола Storage Awareness;
  • Контейнеры хранилища, которые охватывают целый массив.

Архитектура vSphere Virtual Volumes это фреймворк интеграции и управления, который виртуализирует массивы хранилища, предоставляя более эффективную операционную модель, оптимизированную для виртуализированных сред, которые концентрируются на приложениях вместо инфраструктуры. В нее входят (что такое провайдеры – разберем ниже в специальном подразделе):

  • Провайдеры хранилища vSphere Virtual Volumes,
  • Конечные точки протокола (нужны для установления путей данных по требованию от ВМ к их соответствующим виртуальным томам, настраиваются в системе хранилища, могут включать один или более контейнеров хранилища, поддерживают SCSI (iSCSI/FC/FCoE) и NFS):
  • Контейнеры хранилища (место, где находятся виртуальные тома – логические конструкции, которые могут охватывать вплоть до всей емкости массива хранилища, и логически группируют виртуальные тома, опираясь на нужды в управлении и администрировании):
  • Датасторы Virtual Volumes;
  • Виртуальные тома (объекты, которые нативно хранятся в системе хранилища, подключаясь через Ethernet или Fibre Channel сеть, инкапсуляция файлов ВМ, виртуальных дисков и их деривативов, идентифицируются по уникальному GUID и привязаны к определенной конечной точке протокола, но одна точка протокола может подключаться ко многим виртуальным томам).

Система хранения создает виртуальные тома (отвечают каждому файлу виртуального диска «-flat.vmdk») для основных элементов, которые составляют ВМ:

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

Подобно файлам виртуальных дисков в традиционных хранилищах данных, виртуальные тома представлены ВМ как диски SCSI, vSATA или vNVME. Виртуальный том конфигурации или домашний каталог представляет собой небольшой каталог, который содержит файлы метаданных для ВМ. Файлы метаданных включают файл VMX, файлы дескрипторов для виртуальных дисков, файлы журнала логов. Конфигурационный виртуальный том отформатировано при помощи файловой системы. Когда ESXi использует протокол SCSI для подключения к хранилищу, конфигурационные виртуальные тома форматируются при помощи VMFS. С помощью протокола NFS виртуальные тома конфигурации представлены как каталог NFS.

Дополнительные виртуальные тома можно создавать для других компонентов ВМ, таких как снепшоты и файлы свопа. vSphere Virtual Volumes отображает объекты непосредственно на виртуальные тома. Потом vSphere может перегрузить интенсивные операции хранения, такие как создание снепшотов, клонирование и репликация, на систему хранения.

Репликация vSphere Virtual Volumes

vSphere Virtual Volumes поддерживает репликацию, при помощи которой можно разгрузить репликацию ВМ на массив хранилища и использовать возможности репликации массива полностью:

Безусловно, для этого необходимо, чтобы массив хранилища поддерживал репликацию, хосты ESXi были версии 6.5 или новее и были доступны vSphere API for Storage Awareness 3.0.

Реализация репликации виртуальных томов vSphere зависит от массива и имеет отличия у разных вендоров хранилищ. Ко всем вендорам, обычно, применяются такие требования:

  • Массивы хранения, которые используются для репликации, должны быть совместимы с виртуальными томами vSphere и интегрированы с версией 3.0 или более поздней VASA, совместимой репликацией виртуальных томов vSphere.
  • Массивы хранения должны быть способны к репликации и настроены на использование предоставленных вендоров механизмов репликации. Типичные конфигурации, обычно, включают одну или две цели репликации. Любые необходимые конфигурации, такие как объединение реплицируемого сайта и целевого, также должны выполняться системой хранения.
  • По возможности, группы репликации и домены сбоев для виртуальных томов должны быть предварительно настроены системой хранения.

VMFS

Хосты ESXi поддерживают VMFS5 и VMFS6. Обе файловые системы поддерживают параллельный доступ к общему хранилищу, динамическое расширение и блокировку на диске. Но последняя версия, к тому же, еще и нативные 4К устройства хранилища, автоматическое восстановление пространства и целых 128 хостов на один датастор.

Замечание. Прямой апгрейд с VMFS5 на VMFS6 невозможен. Как смигрировать данные из одной версии хранилища на другую подробно рассмотрено в этом КБ.

Вообще же, VMFS – это высокопроизводительная кластеризированная файловая система, где много ESXi-хостов могут одновременно читать и записывать на одно и то же устройство хранения, которое одновременно служит репозиторием для файлов ВМ, шаблонов и ISO-образов:

Доступные функции:

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

К тому же, состояние ВМ сохраняется в центральном месте, обеспечивается поддержка файлов виртуальных дисков (один такой файл может быть до 62 ТБ размером), используется адресация подблоков для эффективного использования хранилища для небольших файлов. А распределение блокировки на уровне блоков гарантирует, что одна и та же ВМ не будет включена на нескольких серверах одновременно. Если же хост падает, блокировка на диске для каждой ВМ снимается, и ее можно перезапустить на других хостах. VMFS можно развернуть на DAS и хранилищах Fibre Channel и iSCSI. Виртуальный диск, который хранится в VMFS, отображается на ВМ как подмонтированное устройство SCSI, и при этом физический уровень хранения скрывается от ОС ВМ. В результате ОС видит только собственную файловую систему.

Создание VMFS-датастора

На любом устройстве хранилища, которое распознается хостом, как сказано выше, можно создать VMFS-хранилище данных. Делается это в левой боковой панели на вкладке хранилищ (третья слева) — в Actions по искомому дата-центру есть пункт меню Storage, клацнув на который можно выбрать New Datastore:

Появится простенький помощник, в пунктах которого задаем все, что он попросит.

Просмотр содержимого датастора

Контент хранилища данных можно просмотреть, если в левой боковой панели перейдем на вкладку хранилищ (третья слева) и по дата-центру встать на вкладку Files:

Панель покажет список датасторов, которые сейчас настроены для всех управляемых ESXi-хостов. Он подан в виде папок, содержащих файлы для ВМ или шаблоны.

Увеличение размера VMFS-датастора

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

  • Выполнить ресканирование, чтобы убедиться, что все хосты видят самое новое хранилище;
  • Записать уникальный идентификатор тома, который хотим расширить.

Динамическое расширение размера VMFS-датастора может пойти двумя путями:

  • Добавление LUN;
  • Расширение хранилища данных в рамках его содержимого:

Важно! Хранилище данных может охватывать несколько уровней, в целом, до 32.

Режим техобслуживания для датастора

Перед тем, как вывести хранилище данных из эксплуатации, его нужно пометить в режим технического обслуживания. До Этого мы должны переместить все ВМ (и включенные, и выключенные) и шаблоны в другой датастор. Делается это там же по искомому датастору, где в Actions выбираем пункт Maintenance — Mode Enter Maintenance Mode:

Появится окошко предупреждения, в котором можно поставить галочку в Let me migrate storage for all virtual machines and continue entering maintenance mode after migration. Если это сделать, когда прямо сейчас начнет свою работу помощник миграции, будет предоставлена возможность переместить ВМ на другой датастор. При наличии шаблонов, при этом можно превратить их в ВМ, смигрировать ВМ, а затем снова конвертировать ВМ в шаблоны.

Важно! Maintenance Mode хранилища – функция vSphere Storage DRS, но этот режим можно использовать без активации vSphere Storage DRS. А вот если vSphere Storage DRS настроена и полностью автоматизирована, миграции ВМ будут происходить автоматически.

Удаление или демонтирование датастора VMFS

Если у нас отпала нужда в каком-то датасторе, его можно демонтировать или удалить – в клиенте vSphere по искомому хранилищу данных в Actions выбираем Unmount Datastore или Delete Datastore:

Демонтирование сохраняет файлы на датасторе, но делает его недоступным для ESXi-хоста.

Важно! Нельзя делать никакие конфигурационные операции, которые могут привести к I/O на хранилище данных, когда демонтирование еще в процессе.

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

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

Важно! До демонтирования VMFS-хранилища обязательно нужно убедиться с помощью клиента vSphere, что:

  • Никакие ВМ не размещены на датасторе;
  • Датастор не является частью кластера датасторов;
  • Датастор не управляется vSphere Storage DRS;
  • Деактивировано vSphere Storage I/O Control;
  • Хранилище не используется vSphere HA heartbeat.

Чтобы сохранить свои данные, рекомендуется сделать бекап контента всех VMFS-хранилищ, до того как начнете удаление или демонтирование.

Настройка балансировки нагрузки для хранилищ

Pluggable Storage Architecture – это уровень VMkernel, ответственный за управление несколькими путями хранения и обеспечения балансировки нагрузки. ESXi-хост можно подсоединить к массивам хранения с active-active или active-passive настройками процессора хранилища. В VMware есть нативные механизмы восстановления после отказа и балансировки нагрузки, которые работают благодаря специальным политикам: Round Robin, Most Recently Used (MRU) и Fixed. Но могут использоваться и решения сторонних вендоров.

Конфигурация этих возможностей происходит по искомому датастору, если в правой части интерфейса встать на вкладку Configure в пункте бокового меню вкладки Connectivity and Multipathing:

Где выбираем нужный датастор, и внизу в его карточке в Actions нужно нажать Edit Multipathing – появится окно, в котором в Path selection policy выбрать один из следующих вариантов:

  • Most Recently Used (VMware). Хост выбирает первый работающий путь, обнаруженный во время загрузки системы. Когда путь становится недоступен, он переходит на альтернативный, и даже когда тот первый путь снова становится доступным, хост к нему не вернется. Это политика по умолчанию для активных и пассивных устройств хранилища данных и является обязательной для них.
  • Round Robin (VMware). Вдобавок к переключению путей после падения, эта политика поддерживает балансировку нагрузки между путями. По умолчанию на хосте активировано механизм задержки, он учитывает пропускную способность ввода-вывода, чтобы выбрать для него оптимальный путь. С этим механизмом Round Robin очень качественно сотрудничает, динамически выбирая путь и достигая лучших результатов балансировки нагрузки. Но, эта политика доступна не для всех устройств хранения – консультируйтесь с вендором.
  • Fixed (VMware). Хост всегда использует желаемый путь для диска, если такой путь доступен. Когда хост не может получить доступ к диску через желаемый путь, он пойдет альтернативным. Политика является политикой по умолчанию для active-active устройств хранения.
Восстановление пространства хранилища

Данные удаляются с датастора VMFS только, если они либо удаляются из гостевой ОС, или файл VMDK удаляется из хранилища данных. Иначе пространство на массиве не освобождается и его часто зовут «мертвым» или «грязным». Следовательно, массив не может повторно использовать это пространство до тех пор, пока мы не скажем ему это сделать, например, командой SCSI UNMAP. В VMFS5 мы вручную посылаем соответствующую esxcli-команду, а в VMFS6 ESXi-хост автоматически ее посылает на массив хранилища.

В первом случае наша команда будет иметь вид:

esxcli storage vmfs unmap

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

-l | —volume-label=volume_label (Метка тома VMFS, которую необходимо отменить. Обязательный аргумент. Используется или –l, или u, никогда вместе)

-u | —volume-uuid=volume_uuid (UUID тома VMFS, который необходимо отменить. Обязательный аргумент. Используется или –l, или u, никогда вместе)

-n | —reclaim-unit=number (Количество блоков VMFS для отмены за итерацию. Опциональный аргумент. Дефолтное значение — 200)

А для настройки автоматического высвобождения пространства на VMFS6-датасторе, в процессе его создания в пункте помощника Partition configuration есть поля Space Reclamation Granularity (определяет размер юнита для команды UNMAP, по дефолту – 1МБ) и Space Reclamation Priority (контролирует скорость, с которой удаленные или отмененные блоки восстанавливаются на LUN, который поддерживает хранилище данных, значение по умолчанию – Low, что соответствует скорости отмены в 25Мбит/с):

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

И, наконец, осталось упомянуть, что и VMFS5, и VMFS6 хранилища данных поддерживают команду unmap, которая исходит из гостевой ОС (если последняя имеет такую возможность). И вот в этом случае для VMFS5 появляется еще один (кроме скрипта) вариант настройки автоматического восстановления пространства.

Важно! Для посылания команд unmap из гостевой ОС на массив хранилища ВМ должен удовлетворять таким условиям:

  • Виртуальный диск должен быть thin-provisioned;
  • Гостевая ОС должна быть способна идентифицировать виртуальный диск как тонкий;
  • В расширенных настройках ESXi-хоста EnableBlockDelete должно быть выставлено на 1:

Замечание. Что касается VMFS6 при использовании настройки Space Reclamation Priority опция EnableBlockDelete игнорируется. И нужно помнить, что запросы unmap из гостевой ОС обрабатываются, только если это пространство равно 1 МБ или является множеством таких кусочков по 1 МБ.

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

NFS

NFS (сетевая файловая система) – это протокол совместного использования файлов, который хосты ESXi используют для коммуникации с подсоединенным к сети устройством хранилища (NAS). NFS поддерживает NFS 3 и 4.1 через TCP/IP. Такое хранилище похоже на VMFS тем, что может держать файлы ВМ, шаблоны, ISO-образы, тома NFS позволяют миграцию vSphere vMotion машин, чьи файлы размещены в нем:

В третьей версии NFS VMware предоставляет собственный протокол поддержки блокировки файлов, а вот NFS 4.1 уже пользуется стандартным общим протоколом Network Lock Manager (NLM) на стороне сервера. По этой причине разные версии NFS не могут использоваться для монтирования одного хранилища данных на нескольких хостах. Сравнение доступности некоторых технологий vSphere для этих версий сетевой файловой системы:

Технология NFS 3 NFS 4.1
vSphere vMotion и vSphere Storage vMotion + +
vSphere HA и vSphere Fault Tolerance + +
vSphere DRS и vSphere DPM +
Stateless ESXi и Host Profiles + частично
vSphere Storage DRS и Storage I/O Control + +
Site Recovery Manager + +
vSphere Virtual Volumes и vSphere Replication + +
vRealize Operations Manager + +
Host Profiles + +
Конфигурирование NFS-датастора

Чтобы сконфигурировать нужное нам хранилище данных NFS, мы должны сделать следующее, пошагово:

  1. Создаем порт VMkernel (для улучшения производительности рекомендуется отделить сеть NFS от сети iSCSI);
  2. Создаем NFS-датастор, введя информацию о:
    • версии NFS (3/4.1),
    • имени хранилища,
    • именах серверов NFS или ІР-адресов,
    • папки на NFS-сервере (будет иметь вид «/templates» или «/nfs_share»),
    • нужно ли подмонтировать файловую систему как разрешенную только для чтения,
    • хостов, которые монтируют этот датастор,
    • данных аутентификации.

Чтобы использовать Kerberos-аутентификацию, мы должны каждый ESXi-хост добавить к домену Active Directory, а затем настроить данные учетной записи NFS Kerberos:

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

Подготовка хостов к использованию Kerberos состоит в настройке параметров клиента NTP в соответствии с общим NTP-сервером (или домен-контроллером, если это возможно).

Важно! NFS 3 и 4.1 используют разные учетные данные аутентификации, что ведет к несовместимости UID и GID на файлах. Кроме того, учитывайте, что использование разных пользователей Active Directory на разных хостах, которые имеют доступ к одному и тому же общему NFS, может привести к сбою миграции vSphere vMotion.

Конфигурация NFS Kerberos может быть автоматизирована при помощи профилей хоста для уменьшения ее конфликтов.

Активация аутентификации Kerberos происходит при создании каждого датастора NFS 4.1 в соответствующем помощнике под 4 его пунктом — Kerberos authentication:

Там есть три варианты выбора (не использовать Kerberos вообще, пользоваться Kerberos только для аутентификации (krb5) или для аутентификации и целостности данных (krb5i)). Ценность KRB5i в обеспечении обнаружения атак типа «man-in-the-middle», которые меняют данные. Первая версия на это не способна.

Демонтирование NFS-датастора

Как и в случае с VMFS, демонтирование NFS-хранилища приводит к недоступности файлов на нем для выбранных ESXi-хостов.

Важно! До демонтирования NFS-датастора необходимо выключить все ВМ, чьи диски размещены на нем.

Делается это, традиционно, в Actions по хранилищу, где есть пункт Unmount Datastore:

Настройка Multipathing для NFS 4.1

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

  • Конфигурация одного VMkernel-порта;
  • Прикрепление NIC к тому же физическому свитчу, чтобы настроить NIC-тиминг (группы NIC должны быть настроены на отдельных внешних свитчах, причем каждая пара NIC сконфигурирована как группа на соответствующем внешнем свитче);
  • Конфигурирование NFS-сервера с несколькими ІР-адресами (даже из одной подсети);
  • Настройка групп NIC с политикой IP hash load-balancing для лучшего использования нескольких соединений.

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

Чтобы настроить мультипассинг для NFS 4.1 (эта версия хранилища поддерживает нативный мультипассинг и транкинг сеанса. Если транкинг доступен, можно пользоваться несколькими ІР-адресами для доступа к одному тому NFS. Транкинг Client ID не поддерживается), нужно при создании нового датастора ввести несколько ІР-адресов сервера:

NVMe

Non-Volatile Memory Express (NVMe) – это стандартизированный протокол для высокопродуктивной многоочередной связи с устройствами NVM. ESXi поддерживает протокол NVMe для подключения к локальным и сетевым устройствам хранения данных.

Начиная с vSphere 7 внедрены следующие функции поддержки NVMe:

  • Стек Pluggable Storage Architecture (PSA) с High-Performance Plug-In (HPP) с мультипассингом. PSA — это открытая модульная структура. Он координирует программные модули, которые отвечают за многопутевые операции. Модули включают общие мультипассинговые модули (MPP) от VMware, например, Native Multipathing Plug-In (NMP) и High Performance Plug-in (HPP), а также MPP сторонних производителей;
  • Добавление и удаление NVM-устройств на горячую при поддержки этого сервером;
  • Поддержка сетевых устройств NVMe, подключенных через Fibre Channel или RDMA.

По поддерживаемым топологиям NVMe следует отметить, что хранилище NVMe может быть напрямую прикреплено к хосту с косвенной помощью разных транспортных сетей, известных как Shared NVMe over Fabrics, или просто NVMe-oF. А именно:

Транспортный протокол NVMe Поддержка в ESXi 7 и более свежих версиях
NVMe over PCIe Локальное хранилище
NVMe over RDMA Общего пользования NVMe-oF хранилище
NVMe over Fibre Channel (FC-NVMe) Общего пользования NVMe-oF хранилище
NVMe over TCP Общего пользования NVMe-oF хранилище

В качестве примера приведем схему удаленного доступа к NVMe-oF, что включает и FC-NVMe, и NVMe over RDMA топологии:

FC-NVMe – это технология, которая позволяет отобразить NVMe на протокол Fibre Channel. С ней данные и команды могут перемещаться между компьютером хоста и целевым устройством хранилища. Для доступа к хранилищу FC-NVMe нужно установить адаптер хранилища Fibre Channel, который поддерживает NVMe на ESXi-хосте. Контроллер, собственно, настраивать не нужно: после инсталляции необходимого аппаратного обеспечения оно автоматически подключится ко всем целям и контроллерам, до которых сможет дотянуться.

Сформулируем требования, необходимые для реализации FC-NVMe:

  • Массив хранилища Fibre Channel, что поддерживает NVMe;
  • NVMe-контроллер на массиве хранилища;
  • ESXi 7+;
  • Адаптер Hardware NVMe на ESXi-хосте (обычно, это HBA Fibre Channel, что поддерживает NVMe).

Сейчас актуальны такие конфигурационные максимумы для NVMe-oF: 256 пространств имен, 2048 путей, 4 пути на каждое пространство имен на каждый хост.

Технология NVMe over RDMA (RoCE v2) использует RDMA для перемещения между двумя системами в сети. Обмен данными происходит в главной памяти, обходя ОС и процессор обеих систем. Ее поддержка с включением RDMA через сеть Ethernet обеспечена в ESXi 7 и более современных версиях. Чтобы получить доступ к хранилищу, ESXi-хост использует сетевой адаптер RDMA, проинсталлированный на хосте, и программный адаптер NVMe over RDMA.

Требования для NVMe over RDMA (RoCE v2):

  • Массив хранилища NVMe с транспортной поддержкой NVMe over RDMA (RoCE v2);
  • NVMe-контроллер на массиве хранилища;
  • ESXi 7+;
  • Свитчи Ethernet с поддержкой сети без потерь;
  • Сетевой адаптер на ESXi-хосте, который поддерживает RoCE v2;
  • Программный адаптер NVMe over RDMA, включенный на ESXi-хостах.

В этом случае конфигурационные максимумы составляют: 32 пространства имен, 128 путей и по 4 пути на пространство имени по каждому хосту.

Чтобы настроить ESXi для NVMe over RDMA (RoCE v2):

  1. Инсталлируем сетевой интерфейс на ESXi-хосте, что поддерживает RDMA (RoCE v2):
  2. В клиенте vSphere убеждаемся, что RDMA-адаптер найден хостом;
  3. Настраиваем привязку VMkernel для адаптера RDMA:
  4. Проверяем конфигурацию привязки VMkernel для адаптера RDMA;
  5. Обнаруживаем NVMe-контроллеры на массиве (автоматически или вручную) – ставим флажок в Add software NVMe over RDMA adapter и выбираем из выпадающего меню соответствующий адаптер:
  6. Повторно сканируем хранилище, чтобы найти пространство имен NVMe;
  7. Создаем собственные хранилища данных.

А вот о vSAN в подробностях мы поговорим как-то в другой раз – в запланированном на ближайшее будущее посвященном ему цикле статей, как одному из самых любимых и самых интересных продуктов VMware.

Провайдер хранилища и vSphere Storage APIs for Storage Awareness и vSphere APIs for I/O Filtering (VASA і VAIO)

vSphere API for Storage Awareness (VASA) помогает вендору хранилища разработать программный  компонент, названный провайдером хранилища для его массивов. Через эти API провайдер хранилища получает информацию о доступной топологии хранилища, возможностях и статусе, следит за здоровьем LUN. Также это очень помогает в настройке политик хранения ВМ с правильным хранилищем в смысле пространства, производительности и требований SLA.

vCenter подключается к провайдеру хранилища и информация с такого провайдера появляется в клиенте – ее можно увидеть, если пройти в vCenter на вкладку ConfigureStorage Providers:

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

  • Постоянные – управляют абстракциями массивов и хранилища, предоставляют сервисы данных, например, репликацию на базе массивов (vSAN storage provider, vSphere Virtual Volumes storage provider);
  • DataServiceProviders – провайдеры I/O фильтрации хранилища или провайдеры сервиса данных (кеширование на базе хоста, компрессия, шифрование).

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

  • Встроенные – предложенные VMware, обычно, не нуждаются в регистрации (провайдеры хранилищ, которые поддерживают vSAN или I/O фильтрацию);
  • Сторонние – предложенные сторонним вендором и, обычно, требующие регистрации (vSphere Virtual Volumes storage provider, vSphere APIs for Storage Awareness storage provider).

Чтобы зарегистрировать нового провайдера хранилища, в клиенте vSphere проходим в Configure Storage Providers:

vSphere APIs for I/O Filtering (VAIO) предоставляет фреймворк для создания и внедрения фильтров I/O в поток данных ВМ. Фильтры ввода-вывода перехватывают и изменяют I/O диска ВМ в VMkernel до того, как данные будут переданы в/из физическое хранилище, и зависят от топологии хранения. VAIO также очень полезна для создания VMware и сторонними вендорами сервисов данных, например, кеширования и репликации.

Замечание. I/O-фильтры поддерживаются во всех типах датасторов (VMFS, NFS 3, NFS 4.1, vSphere Virtual Volumes, vSAN).

Типы I/O фильтров:

  • Replication (репликация) – реплицирует все записанные операции ввода-вывода на внешнюю целевую локацию, например, на другой хост или кластер;
  • Encryption (шифрование) – предоставляет механизм шифрования для ВМ;
  • Caching (кеширование) – внедряет кеширование данных виртуального диска;
  • Storage I/O Control – приоритезирует вводы-выводы хранилища, выделенные для ВМ на протяжении периодов конкуренции I/O.

И именно в таком порядке применяются фильтры в процессе работы фреймворка:

Некоторые из этих типов фильтров уже проинсталлированы на хостах ESXi. Вдобавок, партнеры VMware могут создавать собственные варианты посредством программы разработки vSphere APIs for I/O Filtering.

Информацию о провайдере I/O фильтрации по каждому хосту можно просмотреть, выбрав объект в инвентаре и пройдя на вкладку Configure — Storage Providers:

Управление хранилищем при помощи политик

Storage policy based management (SPBM) гарантирует, что ВМ будет использовать хранилище с указанным уровнем емкости, производительности, доступности, избытком. Фактически, оно абстрагирует сервисы хранилища и данных, предложенные vSAN, vSphere Virtual Volumes, I/O фильтрами или традиционными службами:

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

Политика хранилища ВМ контролирует, какой именно тип хранилища предоставляется ВМ и как она размещена в нем, а также какие сервисы данных могут использоваться. С ней легко категоризировать датасторы, опираясь на уровень сервиса. Политики хранилища ВМ фиксируют характеристики хранения, необходимые для домашних файлов/объектов ВМ и виртуальных дисков для запуска программ на ней. Эти характеристики хранилища определены в наборе правил.

Правила – это базовый элемент политики хранилища, который являет собой утверждение, описывающее одно требование для сервисов хранилища и данных ВМ. Существуют такие категории правил:

  • Правила размещения на основе возможностей – указание конкретного требования хранилища для ВМ, что определяет ее размещение (например, RAID level, Number of failures to tolerate);
  • Правила размещения на основе тегов – ссылка на теги хранилища для определения размещения ВМ (например, Gold Tier tag, Silver Tier tag, Bronze Tier tag);
  • Правила сервисов данных – активирует указанные сервисы данных для ВМ, но не определяет размещение в хранилище и требования к нему для ВМ (кешировнаие, репликация).

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

Каждая политика хранилища может включать один или несколько повторно используемых и взаимозаменяемых строительных блоков, которые называются компонентами политики хранилища, при помощи сервисов VAIO (см. выше). Каждый такой компонент описывает один тип сервиса от провайдера хранилища и их разнообразие зависит от этого провайдера (обычно, или репликация, или шифрование, кеширование или Storage I/O Control). Вот иллюстрация этого утверждения:

Настройка хранилища для использования политик хранилища

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

Компонент политики хранилища создается так:

А сама политика вот так:

Разберем пункты помощника ее создания:

  1. Name and description. Выбираем систему vCenter Server, называем нашу новую политику и даем ее описание:
  2. Policy Structure. Выбираем или Host based services (определяет правила для разрешения и настройки сервисов данных, предоставленных хостом через VAIO), или Datastore specific rules (описывает требования или сервисы для типа хранилища через VASA и методы тегирования):
  3. Tag based placement. Этот пункт появляется, если в предыдущем остановились на втором варианте и поставили галочку в Enable tag based placement rules (например, когда создаем политику хранилища Silver Tier). Здесь выбираем категорию тега, а сам тег можно найти, если нажать на кнопку Browse tags и в открывшемся окне поставить галочку на искомой:
  4. Storage compatibility. Здесь на вкладке Compatible продемонстрируются хранилища, которые являются совместимыми:
  5. Review and finish. Просматриваем сделанные настройки и завершаем создание новой политики.

Далее, когда будем учиться создавать ВМ, можно будет назначать созданную политику (когда ее выберем, покажутся совместимые датасторы, которые нужно будет выбрать флажком):

Проверка совместимости для политики хранения ВМ

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

Политики хранения для vSphere Virtual Volumes

ВМ, которая запущена на виртуальных томах датастора требует политики хранения ВМ. Если не будет создано политику хранения ВМ, совместимую с хранилищем виртуальных томов, система будет использовать дефолтную политику No Requirements, из-за чего не будет задано никаких правил или спецификаций хранения, и массивы смогут самостоятельно определять оптимальное размещение для объектов ВМ:

Создать политику хранилища Virtual Volumes можно, указав во втором пункте помощника, Policy structure, соответствующую галочку в поле, что отвечает за VVOL:

Тогда появится специфический для этого случая третий пункт помощника (название будет характерным для существующего вендора) – например, EMC.UNITY.VVOL rules – где выбираем нужные правила:

Применение политик Storage I/O Control

Storage I/O Control расширяет понятие общего использования, ограничений и резервирования до обработки ресурсов ввода-вывода. Это пропорциональный планировщик операций I/O (IOPS), который при наличии конкуренции регулирует IOPS. Благодаря нему можно регулировать объем вводов-выводов хранилища, выделенных ВМ, в периоды конкуренции. Контроль над I/O хранилища гарантирует, что более важные ВМ получат преимущество над менее важными в смысле выделения ресурсов ввода-вывода:

Общее использование I/O хранилища идентично тому, что мы рассматривали выше, когда говорили о выделении ресурсов памяти и CPU. Общее пользование может обозначаться, обычно, как High, Normal или Low и их значения соотносятся как 4:2:1. Можно также выбрать Custom, чтобы назначить желаемое число общих пользований для каждой ВМ. Тогда ВМ с более высоким значением пользования будут иметь больший доступ к массиву хранилища.

Также, когда выделяем ресурсы ввода-вывода хранилища, можем ограничить разрешенные ВМ IOPS. По умолчанию они не лимитированы.

По умолчанию, Storage I/O Control выключено. Чтобы воспользоваться его преимуществами, придется включить эту функцию на датасторе, и тогда все ВМ на нем будут иметь дефолтные 1 000 общих пользований дисками, никакого ограничения IOPS и никакого резервирования. Но, все эти параметры можно отконфигурировать, как хочется, путем применения соответствующей политики хранилища.

Замечание. При включении Storage I/O Control, ESXi следит за задержкой датастора и регулирует нагрузку ввода-вывода, если средняя задержка превышает пороговое значение, собирает статистику производительности и использует все эти знания для улучшения поведения vSphere Storage DRS. Порог, кстати, определяется автоматически (дефолтные 30мс), но его можно изменить по желанию, установив конкретное значение задержки. Имейте в виду, что дефолтное значение может подойти к некоторым устройствам хранения, но другие могут достичь своего порогового значения задолго до или после достижения параметра по умолчанию.

Требования Storage I/O Control:

  • Поддерживается только на хранилищах, которые управляются единой системой vCenter;
  • Поддерживаются на Fibre Channel, iSCSI, VMFS и NFS3 хранилищах, но vSAN и virtual volumes датасторы не поддерживаются, как и прямое подключение к СХД;
  • Не поддерживаются хранилища с несколькими расширениями;
  • Если датасторы размещены на массивах с возможностью автоматизации уровня хранения, масив должен быть сертифицирован как совместимый со Storage I/O Control.
Настройка Storage I/O Control

На самом деле, говоря о технологии Storage I/O Control мы имеем в виду внедрение фильтрации вводов-выводов. Встроенные компоненты политики хранения определяют возможности Storage I/O Control:

И этот компонент можно использовать, как есть, в Storage I/O Control, или создать пользовательский, который будет определять ограничения IOPS, резервирование и общее пользование. Этот компонент применяется в политике хранения, а потом эту политику сможем назначить ВМ:

Storage I/O Control и vSphere Storage DRS

Как мы уже упоминали, Storage I/O Control собирает для vSphere Storage DRS статистику задержки по ESXi-хосту, посылает ее в vCenter и хранит в его БД. Благодаря этой статистике vSphere Storage DRS знает, когда нужно смигрировать ВМ на другой датастор. При помощи Storage I/O Control можно сбалансировать нагрузку вводов-выводов в кластере хранилища данных, на котором включено vSphere Storage DRS. Делается это здесь:

Работа с виртуальными машинами

Виртуальные машины обладают несколькими преимуществами по сравнению с физическими:

  • Облегченное перемещение или копирование;
  • Независимость от физического аппаратного обеспечения, ведь ВМ инкапсулированы в файлы;
  • Изолированность от прочих ВМ, запущенных на том же самом физическом hardware;
  • Защищенность от изменений физического оборудования:

Любое приложение в любой поддерживаемой ОМ может запускаться на ВМ (гости) и использовать CPU, память, диск и сеть с базированных на хосте ресурсов:

Несколько ВМ, запущенные на физическом хосте совместно пользуются его вычислительными, памятью, сетью и ресурсами хранилища.

А вообще, как мы уже говорили в статье «Инсталляция vSphere 8.0 с нуля», каждая ВМ хранится в виде коллекции файлов или объектов (соответствующая директория с файлами будет на VMFS или NFS датасторе, или это будут объекты в хранилище данных vSAN или vSphere Virtual Volumes). При этом один виртуальный диск инкапсулируется в единственный файл или объект:

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

  • конфигурационный файл (если ВМ была превращена в шаблон, то вместо него будет конфигурационный файл шаблона),
  • своп-файлы, которые используются для восстановления памяти в периоды конфликтов,
  • файл с BIOS или EFI параметрами для ВМ,
  • текущий лог-файл и набор файлов, которые используются для архивации старых записей журналов логов – до 6 таких архиваций могут поддерживаться одновременно (когда запишется седьмой, он заместит 1-й, 1-й заменит 2-й и т. д., пока 6-й не удалится),
  • файл с описанием диска и файл с данными диска (если дисков более одного, столько же соответствующих файлов создастся, с цифровой индикацией в названии),
  • файл статуса Suspend.

Этот перечень общий, но не исчерпывающий.

Умение работать с ними состоит в возможности их создавать, клонировать, управлять или и шаблонами и обновлении шаблонов.

Предоставление виртуальных машин

Через vSphere Client или VMware Host Client можно создавать ВМ несколькими методами:

Метод vSphere Client VMware Host Client
Помощник New Virtual Machine + +
Из существующих шаблонов или клонов +
Из OVF-шаблонов + +

Выбор оптимального метода опирается на размер и тип инфраструктуры и цель, которую перед собой ставите. Первый метод актуален для подготовки машин с уникальными характеристиками, если ни одна в среде ее не напоминает. Клонирование из шаблонов (создаете одну и инсталлируете ОС на ней) очень ускоряет процесс предоставления новых однотипных машин. Развертывание с Open Virtual Machine Format (OVF) доступно из локальных файловых систем (дисков), съемных носителей (CD/USB), общих сетевых дисков или URL.

Создание ВМ через помощник New Virtual Machine

В клиенте vSphere, в инвентаре становимся на хост и в Actions прямо самым первым пунктом идет New Virtual Machine:

Откроется соответствующий помощник, в первом шаге которого (Select a creation type) выбираем Create a new virtual machine, как показано на скриншоте. Далее идем его пунктами:

  1. Select a name and folder. Даем имя нашей новой ВМ и выбираем для нее папку размещения:
  2. Select a compute resource. Выбираем хост, на чьих ресурсах будет запускаться ВМ:
  3. Select a storage. Выбираем политику хранения из выпадающего списка, датастор, где ВМ будет держать свои файлы (ставим флажок в тот, который подходит по своему размеру, скорости, доступности и другим свойствам – все характеристики приведены в списке):

Если хотим не использовать Storage DRS, ставим галочку под политикой;

  1. Select compatibility. Выбираем версию ESXi, с которой ВМ будет совместимой:
  2. Select a guest OS. Выбираем, какую гостевую ОС хотим проинсталлировать на ВМ (семейство, версия):
  3. Customize hardware. Настраиваем виртуальное аппаратное обеспечение для машины. Сразу покажет дефолтные значения, которые были определены, опираясь на выбранную выше гостевую ОС:

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

  1. Ready to complete. Просматриваем все сделанные настройки и жмем Finish, чтобы начать создание ВМ.

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

Настройка hardware ВМ

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

К этой иллюстрации следует сделать несколько важных замечаний.

Замечание. Во всех ВМ унифицированное аппаратное обеспечение (за несколькими исключениями по воле системного администратора) для обеспечения их портуемости между платформами виртуализации VMware.

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

Замечание. USB-устройства доступны лишь для одной ВМ в один момент времени. Если его удалить на одной машине, он становится доступным к выбору на других, которые есть на хосте.

Виртуальное hardware обладает версией (об этом упоминали, когда говорили о совместимости и требованиях в материале об «Инсталляции…»), ее иногда еще называют уровнем совместимости – он определяет функции ОС, которые поддерживает ВМ.

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

Версия гипервизора Версия Hardware
ESXi 8.0 20
ESXi 7.0 U2 + 19
ESXi 7.0 U1 + 18
ESXi 7.0 + 17
ESXi 6.7 U2 + 15
ESXi 6.7 + 14

16-я версия аппаратного обеспечения является специфической для Workstation и Fusion Pro.

Когда мы выбирали в помощнике New Virtual Machine в подразделе выше совместимость (версию ESXi, Select compatibility), нам там показывали, какая версия аппаратного обеспечения будет оптимальной для нашего сетапа.

Вообще, доступно добавление, изменение или настройка ресурсов CPU и памяти в пункте Customize hardware упомянутого помощника для улучшения производительности ВМ. Максимальные конфигурационные значения этих ресурсов приводились в подразделе «Конфигурационные лимиты» статьи об инсталляции vSphere 8.0. Эти настройки, кстати, можно изменить и по уже существующей ВМ, если отредактировать ее параметры, но, обязательно перед этим ее следует выключить – как редактировать машинку рассмотрим ниже в соответствующем подразделе.

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

  • Thick Provisioned (использует все определенное дисковое пространство при создании виртуального диска, независимо от того, действительно ли оно используется файловой системой гостевой ОС),
  • Thin Provisioned (ВМ использует дисковое пространство по необходимости. Диски пользуются емкостью, которая нужна для хранения текущих файлов, однако машина всегда видит весь выделенный размер диска).

Для Thick provisioning известны два подтипа: Lazy-Zeroed и Eager-Zeroed. В первом блок заполняется нулями до того момента, когда данные будут записаны впервые. Второй же вариант означает, что каждый блок будет предварительно заполнен нулями.

Тонкое предоставление подает сигналы и отчеты, которые отслеживают распределение в сравнении с текущим использованием емкости хранилища. Благодаря их свойствам пользователи могут оптимально, но безопасно получать доступное дисковое пространство. Команда «unmap» помогает высвобождать неиспользованное пространство с виртуальных дисков (выше в разделе о ресурсах мы о ней рассказывали). Когда полная емкость тонких виртуальных дисков превышает общую емкость хранилища данных, оно переполняется, и тогда клиент vSphere предложит нам предоставить больше места в базовом хранилище VMFS. ВМ на это время приостановятся, если попробуют что-то записать на хранилище. Можно настроить сигналы тревоги по этому поводу (использование ВМ диска/перевыделение диска хранилища данных), чтобы своевременно среагировать на проблему путем увеличения размера датастора. Также, как вариант, рассмотреть использование vSphere Storage vMotion – миграция осуществляется путем изменения виртуальных дисков толстого формата тонкими в целевом датасторе. Обо всех этих возможностях ниже впоследствии поговорим.

Оба формата, Thick и Thin можно миксовать в среде.

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

  • тип сетевого адаптера из выпадающего списка (Аdapter type),
  • порт-группа, к которой подключаемся (прямо напротив Network adapter 1, возле галочки в Connected),
  • статус сетевого подключения (Status),
  • указание, подключаться ли к сети, когда ВМ включены.

Типы сетевых адаптеров (NIC) можно указывать в настройках, когда их добавляем. Рекомендовано, если жизненно не необходимо иное, использовать всегда VMXNET3. Однако, помните, что идут они только в комплекте с использованием VMware Tools. Другие типы, для справки:

  • E1000-E1000E (эмулированная версия IntelGigabitEthernetNIC с драйверами, доступными в самых новых гостевых ОС),
  • Flexible (может функционировать и как Vlance, и как VMXNET адаптер),
  • PVRDMA (паравиртуализированное устройство, которое обеспечивает улучшенную производительность виртуального устройства, с интерфейсом, похожим на RDMA для гостей vSphere),
  • SR-IOVpass-through (позволяет ВМ и физическому адаптеру обмениваться данными без использования VMkernel как посредника).

Также в настройках аппаратного обеспечения, как мы видим на скриншоте выше, можно добавлять разнообразные виртуальные устройства, которые обеспечивают ВМ рост полезности. Это, в частности, устройства CD/DVD (для подключения к соответствующим приводам или ISO-образу), USB 3.0/3.1, флоппи, дополнительные SCSI-адаптеры, vGPU, криптопроцессор vTPM 2.0 для функций безопасности на базе hardware и прочие.

Развертывание OVF-шаблонов

Виртуальный appliance – это предварительно настроенная ВМ, которая обычно содержит предварительно установленную гостевую ОС и другое необходимое ПО. Его можно добавить или импортировать в инвентарь системы vCenter Server или инвентарь ESXi из VMware Marketplace. Виртуальные appliance развертываются как шаблон OVF, который независим от платформы, эффективен, масштабируем и для которого характерен открытый формат упаковки и распространения ВМ. Файлы OVF сжимаются для ускорения загрузки.

Чтобы развернуть OVF-шаблон с помощью клиента vSphere, кликаем на объект, что подходит (хост ESXi, дата-центр) и выбираем Deploy OVF Template – появится соответствующий помощник:

На первом его шаге Select an OVF template нажимаем кнопку UPLOAD FILES, как показано на скриншоте, чтобы выбрать нужный файл. vSphere Client валидирует OVF-файл перед импортом и гарантирует его совместимость с сервером назначения. Несовместимые с хостом файлы не импортируются.

А далее идем по шагам помощника – почти теми же самыми, что и в случае создания ВМ через помощник New Virtual Machine, рассмотренный подразделом выше.

Удаление ВМ

Удаление ВМ можно осуществить несколькими путями:

  • Удалить из инвентаря (снимается регистрация ВМ с ESXi-хоста и vCenter, ее файлы останутся на диске и ее можно будет позднее повторно добавить в инвентарь);
  • Удалить с диска (все файлы ВМ перманентно удалятся с датастора, снимается регистрация ВМ с ESXi-хоста и vCenter).

Для этого во второй вкладке главного бокового меню встаем на нужную машину и в Actions выбираем одну из упомянутых опций (Remove from inventory/Delete from Disk):

VMware Tools

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

  • Драйверы устройств (дисплей SVGA, VMXNET/VMXNET3, драйвер Balloon driver для управления памятью, драйвер синхронизации для успокоения I/O, паравиртуальный SCSI контроллер);
  • Увеличение производительности графики;
  • Общий доступ к папкам в системе хоста и гостевой файловой;
  • Копирование и вставка текста, графики и файлов между ВМ и хостом или десктопом клиента;
  • Улучшение производительности мыши;
  • Сервис heartbeat для гостевой ОС;
  • Синхронизация времени;
  • Скриптование, которое помогает автоматизировать операции гостевой ОС;
  • Умение выключать ВМ удаленно.

VMware Tools инсталлируются в гостевую ОС вместе с:

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

Замечание. Гостевая ОС может работать, вообще-то, и без VMware Tools, но множество функций VMware при этом будут недоступны. Например, опции выключения или перезапуска с панели инструментов – только опции питания.

Инсталляция VMware Tools

Важно! Нужно убедиться, что выбранная версия VMware Tools является самой свежей для вашей гостевой ОС.

Текущая версия VMware Tools всегда пакуется вместе с vSphere 8 – найти ее можно на странице загрузок в соответствии с уровнем лицензии:

Соответственно, там проходим в GO TO DOWNLOADS и загружаем наши VMware Tools. Метод их инсталляции зависит от типа выбранной гостевой ОС:

Тип гостевой ОС Метод инсталляции VMware Tools
Microsoft Windows С «windows.iso» для Vista и более новых гостей
Linux Одно из двух:

  • Или с «linux.iso»;
  • Или для более свежих дистрибуций Linux  используем open-vm-tools, доступные в разнообразных management-пакетах Linux-систем, например, «yum», «apt» или «rpm».

Центральный репозиторий для VMware Tools

Использование центрального репозитория (иногда можно встретить название «product locker») для VMware Tools имеет множество преимуществ:

  • Оптимизация обновления и установки VMware Tools в среде;
  • Единая локация для VMware Tools, которая значительно упрощает процесс обновления до последней версии;
  • Для любого хоста ESXi, который имеет доступ к общему хранилищу, можно указать центральное хранилище для апдейта VMware Tools;
  • Стандартизация версии ISO VMware Tools на нескольких хостах;
  • Более быстрое употребление последних версий VMware Tools;
  • Более широкий охват разнообразных гостевых ОС.

Чтобы внедрить такой центральный репозиторий:

  1. Копируем нужные пакеты софта VMware Tools в папку на существующем или или новом общем хранилище;
  2. Обновляем UserVars.ProductLockerLocation на каждом хосте ESXi. Для этого в клиенте vSphere в Advanced System Settings по ESXi вписываем новое расположение:

Или при помощи ESXi Shell:

  1. Перезагружаем или вручную копируем измененную конфигурацию, удалив символическую ссылку (symlink) и повторно создав ее в vCenter MOB, чтобы указать на извлеченный каталог в датасторе. Для этого сначала вызываем API при помощи vCenter Managed Object Browser (MOB), куда войти можно с учетной записью administrator@vsphere.local account. Там проходим в content > rootFolder > childEntity > hostFolder:

Или открываем АРІ напрямую при помощи Host ID, выбрав хост в клиенте vSphere с URL, что включает идентификатор хоста (например, «https://<vcenter_fqdn>/mob/?moid=host-4007&method=updateProductLockerLocation»):

Консоль виртуальной машины

Контролировать ВМ можно при помощи ее консоли, где функционируют мышь, клавиатура и дисплей. Она может быть Web-консолью (отдельная вкладка браузера) или удаленной (для нее нужно загрузить VMware Remote Console (VMRC) – отдельное приложение, которое позволяет подключаться к клиентским устройствам и запускать консоли ВМ на удаленных хостах):

Открывается консоль ВМ из клиента vSphere, и с нее можно получить доступ к BIOS или EFI машины, инсталляции ОС, включению/выключению питания и к ее перезапуску. Обычно, для ежедневных задач она не используется – лучше это делать через подключение к удаленному рабочему столу, подключению к виртуальной сети или другое.

Модификация виртуальных машин

На уже существующей ВМ можно отредактировать ее настройки для изменения конфигурации путем:

  • Добавления/удаления виртуального аппаратного обеспечения. Первое возможно и при включенной машине, второе – только в выключенном состоянии;
  • Настройка опций ВМ;
  • Контроля над ресурсами памяти и CPU:

Редактирование виртуального аппаратного обеспечения ВМ

Для добавления устройства, например, мы заходим на первую вкладку редактирования параметров ВМ (Virtual Hardware) и справа сбоку будет выпадающее меню ADD NEW DEVICE, как показано на скриншоте, где выбираем искомое устройство.

По CPU и памяти, при поддерживаемой гостевой ОС, мы можем добавлять ресурсы к запущенной машине – галочку в Enable по CPU Hot Plug или Memory Hot Plug в соответствующих блоках настроек. Также подключение «на горячую» можно организовать по таким устройствам, как USB-контроллеры, Ethernet-адаптеры и устройства жестких дисков.

Важно! Функция hot-plug работает только при установленных VMware Tools 11+ версии.

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

Важно! Увеличение размера виртуального диска ВМ возможно только, если она не имеет прикрепленных снепшотов. Использование нового пространства может потребовать определенных системных инструментов.

Делается это здесь:

Кроме того можно повысить диски тонкого предоставления до толстого формата (eager/zeroed) двумя способами: либо выбором thick-provisioned при использовании vSphere Storage vMotion для миграции ВМ на другой датастор, или выбором файла ВМ с расширением «.vmdk» (когда стоим на этой машине в инвентаре датастора, вкладка Files) и нажатием на функциональную надпись Inflate в верхнем меню:

Редактирование VM Options

Вторая вкладка редактирования ВМ посвящена общим свойствам, вроде имени, типа ОС, конфигурационного файла, директории, в которой должна работать ВМ:

Там же есть блок для VMware Tools, где можно кастомизировать кнопки питания для ВМ, настраивать проверку, есть ли обновление VMware Tools (галочка в Check and upgrade VMware Tools before each power on), синхронизацию времени (Synchronize guest time with host) и характер работы со скриптами:

И, наконец, параметры загрузки ВМ (Boot Options):

Дело в том, что когда ВМ создается и выбирается гостевая ОС, BIOS или EFI выбирается автоматически, в зависимости от встроенного firmware, поддерживаемого ОС. Если ОС поддерживает и то, и другое, по желанию, можно изменить опцию загрузки. Однако, сделать это нужно до инсталляции гостевой ОС. Для UEFI можно поставить галочку в Secure Boot, и тогда каждая часть загрузочного софта будет подписываться, с загрузчиком, ядром ОС и ее драйверами, включительно. В этом случае загружать в такую ВМ можно будет только подписанные драйверы. В Boot Delay мы выставляем время задержки между включением ВМ и загрузкой ОС. Также можно изменить настройки BIOS или EFI, поставив галочку в принудительной загрузке (Force EFI/BIOS setup) – силовой вход в сетап firmware является даже более простым, чем включение ВМ, открытие консоли и попытка как можно быстрее нажать F2. И, наконец, опция Failed Boot Recovery настраивает машину на повторную попытку запуска каждые n секунд (выбирается), дефолтное значение 10, если она не в состоянии сразу найти загрузочное устройство.

Клонирование ВМ

Клонирование ВМ создаст машинку, которая будет точной копией оригинала. Это альтернатива развертыванию ВМ из шаблона (рассмотрим ниже в соответствующем подразделе). При этом не важно, включена машина или нет. Для клонирования ВМ должны быть подключенными к vCenter (не из VMware Host Client!).

Для этого встаем на ВМ-источник, в Actions — Clone — Clone to Virtual Machine:

Чтобы выбрать, что для вас лучше – склонировать работающую ВМ, или запустить развертывание по шаблону, учитывайте следующее:

  • Развертывание ВМ из шаблона принудит их всех начинаться с одного и того же базового образа, а если вы несколько машин попробуете склонировать при включенном состоянии источника, все клоны могут не получиться идентичными – зависит от активностей на ВМ в процессе;
  • Развертывание из шаблонов значительно ускоряет процесс предоставления новых машин, в отличие от клонирования запущенной, если делаем с нее много одновременно;
  • Шаблоны ВМ используют дисковое пространство – планируйте требования к нему соответственно.

Работа с шаблонами ВМ

Template (шаблон) – это статичный образ виртуальной машины, который, обычно, включает:

  • Гостевую ОС,
  • Одно или более приложений,
  • Специфическую конфигурацию VM hardware,
  • VMware Tools.

Для использования шаблонов нужно быть подключенным к vCenter (не VMware Host Client!), а выглядят вкладки с информацией о них так:

Создание шаблонов делает предоставление ВМ намного более быстрым и менее склонным к ошибкам, чем создание их с помощью помощника New Virtual Machine (рассмотренного выше). Шаблоны можно найти там же, где и ВМ – в инвентаре. Можно организовать коллекции ВМ и шаблонов в произвольных папках и применять к ним разрешения. ВМ можно конвертировать в шаблоны без необходимости делать полную копию их файлов и создания объекта. Развертывание ВМ с помощью шаблона добавляет ее в папку, которая была выбрана во время его создания.

Создание новых шаблонов

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

Клонирование ВМ в шаблон

ВМ может быть включенной или выключенной, не важно. Делается это так: встаем на искомую машину в инвентаре, в Actions выбираем опцию Clone и далее Clone to Template:

При этом нам предложат выбрать тип формата хранения виртуальных дисков ВМ:

  • Same format as source (такой же, как у источника),
  • Thin-provisioned format,
  • Thick-provisioned lazy-zeroed format,
  • Thick-provisioned eager-zeroed format.
Конвертация ВМ в шаблон

В этом случае машину обязательно следует выключить. Необходимо:

  1. Выбрать ВМ-источник в инвентаре;
  2. ПКМ по ней – Actions – выбираем Template, и далее — Convert to Template:

Формат диска изменить будет нельзя. Конфигурационный файл «.vmx» заменится на конфигурационный файл шаблона «.vmtx».

Клонирование шаблона

Если у нас уже есть шаблон, создать другой можно его клонированием. Для этого становимся на шаблон и в Actions выбираем Clone to Template:

Обновление шаблонов

Чтобы включить в шаблон новые патчи, добавить или удалить виртуальное аппаратное обеспечение, обновить VMware Tools или версию hardware, проинсталлировать новые приложения, нам не нужно заново создавать шаблон, можно просто идти по алгоритму:

  1. Конвертировать шаблон в ВМ;
  2. Поместить ВМ в изолированную сеть во избежание доступа пользователя;
  3. Сделать в машине необходимые изменения;
  4. Сконвертировать ВМ снова в шаблон.

На первом шаге нам нужно встать на шаблон в инвентаре и в Actions выбирать Convert to Virtual Machine:

Далее все, как описывалось в советах выше для прочих операций.

Развертывание ВМ из шаблона

Чтобы развернуть ВМ из шаблона, нам нужно (как и в случае создания новой, с  нуля) дать ей имя, указать местоположение инвентаря, хост, датастор и данные настройки гостевой ОС. Если мы встанем на нужный шаблон и в Actions выберем New VM from This Template, появится помощник, очень похожий на тот, который мы изучали на создании новой машины, с присущим пунктом Select clone options:

Важно! Кастомизация гостевой ОС предотвращает конфликты, которые могут возникнуть, когда развертывается ВМ и клон с идентичными настройками гостевой ОС. Если этого не сделать, ВМ унаследует имя хоста, ІР-адрес и другое ВМ-источника или шаблона. В процессе кастомизации можно изменить:

  • имя компьютера,
  • настройки сети,
  • параметры лицензии,
  • временную зону,
  • пароль администратора или root,
  • Windows Security Identifier.
Кастомизация гостевой ОС

Для подготовки гостевой ОС можно создать кастомизацию спецификации, которая будет храниться в базе данных vCenter, и поддерживать как Windows, так и Linux. Просматривать существующие спецификации и делать с ними операции можно в Policies and Profiles главного меню:

Кастомизация полезна, когда мы клонируем ВМ или развертываем ее из шаблона, и выбирается в этих процессах она в собственном пункте помощника развертывания из шаблона (Customize guest OS), если в предыдущем пункте (Select clone options) поставили галочку в Customize the operation system:

Важно! На гостевой ОС, которую хотим кастомизировать, должны быть установлены VMware Tools, и она должна быть проинсталлирована на диске, прикрепленном к SCSI ноде 0:0 в конфигурации ВМ.

Чтобы каждый раз, когда происходит кастомизация гостевой ОС, не вводить имена компьютера и ІР-адреса для виртуальных NIC, можно создать пользовательское приложение (понадобится Perl на vCenter Server) и настроить его по аналогии, как vCenter Server генерирует имена и адреса. Это может быть произвольный выполняемый двоичный файл или скрипт, что отвечает ОС, в которой запущен vCenter Server. После создания этого приложения и регистрации его в vCenter Server, каждый раз, когда будем инициировать кастомизацию гостевой ОС, vCenter Server будет его запускать. Рекомендации по написанию этого приложения можно найти в КБ, и сохранить его необходимо на системном локальном диске vCenter Server. А далее:

  1. Выбираем инстанс vCenter Server в инвентаре и проходим на вкладку Configure;
  2. Кликаем на Settings — Advanced Settings;
  3. Жмем на Edit Settings и вводим данные нашего скрипта:
    • В текстовом поле Name вводим config.guestcust.name-ip-generator.arg1
    • В текстовом поле Value вводим c:\sample-generate-name-ip.pl и кликаем Add
    • В текстовом поле Name вводим config.guestcust.name-ip-generator.arg2
    • В текстовом поле Value вводим c:\sample-generate-name-ip.pl – путь к нашему файлу, и кликаем Add
    • В текстовом поле Name вводим config.guestcust.name-ip-generator.program
    • В текстовом поле Value вводим c:\perl\bin\perl.exe и кликаем Add
  1. Кликаем на Save.

Распишем пошагово, как выглядит кастомизация при клонировании или развертывании новой машины:

  1. ПКМ на объект инвентаря, что является валидным родительским объектом для ВМ (дата-центр, кластер, vApp, ресурс-пул, хост) и выбираем New Virtual Machine;
  2. На странице Select a creation page выбираем Clone an existing virtual machineили Deploy from template. Next;
  3. Идем привычно помощником вплоть до пункта Select clone options, где ставим галочку в Customize the operating system. Next;
  4. На странице Customize guest OSвыбираем одну из опций: Select an existing specification (чтобы выбрать спецификацию кастомизации из списка) или Override (чтобы изменить кастомизацию спецификации конкретно для этого развертывания – появится помощник Override VM Customization Specification, идем по нему и по завершению кликаем на ОК);
  5. На странице User settings указываем параметры ВМ;
  6. На странице Ready to complete просматриваем настройки и запускаем клонирование кнопкой Finish.

А чтобы применить кастомизацию к уже существующей ВМ, нужно:

  1. ПКМ на ВМ в инвентаре vSphere и выбираем Guest OS> Customize Guest OS – появится диалоговое окно Customize Guest OS;
  2. Выбираем спецификацию кастомизации из списка и кликаем ОК.

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

Библиотека контента и шаблоны

Content library (библиотека контента) – это репозиторий OVF-шаблонов и других типов файлов, к которым реализован общий доступ и внедрена синхронизация по всем системам vCenter глобально. При этом доступно распределенное управление файлами, ISO подмонтировать можно прямо из библиотеки контента, а версии шаблонов ВМ поддерживаются различные. Такие библиотеки контента могут быть разных типов:

  • Локальная – контент контролируется администратором;
  • Опубликованная – локальная библиотека, доступная по подписке;
  • По подписке – библиотека, которая синхронизируется с другой опубликованной библиотекой.

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

Для библиотек контента в клиенте vSphere есть специальный раздел в главном меню — Content Libraries, где можно создавать собственные библиотеки и управлять ими:

Создание новой библиотеки контента

Чтобы создать новую библиотеку, на странице Content Libraries правой рабочей зоны жмем на функциональную надпись Create, после чего появится помощник, пунктами которого привычно идем:

Кстати, во втором его пункте придется сделать выбор, какого именно типа будет библиотека (локальная, по подписке).

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

  • шаблонами ВМ (храниться могут на любого типа датасторе, за исключением NFS, в дефолтном дисковом формате, ассоциированы с хостом и видимы в инвентаре vCenter),
  • OVF-шаблонами (должны храниться в любом типе датастора, ассоциированном с библиотекой контента, только в формате thin-provisioned, не являются ассоциированными с хостом и не появляются в инвентаре vCenter).
Добавление шаблона ВМ или OVF к библиотеке контента

Помните, выше мы учились клонировать ВМ, в частности в шаблон? Так вот, под пунктом Clone to Template есть пункт Clone to Template to Library, если нажать на который, сможем в соответствующем помощнике выбрать, хотим ли создать шаблон ВМ, или OVF-шаблон:

Это что касается шаблонов ВМ. Если же хотим добавить OVF-шаблон к библиотеке контента, можем склонировать шаблон из инвентаря vCenter в шаблон в библиотеке контента – для этого, аналогично, в Actions под Clone to Template (мы выше с таким вариантом уже работали) выбираем Clone to Library:

Просмотр объектов библиотеки контента и подмонтирование ISO

Панель библиотеки контента (вкладка Templates) выглядит таким образом:

Контент здесь поделен на категории:

  • шаблоны:
    • шаблоны ВМ,
    • OVF-шаблоны,
  • другие типы (например, ISO-образы).

И переключаться между ними можно соответствующими вкладками, ниже главного верхнего меню вкладок.

Выше мы намекали, что ISO-файлами можно пользоваться непосредственно из библиотеки контента, а именно подмонтировать их, что, согласитесь, очень и очень интересно. Для этого нам лишь нужно подключить CD/DVD к ISO-файлу в библиотеке.

Важно! ISO-файлы доступны только для машин, которые зарегистрированы на ESXi-хосте, который имеет доступ к датастору, где размещена библиотека контента.

Развертывание ВМ из библиотеки контента

В развертывании машины из шаблона нам снова поможет помощник New Virtual Machine, который вызываем одноименным пунктом в Actions. В первом его пункте выбираем Deploy from template, а во втором, переключаясь между верхними вкладками, Content Library и Data Center, сможем или увидеть список OVF-шаблонов, или шаблонов ВМ, соответственно:

Публикация библиотеки контента

Чтобы к нашей библиотеке обеспечить доступ пользователям, можем ее опубликовать, путем редактирования ее настроек. Для этого встаем на нужную библиотеку в панели Content Libraries и по Actions вызываем пункт Edit Settings:

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

Теперь эту библиотеку можно увидеть в табличке панели Content Libraries, где будет отображаться ее тип, и отметка о том, опубликована ли она:

Подписка библиотеки на другую опубликованную и синхронизация контента

В подразделе выше мы получили URL для доступа к опубликованной библиотеке. Чтобы наша подписываемая библиотека его имела, нужно в помощнике ее создания выбрать флажком второй блок Subscribed content library и в пункте Subscription URL вставить нужную ссылку:

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

В панели OVF & OVA Templates (вкладка второго ряда) по библиотеке с подпиской выводит списком наши OVF-шаблоны. Периодически эти данные, естественно, устаревают, и чтобы обновить этот список можем выбрать в ACTIONS действие Synchronize.

Важно! Под синхронизацией подпадают только OVF-шаблоны. Те шаблоны, которые должны содержаться на вкладке VM Templates, могут обновиться только в таком случае: сначала создаем и публикуем подписку в опубликованной библиотеке – чтобы подтолкнуть шаблоны ВМ к библиотеке с подпиской.

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

Чтобы опубликовать шаблоны ВМ, нужно создать подписку:

  1. Из панели опубликованной библиотеки выбираем вверху в ACTIONS пункт New Subscription;
  2. В помощнике Create Subscription, что появился, в первом шаге Select subscription type ставим флажок в Create a new subscription to an existing Subscriber library:
  3. Проходим далее помощник до самого конца, пока успешно не создастся новая подписка;
  4. Когда подписка появится в списке, выбираем ее и кликаем на PUBLISH.

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

Для более гранулированной настройки хранения контента библиотекой, процессов ее синхронизации, в том числе, можно воспользоваться кнопкой Advanced на панели библиотек контента (справа от Create, которую мы видели, когда учились создавать новую библиотеку выше), что откроет окошко Advanced Configuration:

Управление шаблонами в библиотеке контента

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

Управление версионностью шаблонов, в целом, выглядит так:

  1. Извлекаем ВМ из шаблона;
  2. Вносим в нее изменения;
  3. Вносим ВМ в шаблон.

Чтобы извлечь ВМ из шаблона, пользуемся вкладкой Versioning по искомому шаблону, где жмем кнопку CHECK OUT VM FROM THIS TEMPLATE, появится небольшой помощник:

Важно! На протяжении извлечения ВМ из шаблона другие пользователи не могут извлекать шаблон ВМ, однако могут развертывать ВМ из него безоговорочно. Вы не можете конвертировать ВМ в шаблон или мигрировать ее в другой инвентарь vCenter во время извлечения.

Далее вносим нужные изменения к ВМ, например, реконфигурируем ее аппаратное обеспечение или делаем что-то с софтом, и при этом шаблон продолжает быть доступным для развертываний. Используется технология linked clone, чтобы склонировать шаблон при выполнении извлечения. На этом клоне мы и меняем то, что хотим, и когда закончим, он снова объединится с шаблоном ВМ, склонированная ВМ уничтожится, а шаблон ВМ обновится. Однако, если изменения сохранять не хотим, или во избежание создания новых версий, можем отменить извлеченную ВМ, нажав «три точки» возле извлеченной ВМ и кликнув на Discard Checked Out VM:

А если хотим сохранить изменения и обновить шаблон, кликаем на кнопку CHECK IN VM TO TEMPLATE – появится окошко, которое покажет детали изменений, которое подтверждаем кнопкой CHECK IN. В результате создастся новая версия шаблона с обновленным состоянием ВМ.

Разные варианты шаблона ВМ в своеобразном хронологическом дереве с указанием автора и времени внесения изменений на вкладке Versioning – см. предыдущий скриншот. И пользуясь «тремя точечками» по каждой версии можно или удалить ее, или вернуться к ней:

Миграция vSphere vMotion и vSphere Storage vMotion

Миграция – перемещение ВМ с хоста, датастора или инстанса vCenter на другой хост, датастор или инстанс vCenter.

Она может быть холодной (выключенной или переведенной в статус suspend ВМ) или горячей (включенной). В первом случае vCenter выполняет проверки совместимости, чтобы убедиться, что ВМ совместимо с целевым хостом.

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

  • Change сompute resource only. Перемещаем ВМ, но не ее хранилище на другой хост (для горячей миграции пользуемся vSphere vMotion),
  • Change storage only. Перемещаем файлы или объекты ВМ на другой датастор (для горячей миграции пользуемся vSphere Storage vMotion),
  • Change both compute resource and storage. Перемещаем ВМ на другой хост или датастор (для горячей миграции пользуемся vSphere vMotion и vSphere Storage vMotion),
  • Cross vCenter Server export. Перемещаем ВМ на хост и датастор, которые управляются другим инстансом vCenter, не связанным с текущим SSO-доменом.

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

Самое важное в настройке vSphere vMotion – конфигурирование соответствующим образом сетей в смысле настройки адаптеров VMkernel на хосте-источнике и цели:

Миграция vSphere vMotion проходит сквозь следующие этапы:

  1. Создается теневая ВМ на хосте назначения;
  2. Состояние памяти ВМ копируется по сети vSphere vMotion с хоста-источника на целевой хост. Но при этом пользователь, потенциально, может иметь доступ к ВМ и обновлять страницы в памяти. Список модифицированных страниц сохраняется в битовом изображении памяти (bitmap) на хосте-источнике;
  3. После завершения первой стадии копирования состояния памяти, начинается вторая, во время которой копируются любые страницы, которые претерпели изменения на протяжении последней итерации. Подобное итерационное копирование происходит до тех пор, пока количество измененных страниц не позволит осуществлять копирование остатка за 500мс;
  4. ВМ погружается в состояние покоя и никакой активности в отношении себя не воспринимает. При этом vSphere vMotion переносит состояние устройств и bitmap памяти на хост назначения. Сразу при входе в состояние покоя на хосте-источнике, ВМ запускается на целевом хосте, а ее файлы разблокируются на хосте-цели;
  5. Пользователи продолжают пользоваться ВМ на целевом хосте вместо хоста-источника;
  6. Страницы памяти, которые использовались ВМ на хосте-источнике помечаются как высвобожденные.

Требования к ВМ для vSphere vMotion Migration:

  • Если ВМ пользуется RDM-диском, RDM-файл и LUN, с которыми она сопоставляется, должны быть доступными на хосте назначения;
  • Не должно быть подключения к виртуальному устройству, вроде CD/DVD или флоппи, с подмонтированными локально для хоста образами. Но с прикрепленными физическими дисками или образом диска можно.

Требования к хосту (и источнику, и цели) для vSphere vMotion Migration:

  • Доступ ко всем хранилищам ВМ (на один датастор максимально возможны 128 параллельных миграций);

Замечание. Если размещение своп-файла на хосте назначения отличается от размещения свопа на цели, он скопируется на новое место.

  • Активировано порт VMkernel с vSphere vMotion;
  • Соответствие семьи ІР-адресов management-сети (IPv4/IPv6) между хостами источником и целью;
  • Количество параллельных активных задач vSphere vMotion является функцией скорости сети vSphere vMotion (каждый активный процесс требует, минимум, пропускной способности в 250 Мбит/с; одновременно мигрировать в гигабитной сети можно только четыре ВМ, а в 10 Гбит/с или более быстрой — 8);

Замечание. Для роста производительности выделите, как минимум, две порт-группы VMkernel для трафика vSphere vMotion.

  • Совместимость CPU (сети функций CPU на хосте-источнике и цели должны быть совместимыми).

Замечание. Некоторые функции CPU можно скрыть при помощи Enhanced vMotion Compatibility или масок совместимости.

Запуск миграции vSphere vMotion

На предпоследнем скриншоте было показано, как запустить помощник Migrate и выбрать нужный тип миграции. Далее:

  1. Select a compute resource. Выбираем хост или кластер, и запустится проверка, удовлетворяет ли он требованиям (см. выше):

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

  1. Select networks. Настраиваем сеть согласно рекомендаций, данных выше;
  2. Select vMotion priority.
  3. Ready to complete. Проверяем все вводы, и если все устраиваем, запускаем миграцию соответствующей кнопкой.
Миграция зашифрованных ВМ

Encrypted vSphere vMotion (зашифрованная миграция) обезопасит конфиденциальность, целостность и аутентифицированность данных, которые перемещаются vSphere vMotion.

Замечание. Encrypted vSphere Storage vMotion не поддерживается.

Миграция зашифрованных ВМ автоматически предпринимает использование зашифрованного vSphere vMotion. Увидеть настройки шифрования vMotion можно в настройках ВМ, вкладка VM Options: если зайти в Edit Settings блок Encryption, в поле Encrypted vMotion будет выпадающее меню, где выбирается одно из:

  • Disabled (выключено),
  • Opportunistic (по умолчанию, Encrypted vSphere vMotion используется, если хосты источника и назначения его поддерживают),
  • Required (требуется Encrypted vSphere vMotion, но если хост-источник или цель его не поддерживают, миграция сфейлится):

Конфигурирование Enhanced vMotion Compatibility

Enhanced vMotion Compatibility – это кластерная функция, которая позволяет миграции vSphere vMotion между хостами с неидентичными наборами функций. Она использует базовые параметры CPU для настройки всех процессоров в кластере, которые активировано для Enhanced vMotion Compatibility:

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

Требования к хостам из кластера EVC по CPU:

  • Одновендорность всех CPU (Intel/AMD);
  • Активация для виртуализации аппаратного обеспечения (AMD-V/Intel VT);
  • Активация для технологии выключения исполнения (AMD No eXecute (NX)/Intel eXecute Disable (XD));
  • Настройка миграции vSphere vMotion.

Замечание. Приложения в ВМ должны быть совместимы по CPU ID.

Режим EVC на существующем кластере можно настроить так:

  1. Встаем на искомый кластер в инвентаре;
  2. На вкладке Configure выбираем в левом боковом меню рабочей панели VMware EVC – увидим, что он опока выключено, — жмем на кнопку EDIT в правом верхнем углу;
  3. Откроется окно Change EVC Mode, где нужно поставить сверху флажок на Enable EVC for <марка процессора> Hosts:

Важно! Перед настройкой EVC на уже существующем кластере, все его хосты следует погрузить в режим техобслуживания, а их ВМ должны быть выключены или переведены в статус suspend. Чтобы не было при этом простоев в работе, рекомендуется задуматься над необходимостью EVC еще в момент создания нового, пустого кластера.

EVC может работать более гранулировано – по каждой ВМ или их совокупности(ям). Имеется в виду, что мы можем его применять к некоторым, или всем машинам в кластере. На уровне ВМ EVC облегчает их миграцию за границы кластера и между системами vCenter и дата-центрами. Режим VM EVC, что интересно, независим от режима EVC, который определен на уровне кластера. Он становится атрибутом ВМ, а не конкретного поколения процессоров, на котором она загружается в кластере. Функция гарантирует плавную миграцию между двумя дата-центрами с разными процессорами. Более того, она сохраняется для каждой ВМ и теряет режим EVC во время миграции между кластерами или на протяжении циклов питания. Вот эта схема иллюстрирует, как EVC может быть не настроен на кластере, однако он  работает для некоторых ВМ:

Что интересно, EVC также может определять общую базу наборов функций GPU в кластере (те функции, которые не входят в базу, маскируются и не доступны для ВМ). Enhanced vMotion Compatibility для vSGA поддерживаются аппаратными графическими процессорами, а также программными рендерами GPU. EVC для vSGA GPU настраиваются на уровне кластера ESXi. Требования к кластеру EVC для режиму графики:

  • Все хосты ESXi должны удовлетворять требованиям GPU определенной базы;
  • Дополнительные хосты не могут присоединиться к кластеру, если они не удовлетворяют базовым требованиям.

Замечание. Кластер из смеси ESXi 6.7 и ESXi 7.0 хостов поддерживается при использовании Enhanced vMotion Compatibility на уровне кластера.

Также EVC для vSGA GPU можно настроить на уровне виртуальной машины. При этом требуется:

  • Совместимость ВМ для ESXi 7.0U1 (версия hardware 18+);
  • ВМ, которые используют GPU Enhanced vMotion Compatibility на уровне ВМ, должны запускаться на ESXi0U1.

Настраивается EVC Graphics Mode на существующем кластере здесь:

А на уровне ВМ вот здесь:

Миграция ВМ с vSphere Storage vMotion

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

Миграция vSphere Storage vMotion проходит сквозь следующие этапы:

  1. Запускаем миграцию хранилища;
  2. Используем способ перемещения данных VMkernel или vSphere Storage API – Array Integration для копирования данных;
  3. Запускаем процесс новой ВМ;
  4. Отзеркаливаем вызовы I/O к блокам файлов, которые уже скопировано на виртуальный диск целевого хранилища данных;
  5. Переходим к процессу целевой ВМ, чтобы получить доступ к копии виртуального диска.

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

Перед тем, как перейти к практике миграции хранилищ, сделаем одно замечание по vSphere Storage API – Array Integration. Очень важно в процессе идентифицировать массивы хранилища, которые поддерживают такие API, ведь именно это является путем к ускорению аппаратного обеспечения при миграции хранилища, и для успеха необходима их поддержка массивом, а также размещение обоих датасторов на одном массиве хранилища. Узнать, поддерживают ли массивы хранилища аппаратное ускорение, можно через клиент vSphere:

Важно! Для запуска vSphere Storage vMotion нужно, чтобы независимые виртуальные диски машины были в persistent mode. Рекомендуется проводить миграции хранилища в непиковые часы.

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

Миграции между vCenter

vSphere vMotion помогает мигрировать ВМ между инстансами vCenter, независимо от того, в одной ли они группе Enhanced Linked Mode (об этом режиме и его активации подробно говорили в подразделе «Присоединение к домену vCenter в Enhanced Linked Mode» статьи «Инсталляция vSphere 8.0 с нуля»). Крос-vCenter миграции помогают, когда нужно:

  • Сбалансировать рабочие нагрузки по всем кластерам и инстансам vCenter, которые содержатся в одном сайте, или в другой географической локации;
  • Переместить ВМ между средами с различными целями, например, из среды разработки в среду продуктива;
  • Переместить ВМ для достижения других уровней соглашений по сервису (SLA) для пространства хранилища, производительности;
  • Переместить ВМ из on-premises дата-центра vSphere в другое публичное облако, такое как VMware Cloud on AWS.

Требования к миграции между vCenter:

  • Хосты должны быть засинхронизированы по времени;
  • Оба инстанса vCenter должны быть в одно мили разных доменах vCenter Single Sign-On;
  • Для миграции только вычислительных ресурсов оба инстанса vCenter должны быть подключены к общему хранилищу, на котором размещена ВМ:

Замечание. Возможна миграция между инстансами vCenter разных версий. Поддерживаемые версии можно найти в этом КБ.

Миграция между vCenter в одном SSO-домене

Если выполняем кросс-vCenter vMotion в одном SSO-домене, ее процесс начинается точно так же, как мы рассматривали выше для вычислительных ресурсов и хранилища – только в первом пункте помощника Migrate — Select a migration type – ставим флажок в Changе Both Compute Resource and Storage, а далее в Select a compute resource выбираем вычислительные ресурсы на инстансе vCenter назначения:

Далее помощник проходится традиционно, повторяться не будем.

Миграция между vCenter в разных доменах SSO

В нашем помощнике Migrate на первом пункте Select a migration type выбираем Cross vCenter Server export:

Далее в Select a source vCenter Server нужно будет указать FQDN или IP-адрес целевого инстанса vCenter и данные учетной записи к нему:

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

Long-Distance vSphere vMotion Migration

Миграция Long-Distance vSphere vMotion является расширением кросс-vCenter миграции и она полезна, когда инстансы vCenter сильно разнесены географически и существует довольно значительная задержка между сайтами. Use cases:

  • Перманентные миграции;
  • Избежание катастрофы;
  • Тестирование Site Recovery Manager и избежание катастрофы;
  • Балансировка нагрузок между сайтами;
  • Поддержка сценария «Follow-the-sun» (Когда одна команда поддержки заканчивает рабочий день, а другая в отличной временной зоне его начинает, удобнее переместить ВМ так, чтобы вторая команда могла с ними работать в своей географической локации. Другой вариант: иногда стоимость, например, электроэнергии даже в рамках одной страны имеет ночной и дневной тарифы, которые существенно отличаются, и тогда выгодно гонять машины с ночного тарифа на одном конце страны/мира на другой такой же в другом).

Требования и подготовка к Long-Distance vSphere vMotion состоят в следующем:

  • Обеспечение в сети ВМ L2-подключения, доступности того же ІР-адреса ВМ в пункте назначения;
  • Обеспечение в сети vSphere vMotion L3-подключения, 250Мбит/с на каждую операцию миграции, времени передачи между хостами не большего 150мс.

Работа со снепшотами

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

Важно! Снепшоты ВМ не являются рекомендованной стратегией бекапирования.

Связи между снепшотами строятся по принципу «родители-дети» — они организовываются в дерево, где каждый имеет свой родительский снепшот и один или более дочерних, за исключением последнего сделанного:

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

  • конфигурацию ВМ,
  • состояние памяти ВМ (опционально, только при включенной машине, если поставить галочку в Include virtual machine memory, выбрана по умолчанию – см. скриншот ниже),
  • виртуальные диски (без Independent виртуальных дисков, persistent или nonpersistent):

Для того, чтобы взять снепшот, нужно по искомой ВМ в Actions выбрать пункт SnapshotsTake Snapshot.

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

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

Тип снепшота Тип датастора  Имя файла  Размер блока
VMFSsparse VMFS5 с виртуальными дисками, меньшими  2ТБ #-delta.vmdk 512 байт
SEsparse •       VMFS6

•       VMFS5 с виртуальными дисками, большими  2ТБ

•       С эффективностью пространства (thin provisioned)

•       Поддерживающие высвобождение диска (unmap)

#-sesparse.vmdk 4КБ
vsanSparse vSAN Дельта-объект 4МБ

Снепшот состоит из набора файлов:

  • -Snapshot#.vmsn – состояние конфигурации,
  • -Snapshot#.vmem – состояние памяти (опционально),
  • -00000#.vmdk – описание диска,
  • -00000#-delta.vmdk — VMFS5 дельта,
  • -00000#-sesparse.vmdk — VMFS6 дельта,
  • .vmsd – сохраняет имена, описания и взаимосвязи для всех снепшотов ВМ:

Управление снепшотами

В клиенте vSphere для выбранной ВМ мы можем просматривать снепшоты и делать с ними разные операции: редактировать (кнопка Edit, менять имя и описание), удалять (один (DELETE) или все (DELETE ALL), если один, то при удалении определенного, файлы снепшота консолидируются до родительского диска снепшота и объединяются с базовым диском ВМ) и возвращаться к нему (когда возвращаемся к снепшоту (Revert), он становится текущим, и все объекты возвращаются к состоянию, которое было актуальным на момент его взятия):

Соответствующие кнопки найдем выше дерева снепшотов.

Консолидация снепшотов – это метод подключения цепочки дельта-дисков к базовым дискам, когда Snapshot Manager показывает, что снимков нет, но файлы дельта-диска остаются в хранилище данных. Она борется с ситуациями, когда файл дескриптора зафиксирован правильно, а окно Snapshot показывает, что все снепшоты удалены, когда файлы снепшота (-delta.vmdk или -sesparse.vmdk) все еще существуют в папке ВМ на датасторе, когда файлы снепшотов продолжают расширяться, пока они не достигнут размера файла -flat.vmdk, или пока в датасторе не исчерпается место. Консолидация снепшотов – это путь к очищению хранилища данных от ненужных дельта-дисков.

Как мы узнаем, когда необходима консолидация дисков? Если встать на нужную машину и пройти на вкладку Monitor в правой рабочей части интерфейса, в ее меню под Issues and Alarms будет пункт All Issues – там будут собраны все оповещения о предупреждениях насчет необходимости консолидации:

Сама же операция вызывается очень просто: стоя на искомой ВМ в Actions выбираем пункт Snapshots и далее – Consolidate:

Там же, кстати, при необходимости, есть быстрый доступ к удалению всех снепшотов.

Больше узнать обо всех best practice по управлению снепшотами в среде vSphere можно в этом КБ.

Бекапирование и восстановление ВМ

В бекапировании ВМ можно использовать vSphere Storage APIs — Data Protection – специальный фреймворк, который создает резервную копию с центральной системы бекапирования (физической или виртуальной). Он не требует агентов бекапирования или каких-либо процессов, которые должны выполняться внутри гостевой ОС, все происходит централизовано, эффективно, независимо от хоста и LAN:

Замечание. Обработка резервного копирования разгружается с хоста ESXi. В дополнение к возможности снепшотов vSphere используются для поддержки бекапов в сети SAN без простоя ВМ. Благодаря этому к нему можно прибегать в любое время суток, не нуждаясь в расширенных окнах резервного копирования.

Замечание. Бекапирование ВМ может добавить задержки хранилищу данных. С помощью клиента vSphere можно внести в расписание задачу деактивации поведения vSphere Storage DRS на протяжении резервного копирования:

Работа с кластерами vSphere

Кластер в vSphere используется для совместного пользования физическими ресурсами группой ESXi-хостов. vCenter управляет ресурсами кластера как единым пулом ресурсов. Можно создавать один или более кластеров, опираясь на цель их заполнения, например, отдельные кластеры для управления, продакшена или вычислений. В одном кластере может быть до 96 ESXi-хостов и в инвентаре клиента vSphere они выглядят, приблизительно вот так:

Создание vSphere-кластера

Создание кластера на практике выглядит как наименование его и включение желаемых служб. Делается это из клиента vSphere, где стоя на нужном дата-центре, выбираем действие по нему в Actions — New Cluster – появится небольшой помощник, в первом пункте которого как раз и выбираем имя для нового кластера, сервисы и делаем другие необходимые настройки, вроде, указания (ставим галочки в соответствующих полях), должны ли все хосты в нем управляться единым образом (флажки в либо создать новый образ, импортировать из существующего хоста в инвентаре vCenter, либо импортировать образ с нового хоста), управлять ли конфигурацией на уровне кластера:

Замечание. Если поставить галочку в Manage all hosts in the cluster with a single image, vSphere Lifecycle Manager сможет обновлять все хосты кластера вместе, используя указанный образ ESXi. Об этом прекрасно расписали в разделе «Обновление ESXi-хостов с vSphere Lifecycle Manager» статьи «Обновление VMware vSphere до версии 8.0».

Службы, которые можно активировать на кластере vSphere:

  • vSphere HA для высокодоступности,
  • vSphereDRS для размещения ВМ и балансировки нагрузки,
  • vSAN.

vSphere HA — функция кластера, которая защищает от сбоев аппаратного обеспечения хоста путем перезапуска виртуальных машин на хостах, которые работают нормально.

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

Далее об обоих сервисах поговорим детально в отдельных персональных подразделах.

После начальной инициации кластера можно с помощью Cluster Quickstart настроить его. Для этого, стоя на нашем новосозданном кластере в инвентаре, в правой рабочей части проходим на вкладку Configure и в боковом меню под Configuration ищем пункт Quickstart:

Возможности Cluster Quickstart:

  • Настройка служб (vSphere HA, vSphere DRS, vSAN);
  • Проверка совместимости аппаратного и программного обеспечения;
  • Развертывание vSphere Distributed Switch;
  • Настройка сетевых параметров для vSphere vMotion и vSAN;
  • Создание растянутого кластера vSAN или доменов сбоя vSAN;
  • Достижение уверенности, что NTP-конфигурация постоянна по всем кластеру.

Этот встроенный помощник не только настраивает начальную конфигурацию кластера, но и может добавлять хосты к нему как часть будущего расширения. В первом его этапе (Cluster basics) проверяем, правильно ли выбрали службы кластера (можно включить или выключить), а также можем отредактировать, при необходимости, имя и выбрать образ для управления хостами через vSphere Lifecycle Manager:

На втором этапе (Add hosts) добавляем новые или существующие хосты к кластеру:

Как показано на скриншоте, после нажатия на кнопку ADD появляется помощник, в котором вверху есть две глобальные вкладки: New hosts и Existing hosts. После выбора нужной, либо вводим новый хост (если несколько — последовательно), либо выбираем из таблички доступных галочками те, которые интересуют. После добавления хостов рабочий процесс помощника продемонстрирует, сколько хостов сейчас присутствуют в кластере и проведет валидацию их работоспособности.

На третьем этапе после нажатия кнопки CONFIGURE можем настроить сеть и кастомизировать службы кластера под себя:

Замечание. Если в процессе (или сразу) нажали кнопку SKIP QUICKSTART сверху справа, ничего страшного – можем вернуться к редактированию кластера прямо из меню клиента vSphere. Однако, помните, что Cluster Quickstart доступен для каждого кластера только один раз.

Если на первом пункте помощника третьего этапа поставить галочку в самом верхнем поле Configure networking settings later, сможем настроить только то, что касается служб кластера (дефолтная конфигурация), но не увидим ничего, что касается параметров сети, и сам помощник более нам не поможет. В общем же случае, он предложит нам выбрать до трех распределенных свитчей:

сеть для vSphere vMotion (если у нас ІР-информация по всем хостам одинакова, можем вписать только первого и нажать на AUTOFILL сбоку):

и минимум один физический адаптер. Далее в этом помощнике будут Advanced Options, в которых можно более гранулировано настроить службы кластера НА и Distributed Resource Scheduler Enhanced vMotion Compatibility, а также параметры хоста (например, включить или выключить режим локдауна, задать NTP-сервер):