Что такое размер СХД и почему он критичен при проектировании
Размер системы хранения данных складывается из трёх измеримых величин: высота корпуса в юнитах стойки, число отсеков под накопители и потолок масштабирования, который задаёт контроллер. Юнит (U) по стандарту EIA-310 равен 44,45 мм, поэтому 1U - это 44,45 мм, 2U - 88,9 мм, 4U - 177,8 мм полезной высоты.
Ошибка в размере даёт о себе знать через год-два эксплуатации. Пример: под задачу нужно 12 дисков 3.5", а закуплен корпус 1U с четырьмя отсеками. Достроить систему получится только внешней полкой JBOD. Полка займёт ещё 2U, добавит два блока питания и кабели, а потребление в простое вырастет на 40-60 Вт. В итоге в стойке два корпуса вместо одного, больше точек отказа и выше стоимость владения при той же ёмкости.
Размер влияет на четыре практических вещи: сколько юнитов стойки останется под другие задачи, доступна ли горячая замена дисков, можно ли нарастить ёмкость без покупки нового корпуса и хватит ли продува для отвода тепла. Плотность стоек здесь работает как жёсткое ограничение: если в стойке 42U и 5 кВт, корпус 4U с 60 дисками может забрать всю доступную мощность.
DevOps-инженер и системный администратор решают вопрос размера за один-два дня, а живёт это решение 3-5 лет, до следующего цикла закупки. Классификация СХД по архитектуре (DAS, NAS, SAN, SDS) задаёт верхний уровень выбора, а размер корпуса определяет то, что физически попадёт в стойку.
Классификация СХД по физическим габаритам: 1U, 2U, 4U, стоечные и напольные
Стоечные корпуса измеряются юнитами и монтируются в 19-дюймовую стойку. Основные варианты: 1U, 2U, 4U, реже встречаются 3U и 5U под дисковые полки. Напольные (башни) в юнитах не измеряются, они стоят на полу или на полке и рассчитаны на 4-8 отсеков.
Высота юнита задаёт не только габарит, но и доступный объём воздуха для охлаждения, размер блока питания и число слотов под контроллеры. Отсюда прямая связь: чем плотнее набит корпус, тем громче вентиляторы и выше требования к продуву стойки.
1U: компактность и ограничения
Высота 44,45 мм. Типовая вместимость: 4-8 отсеков 2.5" или 2-4 отсека 3.5". Мощность блока питания обычно 400-800 Вт, и значительная часть уходит на охлаждение при полной загрузке отсеков.
Сценарии, где 1U оправдан: загрузочные тома, кэш NVMe перед медленным массивом, узлы-шлюзы для SAN, небольшие файловые серверы до 20-30 ТБ. Пример: 1U с восемью отсеками 2.5" U.2 под NVMe SSD общей ёмкостью до 60 ТБ - рабочая конфигурация для метаданных ZFS или кэша Ceph.
Ограничение простое: при росте данных расширение идёт внешними полками, каждая из которых съедает 2U и собственное питание. Горячая замена в 1U есть, но доступ к отсекам плотный, а продув между дисками минимальный.
2U: баланс плотности и расширяемости
Высота 88,9 мм. Вмещает до 24 отсеков 2.5" или 12 отсеков 3.5" с горячей заменой. Здесь появляется место под полноценный RAID-контроллер с кэшем и батареей, два блока питания с резервированием и нормальный воздушный поток.
2U закрывает большинство рабочих задач: виртуализация, базы данных, файловые хранилища, гиперконвергентные узлы. Пример: 12 отсеков 3.5" с HDD по 16 ТБ плюс пара NVMe в тыловых слотах под журнал ZIL или кэш L2ARC.
Причина популярности проста: на один юнит приходится вдвое больше дисков, чем у 1U, при этом охлаждение и питание остаются управляемыми.
4U: максимальная ёмкость на юнит
Высота 177,8 мм. Корпуса этого класса вмещают 60 и более отсеков 3.5" либо 24-36 отсеков 2.5". В 4U ставят крупные вентиляторы 80-120 мм, которые дают нужный продув при меньших оборотах.
Сценарии: холодный архив, ленточные шлюзы, дисковые полки JBOD, аналитические платформы с большим объёмом, где скорость отходит на второй план. Пример: 4U JBOD с 60 дисками 3.5" по 20 ТБ даёт 1,2 ПБ сырой ёмкости на 4 юнита.
Минус один, но весомый: корпус занимает много места в стойке. Если стойка заполнена на 70-80%, 4U может не поместиться без вывода старого оборудования.
Стоечные и напольные исполнения: что выбрать
Стоечное исполнение даёт плотность, кабель-менеджмент, единое питание и охлаждение в стойке, а также стандартные рельсы для монтажа. Напольное (башня) не занимает юниты, работает тише и подходит для офиса без серверной. Верхний предел напольных моделей обычно 8 отсеков, расширение идёт внешними модулями.
Критерий выбора простой: есть стойка и планы на рост - берём стоечный корпус; нет стойки, объёмы до 50 ТБ и команда из 5-10 человек - хватит напольного NAS.
Классификация по количеству отсеков и масштабируемости
Число отсеков задаёт верхнюю границу ёмкости и напрямую влияет на цену: корпус на 24 отсека дороже корпуса на 8 не в три раза, но близко к тому. Типовые значения: 4, 8, 12, 16, 24, 36, 60, 84 отсека. Встречаются промежуточные варианты на 10 или 15 отсеков.
Как рассчитать необходимое количество отсеков
Формула: (полезный объём данных × коэффициент резервирования) / ёмкость одного диска = минимум дисков. Коэффициент резервирования учитывает RAID и служебный запас файловой системы.
Пример расчёта. Нужно 100 ТБ полезной ёмкости, диски по 16 ТБ, RAID 6 (теряем ёмкость двух дисков), служебные 10%. Считаем: 100 ТБ × 1,2 = 120 ТБ сырой ёмкости, 120 / 16 = 7,5, округляем до 8 дисков минимум, с запасом 20-30% на рост получаем 10-12 отсеков.
Для NVMe SSD логика другая: диски меньшей ёмкости берут ради IOPS и параллелизма, поэтому их ставят больше. Пример: 14 SSD по 7.68 ТБ дают около 92 ТБ полезной ёмкости в RAID 6 или RAIDZ2 и кратно больше операций ввода-вывода, чем 7 HDD по 16 ТБ.
Добавляйте отсеки под горячий резерв (spare). Один-два свободных диска в массиве экономят часы простоя при отказе.
Масштабируемость: вертикальная и горизонтальная
Вертикальная (Scale-Up) - установка дисков в свободные отсеки того же корпуса. Растёт ёмкость, конфигурация не меняется, задержка не увеличивается. Предел задан числом отсеков и пропускной способностью backplane.
Горизонтальная (Scale-Out) - подключение внешних полок JBOD по SAS или объединение нескольких узлов в кластер. Пример: СХД с 12 отсеками и поддержкой двух полок по 12 отсеков даёт до 36 дисков на один контроллер.
Ограничения Scale-Out: контроллер должен поддерживать расширение, SAS-цепочка имеет предел по числу устройств (обычно 128-255 адресов), а каждый переход через экспандер добавляет доли миллисекунды к задержке. Разбор обоих подходов и влияния на производительность есть в руководстве по масштабированию СХД.
Практические критерии выбора размера СХД
Алгоритм из шести шагов, который проходится за один вечер:
- Определите текущий объём данных и планируемый на 3-5 лет с учётом типа нагрузки: бэкапы и логи растут быстрее справочников.
- Выберите тип дисков: NVMe или SATA SSD для горячих данных, HDD 3.5" для тёплых и холодных.
- Посчитайте отсеки по формуле выше, добавив 20-30% запаса и 1-2 диска под spare.
- Проверьте свободные юниты в стойке и доступную мощность на стойку.
- Выберите форм-фактор корпуса: 1U, 2U, 4U или напольный.
- Сверьте совместимость контроллера, backplane, глубины корпуса и охлаждения с тем, что уже стоит в стойке.
Для DevOps-инженера добавляется седьмой пункт: как корпус отдаёт метрики. Датчики температуры, состояния дисков и питания через IPMI или Redfish позволяют строить алерты заранее, а не узнавать о перегреве по отказу массива.
Учёт плотности стоек и энергопотребления
Плотность стоек измеряется в юнитах и киловаттах. Если стойка рассчитана на 5 кВт, корпус 4U с 60 дисками 3.5" съест около 700-900 Вт только на накопители и контроллеры, плюс сопоставимая мощность уйдёт на охлаждение.
Ориентиры по потреблению: HDD 3.5" 7200 об/мин - 8-12 Вт под нагрузкой, SATA SSD 2.5" - 3-6 Вт, NVMe U.2 - 12-20 Вт и выше под нагрузкой. 24 NVMe в 2U дадут 300-500 Вт тепла на корпус, и отвести его без мощного продува не получится.
Правило: планируйте питание и холод так же тщательно, как ёмкость. Иногда несколько 2U-корпусов выгоднее одного 4U именно из-за теплового пакета.
Планирование роста объёмов данных
Закладывайте минимум 30% свободных отсеков и 50% запаса по ёмкости на три года. Рост данных неравномерен: базы и логи могут удвоиться за год, а архив прибавляет 10-15% в год.
Если сейчас нужно 50 ТБ, планируйте инфраструктуру под 100 ТБ. Покупка «на вырост» дороже сегодня, но экономит на миграции и простое завтра: перенос данных между контроллерами разного класса обычно требует окна обслуживания.
Связь размера СХД с типом накопителей и интерфейсов
Форм-фактор накопителя определяет, сколько дисков влезет в корпус. Диски 2.5" занимают вдвое меньше места в высоту, поэтому в 2U помещается 24 таких отсека против 12 для 3.5".
Серверные SSD 2.5" с интерфейсом U.2 и протоколом NVMe, например модели Memblaze серии PBlaze7, передают данные напрямую по шине PCI Express, минуя SAS-контроллер. Это снижает задержки и повышает пропускную способность, что критично для баз данных, виртуализации и аналитики.
В линейке Memblaze есть накопители ёмкостью 3.2 ТБ (PBlaze7 7946), 3.84 ТБ (PBlaze7 7940) и 7.68 ТБ (PBlaze7 7A40). Все три - форм-фактор 2.5", интерфейс U.2, память 3D TLC, горячая замена. Поддерживаются также SAS 3.0 (12 Гбит/с) и SAS 4.0 (24 Гбит/с), что важно при подключении к существующим контроллерам без полной замены платформы.
Влияние форм-фактора накопителя на выбор корпуса
Практический расчёт. 100 ТБ на SSD 2.5" по 7.68 ТБ - это 14 накопителей, они уместятся в 2U с 24 отсеками. 100 ТБ на HDD 3.5" по 16 ТБ - это 7 дисков, но корпус под 3.5" в 2U даёт только 12 отсеков, зато каждый диск дешевле за терабайт.
Выбирайте так: приоритет производительности и IOPS - 2.5" NVMe в 1U или 2U; приоритет цены за терабайт - 3.5" HDD в 2U или 4U. Смешанная конфигурация тоже рабочая: HDD 3.5" под ёмкость плюс NVMe 2.5" под кэш и журнал.
SSD выделяют меньше тепла на терабайт, чем HDD, но концентрация тепла выше: 24 NVMe в тесном 2U греются сильнее, чем 12 HDD. Планируйте продув и температуру в стойке до монтажа.
Таблица соответствия форм-факторов типовым задачам
Таблица даёт отправную точку. Итоговый выбор зависит от требуемой ёмкости, IOPS и лимитов стойки.
| Задача | Форм-фактор | Отсеки | Тип дисков | Примечания |
|---|---|---|---|---|
| Кэш, метаданные, загрузочные тома | 1U стоечный | 4-8 (2.5") | NVMe SSD | Отдельный корпус под служебный слой |
| Виртуализация, 20-50 ВМ | 2U стоечный | 12-24 (2.5") | NVMe SSD + HDD | Запас IOPS под пики, кэш на SSD |
| Базы данных OLTP | 2U стоечный | 8-16 (2.5") | NVMe SSD U.2 | Задержка важнее объёма |
| Аналитика и горячие данные | 2U стоечный | 16-24 (2.5") | NVMe SSD | Высокий параллелизм чтения |
| Файловое хранилище малой команды | Напольный | 4-8 (3.5") | HDD + SSD кэш | Нет стойки, до 50 ТБ |
| Архив и резервные копии | 4U или JBOD | 36-60 (3.5") | HDD | Минимальная цена за терабайт |
| Полки расширения | 2U-4U JBOD | 12-60 | HDD / SAS SSD | Подключаются по SAS к базовому контроллеру |
Для виртуализации сверьтесь отдельно с настройками дисковых массивов под гипервизор: выбор iSCSI, NFS или Fibre Channel и параметры multipath меняют требования к задержке и кэшу, детали собраны в руководстве по массивам для VMware, Hyper-V и KVM.
Типичные ошибки при выборе размера СХД
- Недооценка роста данных. Покупка корпуса без свободных отсеков. Решение: считать ёмкость на 3-5 лет и брать 30% запаса отсеков.
- Игнорирование плотности стоек. Выбор 4U с 60 дисками при лимите 5 кВт на стойку. Решение: посчитать энергопотребление и тепловой пакет до закупки.
- Несовместимость накопителей. Попытка поставить HDD 3.5" в корпус, рассчитанный только под 2.5". Решение: проверять спецификацию backplane и глубину корпуса.
- Отсутствие плана охлаждения. Перегрев NVMe при плотной установке. Решение: сверять требования к продуву и температуре с паспортом корпуса и возможностями стойки.
- Напольная СХД при наличии стойки. Потеря юнитов и лишние точки питания. Решение: при наличии 19-дюймовой стойки брать стоечное исполнение.
- Ставка на один контроллер. Отказ контроллера останавливает весь массив. Решение: выбирать модели с двумя контроллерами или планировать репликацию на второй узел.
Отдельная ошибка - не учитывать программный слой. Аппаратный корпус и софт (ZFS, Ceph, TrueNAS) предъявляют разные требования к памяти и кэшу. Сравнение подходов по TCO и стоимости роста ёмкости приведено в материале аппаратная или программная СХД.
Примеры из практики и рекомендации
Пример 1. Небольшая компания, 20 ТБ. Напольный NAS с 4 отсеками 3.5" и HDD по 8 ТБ в RAID 5 или RAIDZ1 плюс SSD под кэш. Стоечного шкафа нет, шум не критичен. Альтернатива: 1U стоечный корпус с внешней полкой, но это дороже и требует стойки. Урок: для 20 ТБ стоечный форм-фактор не нужен.
Пример 2. Средняя компания, 100 ТБ, виртуализация. 2U СХД с 12 отсеками под NVMe SSD U.2 по 7.68 ТБ, например Memblaze PBlaze7 7A40, плюс отдельный узел под бэкап на HDD. Такой корпус даёт высокие IOPS для нескольких десятков виртуальных машин и оставляет запас отсеков под горячий резерв. Альтернатива: 4U с HDD дешевле за терабайт, но не вытянул бы случайный ввод-вывод базы. Урок: характеристики диска важнее размера корпуса.
Пример 3. Крупный архив, 500 ТБ. 4U JBOD с 60 отсеками 3.5" и HDD по 16-20 ТБ, подключённый к контроллеру по SAS. Стоимость за терабайт минимальна, скорость последовательного чтения достаточна для бэкапа и выдачи файлов. Альтернатива из 2U-корпусов заняла бы больше юнитов при том же объёме. Урок: холодные данные выгоднее хранить в 4U.
Общие рекомендации. Документируйте конфигурацию: модель корпуса, число отсеков, раскладку дисков, версию прошивки контроллера. Настраивайте мониторинг температуры, SMART и состояния блоков питания на старте. Проверяйте совместимость дисков с backplane до закупки партии, а не после. И считайте ёмкость с запасом на 3-5 лет: корпус меняется за часы, а перенос данных занимает дни.
Если своя стойка не влезает по юнитам или мощности, часть нагрузки разумно вынести в облако. Timeweb Cloud предоставляет серверы и хранилище с гибким изменением ресурсов, что снимает вопрос плотности стоек для растущего проекта.