Инсталляция и разворот vmware vsphere 7.0

Как настроить VM Encryption

Поскольку есть множество KMS серверов с поддержкой KMIP (у VMware даже есть документ, описывающий «сертифицированные KMS»), я не буду рассматривать конкретную реализацию KMS, выбор и настройку также обойду стороной. В моей тестовой среде уже есть кластер KMS из трёх нод, в котором каждая нода реплицирует данные с другими нодами.

Если у вас нет KMS, можете взять любой из списка «сертифицированных». Бесплатных решений в этом списке нет, если требуется что-то такое, смотрите в сторону PyKMIP. Кластер на PyKMIP построить нельзя, но с vCenter он работает. Проверял.

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

Установка доверительных отношений между vCenter и KMS

Давайте подключим наши vCenter к кластеру KMS. Процедуру подключения необходимо повторить на каждом vCenter.

Создаём новый кластер, указываем адрес нашей первой ноды и порт 5696 (стандартный порт KMIP). В моем случае логин и пароль указывать не требуется, но это может зависеть от реализации KMS.

Говорим vCenter доверять KMS.

На следующем шаге нам нужно, чтобы KMS доверял vCenter. Нажимаем MAKE KMS TRUST VCENTER.

На выбор есть несколько вариантов установки доверия KMS к vCenter. В случае с нашим кластером используется способ загрузки в vCenter ключевой пары KMS.

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

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

Создание Storage Policy с шифрованием

Следующим шагом будет создание Storage Policy, использующей шифрование.

VM Encryption позволяет хранить VM с шифрованием и без шифрования на одной СХД. У нас уже есть Storage Policy vcd-default-policy. Создадим аналогичную vcd-default-encrypted-policy и включим шифрование в параметрах Host based services.

Проверка загрузки процессора хоста (Host CPU Saturation).

Выберите хост, перейдите на вкладку Performance, там переключитесь в режим «Advanced» и выберите объект «CPU»;
Оцените текущую загрузку в MHz (Usage);
Превышает ли средняя загрузка 75% или пиковая — 90%? Если да, возможно, вам не хватает процессорных ресурсов хоста. Проверьте CPU Ready у ВМ этого хоста как показано ниже. Если средняя загрузка ЦП не превышает 75%, перейдите к следующему блоку…

Проверка CPU Ready:

Если вы решаете проблему производительности определенной ВМ, начните с нее. В противном случае выберите хост, перейдите на вкладку Virtual Machines, отсортируйте список по столбцу Host CPU — MHz и проверьте одну-две ВМ из начала списка;
Для измерения CPU Ready выберите ВМ, перейдите на вкладку Performance, выберите режим Advanced и переключитесь в обзор «CPU» (если вы решаете проблему производительности определенной ВМ, начните с нее);
Оцените значение Ready для всех «объектов» виртуальной машины. Отдельным «объектом» является каждый виртуальный процессор ВМ. Вам будет необходимо изменить свойства графика «Chart Options…» для отображения этого графика;
Среднее или максимальное значение Ready для любого виртуального процессора превышает 2000мс? Если да, то у вас наблюдается нехватка процессорных ресурсов хоста.

Схему анализа данного раздела также можно посмотреть на следующем рисунке:

Как это работает

У VMware есть видео, которое демонстрирует работы механизма vSphere Virtual Machine Encryption.

В механизме VM Encryption используется два ключа симметричного шифрования:

1. Data Encryption Key (дал. DEK). Этот ключ генерирует ESXi хост. Таким ключом зашифрованы файлы конфигурации и файлы виртуальных дисков виртуальной машины. Для файлов конфигурации VM DEK хранится в *.vmx в зашифрованном виде, для файлов виртуальных дисков — в *.vmdk файле в зашифрованном виде.

2. Key Encryption Key (дал. KEK). Этот ключ генерирует KMS. Таким ключом зашифрован DEK. Этот ключ хранится в базе данных KMS и в оперативной памяти ESXi хоста, на котором зарегистрирована VM.

