Сервер для разворачивания ОС по сети: диск и сеть на 200-1000 ПК

С чего начинается массовая установка ОС по сети

Массовая установка ОС по сети начинается не с выбора утилиты, а с понимания цепочки загрузки: ПК включился, получил по PXE минимальную среду (загрузчик и WinPE), затем скачал установочные файлы и образ, после чего пошли установка и первичная настройка.

PXE (Preboot Execution Environment) позволяет загрузить компьютер по сети без флешки. Дальше подключается инструмент развертывания. WDS чаще используют для сетевой загрузки и раздачи Windows-образов. MDT добавляет сценарии, драйверы, пакеты и автоматизацию. FOG выбирают, когда нужно быстро клонировать диски и есть сценарии с multicast (одновременно на много ПК).

На практике чаще ломается не софт, а инфраструктура. Когда заканчивается место, образы начинают хранить как попало: теряются версии, удаляется нужное, развертывание срывается в самый неподходящий момент. Когда сеть не рассчитана, PXE-старты превращаются в очередь, а в пике проседают соседние сервисы (почта, 1С, видеонаблюдение).

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

Дальше определите опорные цифры: сколько образов и каков их реальный размер (WIM, драйверы, приложения), сколько установок пойдет одновременно, какой пик трафика допустим в сети (ядро, этажные коммутаторы, Wi‑Fi), и сколько времени есть на одну волну.

Простой ориентир: 200 ПК часто ставят партиями по 20-30, чтобы не упереться в гигабитные аплинки. 1000 ПК почти всегда требуют очередей, multicast или распределения точек раздачи по площадкам.

Какие входные данные собрать до расчета

Точный расчет начинается не с формул, а с коротких ответов на вопросы. Если их пропустить, сервер для развертывания ОС по сети легко окажется либо слабым, либо неоправданно дорогим.

Соберите данные в пяти блоках:

• Масштаб и параллельность: сколько всего ПК и сколько реально ставятся одновременно в одном окне. Для сети и диска важна именно параллельность.
• Набор ОС и вариативность: Windows 10/11, Windows Server, разные редакции, языки, отдельные образы под роли (класс, бухгалтерия, колл-центр). Чем больше вариантов, тем больше места и сложнее сопровождение.
• Состав образа: обновления, офис, антивирус, агенты, базовые приложения, драйверы. Отметьте, используете вы «толстый» образ (почти все внутри) или «тонкий» (ОС плюс установка софта задачами).
• Топология площадок: один офис или несколько, развертывание по LAN или через WAN, скорость и стабильность каналов, ограничения по трафику.
• Окно развертывания: 2 часа, ночь, выходные, поэтапно по отделам.

Отдельно зафиксируйте «единицу установки»: сколько данных реально передается на один ПК и сколько времени занимает путь до рабочего стола. WIM на 18-25 ГБ плюс драйверы и post-install может заметно отличаться от «упакованного» образа на 35-45 ГБ.

Короткий вопросник перед расчетом:

• Сколько ПК ставим одновременно в пике: 20, 50, 100, 200?
• Сколько разных образов действительно нужно, а что можно унифицировать?
• Есть ли разные модели ПК, которым нужны отдельные драйвер-паки?
• Разворачиваем в одном месте или в филиалах по WAN?
• Какой дедлайн: «успеть за ночь» или можно растянуть на неделю?

Если вы закупаете серверы и сеть под это заранее, полезно сразу проверять не только общий объем диска, но и скорость чтения, число одновременных подключений и реальную пропускную способность.

Расчет диска: из чего складывается объем на сервере

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

Обычно на сервере или сетевом хранилище живут: эталонные образы (WIM), приложения и обновления, драйверы, логи и отчеты, кэш контента и временные файлы сборки.

Эталонный Windows-образ в WIM часто занимает 6-12 ГБ, но итог зависит от набора софта и обслуживания образа. Дальше важнее не размер одного WIM, а количество вариантов: разные отделы, языки, роли, иногда и разные модели.

Практичная модель расчета:

