Эксперты в подборе IT-оборудования
Знакомая ситуация: файл на 2 ГБ копируется с сетевой шары дольше, чем скачивается из интернета. Диски новые, коммутатор гигабитный, сервер не загружен - а быстрее не становится. Значит, где-то в цепочке есть звено, которое держит скорость всей остальной инфраструктуры.
Разберём, из чего серверная инфраструктура состоит, в каком месте она обычно упирается и как найти это место, не покупая заранее ничего нового.
Под серверной инфраструктурой понимают всё, что нужно, чтобы приложение доехало от диска до пользователя: сами серверы, сеть между ними, хранилище и обвязка, которая это питает и охлаждает. Более широкое понятие, куда входят ещё и рабочие места с софтом, - это ИТ-инфраструктура.
| Компонент | Что делает | Где чаще всего становится узким местом |
|---|---|---|
| Кабельная система (СКС) | Физическая среда передачи | На категории 5e десять гигабит не поедут: для 10GBASE-T нужен Cat 6a |
| Коммутаторы доступа | Подключают серверы и рабочие места | Дешёвые модели с малым буфером - при пиках теряют пакеты |
| Коммутаторы агрегации, ядро | Собирают трафик с коммутаторов доступа | Аплинки уже, чем суммарный трафик снизу |
| Маршрутизатор, межсетевой экран | Выход наружу и между сегментами | Проверка трафика упирается в процессор устройства |
| Серверы | Считают | Память и диск, а не процессор - вопреки ожиданиям |
| Хранилище (СХД, NAS, локальные диски) | Хранят и отдают данные | Тип носителя и интерфейс к нему |
Порядок в этом списке не случаен: чем ниже уровень, тем дороже его потом менять. Переставить сервер можно за вечер, перетянуть СКС по этажу - это проект.
Проще всего думать об инфраструктуре как о логистике: груз едет по маршруту, и общая скорость доставки определяется самым медленным участком, а не средней скоростью по всему пути. Расширять надо именно его, остальное расширять бессмысленно.
Практика показывает четыре типовых участка.
Носитель данных. Разница между типами дисков - в порядках, а не в процентах. Вот ориентиры по случайным операциям блоком 4 КБ - именно они определяют отзывчивость баз данных и виртуалок:
| Носитель | Случайные операции 4 КБ (IOPS) | Практический вывод |
|---|---|---|
| HDD 7200 об/мин | ~100-200 | Годится под архив и бэкап, не под базу |
| SATA SSD | Десятки тысяч, упирается в интерфейс | Порог входа для рабочих задач |
| NVMe SSD | Сотни тысяч | База, виртуализация, всё интерактивное |
Между HDD и NVMe разница в тысячи раз. Если база живёт на HDD, никакая сеть и никакой процессор этого не компенсируют. Отдельный вопрос - где эти диски стоят: сравнение вариантов есть в разборе DAS, NAS и SAN.
Интерфейс к носителю. SATA III даёт 6 Гбит/с, то есть около 600 МБ/с. При блоке 4 КБ это упирается примерно в 150 тысяч операций в секунду чисто арифметически, а живые SATA SSD выдают меньше. Купить SATA SSD быстрее этого потолка нельзя - в него упирается сам разъём, и обходится это только переходом на NVMe.
Сеть между сервером и потребителем. Здесь чаще всего и прячется исходная загадка про медленный файл. Один NVMe-диск последовательно отдаёт 3 ГБ/с и больше. Канал 10 Гбит/с - это 1,25 ГБ/с. То есть один диск способен насытить десятигигабитную сеть с запасом в два-три раза, а гигабитную - в двадцать с лишним. При гигабите в офисе быстрый сервер упирается не в себя, а в провод. Скорость линка определяется самым медленным звеном цепочки, включая сетевую карту сервера.
Память. Нехватка оперативной памяти на гипервизоре или сервере БД выглядит как «тормозит диск»: система начинает вытеснять страницы на носитель, и нагрузка переезжает на дисковую подсистему. Лечится памятью, а не дисками, но по симптомам легко ошибиться.
Частая ошибка - расширять то, что удобнее купить, а не то, что тормозит. Заменить диски проще, чем протянуть новую СКС, поэтому первыми меняют диски. Если реальное ограничение - гигабитная сеть, новые NVMe ничего не изменят, деньги уйдут впустую.
Есть параметр, который прямо описывает запас сети, но в разговорах о «медленной инфраструктуре» почти не звучит - переподписка (oversubscription).
Считается просто: суммарная полоса, которой подключены серверы к коммутатору, делится на полосу аплинков от этого коммутатора выше. Двенадцать серверов по 10 Гбит/с - это 120 Гбит/с снизу. Два аплинка по 40 Гбит/с - 80 Гбит/с наверх. Переподписка 1,5:1.
Отраслевой ориентир - не хуже 3:1, в задачах с интенсивным обменом между узлами стремятся к 1:1. Смысл в том, что все серверы одновременно на полную не работают почти никогда, и закладывать полосу «один в один» обычно избыточно. Но если переподписка уходит к 10:1 и выше, сеть будет вести себя странно: в среднем всё хорошо, а в момент бэкапа или ночной выгрузки всё встаёт.
Это как раз тот случай, когда узкое место не видно в графике средней загрузки. Смотреть надо пики и потери пакетов на аплинках, а не среднесуточную полку. По той же логике считают и электрическую нагрузку - как это делать, разобрано в материале про расчёт мощности стойки.
Инструментов много, но толку от них мало, если непонятен порядок. Работает такая последовательность.
Шаг 1. Померить, а не предполагать. Взять конкретную медленную операцию (копирование файла, отчёт в 1С, выгрузку) и засечь время. Без исходной цифры вы не поймёте, помогло ли вмешательство.
Шаг 2. Проверить носитель. Посмотреть очередь к диску и время отклика под нагрузкой. Для SSD и NVMe нормой считаются единицы миллисекунд; если под рабочей задачей отклик уходит в десятки, ограничение здесь. Для HDD десятки миллисекунд - штатное поведение, и это само по себе ответ, годится ли такой диск под задачу.
Шаг 3. Проверить память. Если система активно вытесняет страницы на диск, дальше идти рано - сначала память.
Шаг 4. Проверить сеть. Скорость линка, ошибки и потери на портах, загрузку аплинков в пик. Гигабитный порт там, где ожидался десятигигабитный, - находка более частая, чем кажется.
Шаг 5. Только теперь смотреть приложение. Часто оказывается, что инфраструктура в порядке, а тормозит запрос без индекса или однопоточная обработка.
| Что смотрим | Чем | Что ищем |
|---|---|---|
| Общая картина, тренды | Zabbix, Prometheus + Grafana | Загрузка портов и дисков в пик, а не в среднем |
| Трафик по пакетам | Wireshark, tcpdump | Потери, повторы, кто именно занимает полосу |
| Диск под нагрузкой | iostat, Windows Performance Monitor | Длину очереди и время отклика |
| Поведение под нагрузкой | fio для дисков, iperf3 для сети | Реальный потолок, а не паспортный |
Порядок важнее набора: сеть подозревают первой, а упирается чаще в диск или память.
В статьях про инфраструктуру постоянно упоминают топологию Spine-Leaf. Разберём честно, кому она нужна.
В классической трёхуровневой схеме путь между двумя серверами зависит от того, куда они воткнуты: соседние порты - быстро, разные концы сети - через несколько коммутаторов. В Spine-Leaf каждый leaf-коммутатор соединён с каждым spine, и между любыми двумя узлами всегда ровно два перехода. Задержка перестаёт зависеть от места подключения.
| Классическая иерархия | Spine-Leaf | |
|---|---|---|
| Путь между узлами | Разный, зависит от подключения | Всегда 2 перехода |
| Задержка | Плавает | Предсказуемая |
| Рост | Упирается в ядро, нужна перестройка | Добавляются leaf-коммутаторы |
| Стоимость входа | Ниже | Выше: нужно много портов и линков |
| Управление | Привычное | Сложнее, обычно требует автоматизации |
Кому это действительно нужно: там, где серверов много и они часто общаются между собой - виртуализация с живой миграцией, распределённое хранилище, кластеры БД.
Кому нет: если у вас пять-десять серверов в одной стойке и трафик идёт в основном от пользователей к серверу, а не между серверами, Spine-Leaf не даст ничего, кроме счёта за коммутаторы. Пара нормальных коммутаторов с достаточными аплинками закроет задачу.
| Задача | Где обычно упирается | С чего начать |
|---|---|---|
| Файловый сервер, обмен документами | Сеть и СКС | Поднять до 10 Гбит/с сервер и коммутатор, клиентов можно оставить на гигабите |
| Виртуализация | Память, затем диск | Память с запасом, NVMe под диски виртуалок |
| База данных, 1С | Случайные IOPS и задержка | NVMe, память под кэш; частота ядра важнее их количества |
| Видеонаблюдение | Последовательная запись, объём | Ёмкие HDD под запись, отдельный сегмент сети |
| Резервное копирование | Полоса сети в окно бэкапа | Отдельный сегмент или окно, чтобы не конкурировать с рабочим трафиком |
| Аналитика, отчёты | Полоса и объём хранилища | Пропускная способность важнее задержки |
Ориентиры на ближайшие годы, если инфраструктура будет расширяться.
25 Гбит/с постепенно становится тем, чем было 10. Разница в цене между 10 и 25 сокращается, и при обновлении коммутаторов стоит смотреть сразу на 25 - хотя бы на аплинках.
Сетевые адаптеры берут на себя часть работы. SmartNIC и DPU снимают с процессора обработку трафика, шифрование и часть работы с хранилищем. Для малого бизнеса это пока не первоочередная покупка, но в конфигурациях под виртуализацию встречается всё чаще.
Хранилище уезжает на NVMe целиком. Гибридные схемы SSD+HDD остаются там, где нужен объём: архивы, видео, бэкапы.
Стоит держать в голове, что 400 и 800 Гбит/с, о которых пишут в обзорах, - это уровень операторов связи и крупных дата-центров. Для серверной на несколько стоек ориентир другой, и равняться на цифры из статей про гиперскейл смысла нет.
Узкое место почти всегда одно, и оно редко там, где его ищут первым. Порядок проверки - диск, память, сеть, приложение. Расширять стоит только найденное ограничение: вложения в остальные участки не дадут ничего, пока самый медленный не расшит.
Собираете или обновляете серверную и не уверены, где окажется потолок?
Инженеры ITTELO подберут конфигурацию под вашу нагрузку - с запасом там, где он нужен, и без переплаты за то, что не будет использовано. Соберём и протестируем под задачу перед отгрузкой, с гарантией и поддержкой после продажи. На рынке серверов 11+ лет.
Посмотрите серверное оборудование в каталоге или напишите нам - поможем посчитать конфигурацию под ваши задачи.
Телефон: +7 (800) 551-80-12, почта: info@ittelo.ru
