Удаленное подключение к Linux через VMware Horizon Direct Connection

Disclaimer:  все дальнейшие рассуждения и действия не соответствуют политике технической поддержки VMware. Любое использование программного обеспечения не соответствующего системным требованиям VMware может быть использовано только на свой страх и риск.

В разгар локдауна от ковида была написана статья о возможности использования прямого подключения к ПК по протоколу Blast (Blast Extreme) без использования серверной инфраструктуры VMware Horizon:

Удаленное подключение к ПК через VMware Horizon Direct Connection


В последние годы Linux приобретает всё большую популярность, как и потребность в удаленном подключении к нему.

В свою очередь, и компания VMware наращивает функциональность агента и клиента Horizon под операционные системы семейства Linux.

12 января 2023 года вышел релиз VMware Horizon 2212 (8.8). В этом релизе в агент для Linux добавили поддержку Debian 11.5, в котором мы и проведём наш эксперимент.

Для установки нам потребуется следующая документация:

и два дистрибутива агента и плагина:

  1. VMware-horizonagent-linux-x86_64-2212-8.8.0-21071111.tar.gz
  2. VMware-horizonagent-linux-vadc-x86_64-2212-8.8.0-21071111.tar.gz

В соответствии с системными требования проверяем версию Linux:

  • Ubuntu 18.04, 20.04, and 22.04
  • Debian 10.13 and 11.5
  • Red Hat Enterprise Linux (RHEL) Workstation 7.9, 8.4, 8.6, 8.7, 9.0, and 9.1
  • Red Hat Enterprise Linux (RHEL) Server 7.9, 8.4, 8.6, 8.7, 9.0, and 9.1
  • CentOS 7.9
  • SUSE Linux Enterprise Desktop (SLED) 15 SP3 and 15 SP4
  • SUSE Linux Enterprise Server (SLES) 15 SP3 and 15 SP4

и тип окружения рабочего стола: Читать далее «Удаленное подключение к Linux через VMware Horizon Direct Connection»

Наука виртуализации

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

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

Как написать гипервизор самому:

  1. Hypervisor From Scratch — Part 1: Basic Concepts & Configure Testing Environment
  2. Hypervisor From Scratch – Part 2: Entering VMX Operation
  3. Hypervisor From Scratch – Part 3: Setting up Our First Virtual Machine
  4. Hypervisor From Scratch – Part 4: Address Translation Using Extended Page Table (EPT)
  5. Hypervisor From Scratch – Part 5: Setting up VMCS & Running Guest Code
  6. Hypervisor From Scratch – Part 6: Virtualizing An Already Running System
  7. Hypervisor From Scratch – Part 7: Using EPT & Page-Level Monitoring Features
  8. Hypervisor From Scratch – Part 8: How To Do Magic With Hypervisor!

Вложенная виртуализация:

Для понимая поддержки аппаратной виртуализации в VMware ESXi есть довольно полезная, хоть и давно не обновлявшаяся таблица ESX(i) Support of Intel VT-x and AMD-V Features. Вроде, все функции были реализованы в 6.5/6.7: Читать далее «Наука виртуализации»

Подбираем лабораторный сервер с поддержкой vSphere 8

William Lam опубликовал статью Homelab considerations for vSphere 8, перевод которой представлен ниже.

После анонса vSphere 8, который состоялся несколько недель назад, появилось множество отличных технических материалов как от VMware, так и от более широкого сообщества. Многим не терпится получить в свои руки vSphere 8 и vSAN 8 — в этой статье представлены некоторые соображения для тех, кто заинтересован в запуске vSphere 8 в своей домашней лаборатории.

Как и при выпуске любого релиза vSphere, вы всегда должны внимательно изучать примечания к релизу, когда они становятся доступными, и проверять, что все ваше оборудование и базовые компоненты официально включены в список VMware HCL, который будет обновлен после выпуска vSphere 8 и vSAN 8 GA. Только так можно гарантировать, что у вас будет наилучший опыт и поддерживаемая конфигурация от VMware.

Disclaimer: приведенные ниже соображения основаны на ранних наблюдениях за использованием предварительных сборок vSphere 8 и не отражают никаких официальных рекомендаций или поддержки со стороны VMware. Читать далее «Подбираем лабораторный сервер с поддержкой vSphere 8»

Что новое в подсистеме хранения vSphere 8

Disclaimer:  статья основана на следующих источниках:

NVMeoF vVols

