Почему тестовый кластер и продакшн‑кластер — это не одно и то же

SDS‑кластер, собранный на глазок и прошедший приёмочные тесты, вполне может проработать полгода без единой жалобы, а потом упереться в стену. Причина обычно в том, что при проектировании никто не подумал об эксплуатации на годы вперёд — не заложили рост по узлам, памяти или сети, и нагрузка уперлась в архитектурный лимит, который без остановки и миграции не раздвинуть.

Большинство таких проблем можно предсказать и предотвратить ещё на этапе проектирования — об этом статья: как выбрать архитектуру для кластеров MIND uStor, посчитать ресурсы сервера, спроектировать сеть и настроить кластер так, чтобы он держал нагрузку предсказуемо и переживал отказы без драмы. Материал написан для инженеров, которые проектируют или сопровождают такие кластеры.

Правило номер один: считайте лимиты заранее, а не когда в них упретесь

У любого SDS есть потолок масштабирования, и uStor не исключение. Ключевое ограничение в текущей версии продукта — число uStor Disk, физических дисков под управлением кластера: не более 2048 на кластер. Это ограничение введено искусственно, но в текущей версии это главный ограничитель масштаба, и планирование роста на практике ведётся от него.

Есть и второй лимит — по числу узлов, и он зависит от типа накопителей: чем быстрее диски, тем меньше узлов допускается, потому что производительность и отказоустойчивость на быстрых носителях обеспечиваются другими средствами.

Смешивать логику нельзя: кластер классифицируется по доминирующему типу дисков, и этот лимит узлов действует на весь кластер целиком.

К этому нужно добавить ещё несколько жёстких границ, нарушение которых недопустимо ни при каких обстоятельствах:

• Размер одного образа (volume) — не более 256 ТБ. Если сервису нужно больше, режьте на несколько образов: обходить лимит не получится.

• Пулов в кластере — до 256, но на практике в типовой инсталляции их 2–5, так что этот лимит почти недостижим и скорее ориентир для архитектуры, чем реальное ограничение.

• Продакшн начинается с 6 узлов. Конфигурация в 3 узла годится только для dev/test на RF 3, в боевую эксплуатацию с такой схемой заходить не стоит.

Если по расчётам кластер скоро подойдёт к одному из этих лимитов, правильное решение — сразу закладывать создание второго кластера вместо того, чтобы «докручивать» существующий. Расширять кластер поверх лимита — это плохая идея, а иногда и физически невозможная задача, так что решать этот вопрос нужно на этапе capacity planning, заранее.

Есть ещё одна привычка, которая сэкономит инженерам немало нервов при первом же отказе узла: всегда закладывайте минимум на один узел больше, чем нужно по минимальной формуле схемы защиты. Если для EC 6+2 математически достаточно 8 узлов, проектируйте на 9. Без этого запаса кластер после отказа одного сервера будет вынужден работать в деградированном режиме до замены железа, вместо того чтобы самостоятельно восстановить полную избыточность.

Три шага выбора архитектуры

Прежде чем считать серверы и сеть, нужно определиться с тремя базовыми решениями — и в этом порядке, потому что каждый следующий шаг зависит от предыдущего.

• Шаг 1. Тип носителей выбирают по профилю нагрузки: бюджет здесь вторичен. NVMe подходит для latency‑критичных сценариев (СУБД, OLTP, VDI). SATA/SAS SSD дают универсальный баланс цены за петабайт и производительности для виртуализации и смешанных нагрузок. HDD берут для холодных данных, бэкапов и архивов, где важен объём, а не скорость случайного доступа.

• Шаг 2. Количество узлов вытекает из требуемой схемы защиты и целевой ёмкости. Здесь работает простое правило: чем больше узлов, тем выгоднее становится Erasure Coding по сравнению с репликацией (RF), потому что накладные расходы падают. На многоузловом NVMe‑кластере теоретически доступна EC 8+2, но для этого типа нагрузки это редкий сценарий, обычно хватает EC 4+2 или 6+2.

