Дано: 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. Подключение к Диспетчеру подключений. Состоит из следующих шагов: 2. Аутентификация/авторизация в LDAP: 3. Запрос списка рабочих столов: 4. Запрос билета (тикета) на подключение: 5. Запуск протокола доставки рабочего стола: 6. Подключение по протоколу доставки рабочего стола: До этого тестирования мы уже проводили внутреннее нагрузочное, так что к задаче приступали с уже кое-какими опытом — и инструментами. У нас были в наличии: На момент постановки задачи мы могли сделать несколько виртуальных машин, в каждой из которых запустить нагрузочные скрипты. Далее ручками администратора в каждой машине нужно было бы настроить запуск нагрузки на одно и то же время без интервала между запусками Клиента и без рандомизации. После чего админ также ручками должен собрать со всех машин отчеты и свести в один. Короче говоря, имеющихся инструментов было недостаточно для данной задачи. Поэтому нагрузочные инструменты мы доработали: В итоге в час X на всех нагрузочных виртуальных машинах запускаются экземпляры Клиента, в которых проходят все вышеописанные этапы подключения. При этом инструмент позволяет использовать сколь угодное множество нагрузочных виртуальных машин.  Вот так мы добились нагрузки на серверные компоненты VDI-решения в 16 тысяч пользователей чуть более чем за секунду.  Теперь непосредственно про стенд. Включал он следующее оборудование и виртуальные машины: Все оборудование для теста было предоставлено заказчиком, за что ему огромное спасибо. Клиенты, виртуальные рабочие столы, серверные компоненты системы управления виртуализацией и VDI-решения запускались в операционной системе Альт Линукс 7 СПТ. OpenLDAP этой ОС использовался в качестве LDAP.  Всего в тесте принимало участие 96 хостов: На схеме есть еще балансировщик F5, который был у заказчика. Он занимался распределением пользователей по ДП с учетом их загруженности. ДП систематически отправляют на балансировщик комплексный коэффициент своей загруженности от 0 до 1, который учитывается при распределении пользователей. Также мы ввели несколько особых условий проведения теста. Во-первых, из нагрузочных машин Клиенты запускают в качестве протокола доставки рабочего стола SSH, а не RX, который мы на самом деле используем. В отчете данный факт повлиял на время ожидания запуска и подключения непосредственно протокола доставки рабочего стола. Решение такое приняли, согласовав с заказчиком, по следующим причинам:  Во-вторых, мы не генерировали трафик через ДП для имитации работы пользователя внутри виртуального рабочего стола. На то тоже есть несколько причин:  В-третьих, мы не делали нагрузку CPU и дискового ввода-вывода внутри рабочих столов. Запуск нагрузки такого типа — это нагрузка на платформу виртуализации: гипервизор и СХД. Такие тесты Скалы-Р мы проводим систематически с обновлением гипервизора и распределенного хранилища или тестированием новой серверной платформы. Кроме того, есть инсталляции, которые годами уже работают у наших Заказчиков. В общем, в платформе виртуализации мы уверены. Так что главным тестируемым компонентом выступали БМ (в количестве 5 штук). Испытание мы решили провести в три этапа, наращивая нагрузку: в первый проход мы подключили 6080 пользователей, во второй — 12000 и, наконец, в третий — 16000. Результат нас порадовал! Мы также составили графики распределения пользователей по времени, которое у них заняло подключение в рабочий стол. Временную шкалу мы разбили на карманы, по оси Y расположили количество пользователей, чье время выполнения теста входит в данный карман времени. График распределения для 6 080 пользователей: График распределения для 12 000 пользователей: График распределения для 16 000 пользователей: Максимальное время прохождения теста мы разбили на интервалы в 5 секунд и вычислили количество пользователей, время выполнения теста которых уложилось в тот или иной интервал от минимального до максимального времени выполнения теста. Например, для 736 пользователей полное время прохождение теста составило от 130 до 135 секунд, а для 18 пользователей от 315 до 320 секунд. Получилась такая таблица: Таким образом, мы получили, что для 80% пользователей время выполнения теста не превысило: Вот так выглядит график распределения времени каждого из действий теста:  Цель испытаний мы достигли, все испытания прошли успешно, ошибок зафиксировано не было, а система оказалась достаточно производительной для серьезного вызова. Да, система оказалась способна принять подключение 6 080, 12 000 и 16 0000 пользователей в течение 1 секунды, а затем планомерно обрабатывать их очередь на авторизацию, получение списка рабочих столов, получение билета на подключение к рабочему столу.  Конечно, чем больше подключается пользователей — тем дольше процесс. Но даже в весьма маловероятном случае подключения шестнадцати тысяч юзеров разом, самые везучие будут подключаться немногим дольше минуты, а самые неудачливые — 5 минут 18 секунд. В среднем же — всего-навсего около трех минут. Решение оказалось нагрузоустойчивым, и с принятым вызовом мы справились!