Давайте рассмотрим процессы, который происходят при работе VM Encryption.

Этапы инициализации шифрования:

vCenter запрашивает KEK у KMS. KMS генерирует KEK, сохраняет его в своей базе данных, и передает его vCenter. vCenter передаёт KEK всем ESXi в vSphere High Avalibility кластере. ESXi хранят KEK в оперативной памяти и никогда не записывают его на диск.
ESXi, получив KEK, генерирует DEK, зашифровывает DEK с помощью KEK и записывает зашифрованный DEK в конфигурационный файл VM.
ESXi выполняет процесс шифрования файлов VM с помощью DEK.

Этапы включения зашифрованной VM:

ESXi получает команду на запуск зашифрованной VM, проверяет в своей ОЗУ наличие KEK для расшифровки VM. Если KEK нет в ОЗУ ESXi, KEK запрашивается у vCenter, а vCenter запрашивает KEK у KMS.
KMS передаёт KEK vCenter, а vCenter передаёт KEK ESXi хосту.
ESXi хост запускает VM.

Этапы миграции vMotion зашифрованной VM:

При миграции vMotion KMS сервер не используется. Encrypted vMotion можно использовать и без VM Encryption.

ESXi получает команду на миграцию VM на другой ESXi хост. Если миграция выполняется в другой ESXi кластер, то на этом шаге vCenter запросит KEK у KMS и передаст его на ESXi назначения.
ESXi источника запрашивает «одноразовый ключ» у vCenter. vCenter генерирует ключ и передаёт его хостам источника и назначения миграции.
ESXi источника зашифровывает «одноразовым ключом» ОЗУ виртуальной машины и расшифрованный DEK и передаёт их на хост назначения с помощью vMotion
ESXi назначения расшифровывает «одноразовым ключом» полученные данные и VM продолжает работу на ESXi назначения.

Как устранить ошибку

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

Ошибки в файле .htaccess

У этого файла довольно строгий синтаксис, поэтому неверно написанные директивы (команды) могут привести к ошибке. Попробуйте поочередно удалить команды, добавленные последними, и проверьте работу сайта.
Также найти проблемную директиву можно с помощью логов ошибок (через те же инструменты разработчика в браузере). На ошибку в директиве обычно указывает фраза «Invalid command». Информацию о верном написании директивы или способе исправления ошибок в .htaccess вы можете найти в интернете. Не нужно искать, почему сервер выдает ошибку 500, просто введите в строку поиска название нужной команды или текст ошибки из логов.

Ошибки в скриптах сайта

Скрипт не запускается

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

Не хватает оперативной памяти

Если в логах вы видите ошибку «Allowed memory size», для устранения ошибки 500 стоит оптимизировать работу скрипта. Вы можете воспользоваться специальными расширениями для анализа производительности скрипта или обратиться за помощью к специалисту, который поработает над его оптимизацией.

Ошибки в CMS

Если код CMS содержит неверный синтаксис, это может вывести сайт из строя. В таком случае логи сообщат вам об ошибке 500 текстом «PHP Parse error: syntax error, unexpected». Так происходит, когда некорректно работает плагин (или тема, используемая в CMS, но реже) либо есть ошибки в коде. Ошибка может быть допущена случайно, произойти при обновлении плагина или версии CMS.

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

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

Также в большинстве случаев подобные проблемы помогает решить поддержка CMS.

Информацию о других распространенных ошибках вы можете найти в статье «6 наиболее часто возникающих ошибок HTTP и способы их устранения».

Удачи!

Причины ошибки «Превышено время ожидания ответа от сайта» ERR_CONNECTION_TIMED_OUT и способы исправления.

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

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