Виртуальные тома vVols были основным направлением в разработке систем хранения VMware в течение последних нескольких релизов, и в vSphere 8.0 это не изменилось. Самым крупным анонсом в подсистеме хранения vSphere 8.0 (core storage) является добавление поддержки vVols в NVMeoF. Первоначально будет поддерживаться только FC, но в дальнейшем будут проверять и поддерживать другие протоколы, поддерживаемые vSphere NVMeoF. Это новая спецификация vVols Spec, фреймворк VASA/VC — VASA 4.0/vVols 3.0.

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

Еще одним преимуществом NVMeoF vVols является настройка. При развертывании, после регистрации VASA, базовая настройка выполняется в фоновом режиме, необходимо только создать хранилище данных. Виртуальные конечные точки протокола (vPE) и соединения обрабатываются VASA, что упрощает настройку. Читать далее «Что новое в подсистеме хранения vSphere 8»

VMware vSAN 8

Компания VMware анонсировала на мероприятии VMware Explorer новое программно-определяемое хранилище VSAN 8 с новой архитектурой.

Disclaimer:  статья основана на следующих источниках:

Архитектура vSAN Express Storage Architecture (ESA)

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

Тестирование СХД Lenovo ThinkSystem DE6000F по протоколу передачи NVMe over FC

Disclaimer:  все дальнейшие рассуждения, настройки и выбранные методы тестирования могут быть ошибочны. Никакого отношения к компаниям Lenovo, NetApp, Broadcom мы не имеем.

Вступление

Осенью 2021 года в наши загребущие ручонки попала система хранения данных (СХД) Lenovo ThinkSystem DE6000F с внутренней поддержкой протокола передачи NVMe и установленными дисками SAS SSD. Система также позволяет использовать протокол NVMe в среде сети хранения данных (SAN, Storage Area Network). Поскольку это вторая система хранения такого типа в наших руках, то решено подключить её к SAN по протоколу NVMe over FC (NVMe/FC) и проверить, реализуются ли на практике теоретические преимущества протокола NVMe.  Чтобы переключить СХД на использование нового протокола, на сайте Lenovo FOD получена соответствующая лицензия. СХД не может одновременно использовать несколько протоколов в одной среде передачи, поэтому включение протокола NVMe/FC приводит к отключению возможности работы по протоколу FC. Соответственно, СХД пропадает из зоны доступности серверов, FC-адаптеры которых не могут работать с новым протоколом.  Из имеющихся для стендирования серверов поддержку NVMe over FC «из коробки» имеют серверы Lenovo ThinkServer SR650 c 32-гигабитными FC-адаптерами и серверы Lenovo ThinkServer SR630 с 16 -гигабитными FС-адаптерами после обновления прошивок и драйверов FC-адаптеров. Читать далее «Тестирование СХД Lenovo ThinkSystem DE6000F по протоколу передачи NVMe over FC»

Руководство по синтетическому бенчмаркингу корпоративных систем хранения данных и лучшие практики. Часть 3. Практическая иллюстрация на примере бенчмаркинга VMware vSAN

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

Сценарий и определение целей
ВМ-испытатели
Размер виртуального диска и общее использование ёмкости
Тесты воздействия на производительность набора активных рабочих нагрузок
Анализ влияния продолжительности тестирования и прогрева
Тестирование влияния OIO
Лимиты IOPS
Результаты тестирования
Заключение
Особая благодарность
Приложение A

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

Как я уже говорил, всегда стоит начинать с определения целей и задач. Истинная цель дальнейших бенчмарков — продемонстрировать на конкретном примере процесс проведения тестирования, а также проиллюстрировать влияние отдельных параметров на результаты теста. Чтобы сделать это ближе к реальности, давайте придумаем некую гипотетическую, но все же реалистичную ситуацию. Читать далее «Руководство по синтетическому бенчмаркингу корпоративных систем хранения данных и лучшие практики. Часть 3. Практическая иллюстрация на примере бенчмаркинга VMware vSAN»

Руководство по синтетическому бенчмаркингу корпоративных систем хранения данных и лучшие практики. Часть 2. Критерии успеха и параметры бенчмаркинга

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

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

Заключение

Определение критериев успеха для синтетического бенчмаркинга

Как я уже упоминал в первой части руководства, определение целей и критериев успеха является обязательным шагом для успешного POC. Конечно, критерии успеха могут быть разными, но у них есть нечто общее — они должны следовать правилам S.M.A.R.T:

  • Конкретность — цель должна быть конкретной и ясной для всех, кто участвует в тестировании. Не должно быть никаких разночтений, двусмысленных толкований или «само собой разумеется».
  • Измеримость — это означает, что существует метрика или число, которое может однозначно определить прохождение/непрохождение или результат A лучше, чем B.
  • Достижимость — требования должны быть реалистичными и достижимыми (хотя бы теоретически) для каждого участника. В противном случае нет смысла тратить на это время.
  • Релевантность — здесь это самый важный пункт. Вы должны быть в состоянии прояснить и очень четко показать, почему были выбраны именно такие цели и метрики. Как они связаны с потребностями бизнеса? Почему именно эта метрика или число, а не другая? И будьте осторожны со ссылками на «отраслевые стандарты», «вот как мы делали это раньше», «опыт других компаний». Слишком легко ошибиться и потерять релевантность вашим конкретным бизнес-потребностям.
  • Ограниченность во времени — в вашем плане POC должны быть четко и заранее определены временные рамки и сроки.