• WIM: размер одного образа x число вариантов x (1 + число хранимых прошлых версий)
• Драйверы: как стартовая оценка 1-5 ГБ на модель, если храните полноразмерные пакеты
• Пакеты/приложения: по опыту это легко 20-100+ ГБ
• Логи и отчеты: обычно немного, но закладывайте отдельную квоту
• Временные файлы импорта/сборки: минимум как один дополнительный образ, лучше два

Заложите рост. Удобно хранить 2-3 предыдущие версии для быстрого отката (особенно после обновлений Windows и драйверов) и добавлять запас 30-50% к сумме. Он уйдет на новые модели ПК, срочные ветки, большие драйвер-паки и кэш, который не успели почистить.

Правила хранения образов: порядок, версии и резервирование

Когда установок сотни, путаница с образами быстро превращается в простой: кто-то берет «не тот» WIM, драйверы смешиваются, отката нет. Правила хранения важны не меньше, чем выбор железа.

Минимальный набор версий

Держите 2-3 версии каждого образа: текущую, предыдущую (для быстрого отката) и аварийную «золотую», проверенную в разных условиях. Аварийная версия полезна, когда обновления или новые драйверы внезапно ломают установку.

Чтобы не гадать, что внутри, используйте единый формат имен. Например: дата сборки (YYYY-MM-DD), ОС и редакция, версия (v1.2), назначение (Office/Kiosk/Classroom), модель или группа моделей (если образ не универсальный).

Драйверы лучше хранить отдельно от образов, разложив по ОС и моделям. Пример: «Win11 + L200», «Win11 + M200», «Win10 + универсальный». Так проще обновлять драйверы точечно и не пересобирать образ без причины.

Резервирование и восстановление

Очистку планируйте регулярно (например, раз в квартал). Удаляйте только промежуточные сборки, а ключевые версии архивируйте и помечайте как «не трогать».

С бэкапами важно не «иметь копию», а уметь быстро восстановиться. Рабочая схема обычно включает копии минимум в двух независимых местах и периодическую офлайн-копию на случай шифровальщика.

Проверку восстановления делайте заранее: разверните аварийный образ на тестовом ПК и замерьте время. Это единственный надежный способ понять, что резервирование действительно работает.

Расчет сети: сколько пропускной способности нужно под 200-1000 установок

Сетевой трафик при установке по PXE идет неравномерно. В начале клиенты почти одновременно забирают загрузчик и WinPE. Пик короткий. Основной объем возникает на стадии скачивания образа (WIM или архив диска в FOG): трафик держится долго и именно он задает требования.

Практичный способ прикинуть нагрузку: возьмите объем данных, который реально передается на один ПК (образ плюс драйверы и пакеты), умножьте на число одновременных установок и разделите на длину окна. Добавьте запас 20-30% на служебный трафик, повторы и параллельные задачи.

Пример: передаете 12 ГБ на ПК. Запускаете 300 установок и хотите уложиться в 2 часа. 12 ГБ примерно 96 Гбит. 96 Гбит x 300 = 28 800 Гбит. Делим на 7200 секунд, получаем около 4 Гбит/с полезной нагрузки. С учетом накладных расходов и «неровного» скачивания разумно планировать 5-6 Гбит/с. В таком режиме 1 Гбит/с часто мало уже при 200+ параллельных установках, а 10 Гбит/с на сервер и аплинки становится базовым вариантом.

Unicast проще: каждый ПК получает свой поток, нагрузка растет пропорционально числу клиентов. Multicast (например, FOG multicast) помогает, когда все ставят один и тот же образ одновременно: сервер отдает один поток, а коммутаторы размножают его по портам. Но multicast требует аккуратной настройки (например, IGMP); в неподготовленной сети он может принести больше проблем, чем пользы.

Частые узкие места:

• аплинки с этажных коммутаторов (1 Гбит/с на шкаф быстро забивается)
• серверные порты (один 1GbE ограничит даже при быстром диске)
• дисковая подсистема (много одновременных чтений одного и того же образа)
• настройки и возможности коммутаторов (буферы, IGMP, перегруз)
• параллельные задачи после установки (обновления, софт, вступление в домен)

Сеть и сервер надо считать вместе: быстрый 10GbE без нужной скорости чтения образов с диска результата не даст.

