Масштабирование систем хранения и обработки данных (СХОД) сводится к выбору между двумя стратегиями. Scale-up наращивает ресурсы одного узла: процессоры, память, диски, сетевые адаптеры. Scale-out добавляет в кластер новые серверы и распределяет данные между ними. Вертикальный путь дешевле на старте, проще в администрировании и даёт минимальные задержки доступа. Горизонтальный выдерживает отказ узла, растёт почти линейно и упирается только в бюджет и пропускную способность сети.
Практическое правило: если пиковая нагрузка укладывается в возможности одного сервера с запасом 40-50%, а простои на обслуживание допустимы, выбирайте scale-up. Если требуется доступность 99,95% и выше, объём данных растёт в разы за год, а окна обслуживания отсутствуют, стройте scale-out. Рабочий вариант и гибрид: транзакционные базы держат на мощных узлах с NVMe, а холодные данные, бэкапы и архивы складывают в распределённый кластер.
Три метрики определяют, что именно придётся наращивать: ёмкость в терабайтах, производительность в IOPS и задержке, пропускная способность в мегабайтах и гигабитах в секунду. Ошибка в оценке любой из них превращает апгрейд в расход бюджета без прироста скорости.
Что такое масштабирование систем хранения и обработки данных
Масштабирование СХОД означает рост трёх взаимосвязанных характеристик: сколько данных система хранит, как быстро обрабатывает запросы и как быстро передаёт потоки. Диски добавляют первыми, но без памяти, процессора и сети прироста не будет. База данных на 1 ТБ и та же база на 100 ТБ требуют разного объёма кэша страниц, разных планировщиков ввода-вывода и разной сетевой топологии.
Scale-up увеличивает ресурсы одного узла: больше слотов DIMM, больше дисков в корпусе, более быстрые сетевые карты. Scale-out добавляет узлы, а данные и нагрузку распределяет программный слой: распределённая файловая система, объектное хранилище или кластерная СУБД. Каждый вектор по-своему влияет на задержку, стоимость желез на терабайт и сложность эксплуатации.
Ёмкость, производительность и пропускная способность: что именно масштабируем
Ёмкость измеряется в терабайтах полезного пространства, то есть после RAID, репликации и резервирования. Производительность описывают два числа: IOPS (операций ввода-вывода в секунду) и задержка в миллисекундах. Пропускная способность показывает, сколько мегабайт или гигабайт в секунду система отдаёт в последовательном потоке. Метрики растут по разным правилам, и путать их дорого.
| Метрика | Единица | Как растёт при scale-up | Как растёт при scale-out |
|---|---|---|---|
| Ёмкость | ТБ полезно | Диски, внешние полки JBOD | Новые узлы с дисками |
| Производительность | IOPS, мс | Больше шпинделей, NVMe, памяти под кэш | Сумма IOPS узлов минус потери на сеть и репликацию |
| Пропускная способность | МБ/с, Гбит/с | Широкие HBA, новое поколение PCIe, 100G NIC | Агрегация каналов, распределённый доступ |
| Отказоустойчивость | уровень доступности | RAID, ECC, резервные БП | Реплики и кворум на разных узлах и стойках |
Один жёсткий диск 7200 RPM даёт 150-200 IOPS случайного доступа и 200-250 МБ/с последовательного чтения. SATA SSD выдаёт 80-100 тыс. IOPS, корпоративный NVMe - от 500 тыс. до 1 млн IOPS на устройство. Для СУБД с транзакционной нагрузкой решают IOPS и задержка; для файлового хранилища, видеопродакшна и бэкапов важнее последовательная пропускная способность.
Scale-up обычно улучшает все три параметра сразу: больше памяти, больше кэша, больше шпинделей. Предел наступает на границе корпуса и бюджета. Scale-out наращивает метрики приростом узлов при условии, что сеть и алгоритм распределения данных не стали бутылочным горлышком.
Вертикальное масштабирование (scale-up): преимущества и ограничения
Сильная сторона scale-up - простота. Одна ОС, одна файловая система, отсутствие сетевых задержек между узлами, привычные инструменты бэкапа и мониторинга. Доступ к локальному NVMe измеряется десятками микросекунд, тогда как обращение через сеть в распределённом кластере добавляет 0,1-1 мс. Для нагруженной СУБД это разница между комфортной работой и постоянной борьбой за latency.
Ограничения проявляются в момент, когда сервер перестаёт вмещать нужные ресурсы. Масштабирование RAM упирается в число слотов DIMM и поддерживаемый объём на сокет, масштабирование CPU - в тепловой пакет и число ядер, дисковое - в количество отсеков и портов HBA. Каждый следующий шаг стоит дороже предыдущего и приближает к физическому потолку платформы.
Физические и экономические пределы вертикального масштабирования
Двухсокетный сервер на AMD EPYC или Intel Xeon держит 24-32 модуля DIMM и до 6 ТБ памяти на сокет, то есть 12 ТБ на узел. Восьмисокетные платформы поднимают планку до 16-24 ТБ, но их цена и энергопотребление растут быстрее ёмкости. Корпус 4U вмещает 60-90 дисков формата LFF, дальше нужны внешние JBOD-полки.
Каждая внешняя полка добавляет задержку в SAS-цепочке и делит пропускную способность HBA между устройствами. Практический предел одной цепочки SAS - около 200 дисков, и на такой глубине время отклика заметно растёт. Питание и охлаждение тоже упираются в потолок: стойка на 10-15 кВт требует продуманной вентиляции и запаса по мощности.
Экономика нелинейна: топовый процессор стоит в 5-10 раз дороже среднего при приросте производительности в 2-3 раза. Закон Мура замедлился, прирост IPC на поколение составляет 10-15%, а частоты застряли в диапазоне 3-4 ГГц. Смена платформы часто тянет за собой новый набор памяти, новое шасси и новое поколение HBA.
Апгрейд процессора или добавление полки в большинстве случаев требует остановки сервиса. Для системы с окном обслуживания раз в квартал это нормально, для сервиса с SLA 99,99% - нет.
Single point of failure и риски отказоустойчивости
Scale-up концентрирует нагрузку на одном узле, и он становится единой точкой отказа. RAID защищает от выхода диска, ECC - от ошибок памяти, резервный блок питания - от сбоя питания. Ни одна из этих мер не спасает от отказа материнской платы, сбоя прошивки контроллера или ошибки администратора. Сервер, обслуживающий тысячи пользователей, при таком сбое уходит в недоступность целиком.
Частично проблему закрывают пара узлов и репликация на уровне приложения: primary и standby с синхронной записью в журнал. Схема рабочая, но её стоимость уже сопоставима с небольшим кластером, а переключение требует времени и отлаженной процедуры failover. Горизонтальная архитектура снимает риск иначе: отказ одного узла из десяти снижает производительность, но сервис остаётся доступным.
Горизонтальное масштабирование (scale-out): принципы и реализация
Scale-out строит систему из множества узлов, объединённых сетью, и превращает отказ отдельного сервера в штатное событие. Данные делятся на части, копии размещаются на разных узлах, клиенты обращаются к любому из них. Ключевые компоненты: распределённое хранилище или кластерная файловая система, менеджеры метаданных, балансировка нагрузки, быстрый интерконнект.
Технологии, на которых строят такие системы: Ceph для блочного, файлового и объектного доступа; GlusterFS для файловых томов; Hadoop HDFS для аналитики; Apache Cassandra для распределённых СУБД; MinIO для S3-совместимого объектного хранения. Все они позволяют добавлять узлы без остановки кластера.
Рост близок к линейному, но не бесплатен. Три реплики съедают 66% сырой ёмкости, координация между узлами требует сети 10-100 Гбит/с, а обслуживание кластера сложнее работы с одним сервером. Облачная инфраструктура вроде Timeweb Cloud решает часть этих задач иначе: вычислительные ресурсы и хранилище выделяются по требованию, а физические узлы, сеть и отказоустойчивость остаются на стороне провайдера. Это разумный вариант, когда строить собственный кластер нерентабельно.
Шардирование и репликация: как данные распределяются по узлам
Шардирование делит набор данных на части и раскладывает их по узлам. В Ceph нет центральной таблицы размещения: клиент вычисляет положение объекта по CRUSH-карте, зная топологию кластера. Кластер состоит из мониторов (MON), хранящих карту, менеджеров и OSD-процессов по одному на диск. Любой клиент обращается к нужному OSD напрямую, а кворум мониторов не даёт появиться единой точке отказа.
Репликация хранит несколько копий объекта: в Ceph по умолчанию три копии, разнесённые по узлам и стойкам правилами CRUSH. Альтернатива - erasure coding с параметрами вида k=8, m=3: накладные расходы падают с 200% до 37%, но растёт задержка записи и нагрузка на процессор. Репликация выигрывает на горячих данных и мелких объектах, EC - на холодных и крупных.
Проблемы начинаются при неравномерном распределении. Горячий шард упирается в возможности одного узла и тормозит кластер целиком. Помогают продуманный ключ шардирования, предварительный расчёт по реальным данным и тесты до продакшна. Ребалансировка в Ceph идёт фоном, и её стоит ограничивать по скорости, иначе она займёт всю пропускную способность сети.
Ceph и GlusterFS: сравнение подходов к горизонтальному масштабированию
Ceph - единый кластер RADOS для трёх интерфейсов: RADOS Block Device, CephFS и RADOS Gateway с S3-совместимым API. Клиенты работают с объектами напрямую, метаданные распределены по CRUSH, центрального каталога нет. GlusterFS - модульная файловая система: том собирается из кирпичей (bricks), каждый кирпич привязан к каталогу на сервере, а типы томов (distribute, replicate, disperse) задают поведение. Метаданные обслуживает та же файловая система.
| Критерий | Ceph | GlusterFS |
|---|---|---|
| Тип доступа | Блочный, файловый, объектный | Файловый, плюс NFS и SMB через шлюзы |
| Распределение данных | CRUSH, равномерно по OSD | По файлам, зависит от структуры каталогов |
| Метаданные | Распределены, отдельного сервиса нет | Хранит сама файловая система |
| Минимальный кластер | 3 узла, комфортно от 5 | 2 узла, комфортно от 3 |
| Сложность настройки | Высокая | Средняя или низкая |
| Мелкие файлы | Зависит от OSD и сети | Производительность падает при десятках тысяч файлов в каталоге |
| Типовые сценарии | Облако, Kubernetes, S3-хранилище | Файловые шары, медиа, кластеры на 2-6 узлов |
Практический вывод: Ceph берут для крупных кластеров с разнородной нагрузкой (диски виртуальных машин, тома Kubernetes, объектное хранилище), GlusterFS - для простых файловых хранилищ, где важны быстрая настройка и понятная модель томов. Добавление узлов без простоя поддерживают оба решения. Разбор архитектуры, отказоустойчивости и стоимости владения собран в материале ZFS, Ceph и GlusterFS: сравнение программных систем хранения и выбор под задачу.
Добавление дисков в ZFS: практические аспекты масштабирования
ZFS растёт не отдельными дисками, а vdev'ами. Пул (zpool) состоит из одного или нескольких vdev, каждый vdev - из дисков. Ёмкость и производительность суммируются по vdev, надёжность зависит от типа каждого из них. Разобраться в этой иерархии нужно до покупки железа: схема пула определяет его поведение на годы.
Стратегии расширения ZFS-пулов: mirror, RAIDZ и добавление vdev
Первый способ вырастить пул - добавить новый vdev: zpool add tank mirror sda sdb или zpool add tank raidz2 sdc sdd sde sdf sdg sdh. Ёмкость и IOPS растут сразу, существующие данные не перераспределяются, а новые записи идут в свободное пространство нового vdev. Второй способ - заменить диски на более ёмкие с включённым autoexpand: zpool set autoexpand=on tank, и пул сам подхватит прирост после замены всех дисков vdev. Третий - расширить существующий RAIDZ vdev: RAIDZ expansion появился в OpenZFS 2.3 и позволяет добавить диск в raidz1, raidz2 или raidz3 без пересоздания пула. Подробности по расширению пулов, полок SAS и кластеров разобраны в статье Масштабирование СХД: вертикальный и горизонтальный рост в 2026 году.
Выбор типа vdev определяет профиль нагрузки. mirror даёт лучшую случайную запись и быстрое восстановление, но полезная ёмкость равна половине сырой; подходит базам данных и томам виртуальных машин. raidz1 с одной проверкой чётности экономит место на 3-5 дисках, но rebuild после отказа идёт под нагрузкой и риск потери второго диска в этот момент высок. raidz2 с двойной чётностью - рабочий стандарт для 6-10 дисков. raidz3 терпит отказ трёх дисков и оправдан на массивах из 11 дисков и больше, где resilver длится сутками.
Пример: пул из двух mirror-vdev по 2 ТБ полезной ёмкости. Добавление третьего mirror-vdev даёт ещё 2 ТБ и примерно полуторный прирост IOPS на случайных операциях. Для архива та же процедура с raidz2 даст больше ёмкости на вложенный диск при меньшем числе операций в секунду.
Подводные камни при добавлении дисков в ZFS
- В vdev типа raidz нельзя добавить диск на версиях OpenZFS ниже 2.3. До появления RAIDZ expansion приходилось создавать новый vdev или пересобирать пул с копированием данных.
- Диски разного размера в одном vdev: полезная ёмкость считается по минимальному диску, лишние терабайты простаивают. Одинаковые модели и объёмы в одном vdev - базовое правило.
- После добавления vdev старые данные на нём не появляются. Для выравнивания нужна перезапись наборов: копирование файлов или переливка через zfs send и zfs recv на новый датасет.
- Смешивание типов vdev в одном пуле деградирует производительность: пул из mirror и raidz2 на записи работает по слабейшему звену.
- Изменение структуры пула почти необратимо. Удаление vdev поддерживается ограниченно и только при достаточном свободном месте, поэтому схему продумывают заранее.
- Новые диски проверяют до ввода в пул: прогон записи по всей поверхности, проверка SMART и температуры. Тест на стенде дешевле восстановления прода после ошибки.
Планирование масштабирования без простоев
Рост без остановки сервиса опирается на три приёма: rolling upgrade, фоновую миграцию данных и переключение между репликами. В Ceph новый узел добавляют в CRUSH-карту, ждут, пока состояние ceph -s покажет active+clean по всем placement groups, и только потом выводят старый узел на обслуживание. В GlusterFS расширяют том командой gluster volume add-brick и запускают gluster volume rebalance start, ограничивая скорость ребалансировки, чтобы не задушить продуктивную нагрузку. Виртуальные машины переносят живой миграцией, файловые сервисы - переключением виртуального IP.
Blue-green deployment подходит для смены версии кластерного ПО: поднимают второй контур, переносят трафик, старый оставляют как путь отката. Резервное копирование и проверенный план возврата назад обязательны в любом сценарии. Пошаговые процедуры по расширению пулов, массивов и полок собраны в руководстве Масштабирование системы хранения без простоя: расширение ZFS, RAID, Ceph и полок.
Пошаговый план масштабирования без остановки сервисов
- Снимите текущие метрики: занятость ёмкости, средние и пиковые IOPS, задержку, утилизацию сети за последние 3-6 месяцев.
- Спрогнозируйте рост данных и нагрузки на 1-3 года вперёд, добавьте запас 30-40% на пики и служебные нужды.
- Выберите стратегию по узкому месту: если упираетесь в память или задержку одного узла, считайте scale-up; если в ёмкость и доступность, считайте scale-out.
- Проверьте весь путь данных: сеть, HBA, коммутаторы, прошивки. Часто новое железо требует обновления драйверов и микрокода.
- Отработайте процедуру на стенде с копией конфигурации, замерив время ребалансировки и resilver на реальных объёмах.
- Выполняйте поэтапно: добавили узел или vdev, дождались завершения фоновых операций, проверили метрики, перешли к следующему шагу.
- Задокументируйте новую схему: карта размещения, версии ПО, точки подключения, порядок действий при отказе.
Пример из практики: в том GlusterFS на 4 узла добавляют два новых кирпича, том расширяется онлайн, файлы становятся доступны сразу, а ребалансировка идёт несколько дней в фоне. Пользователи не замечают изменений, если скорость ребалансировки ограничена и мониторинг отслеживает задержку ввода-вывода.
Как выбрать стратегию масштабирования под конкретную задачу
Решение определяется не модой, а четырьмя вводными: бюджетом, требованиями к доступности, типом нагрузки и прогнозом роста. Транзакционная СУБД с миллионами мелких операций плохо переносит шардирование и часто выгоднее на одном мощном узле. Аналитическое хранилище, объектное хранилище и файловые шары масштабируются горизонтально почти без ограничений.
Критерии выбора: когда scale-up, а когда scale-out
| Параметр | Scale-up | Scale-out |
|---|---|---|
| Стоимость старта | Ниже: один сервер вместо кластера | Выше: минимум 3 узла и сеть 10G+ |
| Стоимость каждого шага роста | Растёт нелинейно, топовое железо дороже | Близка к линейной при типовых узлах |
| Отказоустойчивость | Единая точка отказа, спасают резерв и реплика | Отказ узла не останавливает сервис |
| Сложность администрирования | Низкая: одна ОС и одна файловая система | Высокая: кластер, кворум, ребалансировка |
| Задержка доступа | Минимальная, локальный NVMe | Выше на 0,1-1 мс из-за сети |
| Предел роста | Слоты DIMM, отсеки корпуса, порты HBA | Практически не ограничен, упирается в бюджет и сеть |
| Тип нагрузки | Транзакционные СУБД, высокая связность данных | Файлы, объекты, контейнеры, аналитика |
Рекомендация по шагам: посчитайте, сколько IOPS и терабайт нужно на горизонте трёх лет. Если эти цифры укладываются в один сервер с запасом 40-50%, а окна обслуживания есть, начинайте с scale-up. Если требуются линейный рост, геораспределение и доступность выше 99,95%, проектируйте scale-out сразу: переделка вертикальной системы в кластер позже обойдётся дороже. Разбор обоих подходов с чек-листом собран в руководстве Масштабирование СХД: вертикальное (Scale-Up) и горизонтальное (Scale-Out) расширение, а сравнение готовых аппаратных и программных решений по стоимости владения есть в статье Аппаратная или программная СХД: как выбрать в 2026 году.
Типичные ошибки и рекомендации по масштабированию
- Недооценка роста данных: закладывают ёмкость на год, а через 8 месяцев пул заполнен на 85%, что для ZFS и Ceph критично.
- Несовместимость оборудования: диски с разным размером или версией прошивки в одном vdev, HBA без поддержки нужного режима, коммутаторы с недостаточным буфером.
- Игнорирование сети: сеть 1G или 10G становится бутылочным горлышком при репликации на несколько узлов и ребалансировке.
- Масштабирование без мониторинга: нет данных о ребалансировке, глубине очереди, задержке, и деградация заметна только от пользователей.
- Расширение сразу на продакшне без стенда: не проверены время resilver, поведение при отказе диска во время пересборки, скорость ребалансировки.
- Отсутствие плана отката: перед изменением не снят бэкап и не описан порядок возврата к прежней конфигурации.
Как избежать узких мест при масштабировании
Каждый раз проверяйте всю цепочку, а не только диски. Смотрите метрики ввода-вывода (iostat, dstat, sar), сетевую статистику (netstat, sar -n DEV), глубину очереди и задержку на уровне приложения. Показательные сигналы: диск загружен на 100% при низком CPU - узкое место в носителе; CPU в простое, а задержка растёт - упор в сеть, контроллер или неверный параметр recordsize и ashift; высокая загрузка сети при ребалансировке - не хватает интерконнекта 10, 25 или 100 Гбит/с.
Мониторинг строят на сборщиках метрик (node_exporter, ceph_exporter) и визуализации в Grafana с алертами на заполнение пула выше 80%, рост задержки и состояние дисков по SMART. Нагрузочное тестирование до и после апгрейда показывает реальный прирост: без замеров легко принять перестановку узких мест за улучшение. Планируйте ёмкость и производительность с запасом, документируйте топологию и версии ПО, тогда масштабирование станет рутинной операцией с предсказуемым результатом.