Цели, а также подробная контрольная программа (описывающая, как именно будут проводиться тесты) должны быть написаны ДО начала POC и одобрены/подтверждены каждым участником.

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

Упрощенный пример критерия успеха может выглядеть следующим образом: «Задержка в гостевых ОС, работающих на системе хранения данных в нормальных условиях и полностью рабочем состоянии, должна быть менее 1,5 мс при 95-м процентиле при обеспечении 100 тыс. IOPS с профилем 8K 70/30 Чтение/Запись 90% Случайный доступ». Рабочая нагрузка генерируется 12 ВМ с 5 виртуальными дисками в каждой, использование хранилища (общий объем данных, хранимых этими ВМ) должно составлять 70% от полезной ёмкости хранилища, размер набора активной рабочей нагрузки составляет 10%, продолжительность теста 2 часа после 1 часа прогрева». Читать далее «Руководство по синтетическому бенчмаркингу корпоративных систем хранения данных и лучшие практики. Часть 2. Критерии успеха и параметры бенчмаркинга»

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

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

Введение
Определение целей бенчмаркинга
Выбор подхода и методологии бенчмаркинга

Выбор инструментов и утилиты для синтетического бенчмаркинга хранилища данных
Формирование конфигурации демонстрационной среды

Заключение

Введение

За более чем десять лет работы в ИТ-индустрии я провел множество тестов и проверок концепций (proof-of-concepts, POC) различных систем хранения данных (СХД). Хотя это были совершенно разные типы систем хранения — традиционные SAN-системы хранения с подключением по FC, NAS, SDS (Software Defined Storage, программно-определяемое хранилище) и платформы HCI (Hyper Converged Infrastructure, гиперконвергентная инфраструктура), задачи были практически одинаковыми. И довольно часто я сталкивался с ситуацией, когда тесты никак не соответствовали потребностям бизнеса и даже были технически некорректны, что приводило к невозможности получить какие-либо значимые результаты.

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

В большинстве случаев валидация/POC систем хранения данных состоит из трех частей — тесты доступности, функциональные тесты и тесты производительности (они же бенчмаркинг):

  1. Функциональные тесты очень специфичны для конкретной организации, поскольку они должны быть согласованы с ИТ-ландшафтом заказчика, бизнес-процессами и другими отличительными аспектами.
  2. Тесты доступности требуют много времени, но это самая очевидная часть — заказчик должен составить список потенциальных рисков, описать ожидаемое поведение в каждом случае, определить с производителем/поставщиком/дистрибьютором варианты моделирования таких сценариев и выполнить такие тесты.
  3. Тесты производительности или бенчмаркинг — сложная и часто противоречивая часть плана тестирования, потому что это всегда баланс между применимостью и точностью против осуществимости и сложности.

В этом руководстве я рассмотрю только аспект тестирования производительности, и он будет связан в основном с синтетическим бенчмаркингом основной системы хранения общего назначения. Основная цель данного руководства — предоставить указания и рекомендации по проведению бенчмаркинга любого типа корпоративных систем хранения данных для получения значимых результатов при минимизации усилий. Я не буду много говорить об общих вещах, связанных с тестированием в целом и с организацией POC.

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

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

VMware vSphere 7.0 update 3 — что сломали на этот раз

Статья прислана читателем бложика.

Перед началом дальнейшего прочтения надо вспомнить, что VMware vSphere состоит из двух мегаменовESXi на хостах и правящий всеми vCenter. Мне лично больше нравится таблица тут, но ее не так быстро обновляют.

Читаем «что там нового»

Как знают все, интересующиеся темой, на VMworld был анонсировано и тут же выложено обновление для ESXi от 2021-10-05/ 18644231, одновременно с vCenter Server 7.0 Update 3 (7.0.3.00000). Обновление ESXi было выложено, потом убрано со скачивания, затем снова выложено в том же виде. По старой традиции VMware убирать странное и делать вид что ничего не было (что уже было не один раз с HCL) – из VMware ESXi 7.0 Update 3 Release Notes – ждем, когда из RN пропадут строки типа: Читать далее «VMware vSphere 7.0 update 3 — что сломали на этот раз»