• Шаг 3. Тип развертывания — standalone или гиперконвергентный (HCI). В standalone‑конфигурации серверы хранения не несут ничего, кроме uStor, и CPU/RAM считаются только под него. В HCI на тех же серверах живут виртуальные машины (zVirt, Basis, SpaceVM), и тогда CPU, RAM и сеть нужно рассчитывать как сумму нагрузки VM и uStor, без права на оптимистичное совмещение. Кроме того, при проектировании HCI архитектуры имеет смысл заранее задуматься о том, чтобы отказ СХД не приводил к полному отказу всего ландшафта управления платформой виртуализации, вместе с базовыми корпоративными инфраструктурными сервисами DNS, NTP, log‑коллектором и мониторингом. При неправильной архитектуре любая авария будет комплексной, что сгенерит огромный объем логов и затруднит диагностику причинно‑следственных связей. Проектируйте так, чтобы каждый отказ не приводил к «эффекту домино».

Сервер: считайте под максимальную вместимость шасси

Одна из самых частых ошибок при заказе железа — рассчитывать процессор и память под то количество дисков, которое реально устанавливается при первичной пусконаладке. Правильный подход — считать под максимальную вместимость шасси. Если в сервер физически помещается 24 диска, а сейчас установлено 8, процессор должен быть рассчитан на 24, потому что до этого объёма кластер, скорее всего, и дорастёт. Апгрейд CPU задним числом на боевом узле куда более болезненная операция, чем разница в цене процессора на старте.

CPU считается по ядрам на диск, и требования сильно различаются по типу носителя: NVMe требует примерно 1 физическое ядро на диск при частоте от 2,6 ГГц, SATA/SAS SSD — около 0,5 ядра, HDD — порядка 0,25 ядра при минимум 2,0 ГГц. Разница логична: чем выше потенциальный IOPS носителя, тем больше вычислительной работы уходит на обслуживание каждого диска.

RAM правильно считать от объёма данных: интуитивно многие инженеры сначала прикидывают память на сервер, но верная единица — терабайт raw. Базовая формула — около 2 ГБ RAM на 1 ТБ raw‑ёмкости, при минимуме 32 ГБ на узел.

Потребление памяти на терабайт у NVMe и SATA/SAS SSD одинаковое (760 МБ/ТБ без контрольных сумм, 1780 МБ/ТБ с ними), потому что память определяется размером блока метаданных. Блок зависит от типа носителя — мелкий у SSD/NVMe ради IOPS, крупный у HDD, — протокол подключения тут ни при чём. HDD с их укрупнённым блоком обходятся заметно дешевле по памяти — 420–540 МБ/ТБ. Если бюджет памяти на NVMe‑кластере ограничен, контрольные суммы стоит оценивать по этому бюджету отдельно: они почти удваивают потребление RAM, но защищают от тихого повреждения данных. Для холодных архивов это почти всегда оправданная цена, а для latency‑критичных нагрузок вопрос конкретного расчёта.

Диски данных должны быть server‑class — оптимально 8–12 на узел, до 24 допустимо при соответствующей скорости сети (об этом ниже). Системные диски всегда отдельно: 2× SSD в RAID1, никогда не смешивайте их с дисками данных.

Здесь же одно из немногих правил, нарушение которых напрямую ведёт к потере данных или производительности: HBA или RAID‑контроллер обязательно в режиме HBA/JBOD. Аппаратный RAID для дисков данных не поддерживается платформой в принципе. Единственное исключение — RAID0 на каждый диск отдельно, и только с полностью отключённым кешем чтения и записи. Любая попытка спрятать диски за аппаратным RAID с активным кешем создаёт риск несогласованности между тем, что видит uStor, и тем, что реально записано на носитель.

BIOS тоже нужно настроить: режим максимальной производительности процессора вместо энергосбережения, ограничение глубоких C‑States (они добавляют задержку на пробуждении ядра), режим I/O Sensitive и Performance bias. Эти настройки снимают большинство плавающих проблем с задержками ещё до того, как кластер увидит первую боевую нагрузку.

Сеть: три изолированных сегмента