Архитектура PXE: где размещать службы и как не усложнить

Для 200-1000 установок рабочая базовая схема выглядит так: DHCP выдает адрес, PXE-клиент получает подсказку, где взять загрузчик, дальше тянет WinPE и уже из WinPE скачивает образ и драйверы.

DHCP почти всегда лучше оставить на существующем сетевом сервере или оборудовании, а не поднимать второй DHCP рядом с PXE. Два DHCP в одной подсети быстро превращаются в хаос. Если PXE-сервер в другой сети, используйте DHCP relay (IP helper) на маршрутизаторе или L3-коммутаторе. PXE-опции в DHCP нередко конфликтуют с телефонией, Wi‑Fi-контроллерами и другими сервисами.

TFTP нужен только на старте (первый небольшой файл). Именно здесь он часто становится узким местом из-за большого числа одновременных запросов. Хорошее правило: держите TFTP на том же сервере, где лежит PXE-загрузчик, и не раздавайте через TFTP тяжелые файлы. Все, что больше начальной загрузки, лучше отдавать из WinPE по SMB или HTTP.

WDS, MDT и FOG: кто за что отвечает

• WDS отвечает за сетевую загрузку и базовую раздачу Windows-образов.
• MDT строится вокруг сценариев: выбор ролей, автоматическая установка софта, внедрение драйверов и настроек.
• FOG чаще используют для клонирования дисков и массовых раскаток, в том числе через multicast.

На практике нередко комбинируют: например, PXE и загрузка через WDS, а логика установки и пост-настройки через MDT. Выбор зависит от того, вам важнее «универсальная установка с разными ролями» или «быстро поставить один и тот же образ на большой парк».

Пошаговый расчет: как быстро прикинуть сервер и сеть

Цель грубого расчета простая: не купить лишнее и не упереться в сеть в день запуска. Достаточно честно задать допущения и затем проверить их пилотом.

1. Определите параллельность и окно: не «500 ПК всего», а «сколько одновременно и за сколько часов».

2. Оцените объем передачи на один ПК: берите WIM/образ диска и «обвязку» (драйверы, пакеты, post-install). Для Windows 10/11 типичный диапазон фактической передачи часто попадает в 12-25 ГБ.

3. Прикиньте сеть: (параллельность x ГБ на ПК) / окно. Затем добавьте запас на пики.

4. Прикиньте диск: (размер образов x число версий) + драйверы + пакеты + временные файлы + запас 30-50%.

5. Проверьте скорость чтения: раздача даже 1-2 Гбит/с при десятках клиентов требует быстрых SSD или RAID из SSD, иначе сеть будет простаивать.

Зафиксируйте допущения и проверьте пилотом

Перед масштабированием запишите, что именно вы считали: объем на ПК, параллельность, окно, тип раздачи (unicast или multicast). Затем прогоните тест на 10-20 ПК и измерьте реальную скорость, пики и время до готового рабочего стола. Если пилот показал в 1,5 раза больше трафика, чем в расчетах, лучше поправить модель заранее, чем искать узкое место ночью.

Типичные ошибки и ловушки при массовом развертывании

Частая ошибка - считать только размер одного WIM. На практике объем съедают версии, пакеты обновлений, приложения, языковые компоненты, драйвер-паки и временные файлы сборки. Без запаса место закончится ровно тогда, когда нужно срочно выпустить правку.

Вторая ловушка - планировать 200-1000 установок и упереться в узкое место: 1 Гбит/с, медленный диск или слабое хранилище. PXE и раздача образов любят стабильную скорость чтения, особенно при параллельных установках. Чаще проблема не в утилите, а в том, что железо и сеть не рассчитали под пик.

Что чаще всего ломает ночь миграции

Проверьте заранее:

• есть ли единое именование и версия прямо в названии образа
• разделены ли драйверы по моделям, а не свалены в одну папку
• знаете ли вы реальную пиковую параллельность, а не среднее за день
• есть ли локальная реплика или кэш, если площадки идут по WAN
• проверена ли скорость чтения диска под нагрузкой, а не «в одиночку»

