Как средней российской компании построить мини‑дата‑центр на 3–5 серверах

Для российских компаний с 50–200 сотрудниками мини‑дата‑центр на 3–5 серверах — это способ уйти от хаотичного зоопарка железа к управляемой платформе виртуализации и хранения. При этом ошибка в роли серверов или выборе хранилища быстро приводит к узким местам: нет IOPS для 1C, нет резервов по дискам, а расширение выглядит как новый проект с простоем. Эта статья помогает IT‑руководителю развести вычислительные и storage‑узлы, выбрать Supermicro/Dell/HPE и заранее посчитать TCO на 3 года.

Определяем роли серверов и нагрузку

Для компании на 50–200 сотрудников ключевой риск — сделать все 3–5 серверов “чистыми вычислительными” и получить узкое место по дискам. Надёжная схема — 2–3 вычислительных узла + 1–2 узла хранения, разнесённые по ролям виртуализации, 1C/ERP и файлового сервиса.

• Вычислительные узлы: 2–3 сервера под VMware/Proxmox, упор на 2×CPU и большой объём памяти (512 ГБ–1 ТБ) для плотности VM; цель — средняя загрузка CPU не выше 70% даже в пике.
• Узлы хранения: 1–2 сервера с RAID6 (8+2) под SAS‑диски и/или NVMe, задачей которых является снять IOPS‑нагрузку с compute‑узлов и обеспечить резерв по дискам с допуском выхода из строя двух накопителей.
• Оценка нагрузки: ориентируйтесь на формулу “число сотрудников × среднее число VM на сотрудника” и держите целевые пороги CPU <70% и заполнение хранилища <80%, чтобы избежать скрытого роста задержек.

По бюджету имеет смысл держать планку до ~5 млн ₽ на сервер, а общий бюджет проекта — до ~20 млн ₽ с резервом около 20% под запасные части и рост потребления электроэнергии. Не стоит пытаться закрывать высокие GPU‑нагрузки на тех же узлах: для рендеринга и ML проще добавить отдельные рабочие станции или специализированные GPU‑серверы.

Рекомендуемые конфигурации серверов и бренды

В условиях санкций выбор обычно идёт между Supermicro (высокая плотность и гибкость), Dell и HPE (удобное управление и поддержка). Практичный подход — делать вычисления на Supermicro, а хранение и управление — на Dell/HPE, используя при этом локальные склады и NBD‑поддержку.

Supermicro даёт лучшую плотность и гибкость DIY, локальная сборка позволяет уложиться в ~4 недели даже под санкциями. Dell/HPE выигрывают удобством управления (iDRAC/iLO) и понятными SLA на 3 года NBD. При выборе конфигурации обязательно проводите POC на плотность VM (>20 VM на узел) и производительность NVMe (>3 ГБ/с чтение), а также оставляйте хотя бы один PCIe x16 под будущие GPU или 10/25G‑карты.

Архитектура хранения и резервного копирования

Основная цель по дискам — не только вместить данные, но и пережить отказ нескольких накопителей без потери сервисов. Оптимальный компромисс для мини‑ЦОД — RAID6 на storage‑узлах + снимки/backup на отдельном сервере с разделением “горячих” и “холодных” данных.

• RAID‑слой: на основном storage‑узле — RAID6 (например, 8+2 диска), допускающий отказ двух HDD без потери массива; на compute‑узлах — зеркалирование 2× NVMe под критические VM и гипервизор.
• ПО и снапшоты: ZFS/TrueNAS SCALE с поддержкой снимков, интеграция с Proxmox Backup Server для инкрементальных бэкапов; целевой RPO — до 1 часа, RTO — <4 часов для критичных сервисов.
• Разделение данных: “горячие” данные и VM‑диски — на NVMe/SSD, “холодные” архивы и файловый обмен — на SAS HDD; суммарный объём до ~1 ПБ можно делить в пропорции 50% NVMe / 50% HDD.

Для снижения катастрофических рисков имеет смысл предусмотреть облачный резерв в российском облаке (например, Yandex) с регулярным тестированием восстановления (цель — поднять критичные сервисы менее чем за 2 часа). Важно не только снимать бэкапы, но и планово проверять восстановление 1–2 ключевых систем раз в квартал.

Сетевая архитектура и высокая доступность

Для связности 3–5 серверов достаточно простой, но грамотно разделённой архитектуры: 1G на рабочих местах, 10G между серверами и хранилищем, стеки коммутаторов для отказоустойчивости. Важно заранее продумать, какие узлы должны переживать отказ без простоя.

• Доступ: Dell S3148P с 24×1G PoE на уровне доступа, стек из двух устройств для отказоустойчивости и питания IP‑телефонии/точек Wi‑Fi, подключение рабочих мест на 1G.
• Агрегация: Cisco C9300 с 10G SFP+ или Dell S5248F‑ON с 25/40G uplink — для связи compute‑ и storage‑узлов; ToR‑соединения <3 м закрываются DAC, межстоечные ~100 м — SR‑модулями по OM4.
• HA: compute‑узлы объединяются в кластер высокой доступности (Corosync/Proxmox VE или VMware HA), storage‑узлы используют общие LUN и механизм failover; мониторинг (Zabbix + Grafana) отслеживает CPU >80% и диски >90% заполнения с отправкой уведомлений.

Типовые ошибки и расчёт TCO на 3 года

Многие российские проекты переоценивают необходимость “всё на NVMe” и недооценивают стоимость электропитания и запасных частей. Надёжнее сразу считать 3‑летний горизонт: закупка + электроэнергия + сервис и запасные части, а также лицензирование Microsoft и альтернативы Alt Linux.

• Ошибка 1 — “всё на NVMe”: в типичной виртуализации лишь 15–20% VM реально требуют максимальных IOPS. Решение: NVMe под критичные базы и кеш, SAS HDD как основной объём.
• Ошибка 2 — нет резервирования по питанию: один БП на узел резко повышает риск простоя. Решение — все узлы с двойным БП (не менее 2×800 Вт) плюс резерв по UPS и дизель‑генератору на критичные серверы.
• Ошибка 3 — игнор Alt Linux и открытых гипервизоров: ставка только на Microsoft увеличивает TCO и регуляторные риски. Решение — POC с Proxmox/Alt Linux, проверка совместимости драйверов и приложений до закупки лицензий.
• Ошибка 4 — нет резерва по PCIe и росту: три сервера загружены “под потолок”, четвёртый добавить физически некуда. Решение — заранее планировать минимум 4 свободных PCIe‑слота в кластере для 10/25G, HBA и GPU.

FAQ: частые вопросы по мини‑ЦОД на 3–5 серверов