У uStor есть параметр, который позволяет разделять клиентский и backend‑трафик даже в рамках одной сети. Эталонная сетевая архитектура uStor строится на трёх физически или логически изолированных сегментах: управление (mgmt), клиентский трафик (data) и кластерный трафик (репликация, восстановление, ребалансировка, etcd). Изоляция кластерного сегмента от клиентского — вопрос предсказуемости: при восстановлении после отказа кластерная сеть может быть загружена полностью, и без разделения это напрямую может повлиять на производительность, которую получают клиенты.

Скорость портов выбирается по типу и количеству дисков на узел, и вот отправная точка проектирования:

Для плотных NVMe‑узлов (12 дисков) под кластерную сеть нужен запас до 2× 100 Гбит/с: репликация при Erasure Coding создаёт поток данных, кратный исходному, и здесь чаще всего недооценивают требования к сети.

По выбору между TCP и RDMA (RoCEv2): RDMA имеет смысл только при двух условиях одновременно — NVMe‑накопители и по‑настоящему lossless‑сеть с полноценно настроенными PFC/ECN. Если коммутаторы не поддерживают PFC в полном объёме, надёжнее остаться на TCP поверх сетей 25/100 Гбит/с с правильным QoS, а переход на RDMA рассматривать отдельным следующим шагом после стабилизации инфраструктуры. RDMA без lossless‑сети не даёт прироста производительности, а добавляет риски.

RF или EC: выбор по профилю данных

Выбор между репликацией (RF) и Erasure Coding — частое архитектурное решение, и здесь легко ошибиться, если исходить только из экономии места. Правило простое: RF 3 для горячих, latency‑критичных данных (СУБД, VDI), EC для объёмных (архив, бэкап, general storage), когда нам важно вытащить из оборудования всю возможную производительность. Причина в физике: EC требует пересборки данных из частей при чтении и большего числа узлов, участвующих в операции записи, что добавляет небольшую задержку по сравнению с прямым чтением полной копии при RF. Когда задача — вытащить из железа каждый IOPS, это может быть критично.

Важное практическое следствие: не смешивайте горячий и холодный профили нагрузки в одном пуле. Разделяйте их тегами uStor disk на разные пулы: это влияет и на эффективность, и на то, чтобы фоновые операции восстановления одного пула не создавали задержки для чувствительной нагрузки в другом.

То, что не видно на этапе приемки, но проявится через год

Часть проблем с предсказуемостью кластера не связана с выбором железа, они всплывают только при масштабировании и постоянной эксплуатации.

etcd не узкое место, но единственная точка отказа для управления кластером. Он хранит только служебные данные (конфигурацию пулов, состояние PG и uStor disk) и не стоит на пути пользовательского чтения/записи, но без него кластер не может управлять восстановлением. Главное правило масштабирования здесь противоречит интуиции: etcd разворачивается на 5 узлах, не на каждом узле кластера. Благодаря этому рост кластера с 10 до 50+ узлов не увеличивает нагрузку на Raft‑консенсус: число участников кворума фиксировано. Для продакшена рекомендуется 5 членов кворума (переживает отказ двух узлов), с выделенным SSD/NVMe под директорию etcd: задержка fsync здесь напрямую определяет скорость всего консенсуса. Стоит заранее поднять квоту backend (до 8 ГиБ) и настроить периодическую компакцию, иначе есть риск упереться в жёсткий стоп записи при значении по умолчанию в 2 ГБ.

Число Placement Groups стоит спланировать заранее — оставлять его по умолчанию не лучшая идея. Ориентир — 10–100 PG на один uStor disk. Слишком мало PG — нагрузка распределяется неравномерно; слишком много — растёт накладная нагрузка на Monitor и etcd. При росте кластера пересчёт размещения становится заметнее по времени, так что грамотное планирование PG с самого начала избавляет от болезненных перенастроек позже.

На крупных кластерах (от 1500 uStor disk) стандартные сетевые буферы RDMA становятся риском для памяти. При настройках по умолчанию каждый uStor disk может занять под буферы приёма RDMA до ~12 ГБ RAM на 64-узловом кластере с большим числом uStor disk. Для таких конфигураций параметр rdma_max_recv нужно снижать с 16 до 4–8, иначе можно неожиданно упереться в исчерпание памяти в тот момент, когда кластер и так под нагрузкой роста.