Те или иные проблемы с Интернет-подключением.
Временные проблемы со стороны сайта (если не открывается лишь какой-то один сайт) или указание неправильного адреса сайта (при этом «существующего»).
Использование прокси или VPN дли Интернета и их временная неработоспособность (со стороны компании, предоставляющей эти услуги).
Перенаправленные адреса в файле hosts, наличие вредоносных программ, влияние стороннего ПО на работу Интернет-подключения.
Медленное или сильно нагруженное Интернет-соединение.

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

Убедитесь, что адрес сайта введен верно (если вы вводили его с клавиатуры). Отключите Интернет, проверьте, плотно ли вставлен кабель (или выньте его и снова вставьте), перезагрузите роутер, если подключаетесь по Wi-FI, перезагрузите компьютер, подключитесь к Интернету снова и проверьте, исчезла ли ошибка ERR_CONNECTION_TIMED_OUT.
Если не открывается один единственный сайт, проверьте, а работает ли он, например, с телефона по мобильной сети. Если нет — возможно, проблема на сайте, здесь только ожидать исправления с его стороны.
Отключите расширения или приложения VPN и прокси, проверьте работу без них.
Проверьте, не выставлен ли прокси-сервер в настройках подключений Windows, отключите его. См. Как отключить прокси-сервер в Windows.
Проверьте содержимое файла hosts. Если там есть строка, не начинающаяся со знака «решетки» и содержащая адрес недоступного сайта, удалите эту строку, сохраните файл и выполните повторное подключение к Интернету. См. Как редактировать файл hosts.
Если на вашем компьютере установлены сторонние антивирусы или фаерволы, попробуйте временно отключить их и посмотреть, как это повлияло на ситуацию.
Попробуйте использовать AdwCleaner для поиска и удаления вредоносных программ и сброса параметров сети. Скачайте программу с официального сайта разработчика https://ru.malwarebytes.com/adwcleaner/. Затем в программе на странице «Настройки» установите параметры как на скриншоте ниже и на вкладке «Панель управления» выполните поиск и удаление вредоносных программ.
Выполните очистку кэша DNS в системе и Chrome.
Если на вашем компьютере установлена Windows 10, попробуйте встроенное средство сброса сетевых настроек.
Используйте встроенную утилиту очистки Google Chrome.

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

Надеюсь, один из предложенных вариантов помог вам и проблема оказалась решена

Если же нет, обратите внимание на еще один материал, в котором речь идет о похожей ошибке: Не удается получить доступ к сайту ERR_NAME_NOT_RESOLVED

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

Устранение ошибки timed out as the remote server

Начнем проверку по-нашему чек листу, первое, на что я просил обратить внимание, это состояние службы vCenter Server, делается это через оснастку службы в Windows версии и так же в виртуальном appliances.Нажимаете Win+R и вводите services.msc. У вас откроется оснастка службы, найдите там cke;,e VMware VirtualCenter Server, попробуйте ее перезапустить

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

https://адрес вашего сервера:9443/vsphere-client

Логином будет administrator@

Если на уровне SSO все хорошо и проблем не обнаружено, то двигаемся дальше. Проверяем загрузку виртуальной машины или сервера VMware VirtualCenter Server. Во-первых откройте диспетчер задач и перейдите на вкладку производительность. Посмотрите хватает ли вам процессорных мощностей и объема памяти, так же советую нажать «открыть монитор ресурсов» и посмотреть длину очереди к локальным дискам, может быть проблемы в них, они стали ломаться.

Так же проведите процедуру сетевой доступности VMware VirtualCenter Server, с помощью специальной команды ping в командной строке, если диски проседают или процессор, то вы увидите в вашей локальной сети прыгающие значения, в идеале все должно быть 1 мс.

Если есть проблемы с дисками, то смотрите здоровье вашего хоста VMware ESXI, на вкладке hardware status.

