Дано: 96 серверов, 16 000 виртуальных рабочих мест, 160 нагрузочных виртуальных машин и наш софт: система управления платформой виртуализации Скала-Р Управление (СУПВ) и VDI-решение Скала-Р Виртуальное Рабочее Место (ВРМ).

Задача: протестировать систему на эдакий logon storm, при котором имитируется, как 16 000 пользователей одновременно (в течение 1-2 секунд) подключаются к инфраструктуре VDI и своим виртуальным рабочим столам, проходя все этапы авторизации и подключения. Цель: наш VDI должен выдержать нагрузку. Пользователи должны ждать подключения не более 10 минут.

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

Если вам интересно, как такое масштабное тестирование было организовано и что конкретно отражает эта диаграмма — добро пожаловать под кат.

Архитектура и постановка задачи

В каждом VDI-решении есть «брокер подключений», принимающий на сервере и обрабатывающий все запросы пользователей. У разных производителей он устроен по-разному; наш брокер подключений состоит из двух частей: диспетчера подключений и брокер-менеджера. Для больших вендоров VDI-решений это вполне стандартная архитектура. Диспетчер терминирует на себе подключения пользователей, которым нужен сетевой доступ только к нему (этот компонент размещается в ДМЗ), — а напрямую к инфраструктуре (и к собственному виртуальному рабочему столу) они доступа не имеют. Подробнее, как это работает, рассмотрим ниже.

Нашей целью было протестировать компоненты именно VDI-решения на единовременное, в течение 1-2 секунд, подключение 16000 пользователей, их авторизацию и затем доступ к рабочим столам. Было поставлено ограничение по времени: пользователи должны подключиться менее чем за 10 минут. На самом деле заказчик работает примерно с вдвое меньшим количеством одновременных подключений, которые, конечно, не могут «по гудку» подключиться в одну секунду. Также, разумеется, что 10 минут ожидания достаточно долго, чтобы «Марья Ивановна» начала нервничать, однако для данного теста поставили именно такую планку. В общем, нам самим стало интересно, как добиться такой одновременной нагрузки, и посмотреть, потянет ли наша система такой logon storm!

В целом архитектура решения выглядит так:

Скала-Р — гиперконвергентная платформа виртуализации, включающая гипервизор, программно-определяемое СХД и систему управления платформой виртуализации Скала-Р Управление (в команде зовем коротко СУПВ).

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

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

Клиент ВРМ (далее Клиент) — клиентское ПО, которое устанавливается на устройство доступа (АРМ) пользователя. Представляет графический интерфейс взаимодействия конечного пользователя с инфраструктурой VDI. Занимается настройкой и запуском протокола доставки рабочего стола. Своего протокола доставки рабочего стола у нас нет, на текущий момент это готовые решения, которые мы поддерживаем. Для виртуальных рабочих столов Windows — RDP, для виртуальных рабочих столов Linux — RX@Etersoft. Клиент работает с диспетчером подключений по двум каналам: управляющему (авторизация, запрос списка рабочих столов, запрос на подключение к рабочему столу и т. д.) и каналу протокола доставки рабочего стола.

Диспетчер подключений (далее ДП) — по сути, прокси в ДМЗ. Запросы по управляющему каналу передает брокер-менеджеру и обратно пользователю. Трафик протокола доставки рабочего стола проксирует от пользователя напрямую в рабочий стол.

Брокер-менеджер (далее БМ) получает запросы на авторизацию (соответственно, авторизует пользователя в Active Directory/OpenLDAP), на получение списка доступных рабочих столов, на подключение к рабочему столу; занимается подготовкой рабочего стола к подключению через VDI-агента; занимается автоматизацией жизненного цикла рабочих столов, отсчитывает тайм-ауты и еще много чего другого.

VDI-агент (далее Агент) внутри виртуального рабочего стола настраивает рабочий стол при создании (добавляет в домен AD или настраивает авторизацию LDAP/Kerberos в случае с OpenLDAP); настраивает рабочий стол перед подключением пользователя; исполняет команды БМ.

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

Генерация нагрузки и сбор результатов

До этого тестирования мы уже проводили внутреннее нагрузочное, так что к задаче приступали с уже кое-какими опытом — и инструментами. У нас были в наличии:

