Связку «Альт Домен» и Termidesk можно включать в проект как документированный вариант доменной аутентификации. Но эта совместимость не отвечает на главный вопрос закупки: сколько пользователей выдержит физический сервер.
Если тебе нужно защитить проект перед директором, раздели два утверждения. Первое: Termidesk умеет обращаться к «Альт Домен» через LDAP или LDAPS. Второе: выбранная серверная конфигурация выдерживает 100 одновременных VDI-сессий. Первое подтверждает документация. Второе придётся доказать расчётом и нагрузочным тестом.
Документация подтверждает интеграцию, а не сертификацию связки
В руководстве «Добавление домена аутентификации Альт Домен в Termidesk» описано подключение службы каталогов. Сервер задают по IP-адресу или доменному имени. Для LDAP используют порт 389, для LDAPS — 636.
Там же перечислены параметры поиска пользователей и групп, DN учётной записи и выбор порталов фермы. При PKINIT атрибутом идентификатора пользователя служит name. Клиент Termidesk младше версии 6.0 поддерживает только формат sAMAccountName.
Этого достаточно для формулировки «интеграция документирована». Формулировка «программный комплекс сертифицирован» требует другого основания.
В таблице совместимости Termidesk Connect 1.3 есть сертификаты для «Альт Виртуализация 11», РЕД Виртуализация 7.3, «Роса Виртуализация 4» и zVirt 5.0. «Альт Домен» отдельной строкой в таблице не указан.
Поэтому в техническом задании лучше записать точное утверждение: «Termidesk подключается к службе каталогов „Альт Домен“ по документированному сценарию». Упоминать сертификат совместимости двух продуктов можно только после того, как поставщик предъявит документ с их точными названиями и версиями.
Сервер считают по VDI-сессиям, а не по числу учётных записей
«Альт Домен» проверяет учётную запись. Termidesk выдаёт пользователю виртуальное рабочее место. Процессор, память и диски физического узла исполняют виртуальные машины.
По описанию продуктовой линейки «Базальт СПО», ALT Workstation устанавливается на физические и виртуальные машины и может работать как тонкий клиент VDI. ALT Virtualization предоставляет виртуализацию вычислений, сети и хранения. Эти сведения подтверждают архитектурный сценарий, но не ёмкость конкретного сервера.
Даже 500 заведённых учётных записей могут дать лишь 80 одновременных подключений. И наоборот: 100 пользователей с браузером и офисными документами нагружают узел иначе, чем 100 дизайнеров с обработкой фото и видео. Закупку определяет одновременная нагрузка.
Спецификация под 100 офисных VDI-сессий
Считаем стартовую конфигурацию для 100 одновременно работающих пользователей. Типовая сессия включает браузер, документы, таблицы и одну-две внутренние системы. Обработку видео, трёхмерную графику и вычисления на GPU в этот расчёт не включаем.
Принимаем четыре проектных допущения:
- одной виртуальной машине нужны 2 vCPU;
- на одну сессию выделяем 4 ГБ памяти;
- четыре виртуальных процессора делят одно физическое ядро;
- к расчётной памяти добавляем 20% на гипервизор и запас.
Процессорный расчёт выглядит так:
100 сессий × 2 vCPU ÷ 4 = 50 физических ядер
Платформа ровно на 50 ядер не оставляет места для служебных процессов и неудачного распределения нагрузки между виртуальными машинами. Поэтому стартовая точка — 64 физических ядра, например два процессора по 32 ядра.
Частоту нельзя назначить одной формулой: две модели с одинаковым числом ядер могут показать разный результат на офисной нагрузке. В закупочной спецификации фиксируй не условные гигагерцы, а точную модель процессора, на которой поставщик проведёт контрольный тест. Если тестовую модель меняют, результат проверяют заново.
Память считаем отдельно:
100 сессий × 4 ГБ × 1,2 = 480 ГБ
Ближайший практический объём выше расчёта — 512 ГБ ECC RDIMM. Модули стоит разложить по каналам памяти симметрично и оставить свободные слоты: иначе следующий апгрейд потребует заменить уже купленные RDIMM.
Стартовая спецификация получается такой:
| Компонент | Требование | Почему столько |
|---|---|---|
| Процессоры | 64 физических ядра, например 2 × 32 | Расчёту нужны 50 ядер, остаток забирают гипервизор и пики нагрузки |
| Память | 512 ГБ ECC RDIMM | Расчёт даёт 480 ГБ с резервом 20% |
| Диски | NVMe-массив с резервированием | Число накопителей определяет тест задержки и дисковой нагрузки |
| Сеть | Два независимых сетевых порта, скорость — по архитектуре хранения | Локальный массив и внешнее хранилище создают разную нагрузку на сеть |
| Питание | Два блока питания с горячей заменой | Отказ одного блока не должен останавливать весь VDI-узел |
| Корпус | Стоечный, с запасом отсеков под NVMe и свободными DIMM-слотами | Накопители и память должны добавляться без смены платформы |
Конкретное семейство сервера выбирай среди платформ, рассчитанных на установку двух процессоров, 512 ГБ памяти и нужное число NVMe. Отдельный разбор таких платформ есть в материале про серверы для виртуализации.
Главный компромисс этой конфигурации — процессорный запас. Он снижает риск повторной закупки при росте числа сессий, но сам по себе не доказывает, что сервер обслужит 100 рабочих мест с приемлемой задержкой.
Число NVMe определяет контрольный прогон
Назначить два, четыре или восемь накопителей без профиля дисковой нагрузки нельзя. Для VDI важны не только последовательная скорость и паспортные IOPS, но и задержка при одновременной работе виртуальных машин.
UL Solutions разработала Servermark VDI для измерения ёмкости VDI-инфраструктуры и производительности рабочих мест. Universal VDI работает с любой платформой, которая соответствует системным требованиям теста, и измеряет результат каждой виртуальной машины.
Отчёт показывает распределение баллов по ВМ, загрузку процессоров, памяти и дисков. По этим графикам видно, куда ушёл запас:
- процессоры держатся у предела — добавляй вычислительный узел или сокращай число сессий на сервер;
- память заполнена раньше завершения теста — увеличивай объём RAM;
- баллы виртуальных машин падают вместе с ростом дисковой задержки — расширяй NVMe-массив или меняй схему хранения;
- нагрузка распределена неравномерно — проверяй размещение ВМ и повторяй тест до приёмки.
В договоре зафиксируй не марку накопителей сама по себе, а результат: сервер должен пройти выбранный профиль Servermark VDI при 100 одновременно запущенных рабочих местах. Тогда поставщик отвечает за ёмкость системы, а не только за сумму характеристик в спецификации.
Как пересчитать конфигурацию под другое число пользователей
Для той же офисной нагрузки действуют две формулы:
физические ядра = одновременные сессии × vCPU на сессию ÷ переподписка
память = одновременные сессии × память одной ВМ × 1,2
При 50 сессиях получаем 25 физических ядер и 240 ГБ памяти. Стартовая конфигурация — 32 ядра и 256 ГБ ECC RDIMM.
При 200 сессиях расчёт даёт 100 ядер и 960 ГБ. Здесь разумнее сравнить один сервер с объёмом памяти от 1 ТБ и несколько узлов. Несколько узлов дороже по сети, корпусам и лицензированию, зато отказ одной машины не останавливает все 200 рабочих мест.
Офисный коэффициент нельзя переносить на обработку фото и видео. Servermark VDI разделяет базовую работу с браузером, документами и таблицами и тяжёлые мультимедийные сценарии. Для такой нагрузки сначала выбирают соответствующий профиль теста, затем определяют число сессий на узел.
Что записать в проект и договор
В проект включай «Альт Домен» и Termidesk как документированную интеграцию доменной аутентификации. Не называй её сертифицированной связкой, пока у тебя нет сертификата на точные версии обоих продуктов.
Для 100 одновременных офисных сессий отправная точка — 64 физических ядра и 512 ГБ ECC RDIMM. Конкретную модель процессора, число NVMe и количество узлов утверждай после прогона Servermark Universal VDI на предлагаемой конфигурации.
Приёмочный критерий простой: тест запускает 100 рабочих мест с согласованным офисным профилем, а отчёт сохраняет баллы каждой ВМ и графики CPU, RAM и дисковой нагрузки. Без такого прогона спецификация остаётся расчётной гипотезой — даже если аутентификация уже подтверждена документацией.