Если с физиков все в порядке, то возможно у вам подойдет решение KB2072539 по: The vSphere Client could not connect to vCenter server . The server vCenter server took too long to respond. (The command has timed out as the remote server is taking too long to respon.

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

Через vSphere Client
Через реестр Windows

В vSphere Client, попробуйте залогиниться на любой хост ESXI, нужно чтобы вас пустило. Нажмите Edit > Client Settings.

На вкладке General, найдите поле Client-Server Command Timeout и активируйте параметр Use a custom value со значением 60 секунд. После чего пробуйте попасть на VMware VirtualCenter Server.

Если это не поможет, то можно поправить его с помощью реестра Windows, для этого откройте regedit и перейдите вот в такую ветку.

HKEY_CURRENT_USE\Software\VMware\VMware Infrastructure Client\Preferences\CLIENT_CMD_TIMEOUT

Значение CLIENT_CMD_TIMEOUT поставьте 60, если вдруг этого параметра не будет, то нужно его создать, тип ключа будет REG_SZ.

Кому лень заморачиваться, вот готовый ключ реестра CLIENT_CMD_TIMEOUT

Если же вам и это не помогло, то могу посоветовать восстановить резервную копию VMware VirtualCenter Server, при наличии таковой.

Требования к Vmware vmotion

Ниже представлена картинка с основными требованиями к данной технологии

Минимум гигабитная сеть, желательно выделенная — Настройте каждый хост как минимум с одним сетевым интерфейсом для трафика vMotion. Чтобы обеспечить безопасную передачу данных, сеть vMotion должна быть безопасной сетью, доступной только доверенным сторонам. Дополнительная пропускная способность значительно улучшает производительность vMotion. Когда вы переносите виртуальную машину с помощью vMotion без использования общего хранилища, содержимое виртуального диска также передается по сети.
Совместимость процессоров
Доступ по сети — Для миграции с помощью vMotion требуются правильно настроенные сетевые интерфейсы на исходном и целевом хостах.
vSphere 6.5 и более поздние версии позволяют шифровать сетевой трафик с помощью vMotion. Зашифрованный vMotion зависит от конфигурации хоста или от совместимости между исходным и целевым хостами.
На каждом хосте настройте группу портов VMkernel для vMotion
Чтобы трафик vMotion маршрутизировался через IP-подсети, включите стек vMotion TCP/IP на узле

Дополнительно — https://docs.vmware.com/en/VMware-vSphere/7.0/com.vmware.vsphere.vcenterhost.doc/GUID-3B41119A-1276-404B-8BFB-A32409052449.html

Загрузка vApp в VMware Cloud Director

Переходим в vcd.cloud4y.ru и загружаем vApp из OVF.

Нажимаем Browse и выбираем все файлы, которые мы экспортировали из vCenter.

На последующих шагах принимаем EULA и не вносим изменений в параметры развёртывания. Нажимаем Next-> Next -> … -> Finish.

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

Спасибо за внимание!

Что ещё интересного есть в блоге Cloud4Y

→ Пароль как крестраж: ещё один способ защитить свои учётные данные

→ Тим Бернерс-Ли предлагает хранить персональные данные в подах

→ Виртуальные машины и тест Гилева

→ Создание группы доступности AlwaysON на основе кластера Failover

→ Как настроить SSH-Jump Server

Подписывайтесь на наш Telegram-канал, чтобы не пропустить очередную статью. Пишем не чаще двух раз в неделю и только по делу.

Дополнительные возможности для Windows

Virtualization Based Security

Для Windows 10, Windows Server 2016 и новее мы можем использовать Virtualization Based Security. Включение VBS принудительно установит механизм загрузки в UEFI и включит Secure Boot. Если VM использовала BIOS, она, скорее всего, не загрузится после включения.

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

Virtual Trusted Platform Module

Для Windows 10 и Windows Server 2016 и новее, включив шифрование конфигурационных файлов VM и используя для загрузки UEFI (Secure boot можно не включать), в настройках VM становится доступна установка vTPM.

Данные vTPM хранятся в файле *.nvram в зашифрованном виде.

В гостевой ОС vTPM определяется как обычный физический TPM 2.0.

vTPM в Windows определяется как обычный TPM 2.0

Bitlocker

С vTPM мы можем использовать Windows Bitlocker без ввода пароля при загрузке Windows.

Windows будет загружаться автоматически и разблокировать диски с помощью ключей в vTPM. Если такую VM вынести за пределы площадки облачного провайдера, (или, если vTPM будет изменён, а такое происходит даже при восстановлении бэкапа VM, кроме восстановления поверх) то Bitlocker будет требовать ввести ключ восстановления Bitlocker. Перенести ключи из vTPM невозможно (такой кейс не описан в документации и простых способов извлечения ключей из vTPM я не вижу).

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

Кейс использования vTPM + Bitlocker может быть компромиссом между удобством (VM включается автоматически без ввода пароля Bitlocker) и безопасностью данных (данные зашифрованы средствами гостевой ОС).

Через панель управления VMware Cloud Director 10.1 и новее есть возможность выбрать Storage Policy, использующую шифрование.

Можно изменять как VM default policy, и в этом случае, изменится политика всех дисков VM, у которых Storage policy не задана явно (задана как VM default policy), а также изменится политика хранения конфигурационных файлов VM.

Также можно задавать Storage Policy индивидуально для каждого диска.

Необходимо придерживаться правила, чтоб все диски VM были или зашифрованы, или были без шифрования. При попытке использования дисков с шифрованием и без шифрования на одной виртуальной машине VMware Cloud Director не позволит это сделать.

При зашифрованных конфигурационных файлах виртуальной машины мы увидим напротив VM Storage Policy надпись (Encrypted). При зашифрованных дисках надпись (Encrypted) будет отображаться напротив каждого виртуального диска.

vTPM без шифрования диска средствами VM Encryption

Чтобы подключить vTPM, конфигурационные файлы VM нужно зашифровать (также, должен быть включен Secure Boot и использовать Windows в качестве гостевой ОС). Если использовать Bitlocker, то шифрование дисков VM средствами VM Encryption приведёт к двойному шифрованию и может негативно сказаться на производительности. Чтобы зашифровать конфигурационные файлы и не шифровать диски VM,необходимо назначить VM Storage Policy c шифрованием, а для дисков использовать Storage Policy без шифрования.

Подключить vTPM из интерфейса VMware Cloud Director нельзя, но это возможно сделать через vSphere Client силами инженеров облачного провайдера.

Отказоустойчивость

Что будет, если упадёт кластер KMS

Очевидно, что ничего хорошего. В окне конфигурации Key Management Servers в vCenter будет такая картина.

Падение KMS не повлияет на уже запущенные VM, которые продолжать работать (и их можно будет выключать, включать, мигрировать на другие хосты) до тех пор, пока в ОЗУ ESXi хранятся KEK, ранее полученные у KMS. KEK будут храниться в памяти до перезагрузки ESXi хоста.

При попытке включить VM Encryption при неработающем KMS пойдут ошибки генерации ключа.

Что произойдёт при перезагрузке ESXi хоста

Хост будет требовать включить шифрование вручную

VM, будучи зарегистрированной на хосте, который не хранит в ОЗУ KEK для этой VM (например, если ESXi хост был перезагружен или был добавлен в кластер после первичной инициализации шифрования), будет требовать разблокировать её, передав KEK на ESXi хост.

Описание ошибки «vsphere ha agent is not reachable»

И так у меня есть кластер построенный на базе гипервизоров Vmware ESXI 6.5. В какой-то момент система мониторинга прислала оповещение, что один из хостов стал недоступен и часть виртуальных машин стала неактивна. Когда я залез на vCenter, то обнаружил, что один из хостов имеет состояние «not responding». Выбрав его там красовалось 2 алерта:

Cannot synchronize host. vSphere HA agent s for this host has an error. vSphere ha agent is not reachable.

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