Сервер или СХД: отличия архитектур и критерии выбора

Ситуация: компания купила два Dell PowerEdge R750, набила их по 24 диска SAS, поставила Proxmox — и через полгода IT-директор пишет в чат: «Почему у нас хранилище тупит?». Потому что сервер — это не система хранения данных. Это как попросить бухгалтера разгружать фуры: справится, но не за этим брали.

Вопрос «сервер vs схд» звучит просто, но за ним стоит архитектурная развилка, которая определяет судьбу всей инфраструктуры на 5–7 лет вперёд. Разберём, чем они принципиально отличаются — и как не ошибиться с выбором оборудования: типичные ошибки при выборе СХД, которые стоят денег, мы разобрали отдельно.

Архитектурные отличия: мозг и склад

Эти два типа устройств строились под отдельные задачи с самого начала, и это видно прямо в железе.

Сервер — это вычислительная машина. Его сильные стороны: многоядерные CPU (Intel Xeon Scalable или AMD EPYC с 96+ ядрами), ECC RAM объёмом до нескольких терабайт, PCIe-слоты для GPU и FPGA. Диски здесь — дополнение, а не главное. Локальный RAID на сервере строится на контроллере (HBA или RAID-карта), который не предназначен для обслуживания сотен одновременных I/O-запросов от внешних клиентов.

СХД — система хранения данных — спроектирована ровно наоборот. Её ценность в дисковом пространстве, пропускной способности и отказоустойчивости. Дублированные контроллеры, кеш-память с battery backup (BBU), поддержка тысяч дисков разных классов (HDD, SSD, NVMe), MTBF у топовых моделей — свыше 2 миллионов часов. Всё это про надёжность и IOPS, а не про вычисления.

Ключевой момент — дублированные контроллеры в СХД. Когда один контроллер умирает (а он умрёт, закон Мёрфи не отменяли), второй подхватывает нагрузку без остановки. На сервере с одной RAID-картой такого нет — отказ контроллера означает простой.

Ещё одно принципиальное отличие — масштаб дискового пространства. Сервер формата 2U физически вмещает 24–36 дисков. СХД корпоративного класса — например, NetApp AFF или HPE Alletra — работает с сотнями и тысячами дисков в одном пространстве имён. При этом СХД управляет дисковыми полками (JBOD), перераспределяет нагрузку между ними и следит за здоровьем каждого накопителя централизованно. Администратору не надо держать в голове, на каком физическом сервере лежат данные.

Отдельно про DAS (Direct Attached Storage) — это когда диски подключены напрямую к серверу. Дёшево, быстро, нулевая сетевая задержка. Но масштабировать такую схему неудобно: каждый сервер работает только со своим локальным хранилищем, и если нужно поделиться данными между нодами — придётся городить огород с репликацией или сетевыми протоколами поверх.

NAS или SAN: протоколы решают всё

Когда говорят «архитектура хранения данных», чаще всего имеют в виду два лагеря: NAS (Network Attached Storage) и SAN (Storage Area Network). Это не конкуренты, это два инструмента под принципиально отличающиеся задачи.

NAS работает через файловые протоколы — NFS для Linux-окружений и SMB/CIFS для Windows. Вы монтируете сетевую папку, и всё. Просто настраивается, дёшево масштабируется, хорошо подходит для файловых серверов, бэкапов и медиа-архивов. Latency — от 1 до 5 мс, иногда выше при высокой нагрузке.

SAN — другой уровень. Это блочное хранилище, которое сервер видит как локальный диск. Fibre Channel (FC) обеспечивает latency ~0.1–0.2 мс и пропускную способность 32–64 Гбит/с на линк. iSCSI — бюджетная альтернатива поверх обычного Ethernet, latency 0.3–1 мс. NVMe-oF (NVMe over Fabrics) — новейший стандарт, который приближает latency сетевого хранилища к локальному NVMe: <0.1 мс при использовании RDMA-транспорта (RoCE или InfiniBand).

Для кластера Proxmox с 10–20 нодами iSCSI или NFS — вполне рабочая связка. Для Oracle RAC или MS SQL с тысячами транзакций в секунду уже смотрят в сторону FC или NVMe-oF.