Смешивание разных моделей без разделения драйверов часто дает «случайные» падения: на одной партии все хорошо, на другой начинается BSOD или не поднимается сеть после перезагрузки. Лучше заранее выделить группы по моделям и держать для них отдельные наборы драйверов и задач.

Отдельная боль - установка через WAN без локального кэша. Даже если расчет пропускной способности выглядит приемлемо на бумаге, задержки и потери пакетов превращают процесс в лотерею.

Чеклист перед запуском на 200-1000 ПК

Сначала зафиксируйте пик одновременных установок. Не общее число ПК, а сколько реально стартуют параллельно (например, 50, 150 или 300). Этот пик решает, выдержат ли сервер и аплинки.

Дальше определите, сколько данных уходит на 1 ПК. Удобнее брать средний объем фактической передачи (например, 12-25 ГБ), а не размер ISO.

Перед стартом проверьте три вещи: порт сервера (1/10/25 Гбит/с), аплинки коммутаторов до места установки (часто проблема на «этаже»), и дисковую подсистему (чтобы сеть не ждала диск).

По образам заранее заложите версии и откат: минимум текущая стабильная и предыдущая рабочая версия, плюс отдельная ветка для пилота. Место под откат должно быть в расчете сразу.

И обязательно сделайте пилот с измерениями: 10-20 ПК на типовом железе, с фиксацией времени и скорости. Если один ПК ставится за 25 минут, а при параллельном запуске 100 ПК время стало 70 минут, значит упираетесь в uplink или диск.

Пример сценария: расчет под 500 рабочих мест

Исходные условия: 500 ПК, на установку есть 8 часов, параллельно ставим ОС на 100 машин. Один WIM с нужными приложениями весит 12 ГБ, типичная установка (применение образа и перезагрузка) занимает около 30 минут.

Сеть: unicast против multicast

Unicast: сервер отдает 100 потоков. На волну нужно 100 x 12 ГБ = 1200 ГБ за 0,5 часа. Это около 0,67 ГБ/с, то есть примерно 5,3 Гбит/с только на раздачу образа (без накладных расходов PXE, драйверов и post-install). Поэтому здесь обычно целятся в 10GbE на сервере и аплинках, иначе окно в 8 часов начинает «плыть» из-за очередей и повторов.

Multicast (например, FOG multicast): один поток образа идет на группу, и нагрузка ближе к одному клиенту, а не к сотне. Для 12 ГБ за 30 минут это около 0,8-1,0 Гбит/с на сегмент, но потребуется настройка IGMP snooping и проверка, что сеть не «заливает» соседние порты.

Диск: образы, версии и драйверы

Допустим, нужно 3 образа по ролям (офис, инженерный, учебный) и по 3 версии каждого (текущая, предыдущая, тестовая). Это 9 WIM x 12 ГБ = 108 ГБ. Драйверы под 10 моделей, условно по 1,5 ГБ, дадут еще около 15 ГБ. Но основной объем быстро набирают пакеты, рабочие копии, временные файлы и бэкапы. Поэтому под хранилище развертывания разумно закладывать запас в несколько раз: например, 500 ГБ-1 ТБ быстрых SSD или NVMe.

Перед запуском проведите пилот на 20-30 ПК и измерьте: скорость чтения диска, загрузку сетевого порта, среднюю скорость на клиента и процент PXE-ошибок.

Следующие шаги: как перейти от расчетов к внедрению

Сведите расчеты в план: сколько ПК нужно переустановить за смену или за ночь, какой простой допустим и сколько площадок участвует. Это определит и сроки, и требования к сети, и схему размещения служб.

Если все установки идут из одного ЦОДа, вам нужна предсказуемая магистраль и контроль ограничений по пути до клиентов. Если есть филиалы с узкими каналами, чаще выигрывает локальная реплика или отдельная точка раздачи в филиале, чтобы не забивать WAN во время массового старта.

Дальше проверьте баланс системы целиком: диски (IOPS и стабильное чтение), сетевые порты, аплинки, возможности коммутаторов, и только потом CPU и RAM.

Если нужна готовая платформа под такие нагрузки, имеет смысл смотреть на серверы и интеграционные услуги GSE.kz (gse.kz), включая стойкие серверы S200 Series и дальнейшую поддержку после запуска.