• Консольный Клиент, который в качестве входных параметров может принимать логин-пароль пользователя и адрес ДП. У него нет GUI, в остальном он полноценный Клиент и ведет себя соответствующим образом;
• нагрузочный скрипт, в котором указывается список логинов и паролей пользователей, адрес ДП и параметры теста (момент начала, продолжительность, частота запусков Клиента с их рандомизацией, симулирующей их хаотичность). Скрипт же собирает логи обо всех этапах подключения каждого пользователя с фиксации временных параметров;
• возможность вызвать скрипт или команду внутри виртуального рабочего стола в случае успешного подключения.

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

Короче говоря, имеющихся инструментов было недостаточно для данной задачи. Поэтому нагрузочные инструменты мы доработали:

• создали маленький скрипт, который вызывается внутри виртуального рабочего стола при успешном подключении. Это curl с измененным user-агентом, который обращается к веб-серверу apache и оставляет логин пользователя. Так мы добиваемся подтверждения, что пользователь прошел все этапы подключения;
• сделали веб-сервер, на котором отмечаются пользователи, прошедшие все этапы подключения, оставляя свои логин и временную метку;
• сделали «оркестратор» нагрузочного теста, в котором задавались параметры для всех нагрузочных виртуальных машин. Перед запуском теста он синхронизирует все нагрузочные машины и веб-сервер по NTP. Далее все нагрузочные машины через него настраиваются, в cron создается задача на старт теста, а по его окончании собираются отчеты со всех нагрузочных машин и веб-сервера. Они затем сводятся в один большой отчет в формате CSV.

В итоге в час X на всех нагрузочных виртуальных машинах запускаются экземпляры Клиента, в которых проходят все вышеописанные этапы подключения. При этом инструмент позволяет использовать сколь угодное множество нагрузочных виртуальных машин.

Вот так мы добились нагрузки на серверные компоненты VDI-решения в 16 тысяч пользователей чуть более чем за секунду.

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

Все оборудование для теста было предоставлено заказчиком, за что ему огромное спасибо. Клиенты, виртуальные рабочие столы, серверные компоненты системы управления виртуализацией и VDI-решения запускались в операционной системе Альт Линукс 7 СПТ. OpenLDAP этой ОС использовался в качестве LDAP.

Всего в тесте принимало участие 96 хостов:

• кластер из 14 хостов под инфраструктурные ВМ, на котором развернуто две инсталляции нашего ПО:
• 2 хоста для СУБД PostgreSQL (на таких нагрузках в виртуальных машинах жить он не хотел, поэтому вынесли на железо);
• кластер из 16 хостов под генерацию нагрузки, на которых размещались нагрузочные ВМ, оркестратор и веб-сервер;
• 4 кластера по 16 хостов для размещения виртуальных рабочих столов пользователей. По 4 000 виртуальных рабочих места на каждом.

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

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

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

1. Запуск протокола доставки требует больших ресурсов от нагрузочных ВМ, экземпляров протокола должно запуститься по количеству пользователей этой нагрузочной ВМ. Мы пробовали, но аппаратных ресурсов не хватало.
2. Обнаружили, что при множественном запуске клиента RX (десятки экземпляров) в рамках одной ОС, появлялись проблемы и ошибки в работе протокола. Как следствие, часть пользователей не подключалась в рабочий стол и не отмечалась на веб-серверах из-за ошибок протокола доставки. Исследовать эту проблему смысла не было, протокол просто не предназначен для использования в таком сценарии.
3. Протокол доставки рабочего стола RX тестировали отдельно, проверяя его функциональные возможности и стабильность работы (в том числе на спутниковых каналах). Тестировали, разумеется, в нормальном режиме — 1 клиент RX в рамках одной ОС.

Во-вторых, мы не генерировали трафик через ДП для имитации работы пользователя внутри виртуального рабочего стола. На то тоже есть несколько причин:

1. В ранее проводимых тестах (до проведения этого нагрузочного тестирования) мы нагружали диспетчеры подключений и получили эмпирическую цифру в 2000 одновременных подключений через один ДП. В том тесте трафик генерировали запуском GIF-ки внутри виртуального рабочего стола.
2. ДП можно создать сколь угодно много, главное — распределить по ним пользователей (в этом тесте для этих целей использовался F5). Этот компонент без проблем масштабируется.
3. Спрогнозировать, какой реально трафик будет генерироваться конкретными пользователями, крайне затруднительно.