Отдельный вопрос — что делать, если FC слишком дорог, а iSCSI уже не хватает производительности? NVMe-oF через Ethernet (RoCEv2) закрывает этот зазор. Достаточно 25GbE или 100GbE карт с поддержкой RDMA — и получаете sub-millisecond latency без специализированных FC-свитчей за сотни тысяч рублей. Правда, настройка RoCEv2 требует аккуратной конфигурации QoS и PFC (Priority Flow Control) на свитчах — иначе latency будет скакать как биткоин в 2022-м.

Когда брать что: критерии выбора

Универсального ответа нет, но есть понятные ориентиры, которые сужают выбор оборудования до двух-трёх вариантов.

Виртуализация (VMware, Proxmox, Hyper-V). Если вы ещё не определились с платформой — стоит сначала изучить сравнение популярных гипервизоров. Связка сервер + СХД — классика жанра. Серверы занимаются вычислениями, СХД отдаёт блочное хранилище по iSCSI или FC. При грамотном расчёте IOPS это даёт экономию 20–40% по сравнению с покупкой серверов с локальными дисками для каждой ноды — меньше избыточности, лучше утилизация.

Базы данных с высокой нагрузкой. OLTP-системы с тысячами транзакций в секунду требуют All-Flash СХД с FC или NVMe-oF. Здесь важен не только IOPS, но и стабильность latency — всплески выше 5 мс убивают время отклика приложения. Серверный локальный NVMe в этом сценарии конкурентоспособен, но теряет в масштабируемости и отказоустойчивости.

AI/ML и большие данные. GPU-серверы с локальными NVMe или NVMe-oF — СХД здесь скорее вспомогательный элемент для хранения датасетов. Вычисления первичны, хранение вторично.

Архивы и холодное хранилище. Объём данных от 10 PB — территория СХД с erasure coding (EC). EC эффективнее классического RAID при больших объёмах: при схеме 8+2 накладные расходы составляют 25% против 50% у RAID-5 на том же числе дисков.

Про RAID и ZFS стоит сказать отдельно. Серверный ZFS — мощный инструмент, особенно с zpool на NVMe. ZRAID2 держит отказ двух дисков одновременно, встроенный кеш (ARC + L2ARC) ускоряет чтение. Но ZFS рассчитан на локальное использование: делать общий zpool для 30 серверов через сеть — это боль. Enterprise СХД с аппаратным RAID и дедупликацией на уровне контроллера решает задачу централизованно и без таких компромиссов. Выбор зависит от того, насколько централизованно вы хотите управлять хранилищем.

Энергопотребление — отдельная тема. Крупная СХД с 200+ дисками потребляет до 10 кВт на стойку. Это означает серьёзные требования к серверному помещению: питание, охлаждение и PDU — и отдельную строку в бюджете на электричество. Сервер с 24 дисками — в районе 1–2 кВт. Считайте TCO за 3 года, а не только закупочную цену.

HCI: когда граница стирается

Гиперконвергентная инфраструктура (HCI) — это ответ индустрии на вечный спор «сервер или система хранения данных». В HCI-узле сервер и хранилище объединены физически: вычислительные ресурсы и диски в одном шасси, а программный слой (vSAN, Ceph, Nutanix AOS) создаёт распределённый пул хранилища из локальных дисков всех узлов.

Плюсы очевидны: latency снижается на 30–50% по сравнению с классической связкой сервер + внешняя СХД (данные физически ближе к вычислениям), масштабирование линейное — добавил узел, получил больше и CPU, и хранилища. Минус — жёсткая связанность: нельзя отдельно нарастить только хранилище без добавления вычислительных ресурсов.

Для SMB-сегмента с ограниченным бюджетом на администрирование HCI на базе Proxmox + Ceph — разумная альтернатива классической трёхзвенной архитектуре. Для крупного enterprise с разными профилями нагрузки традиционное разделение сервер/СХД даёт больше гибкости.

Важно понимать ограничения HCI: минимальный порог входа — три узла (Ceph не любит кластеры из двух машин и требует нечётного числа мониторов). И если один узел вышел из строя, кластер продолжает работу, но деградирует по производительности сразу в двух измерениях: теряется и вычислительная мощность, и часть дискового пространства. При классической архитектуре эти проблемы решаются независимо.

Архитектура хранения данных не стоит на месте: NVMe-oF постепенно превращает внешнюю СХД в нечто неотличимое от локального диска по производительности. Через несколько лет вопрос «nas или san» может стать менее острым — но вопрос «зачем нам это хранилище и какие у него требования по IOPS и отказоустойчивости» останется всегда актуальным. Ответьте на него честно до покупки — и следующие 5 лет пройдут спокойнее.