16 тысяч подключений в секунду: как мы тестировали СКАЛУ-Р Виртуальное Рабочее Место
06.05.2020
Задача: протестировать систему на эдакий logon storm, при котором имитируется, как 16 000 пользователей одновременно (в течение 1-2 секунд) подключаются к инфраструктуре VDI и своим виртуальным рабочим столам, проходя все этапы авторизации и подключения. Цель: наш VDI должен выдержать нагрузку. Пользователи должны ждать подключения не более 10 минут.
Дано: 96 серверов, 16 000 виртуальных рабочих мест, 160 нагрузочных виртуальных машин и наш софт: система управления платформой виртуализации Скала-Р Управление (СУПВ) и VDI-решение Скала-Р Виртуальное Рабочее Место (ВРМ).

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

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

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

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

В каждом 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. Подключение к Диспетчеру подключений. Состоит из следующих шагов:

2. Аутентификация/авторизация в LDAP:

3. Запрос списка рабочих столов:

4. Запрос билета (тикета) на подключение:

5. Запуск протокола доставки рабочего стола:

6. Подключение по протоколу доставки рабочего стола:

Скала-Р стойка.jpeg

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Стойка 2.jpeg

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

Испытание мы решили провести в три этапа, наращивая нагрузку: в первый проход мы подключили 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

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

График 1.jpeg

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

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

График 2.jpeg

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

График 3.jpeg

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

График 4.jpeg

Максимальное время прохождения теста мы разбили на интервалы в 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% пользователей время выполнения теста не превысило:

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

График 5.jpeg

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

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

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