Плохой сосед и tail latency — фундаментальное свойство любого консистентного SDS: с этим сталкивается любая платформа, которая гарантирует такую консистентность. Синхронная запись завершается только после подтверждения всех реплик (или нужного числа чанков EC), и если один uStor disk подвисает из‑за сборки мусора на SSD или пика на HBA, ждёт весь клиентский запрос. Полностью убрать этот эффект нельзя, но его вероятность существенно снижается выбором server‑class SSD с защитой питания на основе конденсаторов (вместо десктопных моделей), сетью с PFC/ECN и постоянным мониторингом per‑uStor disk latency с заменой медленных дисков до того, как они начнут тормозить весь пул.

Scrub — это страховка от тихого повреждения данных, и отключать его ради экономии ресурсов не стоит. Без регулярной фоновой проверки целостности повреждённый блок может обнаружиться только при чтении, иногда уже после потери второй копии. Правильная настройка — держать auto_scrub включённым, но консервативно ограничить его влияние на клиентский I/O через scrub_sleep и глубину очереди, чтобы проверка шла в фоне незаметно.

Три типовых паттерна — с чего начать разговор с заказчиком

Если нужно быстро сориентировать заказчика по классу решения, удобно оттолкнуться от трёх типовых сценариев.

Малый SSD‑кластер (виртуализация, VDI). 3–5 узлов, RF 3 с переходом на EC 4+2 при росте до 6+ узлов, 12–16 SSD на узел, сеть 2× 25 Гбит/с. Подходит для dev/test и небольших ферм.

Средний SSD‑кластер (продакшн). 6–16 узлов, разделение на пулы: горячий на RF 3, общего назначения на EC 4+2 или 6+2, 16–24 диска на узел, сеть 2× 25 Гбит/с с переходом на 40 Гбит/с при плотности от 17 дисков. Основной сценарий для боевой инфраструктуры.

Крупный HDD‑кластер (холодный архив). 10–64 узла, схема EC растёт вместе с числом узлов, от 4+2 на 6–7 узлах до 8+2 на 10 и более, до 12 HDD на узел, сеть 2× 10 Гбит/с. Не забудьте добавить высокопроизводительные SSD‑диски под журналирование, выбирая объем SSD пропорционально совокупному объему HDD. Оптимален для бэкапов и архивного хранения, где куда важнее цена за терабайт, чем IOPS.

Масштабирование: расширяйте пакетами, не поштучно

uStor поддерживает добавление узлов без остановки кластера: Monitor автоматически перераспределяет PG при появлении новых uStor disk. Практический триггер для расширения — утилизация в 80%. Дожидаться более высоких значений не стоит: операции ребалансировки сами по себе требуют свободного места для манёвра.

Если кластер подходит к лимиту узлов или к пределу в 2048 uStor disk, лучше создать новый кластер, чем пытаться дотянуть существующий сверх лимита. То же самое касается требований изоляции по SLA и работы в разных дата‑центрах: разные ЦОД — это всегда разные кластеры. Растягивать одну логическую блочную СХД на несколько физических площадок нельзя ни при каких обстоятельствах: сетевые задержки между ЦОД разрушают синхронную репликацию и делают задержки непредсказуемыми, а предсказуемость — это как раз то, ради чего строится весь набор практик выше.

Итог

Отличие хорошо спроектированного SDS‑кластера от плохо спроектированного видно не сразу — оно проявляется через год эксплуатации, когда данных стало в разы больше, добавились новые узлы, а нагрузка выросла настолько, что стали заметны решения, принятые (или не принятые) на старте. Большая часть правил в этом материале сводится к одной идее: закладывать ресурсы под то состояние, в которое кластер придёт через несколько циклов роста, — сегодняшние цифры здесь плохой ориентир. Запас нужен там, где расширение задним числом невозможно или дорого: по числу узлов, по памяти под etcd, по сетевой пропускной способности под кластерный трафик. Это и отличает кластер, который просто работает, от кластера, который держит нагрузку предсказуемо и годы подряд.