Сто сотрудников работают из офиса и дома, но корпоративные рабочие столы нельзя переносить в публичное облако. Для такого сценария Termidesk оставляет виртуальные рабочие места в контуре компании и даёт сотрудникам удалённый доступ к ним.

Для 100 одновременных офисных сеансов я бы закладывал два вычислительных узла по 16 физических ядер и 192 ГБ ECC-памяти. Каждый узел должен выдерживать всю нагрузку самостоятельно. Эта схема почти удваивает расходы на серверы, зато отказ одного хоста не останавливает рабочие места.

Облако дополняет локальную площадку, а не заменяет её

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

Azure Architecture Center описывает два базовых способа связать локальную инфраструктуру с Azure: VPN и выделенный канал ExpressRoute. Это сетевое соединение двух сред, а не обязательный перенос виртуальных машин в облако.

Termidesk поддерживает VMware, zVirt, oVirt, OpenStack, VMmanager, Rosa Virtualization, РЕД Виртуализацию и другие платформы. Рабочие места могут работать на Windows 10 и 11, Astra Linux, РЕД ОС, Ubuntu, Debian и ряде других систем. Поэтому внедрение Termidesk само по себе не требует одновременно менять гипервизор и образы рабочих столов.

Рост IaaS не отменяет локальные узлы. Он меняет распределение сервисов между площадками — подробнее это разобрано в материале о том, зачем компании сохранять собственный сервер при переходе к IaaS.

Сто пользователей — не характеристика сервера

Плотность VDI определяет профиль рабочего места. Бухгалтер с одной учётной системой, разработчик с локальной сборкой и инженер с САПР создают три разные нагрузки, хотя Termidesk считает каждого одним пользователем.

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

TechTarget в материале Стивена Бигелоу и Брайена Пози от 13 октября 2020 года приводит ориентир: сервер с двумя восьмиядерными процессорами и 192 ГБ памяти мог обслуживать от 80 до 130 VDI-сеансов. Разброс в 50 рабочих мест показывает, насколько результат зависит от нагрузки.

Этот ориентир нельзя превращать в обещание поставщика. Материал описывает серверы с DDR3 и не учитывает конкретные приложения твоей компании. Но для начальной оценки он годится: 100 офисных сеансов попадают внутрь опубликованного диапазона, поэтому узел на 16 физических ядер и 192 ГБ памяти можно взять за расчётную единицу.

Выбирать конкретные платформы стоит уже после расчёта ресурсов. Соседний материал поможет сверить возможности серийных серверов с требованиями виртуальной среды.

Отказ одного узла не должен уменьшать кластер до половины мощности

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

Поэтому базовая схема состоит из двух одинаковых узлов. Каждый получает 16 физических ядер и не менее 192 ГБ ECC-памяти. В обычном режиме нагрузка распределяется между ними, но после отказа одного хоста второй принимает 100 сеансов.

Это N+1: кластер сохраняет рабочую ёмкость при потере одного узла. Termidesk поддерживает отказоустойчивую архитектуру и работу при отказе компонентов, однако программная высокая доступность не создаёт свободные ядра и память. Их нужно купить заранее.

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

Для САПР и 3D этот расчёт не подходит. Termidesk поддерживает такие сценарии, но опубликованной плотности для них нет. Проведи пилот на рабочих проектах и замерь CPU, память и пиковые IOPS. Масштабировать офисный коэффициент на инженеров нельзя.

Хранилищу нужны ёмкость, ресурс записи и отдельная сеть

Считаем базовый объём на явном допущении: один образ занимает 40 ГБ, рабочих мест — 100.

100 × 40 ГБ = 4 ТБ

Добавим 30% под обновления образов и рост:

4 ТБ × 1,3 = 5,2 ТБ

Значит, кластеру требуется не менее 5,2 ТБ полезной ёмкости. Полезной — уже после RAID, служебного резерва и потерь выбранной схемы хранения. Если образ занимает 60 ГБ, тот же расчёт даст 7,8 ТБ: 100 × 60 ГБ × 1,3.

