Сегодня мы расскажем о VDI (Virtual Desktop Infrastructure) – среде развёртывания виртуальных машин. Она нужна в первую очередь тем, кто работает с большими объёмами данных. А чтобы наглядно продемонстрировать возможности инфраструктуры, мы развернули тестовую установку VDI – она работает под управлением VMware Horizon View и включает 800 рабочих мест. Для максимальной скорости обмена данными мы использовали технологию Dell Fluid Cache for SAN и дисковый массив Dell Compellent.
Часть 1: Формулируем задачу и описываем конфигурацию системы
Зачем использовать виртуальные машины? Просто-напросто это выгодно. Начнем с того, что «виртуалки» позволяют экономить на закупке и содержании техники, они безопасны и просты в управлении. Терминалом в виртуальной среде может стать даже устаревший компьютер и мобильное устройстве, которое уже не способно выполнять свои основные функции – сплошные плюсы! Однако это относится к «обычным» рабочим местам. Разработчики, исследователи, аналитики и другие профессионалы, работающие с большими объёмами данных, обычно пользуются мощными рабочими станциями. Платформа Dell VDI предназначена для виртуализации именно таких машин.
Вот что нам предстояло сделать:
• Разработать целостную инфраструктуру для Horizon View и VDI на основе vSphere для «тяжёлых» задач. Мы собирались использовать технологии Fluid Cache, дисковые массивы Compellent, серверы PowerEdge и коммутаторы Dell Networking.
• Определить производительность сборки на каждом уровне реализации стека VDI при высоких требованиях к обмену с дисковой подсистемой. Мы считали ее как 80-90 IOPS на 1 ВМ в течении всего рабочего процесса.
• Определить падение производительности на пиковых нагрузках (так называемых Boot and Login Storms).
Программно-аппаратная платформа состояла из:
• VMware Horizon View 6.0,
• VMware vSphere 5.5 hypervisor,
• серверов Dell PowerEdge R720 с установленными Dell Express PCIe SSD,
• коммутаторов Dell Networking S4810,
• дискового массива Dell Compellent SC8000.
То, что написано ниже, будет интересно системным архитекторам, планирующим внедрять технологии виртуализации для пользовательских рабочих мест с высокой нагрузкой.
Компоненты системы
1. Dell Fluid Cache для SAN и VDI
Эта технология использует установленные в серверы «диски» Express Flash NVMe PCIe SSD и открывает удалённый доступ к памяти (RDMA). Дополнительный уровень кэша – быстрый посредник между дисковым массивом и серверами. Особенности архитектуры в том, что она изначально распараллелена, устойчива к сбоям и готова к распределению нагрузки, а в паре с со скоростной сетью SAN позволяет устанавливать диски для кэширования хоть во все серверы сборки, хоть в некоторые из них. Быстрее обмениваться данными будут даже те машины, которые не содержат Flash NVMe PCIe SSD. Кэшированные данные передаются в сети по протоколу RDMA, преимущество которого, как известно, в минимальных задержках. По мере того, как ПО Dell Compellent Enterprise обнаруживает компоненты кэша, кластер Fluid Cache создается и конфигурируется в нём автоматически. Быстрее всего при использовании Fluid Cache записываются данные на внешний дисковый массив – это повышает количество IOPS (операций ввода-вывода в секунду).
На схеме показана сетевая архитектура распределённого кэша.
2. Архитектура решения
Вот так выглядит высокоскоростной обмен данными между виртуальными машинами и внешним дисковым массивом:
3. Программы
Horizon view
Horizon view – комплексное решение для VDI, которое делает виртуальные рабочие места безопасными и управляемыми. Его компоненты работают на уровне ПО, сетевого окружения и аппаратного обеспечения.
Виртуальные рабочие места
С разными виртуальными машинами приходится работать по-разному. Постоянная «виртуалка» конкретного пользователя имеет свое место на диске, где лежат и файлы ОС, и программы, и личные данные. Временная виртуальная среда создаётся на основе исходного образа ОС, когда пользователь подключается к системе (соответственно, при выходе она уничтожается). Такая схема работы экономит системные ресурсы и позволяет создать унифицированное рабочее место – безопасное и отвечающее всем требованиям компании. Это подходит для типовых задач, но ведь не все работники выполняют типовые задачи.
VMware View Personal profile management хороша тем, что объединяет лучшее из обоих подходов. ОС Windows давно умеет работать не только с локальными профайлами пользователей, но и теми, что хранятся на сервере. В итоге пользователь получает временную виртуальную машину из образа ОС, но в неё подгружаются личные данные из его профайла на сервере. Такие машины – VMware-linked clones – лучше всего использовать при высокой нагрузке на дисковую память.
Horizon view desktop pools
Horizon view создаёт разные пулы для разных видов виртуальных машин – так их легче администрировать. Например, в пул Manual попадают постоянные физические и виртуальные машины, а Automated Pool содержит «одноразовые», шаблонные. Через интерфейс программы можно управлять и клонами с назначенным пользовательским профайлом. Вот здесь можно почитать об особенностях конфигурации, настройке и сопровождении.
Гипервизор: VMware vSphere 5.5
Платформа VMware vSphere 5.5 нужна для создания VDI и облачных решений. Она состоит из трёх основных уровней: виртуализации, управления и интерфейсного. Уровень виртуализации – это инфраструктура и системное ПО. Уровень управления помогает создавать виртуальное окружение. Интерфейсный – это утилиты на основе на веб-доступа и программы vSphere client.
По рекомендациям VMware и Microsoft в среде виртуализации используются еще и сервисы ядра сети – NTP, DNS, Active Directory и другие.
4. Аппаратное обеспечение Dell
Виртуальные машины разместились на кластере из восьми узлов, которые управляются vSphere. У каждого такого сервера есть PCIe SSD и функции провайдера Fluid Cache. Все они подключены к трем сетям: 10 GB Ethernet iSCSI SAN, сети управления VDI и той, что обеспечивает работу кэша.
Есть и еще один кластер из двух узлов под управлением vSphere. На нём находятся виртуальные машины, которые заставляют функционировать инфраструктуру VDI: vCenter Server, View Connection Server, View Composer Server, SQL Server, Active Directory и т.д. Эти узлы тоже подключены к сетям управления VDI и iSCSI SAN.
У дискового массива Dell Compellent SC8000 спаренные контроллеры и диски трёх типов: Write Intensive (WI) SSD, 15K SAS HDD и 7,2K NL-SAS HDD. Как видим, дисковая подсистема одновременно и производительная, и ёмкая.
Коммутаторы объединены в стек попарно – это обеспечивает отказоустойчивость на сетевом уровне. Они обслуживают все три сети – и клиентскую для виртуальных машин, и управляющую для среды VDI, и iSCSI SAN. Пропускная способность разделяется на основе VLAN, так же выполняется и приоритезация трафика. Оптимальная пропускная способность для этих сетей 40 Гбит/с, но хватит и 10 Гбит/с.
Вот общий план установки:
1. Консоль управления.
2. Сети управления VDI и клиентские.
3. Серверы vSphere для виртуальных машин.
4. Контроллеры Fluid Cache (2 шт.).
5. Коммутаторы SAN (2 шт.).
6. Контроллеры дискового массива (2 шт.).
7. Полки дискового массива (2 шт.).
8. Серверы, обеспечивающие инфраструктуру VDI.
5. Конфигурация компонентов.
Серверы
В каждом из восьми серверов Dell PowerEdge R720, составляющих кластер для VM, установлены:
• два десятиядерных процессора Intel Xeon CPU E5-2690 v2 @ 3.00GHz,
• 256 ГБ оперативной памяти,
• накопитель Dell Express Flash PCIe SSD ёмкостью 350 ГБ,
• сетевая карта Mellanox ConnectX-3,
• гигабитный сетевой контроллер Dual-port Broadcom NetXtreme II BCM57810 10,
• гигабитный сетевой контроллер Quad-port Broadcom NetXtreme BCM5720.
На кластере из двух Dell PowerEdge R720 мы разместили виртуальные машины для Active Directory, VMware vCenter 5.5 server, Horizon View Connection server (основного и запасного), View Composer server, файл-сервера на базе Microsoft Windows Server 2012 R2 и MS SQL Server 2012 R2. Сорок виртуальных машин LoginVSI launcher используются для тестирования установки – они создают нагрузку.
Сеть
Мы использовали в установке три пары свитчей: Force10 S55 1 GB и Force10 S4810 10 GB. Первый отвечал за создание среды VDI и управление серверами, дисковым массивом, коммутаторами, vSphere и т.д. VLAN для всех этих компонентов разные. Вторая пара, Dell Force10 S4810 10 GB, помогала организовать сеть кэширования Fluid Cache. Ещё одна аналогичная пара отвечала за работу сети iSCSI между кластерами и дисковым массивом Compellent SC8000.
Дисковый массив Compellent SC8000
Для виртуальных машин служебных серверов мы создали диск ёмкостью 0,5 ТБ, где разместили Active Directory, SQL Server, vCenter Server, View Connection Server, View Composer и файл-сервер. Для профайлов пользователей выделили диск объёмом 2 ТБ (примерно по 2,5 ГБ на каждую машину). Мастер образы ОС разместились на зеркальном диске на 100 ГБ. Наконец, для виртуальных машин решили сделать 8 дисков по 0,5 ТБ каждый.
Виртуальная сеть
На каждом хосте под управлением гипервизора VMware vSphere 5.5 пять виртуальных коммутаторов:
Horizon view
Настраивали мы по этой инструкции.
Виртуальные машины
Настройкой исходных образов Windows 7 мы занялись по руководствам VMware и Login VSI. Вот, что у нас получилось:
• VMware Virtual Hardware v8,
• 2 виртуальных ЦПУ,
• 3 ГБ RAM, 1,5 ГБ зарезервировано,
• 25 ГБ дисковой памяти,
• один виртуальный сетевой адаптер, подключенный к сети VDI,
• Windows 7 64-bit.
Руководство VMware Horizon with View Optimization Guide for Windows 7 and Windows 8 можно скачать здесь.
Часть 2: Тестируем, описываем результаты, делаем выводы.
Методы проверки и настройка компонентов
Дальше мы проверяли, как ведет себя система с разными сценариями использования виртуальных машин. Мы хотели добиться того, чтобы восемьсот «виртуалок» работали без ощутимых задержек и обменивались информацией с дисковой подсистемой в районе 80-90 IOPS в течении всего дня. Параллельно мы проверяли работу инсталляции при обычной «офисной» нагрузке – и в течение рабочего дня, и когда создавали виртуальные машины, и когда пользователи входили в систему – например, в начале рабочего дня и после обеденного перерыва. Назовем такие условия Boot&Login Storm.
Для тестирования мы использовали две утилиты – комплексную программу Login VSI 4.0, которая создаёт нагрузку на виртуальные машины и анализирует результаты, а также Iometer – она помогает следить за дисковой подсистемой.
Для того, чтобы создать «стандартную» нагрузку для средней офисной машины, мы:
• Запускали до пяти приложений одновременно.
• Использовали программы Microsoft Internet Explorer, Microsoft Word, Microsoft Excel, Microsoft PowerPoint, PDF reader, 7-Zip, Movie player и FreeMind.
• Заново запускали сценарии примерно каждые 48 минут, пауза – 2 минуты.
• Каждые 3-4 минуты замеряли время отклика на действия пользователя.
• Установили скорость печати на уровне 160 мс на символ.
Имитировали высокую нагрузку с помощью того же теста, а чтобы активировать обмен с дисковой подсистемой на каждой виртуальной машине, запускали Iometer. Стандартный набор тестов генерировал 8-10 IOPS на машину, при высокой нагрузке этот показатель составлял 80-90 IOPS. Базовые образы ОС в Horizon view pool мы создали со стандартными настройками и набором ПО для LoginVSI, плюс дополнительно установили Iometer, который запускался из logon script.
Для мониторинга работы и записи показателей под нагрузкой использовали вот такие инструменты:
• Dell Compellent Enterprise Manager для оценки производительности Fluid Cache и Compellent SC8000 storage array,
• VMware vCenter statistics для мониторинга vSphere,
• Login VSI Analyzer для оценки среды пользователей.
Критерий оценки работы дисковой подсистемы – время отклика на действия пользователя. Если оно не выше 10 мс, то все в порядке.
Загрузка системы на уровне гипервизора:
• Нагрузка на любом ЦПУ в кластере не должна быть выше 85%.
• Минимальный memory ballooning (совместное использование области памяти виртуальными машинами).
• Нагрузка на каждый из сетевых интерфейсов – не больше 90%.
• Повторная отправка пакетов TCP/IP – не больше 0,5%.
Максимальное количество запросов от виртуальных машин вычисляли по методике VSImax.
Единый набор виртуальных машин создали на основе базового образа Windows 7 с помощью VMware Horizon View Administrator interface.
Настройки были такие:
• Automatic Desktop Pool: машины создаются по запросу на «включение».
• Каждому пользователю назначается рандомная машина.
• View Storage Accelerator разрешён для всех машин с периодом обновления 7 дней.
• 800 виртуальных машин расположены на 8 физических (по 100 на каждой).
• Исходные образы ОС находятся на отдельных дисках.
Результаты тестирования и анализ
Сценарии были такие:
1. Boot Storm: максимальная нагрузка на систему хранения данных, когда одновременно много пользователей «включают», то есть, создают виртуальные машины.
2. Login Storm: еще одна сильная нагрузка на дисковую подсистему, когда пользователи входят в систему в начале рабочего дня или после перерыва. Для этого теста мы включили виртуальные машины и оставили до входа в систему на 20 минут без каких-либо действий.
3. Стандартная нагрузка: после того, как пользователи вошли в систему, запускался сценарий «стандартной» офисной работы. За откликом системы на действия пользователя наблюдали по параметру VSImax (Dynamic) из Login VSI.
4. Высокая нагрузка: аналогично стандартной, но показатели IOPS в 10 раз выше.
Boot Storm
Прим.: Здесь и далее указаны задержки (latency) со стороны СХД
800 машин во время теста генерировали в среднем 115 000 IOPS. Преобладали операции записи. Через четыре минуты все машины были доступны для работы.
Login Storm и стандартная нагрузка
Мы запрограммировали Login VSI на вход в 800 виртуальных машин примерно через час после их загрузки. Пиковые показатели IOPS не превысили 6 500 на всю платформу (или 8-10 на машину). Запросов на запись было больше, чем во время запуска машин и дальнейшей работы, так как создавался профайл пользователя, запускались сервисы ОС и прикладные приложения. Спустя время, необходимое для стабилизации, ОС кэширует основные пользовательские и программные данные в оперативной памяти – нагрузка на дисковую подсистему снижается. На уровне Fluid Cache при максимальных 6 500 IOPS операции записи кэшируются на 100%, чтения – около 95%. Поток данных в 98 Мбит/с вызывает задержку обращения к диску всего на 2 мс.
Производительность на физическом уровне
Статистику производительности физических компонентов системы vSphere мы снимали с помощью VMware vCenter Server. За всё время теста нагрузка на процессоры, память и все уровни системы хранения данных была примерно одинаковая. Результаты оказались такими, какие мы и ожидали увидеть, ставя задачу:
• Загрузка ЦПУ не больше 85%.
• Активное используемое дисковое пространство не больше 80% (когда создавались виртуальные машины) и не больше 60% во время тестов.
• Memory ballooning минимальная (местами вообще не применялась).
• Нагрузка на сеть около 45%, включая iSCSI, SAN, VDI LAN, Management LAN и vMotion LAN.
• Средняя задержка чтения/записи на адаптерах дисковой СХД – 2 мс.
Это график производительности системы с точки зрения пользователя. Он зависит от количества машин, которые работают одновременно:
В реальной жизни это значит, что на нашей системе можно спокойно разворачивать рабочие места для тысячи пользователей. Задержек ОС не будет, даже если все станут активно работать в одно и то же время.
Вот какие выводы можно сделать по трём тестам «обычного» пользовательского окружения:
• Тестовая система Dell Fluid Cache for SAN-based VDI вполне справилась с задачей: одновременно могут работать 800 пользователей.
• Операции записи составляют 98%, и только 2% приходится на операции чтения.
• Ни один из ресурсов системы не загружался больше, чем мы рассчитывали.
• Login Storm в течении 20 минут не превышал 8-10 IOPS и не вызывал задержек обращения к диску больше 2 мс.
Тяжёлая нагрузка
Такими были настройки Iometer для большой нагрузки на систему ввода/вывода: размер блока – 20 КБ, 80% операций записи, из них 75% не из кэша, 25 мс Burst Delay.
На уровне Fluid Cache максимальная интенсивность ввода/вывода достигала 72 000 (по 90 IOPS на виртуальную машину). Кэширование операций записи – 100%, чтения – 95%. При пиковой производительности СХД в 900 Мбит/с максимальная задержка была 7,5 мс.
Нагрузка на физическом уровне установки оказалась такой же, как и в предыдущем тесте. СХД, ЦПУ и сетевые адаптеры работали так, как мы и запланировали.
Это график отклика системы на действия пользователя. Он зависит от количества машин, которые работают одновременно:
Наши выводы из тестирования под высокой нагрузкой:
• Dell VDI на базе Dell Fluid Cache for SAN можно использовать для одновременной работы 800 виртуальных машин, которые интенсивно обмениваются данными с дисковой памятью.
• 98% приходится на операции записи, 2% – на операции чтения.
• Ни один из системных ресурсов серверов базирования, которые использует vSphere, не был задействован по максимуму. Обозначенные пределы не превышались.
• Высокая нагрузка на виртуальные машины создала задержку в 7,5 мс при общей интенсивности обмена в 72 000 IOPS (90 IOPS на каждую из 800 машин). Это тоже в рамках приемлемой скорости реакции ОС на действия пользователя.
Рекомендации
VDI – среда для виртуальных машин с Dell Fluid Cache for SAN.
• Если использовать перемещаемые профайлы пользователей и хранить данные в перенаправленных папках, то нагрузка на систему ввода/вывода будет ниже. Это имеет значение во время пиковых нагрузок, когда создаются виртуальные машины, а пользователи массово входят в систему. Это же относится и к сетевым папкам общего доступа. Такая схема экономит системные ресурсы и облегчает администрирование. Рекомендуем выделить для пользовательских данных отдельный высокоскоростной дисковый массив.
• Учитывая высокую нагрузку на систему при создании виртуальных машин, предлагаем держать наготове несколько готовых «виртуалок». В VMware Horizon View можно настроить количество рабочих мест, которые всегда будут доступны пользователям.
• Рекомендуем настроить исходные образы Windows 7 и 8 по этой инструкции. Если отключить ненужные системные службы, то на клиенте ускорится авторизация и прорисовка экрана, а общая производительность только вырастет.
Настройка инсталляции:
• Следуйте рекомендациям VMware и Dell при установке и конфигурировании vSphere.
• Создайте отдельные виртуальные коммутаторы для разделения трафика iSCSI SAN, VDI, vMotion и управляющей сети.
• Для отказоустойчивости назначьте каждый сетевой путь минимум двум физическим адаптерам.
• Зарезервируйте минимум 10% физических накопителей, чтобы сервис был доступнее.
Сетевой уровень:
• Используйте не меньше двух физических сетевых адаптеров под сеть VDI на каждом из серверов vSphere.
• Когда вы используете VLAN для разделения трафика в пределах одной физической сети, разносите про разным виртуальным сетям логические сети VDI, vMotion и управляющую.
• На физическом уровне разделяйте сети iSCSI SAN и Fluide Cache. Это повысит производительность системы в целом.
• Виртуальные коммутаторы vSphere по умолчанию ограничены 120 портами. Если машинам нужно больше сетевых подключений, то после изменения настроек сервер придётся перегрузить.
• На коммутаторах iSCSI SAN запретите протокол Spanning tree. Для портов, подключённых и к серверам, и к адаптерам СХД, разрешите PortFast. Jumbo frames и Flow control, если их поддерживают коммутаторы и адаптеры, нужно активировать на всех компонентах сети iSCSI. Здесь можно прочитать об этом подробнее.
Система хранения данных:
• Dell SC Compellent storage arrays отлично работает в паре с технологией Fluid Cache. Это производительное и относительно недорогое решение для среды Dell VDI.
• Fluid Cache улучшает работу СХД при обмене данными между сервером и дисковым массивом. Под управлением ПО Storage Center 6.5 вычислительный кластер, сетевое окружение и система хранения данных работают на полную силу. Единый сервер не может этим похвастаться.
• Рекомендуем использовать отдельные дисковые массивы для исходных образов ОС и пользовательских виртуальных машин. Так проще администрировать диски, замерять производительность и отслеживать узкие места. К тому же, это будет хорошей основой для дальнейшего масштабирования системы.
• Рекомендуем выделить дисковые массивы для перемещаемых пользовательских профайлов и сетевых папок с общим доступом, а также системных серверов и служб общего пользования.
Часть 1: Формулируем задачу и описываем конфигурацию системы
Зачем использовать виртуальные машины? Просто-напросто это выгодно. Начнем с того, что «виртуалки» позволяют экономить на закупке и содержании техники, они безопасны и просты в управлении. Терминалом в виртуальной среде может стать даже устаревший компьютер и мобильное устройстве, которое уже не способно выполнять свои основные функции – сплошные плюсы! Однако это относится к «обычным» рабочим местам. Разработчики, исследователи, аналитики и другие профессионалы, работающие с большими объёмами данных, обычно пользуются мощными рабочими станциями. Платформа Dell VDI предназначена для виртуализации именно таких машин.
Вот что нам предстояло сделать:
• Разработать целостную инфраструктуру для Horizon View и VDI на основе vSphere для «тяжёлых» задач. Мы собирались использовать технологии Fluid Cache, дисковые массивы Compellent, серверы PowerEdge и коммутаторы Dell Networking.
• Определить производительность сборки на каждом уровне реализации стека VDI при высоких требованиях к обмену с дисковой подсистемой. Мы считали ее как 80-90 IOPS на 1 ВМ в течении всего рабочего процесса.
• Определить падение производительности на пиковых нагрузках (так называемых Boot and Login Storms).
Программно-аппаратная платформа состояла из:
• VMware Horizon View 6.0,
• VMware vSphere 5.5 hypervisor,
• серверов Dell PowerEdge R720 с установленными Dell Express PCIe SSD,
• коммутаторов Dell Networking S4810,
• дискового массива Dell Compellent SC8000.
То, что написано ниже, будет интересно системным архитекторам, планирующим внедрять технологии виртуализации для пользовательских рабочих мест с высокой нагрузкой.
Компоненты системы
1. Dell Fluid Cache для SAN и VDI
Эта технология использует установленные в серверы «диски» Express Flash NVMe PCIe SSD и открывает удалённый доступ к памяти (RDMA). Дополнительный уровень кэша – быстрый посредник между дисковым массивом и серверами. Особенности архитектуры в том, что она изначально распараллелена, устойчива к сбоям и готова к распределению нагрузки, а в паре с со скоростной сетью SAN позволяет устанавливать диски для кэширования хоть во все серверы сборки, хоть в некоторые из них. Быстрее обмениваться данными будут даже те машины, которые не содержат Flash NVMe PCIe SSD. Кэшированные данные передаются в сети по протоколу RDMA, преимущество которого, как известно, в минимальных задержках. По мере того, как ПО Dell Compellent Enterprise обнаруживает компоненты кэша, кластер Fluid Cache создается и конфигурируется в нём автоматически. Быстрее всего при использовании Fluid Cache записываются данные на внешний дисковый массив – это повышает количество IOPS (операций ввода-вывода в секунду).
На схеме показана сетевая архитектура распределённого кэша.
2. Архитектура решения
Вот так выглядит высокоскоростной обмен данными между виртуальными машинами и внешним дисковым массивом:
3. Программы
Horizon view
Horizon view – комплексное решение для VDI, которое делает виртуальные рабочие места безопасными и управляемыми. Его компоненты работают на уровне ПО, сетевого окружения и аппаратного обеспечения.
| Компонент | Пояснение |
| Клиентские устройства | Персональные устройства, которые дают пользователю доступ к виртуальным рабочим местам: специализированные терминалы (например, Dell Wyse end points), мобильные телефоны, планшеты, ПК и т.д. |
| Horizon View Connection Server | Программный продукт, который авторизует пользователя в системе, а затем перенаправляет его к терминалу, виртуальной или физической машине. |
| Horizon View Client | Клиентская часть программы. Она используется для доступа к рабочим местам под управлением Horizon View. |
| Horizon View Agent | Служба, которая обеспечивает коммуникации между клиентами и серверами Horizon View. |
| Horizon View Administrator | Веб-интерфейс для управления инфраструктурой и компонентами Horizon View. |
| vCenter Server | Основная платформа для администрирования, конфигурирования и управления массивами виртуальных машин VMware. |
| Horizon View Composer | Приложение для создания пула виртуальных машин на основе базового образа ОС. С его помощью проще администрировать систему и можно экономить ресурсы. |
Виртуальные рабочие места
С разными виртуальными машинами приходится работать по-разному. Постоянная «виртуалка» конкретного пользователя имеет свое место на диске, где лежат и файлы ОС, и программы, и личные данные. Временная виртуальная среда создаётся на основе исходного образа ОС, когда пользователь подключается к системе (соответственно, при выходе она уничтожается). Такая схема работы экономит системные ресурсы и позволяет создать унифицированное рабочее место – безопасное и отвечающее всем требованиям компании. Это подходит для типовых задач, но ведь не все работники выполняют типовые задачи.
VMware View Personal profile management хороша тем, что объединяет лучшее из обоих подходов. ОС Windows давно умеет работать не только с локальными профайлами пользователей, но и теми, что хранятся на сервере. В итоге пользователь получает временную виртуальную машину из образа ОС, но в неё подгружаются личные данные из его профайла на сервере. Такие машины – VMware-linked clones – лучше всего использовать при высокой нагрузке на дисковую память.
Horizon view desktop pools
Horizon view создаёт разные пулы для разных видов виртуальных машин – так их легче администрировать. Например, в пул Manual попадают постоянные физические и виртуальные машины, а Automated Pool содержит «одноразовые», шаблонные. Через интерфейс программы можно управлять и клонами с назначенным пользовательским профайлом. Вот здесь можно почитать об особенностях конфигурации, настройке и сопровождении.
Гипервизор: VMware vSphere 5.5
Платформа VMware vSphere 5.5 нужна для создания VDI и облачных решений. Она состоит из трёх основных уровней: виртуализации, управления и интерфейсного. Уровень виртуализации – это инфраструктура и системное ПО. Уровень управления помогает создавать виртуальное окружение. Интерфейсный – это утилиты на основе на веб-доступа и программы vSphere client.
По рекомендациям VMware и Microsoft в среде виртуализации используются еще и сервисы ядра сети – NTP, DNS, Active Directory и другие.
4. Аппаратное обеспечение Dell
Виртуальные машины разместились на кластере из восьми узлов, которые управляются vSphere. У каждого такого сервера есть PCIe SSD и функции провайдера Fluid Cache. Все они подключены к трем сетям: 10 GB Ethernet iSCSI SAN, сети управления VDI и той, что обеспечивает работу кэша.
Есть и еще один кластер из двух узлов под управлением vSphere. На нём находятся виртуальные машины, которые заставляют функционировать инфраструктуру VDI: vCenter Server, View Connection Server, View Composer Server, SQL Server, Active Directory и т.д. Эти узлы тоже подключены к сетям управления VDI и iSCSI SAN.
У дискового массива Dell Compellent SC8000 спаренные контроллеры и диски трёх типов: Write Intensive (WI) SSD, 15K SAS HDD и 7,2K NL-SAS HDD. Как видим, дисковая подсистема одновременно и производительная, и ёмкая.
Коммутаторы объединены в стек попарно – это обеспечивает отказоустойчивость на сетевом уровне. Они обслуживают все три сети – и клиентскую для виртуальных машин, и управляющую для среды VDI, и iSCSI SAN. Пропускная способность разделяется на основе VLAN, так же выполняется и приоритезация трафика. Оптимальная пропускная способность для этих сетей 40 Гбит/с, но хватит и 10 Гбит/с.
Вот общий план установки:
1. Консоль управления.
2. Сети управления VDI и клиентские.
3. Серверы vSphere для виртуальных машин.
4. Контроллеры Fluid Cache (2 шт.).
5. Коммутаторы SAN (2 шт.).
6. Контроллеры дискового массива (2 шт.).
7. Полки дискового массива (2 шт.).
8. Серверы, обеспечивающие инфраструктуру VDI.
5. Конфигурация компонентов.
Серверы
В каждом из восьми серверов Dell PowerEdge R720, составляющих кластер для VM, установлены:
• два десятиядерных процессора Intel Xeon CPU E5-2690 v2 @ 3.00GHz,
• 256 ГБ оперативной памяти,
• накопитель Dell Express Flash PCIe SSD ёмкостью 350 ГБ,
• сетевая карта Mellanox ConnectX-3,
• гигабитный сетевой контроллер Dual-port Broadcom NetXtreme II BCM57810 10,
• гигабитный сетевой контроллер Quad-port Broadcom NetXtreme BCM5720.
На кластере из двух Dell PowerEdge R720 мы разместили виртуальные машины для Active Directory, VMware vCenter 5.5 server, Horizon View Connection server (основного и запасного), View Composer server, файл-сервера на базе Microsoft Windows Server 2012 R2 и MS SQL Server 2012 R2. Сорок виртуальных машин LoginVSI launcher используются для тестирования установки – они создают нагрузку.
Сеть
Мы использовали в установке три пары свитчей: Force10 S55 1 GB и Force10 S4810 10 GB. Первый отвечал за создание среды VDI и управление серверами, дисковым массивом, коммутаторами, vSphere и т.д. VLAN для всех этих компонентов разные. Вторая пара, Dell Force10 S4810 10 GB, помогала организовать сеть кэширования Fluid Cache. Ещё одна аналогичная пара отвечала за работу сети iSCSI между кластерами и дисковым массивом Compellent SC8000.
Дисковый массив Compellent SC8000
| Роль | Тип | Количество | Пояснения |
| Контроллер | SC8000 | 2 | System Center Operating System (SCOS) 6.5 |
| Полка | Внешние | 2 | 24 отсека для 2,5” дисков |
| Порты | Ethernet 10 Гбит/с | 2 | Front end host connectivity |
| SAS 6 Гбит/с | 4 | Back end drive connectivity | |
| Диски | 400 ГБ WI SSD | 12 | 11 активных и 1 в горячем резерве |
| 300 ГБ 15K SAS | 21 | 20 активных и 1 в горячем резерве | |
| 4 ТБ 7.2K NL-SAS | 12 | 11 активных и 1 в горячем резерве |
Для виртуальных машин служебных серверов мы создали диск ёмкостью 0,5 ТБ, где разместили Active Directory, SQL Server, vCenter Server, View Connection Server, View Composer и файл-сервер. Для профайлов пользователей выделили диск объёмом 2 ТБ (примерно по 2,5 ГБ на каждую машину). Мастер образы ОС разместились на зеркальном диске на 100 ГБ. Наконец, для виртуальных машин решили сделать 8 дисков по 0,5 ТБ каждый.
Виртуальная сеть
На каждом хосте под управлением гипервизора VMware vSphere 5.5 пять виртуальных коммутаторов:
| vSwitch | Назначение |
| vSwitch0 | Управляющая сеть |
| vSwitch1 и vSwitch2 | iSCSI SAN |
| vSwitch3 | Fluid Cache VLAN |
| vSwitch4 | VDI LAN |
Horizon view
Настраивали мы по этой инструкции.
| Роль | Количество | Тип | Память | ЦПУ |
| Horizon View Connection Servers | 2 | VM | 16 ГБ | 8nos |
| View Composer Server | 1 | VM | 8 ГБ | 8nos |
Виртуальные машины
Настройкой исходных образов Windows 7 мы занялись по руководствам VMware и Login VSI. Вот, что у нас получилось:
• VMware Virtual Hardware v8,
• 2 виртуальных ЦПУ,
• 3 ГБ RAM, 1,5 ГБ зарезервировано,
• 25 ГБ дисковой памяти,
• один виртуальный сетевой адаптер, подключенный к сети VDI,
• Windows 7 64-bit.
Руководство VMware Horizon with View Optimization Guide for Windows 7 and Windows 8 можно скачать здесь.
Часть 2: Тестируем, описываем результаты, делаем выводы.
Методы проверки и настройка компонентов
Дальше мы проверяли, как ведет себя система с разными сценариями использования виртуальных машин. Мы хотели добиться того, чтобы восемьсот «виртуалок» работали без ощутимых задержек и обменивались информацией с дисковой подсистемой в районе 80-90 IOPS в течении всего дня. Параллельно мы проверяли работу инсталляции при обычной «офисной» нагрузке – и в течение рабочего дня, и когда создавали виртуальные машины, и когда пользователи входили в систему – например, в начале рабочего дня и после обеденного перерыва. Назовем такие условия Boot&Login Storm.
Для тестирования мы использовали две утилиты – комплексную программу Login VSI 4.0, которая создаёт нагрузку на виртуальные машины и анализирует результаты, а также Iometer – она помогает следить за дисковой подсистемой.
Для того, чтобы создать «стандартную» нагрузку для средней офисной машины, мы:
• Запускали до пяти приложений одновременно.
• Использовали программы Microsoft Internet Explorer, Microsoft Word, Microsoft Excel, Microsoft PowerPoint, PDF reader, 7-Zip, Movie player и FreeMind.
• Заново запускали сценарии примерно каждые 48 минут, пауза – 2 минуты.
• Каждые 3-4 минуты замеряли время отклика на действия пользователя.
• Установили скорость печати на уровне 160 мс на символ.
Имитировали высокую нагрузку с помощью того же теста, а чтобы активировать обмен с дисковой подсистемой на каждой виртуальной машине, запускали Iometer. Стандартный набор тестов генерировал 8-10 IOPS на машину, при высокой нагрузке этот показатель составлял 80-90 IOPS. Базовые образы ОС в Horizon view pool мы создали со стандартными настройками и набором ПО для LoginVSI, плюс дополнительно установили Iometer, который запускался из logon script.
Для мониторинга работы и записи показателей под нагрузкой использовали вот такие инструменты:
• Dell Compellent Enterprise Manager для оценки производительности Fluid Cache и Compellent SC8000 storage array,
• VMware vCenter statistics для мониторинга vSphere,
• Login VSI Analyzer для оценки среды пользователей.
Критерий оценки работы дисковой подсистемы – время отклика на действия пользователя. Если оно не выше 10 мс, то все в порядке.
Загрузка системы на уровне гипервизора:
• Нагрузка на любом ЦПУ в кластере не должна быть выше 85%.
• Минимальный memory ballooning (совместное использование области памяти виртуальными машинами).
• Нагрузка на каждый из сетевых интерфейсов – не больше 90%.
• Повторная отправка пакетов TCP/IP – не больше 0,5%.
Максимальное количество запросов от виртуальных машин вычисляли по методике VSImax.
Единый набор виртуальных машин создали на основе базового образа Windows 7 с помощью VMware Horizon View Administrator interface.
Настройки были такие:
• Automatic Desktop Pool: машины создаются по запросу на «включение».
• Каждому пользователю назначается рандомная машина.
• View Storage Accelerator разрешён для всех машин с периодом обновления 7 дней.
• 800 виртуальных машин расположены на 8 физических (по 100 на каждой).
• Исходные образы ОС находятся на отдельных дисках.
Результаты тестирования и анализ
Сценарии были такие:
1. Boot Storm: максимальная нагрузка на систему хранения данных, когда одновременно много пользователей «включают», то есть, создают виртуальные машины.
2. Login Storm: еще одна сильная нагрузка на дисковую подсистему, когда пользователи входят в систему в начале рабочего дня или после перерыва. Для этого теста мы включили виртуальные машины и оставили до входа в систему на 20 минут без каких-либо действий.
3. Стандартная нагрузка: после того, как пользователи вошли в систему, запускался сценарий «стандартной» офисной работы. За откликом системы на действия пользователя наблюдали по параметру VSImax (Dynamic) из Login VSI.
4. Высокая нагрузка: аналогично стандартной, но показатели IOPS в 10 раз выше.
Boot Storm
Прим.: Здесь и далее указаны задержки (latency) со стороны СХД
800 машин во время теста генерировали в среднем 115 000 IOPS. Преобладали операции записи. Через четыре минуты все машины были доступны для работы.
Login Storm и стандартная нагрузка
Мы запрограммировали Login VSI на вход в 800 виртуальных машин примерно через час после их загрузки. Пиковые показатели IOPS не превысили 6 500 на всю платформу (или 8-10 на машину). Запросов на запись было больше, чем во время запуска машин и дальнейшей работы, так как создавался профайл пользователя, запускались сервисы ОС и прикладные приложения. Спустя время, необходимое для стабилизации, ОС кэширует основные пользовательские и программные данные в оперативной памяти – нагрузка на дисковую подсистему снижается. На уровне Fluid Cache при максимальных 6 500 IOPS операции записи кэшируются на 100%, чтения – около 95%. Поток данных в 98 Мбит/с вызывает задержку обращения к диску всего на 2 мс.
Производительность на физическом уровне
Статистику производительности физических компонентов системы vSphere мы снимали с помощью VMware vCenter Server. За всё время теста нагрузка на процессоры, память и все уровни системы хранения данных была примерно одинаковая. Результаты оказались такими, какие мы и ожидали увидеть, ставя задачу:
• Загрузка ЦПУ не больше 85%.
• Активное используемое дисковое пространство не больше 80% (когда создавались виртуальные машины) и не больше 60% во время тестов.
• Memory ballooning минимальная (местами вообще не применялась).
• Нагрузка на сеть около 45%, включая iSCSI, SAN, VDI LAN, Management LAN и vMotion LAN.
• Средняя задержка чтения/записи на адаптерах дисковой СХД – 2 мс.
Это график производительности системы с точки зрения пользователя. Он зависит от количества машин, которые работают одновременно:
В реальной жизни это значит, что на нашей системе можно спокойно разворачивать рабочие места для тысячи пользователей. Задержек ОС не будет, даже если все станут активно работать в одно и то же время.
Вот какие выводы можно сделать по трём тестам «обычного» пользовательского окружения:
• Тестовая система Dell Fluid Cache for SAN-based VDI вполне справилась с задачей: одновременно могут работать 800 пользователей.
• Операции записи составляют 98%, и только 2% приходится на операции чтения.
• Ни один из ресурсов системы не загружался больше, чем мы рассчитывали.
• Login Storm в течении 20 минут не превышал 8-10 IOPS и не вызывал задержек обращения к диску больше 2 мс.
Тяжёлая нагрузка
Такими были настройки Iometer для большой нагрузки на систему ввода/вывода: размер блока – 20 КБ, 80% операций записи, из них 75% не из кэша, 25 мс Burst Delay.
На уровне Fluid Cache максимальная интенсивность ввода/вывода достигала 72 000 (по 90 IOPS на виртуальную машину). Кэширование операций записи – 100%, чтения – 95%. При пиковой производительности СХД в 900 Мбит/с максимальная задержка была 7,5 мс.
Нагрузка на физическом уровне установки оказалась такой же, как и в предыдущем тесте. СХД, ЦПУ и сетевые адаптеры работали так, как мы и запланировали.
Это график отклика системы на действия пользователя. Он зависит от количества машин, которые работают одновременно:
Наши выводы из тестирования под высокой нагрузкой:
• Dell VDI на базе Dell Fluid Cache for SAN можно использовать для одновременной работы 800 виртуальных машин, которые интенсивно обмениваются данными с дисковой памятью.
• 98% приходится на операции записи, 2% – на операции чтения.
• Ни один из системных ресурсов серверов базирования, которые использует vSphere, не был задействован по максимуму. Обозначенные пределы не превышались.
• Высокая нагрузка на виртуальные машины создала задержку в 7,5 мс при общей интенсивности обмена в 72 000 IOPS (90 IOPS на каждую из 800 машин). Это тоже в рамках приемлемой скорости реакции ОС на действия пользователя.
Рекомендации
VDI – среда для виртуальных машин с Dell Fluid Cache for SAN.
• Если использовать перемещаемые профайлы пользователей и хранить данные в перенаправленных папках, то нагрузка на систему ввода/вывода будет ниже. Это имеет значение во время пиковых нагрузок, когда создаются виртуальные машины, а пользователи массово входят в систему. Это же относится и к сетевым папкам общего доступа. Такая схема экономит системные ресурсы и облегчает администрирование. Рекомендуем выделить для пользовательских данных отдельный высокоскоростной дисковый массив.
• Учитывая высокую нагрузку на систему при создании виртуальных машин, предлагаем держать наготове несколько готовых «виртуалок». В VMware Horizon View можно настроить количество рабочих мест, которые всегда будут доступны пользователям.
• Рекомендуем настроить исходные образы Windows 7 и 8 по этой инструкции. Если отключить ненужные системные службы, то на клиенте ускорится авторизация и прорисовка экрана, а общая производительность только вырастет.
Настройка инсталляции:
• Следуйте рекомендациям VMware и Dell при установке и конфигурировании vSphere.
• Создайте отдельные виртуальные коммутаторы для разделения трафика iSCSI SAN, VDI, vMotion и управляющей сети.
• Для отказоустойчивости назначьте каждый сетевой путь минимум двум физическим адаптерам.
• Зарезервируйте минимум 10% физических накопителей, чтобы сервис был доступнее.
Сетевой уровень:
• Используйте не меньше двух физических сетевых адаптеров под сеть VDI на каждом из серверов vSphere.
• Когда вы используете VLAN для разделения трафика в пределах одной физической сети, разносите про разным виртуальным сетям логические сети VDI, vMotion и управляющую.
• На физическом уровне разделяйте сети iSCSI SAN и Fluide Cache. Это повысит производительность системы в целом.
• Виртуальные коммутаторы vSphere по умолчанию ограничены 120 портами. Если машинам нужно больше сетевых подключений, то после изменения настроек сервер придётся перегрузить.
• На коммутаторах iSCSI SAN запретите протокол Spanning tree. Для портов, подключённых и к серверам, и к адаптерам СХД, разрешите PortFast. Jumbo frames и Flow control, если их поддерживают коммутаторы и адаптеры, нужно активировать на всех компонентах сети iSCSI. Здесь можно прочитать об этом подробнее.
Система хранения данных:
• Dell SC Compellent storage arrays отлично работает в паре с технологией Fluid Cache. Это производительное и относительно недорогое решение для среды Dell VDI.
• Fluid Cache улучшает работу СХД при обмене данными между сервером и дисковым массивом. Под управлением ПО Storage Center 6.5 вычислительный кластер, сетевое окружение и система хранения данных работают на полную силу. Единый сервер не может этим похвастаться.
• Рекомендуем использовать отдельные дисковые массивы для исходных образов ОС и пользовательских виртуальных машин. Так проще администрировать диски, замерять производительность и отслеживать узкие места. К тому же, это будет хорошей основой для дальнейшего масштабирования системы.
• Рекомендуем выделить дисковые массивы для перемещаемых пользовательских профайлов и сетевых папок с общим доступом, а также системных серверов и служб общего пользования.