В-третьих, мы не делали нагрузку CPU и дискового ввода-вывода внутри рабочих столов. Запуск нагрузки такого типа — это нагрузка на платформу виртуализации: гипервизор и СХД. Такие тесты Скалы-Р мы проводим систематически с обновлением гипервизора и распределенного хранилища или тестированием новой серверной платформы. Кроме того, есть инсталляции, которые годами уже работают у наших Заказчиков. В общем, в платформе виртуализации мы уверены.

Так что главным тестируемым компонентом выступали БМ (в количестве 5 штук).

Результаты испытаний

Испытание мы решили провести в три этапа, наращивая нагрузку: в первый проход мы подключили 6080 пользователей, во второй — 12000 и, наконец, в третий — 16000. Результат нас порадовал!

Подробный анализ результатов тестирования с таблицами и диаграммами можно посмотреть под вот этим катом

Параметр	Проход 1	Проход 2	Проход 3
Общее количество пользователей, шт.	6080	12000	16000
Количество пользователей успешно прошедших тест, шт.	6080	12000	16000
Количество ошибок, шт.	0	0	0
Скорость подключения пользователей в секунду, шт.	6080	12000	16000
Общее время прохождения теста, время (чч: мм: сс, мс)	00:01:57,942	00:03:35,760	00:05:19,593
Минимальное время прохождения теста для одного пользователя, с	26,71	50,09	67,08
Максимальное время прохождения теста для одного пользователя, с	117,02	214,84	318,75
Среднее время прохождения теста для одного пользователя, с	63,28	127,90	184,49
Среднее время операции подключения к Диспетчеру подключений, с	0,25	0,64	1,05
Среднее время авторизации, с	13,59	25,09	32,79
Среднее время получения списка РС, с	15,77	31,89	43,73
Среднее время получения билета на подключение к РС, с	29,78	64,09	99,19
Среднее время запуска RX-клиента, с	3,01	4,98	5,14
Среднее время подключения в РС, с	0,88	1,20	2,61

Время прохождения полного теста для одного пользователя:

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

График распределения для 6 080 пользователей:

График распределения для 12 000 пользователей:

График распределения для 16 000 пользователей:

Максимальное время прохождения теста мы разбили на интервалы в 5 секунд и вычислили количество пользователей, время выполнения теста которых уложилось в тот или иной интервал от минимального до максимального времени выполнения теста. Например, для 736 пользователей полное время прохождение теста составило от 130 до 135 секунд, а для 18 пользователей от 315 до 320 секунд.

Получилась такая таблица:

Параметр	Проход 1	Проход 2	Проход 3
Количество пользователей, шт.	6080	12000	16000
Время теста для 40%, с	53,17	104,04	149,14
Время теста для 50%, с	56,77	114	173,53
Время теста для 60%, с	61,33	140,06	201,19
Время теста для 70%, с	68,70	156,57	218,65
Время теста для 80%, с	82,36	169,68	244,99
Время теста для 90%, с	97,73	187,07	271,75
Максимальное время теста для одного пользователя, с	116,10	214,48	317,30
Соотношение максимального времени теста, к времени 80% пользователей	1,41	1,26	1,30

Таким образом, мы получили, что для 80% пользователей время выполнения теста не превысило:

• 83 секунд в тесте для 6080 пользователей, что в 1,41 раза меньше максимального времени;
• 170 секунд в тесте для 12 000 пользователей, что в 1,26 раза меньше максимального времени;
• 245 секунд в тесте для 16 000 пользователей, что в 1,30 раза меньше максимального времени.

Вот так выглядит график распределения времени каждого из действий теста:

Цель испытаний мы достигли, все испытания прошли успешно, ошибок зафиксировано не было, а система оказалась достаточно производительной для серьезного вызова. Да, система оказалась способна принять подключение 6 080, 12 000 и 16 0000 пользователей в течение 1 секунды, а затем планомерно обрабатывать их очередь на авторизацию, получение списка рабочих столов, получение билета на подключение к рабочему столу.

Конечно, чем больше подключается пользователей — тем дольше процесс. Но даже в весьма маловероятном случае подключения шестнадцати тысяч юзеров разом, самые везучие будут подключаться немногим дольше минуты, а самые неудачливые — 5 минут 18 секунд. В среднем же — всего-навсего около трех минут.

Решение оказалось нагрузоустойчивым, и с принятым вызовом мы справились!