Локальные диски обоих хостов можно объединить программно либо вынести рабочие столы на отдельную СХД. Цена, задержки и поведение при отказе у этих схем различаются; сравнение есть в разборе архитектуры общего хранилища для гипервизора.

Трафик к хранилищу не стоит смешивать с пользовательскими сеансами в одной физической сети. TechTarget рекомендует отдельную сеть хранения — например, Fibre Channel или обособленный LAN. Так загрузка образов и запись профилей не конкурируют с подключениями пользователей.

SSD выбирай не только по объёму и MTBF. Производитель накопителей ATP определяет TBW как общий объём записи до износа NAND, а DWPD — допустимое число полных перезаписей накопителя в сутки за гарантийный срок. MTBF описывает случайные отказы группы устройств и не показывает износ флеш-памяти.

Для VDI важны показатели под случайную запись. ATP отдельно публикует последовательный TBW с блоками 128 КБ и случайный TBW по методике JESD219A. Случайная запись повышает коэффициент внутренней перезаписи, поэтому два SSD одинаковой ёмкости и с похожим последовательным TBW могут по-разному вести себя под профилями пользователей.

Совместимость проверяют на уровне всей платформы

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

Для VMware эту проверку проводят через Broadcom Compatibility Guide. В инструкции Broadcom перечислены причины, которые могут сорвать обновление ESXi: несовместимое серверное оборудование, старая версия BIOS, прошивка контроллера и неподходящее сочетание драйвера с прошивкой сетевого адаптера.

Совместимость с предыдущей версией ESXi не гарантирует совместимость со следующей. Поэтому в закупочной спецификации недостаточно написать «поддерживает VMware». Укажи точную версию гипервизора и приложи результат проверки всей конфигурации.

Спецификация под 100 офисных рабочих мест

Расчёт относится к 100 одновременным офисным сеансам без 3D. Один образ занимает 40 ГБ, запас ёмкости — 30%, а кластер должен продолжить работу после отказа одного вычислительного узла.

Компонент	Базовая спецификация	Почему столько
Вычислительные узлы	2 одинаковых сервера	Один узел принимает всю нагрузку при отказе второго
Процессор каждого узла	16 физических ядер	Опубликованный ориентир — 80–130 VDI-сеансов на 16 ядер; 100 сеансов попадают в этот диапазон
Память каждого узла	от 192 ГБ ECC RDIMM	Соответствует исходному ориентиру и сохраняется целиком при отказе соседнего узла
Хранилище	от 5,2 ТБ полезной ёмкости	100 образов × 40 ГБ × коэффициент запаса 1,3
Накопители	серверные SSD с заявленными TBW и DWPD для случайной нагрузки	VDI создаёт случайную запись, а MTBF не описывает износ NAND
Сеть хранения	отдельная физическая сеть или Fibre Channel	Трафик СХД не конкурирует с пользовательскими подключениями
Питание	резервные блоки питания и независимые линии, если площадка их поддерживает	Отказ одного блока не должен выключить узел целиком
Совместимость	сервер, BIOS, контроллеры, NIC, драйверы и прошивки проверены для выбранного гипервизора	Поддержка продукта не гарантирует совместимость каждого компонента

При 200 одновременных офисных сеансах удвой расчётную ёмкость: кластер после отказа одного узла всё равно должен сохранять ресурсы на 200 рабочих мест. Это можно собрать из трёх узлов по схеме N+1 либо из двух более крупных, но конкретную плотность придётся подтвердить пилотом.

При 3D, САПР и тяжёлых локальных приложениях начни с пилотной группы. Запиши среднее и пиковое потребление CPU, памяти и IOPS на пользователя, затем умножь измерения на число одновременных сеансов и добавь ресурс отказавшего узла.

Если простой допустим, можно отказаться от полного N+1. Зафиксируй последствие прямо в проекте: после отказа одного хоста часть или все сотрудники потеряют рабочие места до ремонта.

Закупку защищает не формула «Termidesk на 100 пользователей», а проверяемая цепочка: 100 одновременных сеансов, два узла с полной ёмкостью каждого, 5,2 ТБ полезного хранилища по названному расчёту, отдельная сеть СХД и совместимость компонентов с точной версией гипервизора.