В офисе на 100 человек один сервер держит 18 виртуальных машин, 12 ТБ рабочих файлов и их резервные копии. Отказывает корпус, RAID-контроллер или питание — сотрудники теряют доступ и к оригиналам, и к локальной копии.
Тебе нужно решить, оставлять ли файлы на гипервизоре или покупать отдельный сервер. Заодно — объяснить директору, почему резервным копиям нужен ещё один физический контур, хотя свободные отсеки есть и в основном корпусе.
Посчитаем две схемы для одной нагрузки. В первой файлы остаются рядом с виртуальными машинами. Во второй у каждой роли своё железо. В обоих вариантах единственная резервная копия живёт отдельно от оригинала.
Три роли не становятся независимыми оттого, что лежат на разных массивах
Файловый сервис отдаёт сотрудникам рабочие документы. Сервер резервного копирования принимает версии этих документов и образы виртуальных машин. Третий контур сохраняет копию при потере офиса, стойки или основной площадки.
Поставщик может разместить первые две роли в одном корпусе и выделить каждой свой RAID-массив. Это экономит сервер, два блока питания и сетевой порт. Но независимой копии не появляется: оба массива зависят от одной системной платы, контроллеров, питания и физического доступа к машине.
Поэтому вопрос «один сервер или два» нельзя решить по объёму файлов. Сначала назови допустимый простой. Если поломка гипервизора может одновременно остановить 18 ВМ и файловый сервис на время ремонта, роли можно совместить. Если ВМ должны работать во время восстановления файлового массива, нужен отдельный файловый узел.
Такое обоснование проще защищать через связку «бизнес-процесс — допустимый простой — ограничение железа». Подробно она разобрана в материале про метрики архитектуры, которые обосновывают покупку сервера.
Для 12 ТБ файлов нужно не 12, а 15,84 ТБ полезной ёмкости
Считаем офис с 12 ТБ рабочих файлов. Закладываем 20% свободного места для роста: 12 × 1,2 = 14,4 ТБ. Ещё 10% оставляем под служебные операции массива и временные данные: 14,4 × 1,1 = 15,84 ТБ.
Это полезная ёмкость после RAID, а не сумма цифр на накопителях. Например, восемь дисков по 4 ТБ в RAID6 дают 24 ТБ до учёта разницы между десятичными и двоичными единицами: (8 − 2) × 4 = 24 ТБ. Такого массива хватает на расчётные 15,84 ТБ и замену дисков на более ёмкие без немедленной перестройки корпуса.
Тип накопителей зависит от профиля файлов. Для документов, архивов и общих папок можно использовать серверные HDD. Если сотрудники одновременно открывают крупные проекты, работают с множеством мелких файлов или запускают сборки по сети, ёмкости недостаточно — поставщик должен подтвердить дисковую производительность под эту нагрузку. Покупать NVMe только ради объёма нет смысла.
Резервные копии считаются отдельно. При ежедневном приросте 120 ГБ и хранении 30 версий нужно 0,12 × 30 = 3,6 ТБ. Добавляем 10% свободного места: 3,6 × 1,1 = 3,96 ТБ полезной ёмкости.
Если прирост вырастет до 240 ГБ в сутки, серверу копий понадобится уже 0,24 × 30 × 1,1 = 7,92 ТБ. Поэтому корпус на четыре отсека годится лишь пока срок хранения и объём изменений не растут.
Когда файлы и копии лежат в одном массиве, расчёт даёт (14,4 + 3,6) × 1,1 = 19,8 ТБ. Места хватает, защиты от отказа корпуса — нет.
Общий сервер требует 32 ядер и 256 ГБ памяти
Для расчёта примем, что каждая из 18 виртуальных машин получает по 4 vCPU и 8 ГБ памяти. Файловой роли выделяем ещё 4 vCPU и 32 ГБ.
При переподписке процессора 3:1 получаем (18 × 4 + 4) ÷ 3 = 25,3 физического ядра. Добавляем 20% на гипервизор и пики: 25,3 × 1,2 = 30,4. В закупку закладываем 32 физических ядра.
Память считаем без переподписки: 18 × 8 + 32 = 176 ГБ. После запаса в 20% выходит 211,2 ГБ, поэтому ближайшая практичная конфигурация — 256 ГБ ECC RDIMM. Расчёт виртуальных машин можно сверить с разбором сервера виртуализации для офиса на 100 человек.
Файлам нужен отдельный массив от 15,84 ТБ полезной ёмкости. Иначе обращения сотрудников к документам будут конкурировать с дисковой нагрузкой виртуальных машин. Отдельный массив не спасает от остановки корпуса, но хотя бы разделяет рабочие очереди.
Такую схему можно оставить, если бизнес принимает единый простой для ВМ и файлов. Резервные копии при этом должны находиться на другой физической машине.
Разделять роли нужно до аварии, а не во время восстановления
Отдельный файловый сервер нужен в двух случаях. Первый: виртуальные машины должны продолжать работать, пока ремонтируют файловый массив. Второй: восстановление 12 ТБ не должно отнимать дисковую полосу у 18 ВМ.
Сервер резервных копий нужен при любой схеме, где поломка основного корпуса не должна уничтожить оригинал и локальную копию. Это не вопрос скорости. Это граница отказа.
Контроллер под массив выбирают после накопителей, а не наоборот. По спецификации Microchip, SmartROC 3200 подключается через PCIe Gen 4 и поддерживает NVMe, 24G SAS и SATA в tri-mode. Но наличие нужного интерфейса ещё не подтверждает работу конкретного контроллера, бэкплейна и модели диска в выбранном сервере.
Совместимость проверяют по матрице производителя платформы. Например, HPE публикует интерактивные матрицы поддержки и сертификации серверов; актуальный документ HPE вышел в июне 2025 года. До заказа поставщик должен показать в матрице сервер, контроллер, бэкплейн и накопители из спецификации.
Спецификация под задачу
Считаем офис на 100 человек: 18 ВМ по 4 vCPU и 8 ГБ, 12 ТБ файлов, прирост копий 120 ГБ в сутки, хранение 30 дней.
Если ВМ и файлы могут останавливаться вместе
- Процессор: 32 физических ядра. Расчёт с файловой ролью дал 30,4 ядра.
- Память: 256 ГБ ECC RDIMM. Нагрузка требует 211,2 ГБ с запасом.
- Файловый массив: от 15,84 ТБ полезной ёмкости после RAID. Практический ориентир — восемь серверных дисков по 4 ТБ в RAID6, если их производительности хватает под профиль файлов.
- Сеть: два порта от 10 Гбит/с, чтобы развести рабочий трафик и копирование по физическим интерфейсам.
- Питание: два блока питания с горячей заменой.
- Корпус: стойка 2U с восемью отсеками под рабочий массив и свободными слотами расширения.
- Резервные копии: отдельная физическая машина с полезной ёмкостью от 3,96 ТБ.
Такая схема экономит один вычислительный узел. Плата за экономию — общий простой: отказ гипервизора одновременно останавливает ВМ и файлы.
Если ВМ и файлы должны переживать ремонт друг друга
Сервер виртуализации получает 32 физических ядра: (18 × 4) ÷ 3 × 1,2 = 28,8. Памяти нужно 18 × 8 × 1,2 = 172,8 ГБ, поэтому ставим 192 ГБ ECC RDIMM при фиксированной нагрузке или 256 ГБ, если число ВМ будет расти.
Файловому серверу выделяем 4 ядра, 32 ГБ ECC RDIMM и массив от 15,84 ТБ полезной ёмкости. Корпус — не меньше 2U с восемью отсеками, двумя сетевыми портами от 10 Гбит/с и парой блоков питания.
Серверу копий достаточно 4 ядер и 16 ГБ ECC при последовательном приёме копий. Полезная ёмкость — от 3,96 ТБ при приросте 120 ГБ в сутки или от 7,92 ТБ при 240 ГБ. Для первого сценария подойдёт массив из четырёх дисков по 4 ТБ в RAID6: (4 − 2) × 4 = 8 ТБ до поправки на единицы измерения.
Раздельная схема требует трёх корпусов вместо двух: гипервизор, файловый сервер и сервер копий. Зато ремонт файлового узла не останавливает ВМ, а восстановление не конкурирует с ними за диски.
Правило для закупки короткое. Общий сервер допустим, когда бизнес принимает единый простой, а копия физически вынесена. Если ВМ должны пережить ремонт файлового узла или файлы — ремонт гипервизора, разделяй роли. Единственную резервную копию рядом с оригиналом не закладывай ни в одну спецификацию.
