Дано: 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); настраивает рабочий стол перед подключением пользователя; исполняет команды БМ.
Корректное нагрузочное тестирование должно быть как можно ближе к реальным условиям. Поэтому под катом вы можете ознакомиться со всеми этапами подключения пользователя в виртуальный рабочий стол.
1. Подключение к Диспетчеру подключений. Состоит из следующих шагов:
- При запуске Клиент ВРМ собирает информацию об устройстве, на котором его запустили. На основе аппаратной конфигурации формирует уникальный hardware ID(HWID).
- Далее происходит подключение к ДП и авторизация устройства доступа. Клиент ВРМ передает через ДП HWID Брокер-менеджеру. БМ смотрит в своей БД в Postgre текущую политику и авторизует устройство. Если авторизация прошла неудачно, пользователь получит ошибку и даже не увидит окна ввода данных для авторизации. Если авторизация прошла успешно, ОК передается на ДП, который в свою очередь передает Клиенту текущую политику аутентификации. Одна из четырех: логин-пароль; сертификат; двухфакторная аутентификация; либо логин-пароль, либо сертификат. В рамках нагрузочного тестирования используется пара логин-пароль.
2. Аутентификация/авторизация в LDAP:
- Клиент получил текущую политику и показал окно ввода логина-пароля пользователю. Пользователь вводит логин-пароль.
- Данные передаются по управляющему каналу через ДП Брокер-менеджеру.
- БМ производит авторизацию пользователя в LDAP/Kerberos.
- Если неверный логин-пароль, результат передается через ДП Клиенту. Пользователь видит ошибку.
- Если все успешно, но LDAP сообщает, что пароль пользователя «протух», результат передается через ДП Клиента. Пользователь видит окно смены пароля.
- Если в LDAP все прошло успешно, БМ проверяет, не «протух» ли пароль пользователя по парольной политике Брокер-менеджера. Если «протух» — запрашиваем смену пароля.
3. Запрос списка рабочих столов:
- Если в LDAP авторизация прошла успешно, Клиент ВРМ передает через ДП запрос на получение списка рабочих столов. Запрос попадает одному из БМ.
- БМ получает из LDAP список групп, в которых состоит пользователь.
- В собственной БД находит персонализированные рабочие столы, назначенные на УЗ пользователя, и пулы сессионных рабочих столов, на которые назначены группы пользователей, в которых данная УЗ состоит. Итоговый список передается Клиенту через ДП.
- Клиент отображает список доступных рабочих столов и пулов рабочих столов для подключения.
- Если в списке доступен только 1 виртуальный рабочий стол (или сессионный пул), Клиент инициирует подключение к нему автоматически. В ином случае пользователь выбирает, к чему подключаться.
4. Запрос билета (тикета) на подключение:
- Запрос на подключение передается через ДП, к которому пользователь подключен.
- Если запрос на подключение к персонализированному столу, БМ дает команду Агенту на подготовку рабочего стола к подключению.
- Если это запрос на подключение к сессионному пулу (доступ к которому определяется по членству в группе LDAP), БМ определяет:
- Агент, получив команду от БМ, настраивает:
- Агент рапортует Брокер-менеджеру о готовности к подключению пользователя.
- БМ передает через ДП «тикет» на подключение к рабочему столу Клиенту.
5. Запуск протокола доставки рабочего стола:
- Клиент создает TLS туннель до Диспетчера подключений. После чего запускает клиентскую часть протокола доставки рабочего стола с параметрами, указанными в VDI-Клиенте через созданный туннель. Адресом для подключения для протокола доставки рабочего стола выступает localhost с определенным портом.
6. Подключение по протоколу доставки рабочего стола:
- После вызова клиентской части протокола, ждем, пока он начнет подключаться к localhost, затем трафик попадет на ДП.
- Диспетчер подключений идентифицирует трафик протокола доставки рабочего стола конкретного пользователя и проксирует его в рабочий стол, для которого был получен тикет на подключение.
- В ОС виртуального рабочего стола производится сквозная авторизация пользователя LDAP (пользователь ничего дополнительно не вводит, он уже авторизовался в Клиенте ВРМ, и этого достаточно) для этого действия. Агент подготовил рабочий стол еще на этапе создания (добавлял в домен или настраивал авторизацию LDAP/Kerberos). Если в процессе подготовки что-то пошло не так, то рабочий стол не будет считаться подготовленным, и ни один пользователь его не получит. Короче говоря, если все этапы до этого прошли успешно, то авторизация в ОС рабочего стола тоже пройдет успешно и автоматически, мы об этом заботимся и бракованные столы пользователям не выдаем.
- На устройстве доступа пользователя отображается активное подключение в виртуальный рабочий стол.
Генерация нагрузки и сбор результатов
До этого тестирования мы уже проводили внутреннее нагрузочное, так что к задаче приступали с уже кое-какими опытом — и инструментами. У нас были в наличии:
- Консольный Клиент, который в качестве входных параметров может принимать логин-пароль пользователя и адрес ДП. У него нет 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, который мы на самом деле используем. В отчете данный факт повлиял на время ожидания запуска и подключения непосредственно протокола доставки рабочего стола. Решение такое приняли, согласовав с заказчиком, по следующим причинам:
- Запуск протокола доставки требует больших ресурсов от нагрузочных ВМ, экземпляров протокола должно запуститься по количеству пользователей этой нагрузочной ВМ. Мы пробовали, но аппаратных ресурсов не хватало.
- Обнаружили, что при множественном запуске клиента RX (десятки экземпляров) в рамках одной ОС, появлялись проблемы и ошибки в работе протокола. Как следствие, часть пользователей не подключалась в рабочий стол и не отмечалась на веб-серверах из-за ошибок протокола доставки. Исследовать эту проблему смысла не было, протокол просто не предназначен для использования в таком сценарии.
- Протокол доставки рабочего стола RX тестировали отдельно, проверяя его функциональные возможности и стабильность работы (в том числе на спутниковых каналах). Тестировали, разумеется, в нормальном режиме — 1 клиент RX в рамках одной ОС.
Во-вторых, мы не генерировали трафик через ДП для имитации работы пользователя внутри виртуального рабочего стола. На то тоже есть несколько причин:
- В ранее проводимых тестах (до проведения этого нагрузочного тестирования) мы нагружали диспетчеры подключений и получили эмпирическую цифру в 2000 одновременных подключений через один ДП. В том тесте трафик генерировали запуском GIF-ки внутри виртуального рабочего стола.
- ДП можно создать сколь угодно много, главное — распределить по ним пользователей (в этом тесте для этих целей использовался F5). Этот компонент без проблем масштабируется.
- Спрогнозировать, какой реально трафик будет генерироваться конкретными пользователями, крайне затруднительно.
В-третьих, мы не делали нагрузку 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 секунд. В среднем же — всего-навсего около трех минут.
Решение оказалось нагрузоустойчивым, и с принятым вызовом мы справились!
