Построение системы сбора и хранения данных: пошаговое руководство 2026

Введение: зачем нужна система сбора и хранения данных и кому подходит это руководство

Систему сбора и хранения данных собирают в шесть этапов: аудит источников, перевод требований в цифры, выбор архитектуры и железа, настройка ZFS или Ceph, защита от отказов, ввод в эксплуатацию с проверкой восстановления. Ниже приведён план с командами, параметрами и типовыми конфигурациями, рассчитанный на применение без чтения официальной документации целиком.

Руководство адресовано системным администраторам и DevOps-инженерам, которые проектируют хранилище под конкретную задачу: логирование, резервное копирование, медиахранение, базы данных или данные потоковых платформ. Логика простая: сначала считают объём и пиковую скорость, затем подбирают диски, контроллеры и сеть, потом создают пулы и проверяют, что данные переживают отказ диска, узла и ошибку оператора.

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

Аудит источников данных и определение требований к системе хранения

Аудит начинается с инвентаризации источников. Выпишите приложения, которые пишут данные: веб-серверы Nginx и Apache, системные журналы journald и rsyslog, базы данных PostgreSQL и MySQL, брокеры сообщений Kafka, контейнерные платформы Docker и Kubernetes, системы резервного копирования, файловые шары. Для каждого источника зафиксируйте способ доставки: локальный агент Filebeat, Promtail или node_exporter, удалённая отправка через syslog, выгрузка по API, монтирование тома.

Потоковые источники считают отдельно. Kafka и CDC-коннекторы дают непрерывный поток событий, который затем складывается в объектное хранилище или в аналитическую СУБД, и требования к пропускной способности у такого потока выше, чем у пакетной выгрузки. Методика сбора и переноса больших массивов разобрана в статье Хранение больших данных и массивов: технологии сбора и миграция в 2026.

Чек-лист аудита источников данных

• Какие приложения пишут данные и с какой периодичностью.
• Формат: текст, JSON, бинарные файлы, журналы СУБД, медиа.
• Средний объём в сутки и пиковый объём в секунду.
• Срок хранения: 7, 30, 90 дней, год или бессрочно.
• Нужны ли сжатие, дедупликация, шифрование.
• Кто потребители данных и насколько быстро им нужен доступ: интерактивный поиск или архивная выгрузка.
• Требования к доступности: RPO (допустимая потеря данных) и RTO (допустимое время простоя).
• Регуляторные ограничения по срокам хранения и размещению данных.

Пример заполнения для одного источника: Nginx пишет 50 ГБ логов access и error в сутки, пик записи 10 МБ/с в часы нагрузки, срок хранения 30 дней, поиск нужен в пределах минуты. Отсюда получаются около 1,5 ТБ сырых логов, RPO 1 час и RTO 4 часа.

Как перевести требования в параметры системы

Ёмкость считают по формуле: суточный объём умножить на срок хранения и на коэффициент запаса. Запас 1,3 закрывает метаданные, снапшоты и рост нагрузки. Для 50 ГБ в сутки и 30 дней хранения: 50 × 30 × 1,3 = 1950 ГБ, то есть примерно 2 ТБ полезного места.

Пропускную способность берут из измерений, а не из паспорта диска. Пик 10 МБ/с оставляет запас даже для SATA, а 500 МБ/с требуют NVMe или нескольких vdev. IOPS считают там, где запись случайная и идёт блоками 4-16 КБ: журналы СУБД, метаданные, очереди сообщений. Последовательные потоки (медиа, архивы, бэкапы) оценивают по пропускной способности.

Дальше добавляют накладные расходы. RAIDZ2 из четырёх дисков отдаёт около половины сырой ёмкости, Ceph с тремя репликами - треть. Снапшоты ZFS занимают место, пока на блоки есть ссылки. Журнал транзакций PostgreSQL растёт независимо от основного объёма данных. Ошибка в этих коэффициентах приводит к заполнению пула за месяцы.

Проектирование системы сбора данных: архитектура и выбор аппаратного обеспечения

Архитектуру выбирают по двум параметрам: число узлов и скорость роста. Одноузловая схема с ZFS закрывает десятки терабайт и миллионы мелких файлов: логи, бэкапы, медиатеку, файловые шары. Распределённая схема нужна для горизонтального масштабирования, отказоустойчивости на уровне узла и доступа по S3 или POSIX из Kubernetes. Как устроены уровни хранилища, кэш и репликация, разобрано в статье Как устроено программное хранилище данных: архитектура, уровни и основные компоненты.

Диски подключают через HBA в режиме IT. RAID-контроллер с собственным кэшем мешает ZFS и Ceph видеть реальные накопители, ломает проверку целостности и удлиняет восстановление. Для 8-12 дисков достаточно HBA уровня LSI 9300-8i или 9400-16i.

Памяти для ZFS отводят 1 ГБ на каждый 1 ТБ ёмкости, минимум 16 ГБ. Дедупликация требует в разы больше, поэтому в большинстве задач выгоднее сжатие zstd или lz4. Для Ceph закладывают 2-4 ГБ на каждый OSD плюс память для MON и MDS.

Сеть подбирают по задаче: 1GbE для файловых шар и небольших объёмов логов, 10GbE для бэкапов и репликации, 25GbE и выше для Ceph, где восстановление после отказа диска занимает канал целиком. Резервируют блоки питания, сетевые карты и пути к дискам.

Выбор между ZFS и Ceph: критерии и сценарии

Правило выбора короткое: один сервер и до сотни терабайт - ZFS, часто в составе TrueNAS; несколько узлов и потребность в S3-совместимом API - Ceph. Подробное сравнение сценариев от домашней лаборатории до продакшн-кластера приведено в статье ZFS, Ceph и GlusterFS: сравнение программных систем хранения и выбор под задачу.

Примеры конфигураций под типовые задачи

Ceph требует минимум трёх узлов. Типовая сборка: 8 HDD на узел, 2 NVMe под DB и WAL для OSD, 10 или 25GbE, раздельные сети public и cluster, 3 MON и 3 MDS для CephFS. Сравнение TrueNAS, Ceph, ZFS и других систем под NAS, виртуализацию и Kubernetes разобрано в материале TrueNAS, Ceph, ZFS и другие программные системы хранения: практическое сравнение.

Настройка ZFS: пошаговое руководство

В Debian и Ubuntu ZFS ставится пакетом zfsutils-linux, в RHEL-совместимых системах - из репозитория OpenZFS. В TrueNAS SCALE файловая система уже встроена, пулы создаются через веб-интерфейс, но команды нужны для диагностики и восстановления.

Первое действие - найти стабильные имена дисков: ls -l /dev/disk/by-id/. Создавать пулы на sdX нельзя, порядок букв меняется после перезагрузки или замены накопителя.

Создание пула и выбор типа vdev

Для четырёх дисков берут RAIDZ2, для восьми - RAIDZ2 или RAIDZ3, если данные критичны. Создание пула выглядит так:

zpool create -o ashift=12 tank raidz2 /dev/disk/by-id/ata-WDC_WD80EFAX_01 /dev/disk/by-id/ata-WDC_WD80EFAX_02 /dev/disk/by-id/ata-WDC_WD80EFAX_03 /dev/disk/by-id/ata-WDC_WD80EFAX_04

Параметр ashift=12 задаёт сектор 4 КБ, и изменить его после создания пула нельзя. Проверка результата: zpool status tank и zpool list -v.

Настройка датасетов и снапшотов

Логическое разделение данных делают датасетами:

zfs create tank/logs
zfs create tank/backups
zfs create tank/media

Параметры для логов и бэкапов:
zfs set compression=lz4 tank/logs
zfs set atime=off tank/logs
zfs set recordsize=128K tank/logs
zfs set compression=zstd tank/backups
zfs set recordsize=1M tank/media

Снапшот создаётся мгновенно и не копирует блоки:
zfs snapshot tank/logs@2026-09-16
zfs list -t snapshot

Расписание удобно вести через sanoid. В sanoid.conf описывают шаблон production с наборами frequently, hourly, daily, monthly и weekly, а для датасета tank/logs задают, например, 24 часовых, 30 суточных и 6 месячных копий. Снапшоты защищают от случайного удаления файлов, но не от отказа пула целиком, поэтому их дополняют отправкой на второй сервер.

Обслуживание сводится к трём действиям: zpool scrub tank раз в месяц, проверка zpool status -x, анализ smartctl -a /dev/sdX и контроль заполнения через zfs list -o space.

Настройка Ceph: пошаговое руководство

Кластер начинают с подготовки узлов: синхронизация времени через chrony, уникальные hostname, рабочий DNS, Python 3, контейнерный runtime и настроенный SSH-доступ для cephadm. Все узлы должны видеть друг друга по сетям public и cluster.

Развёртывание кластера Ceph с помощью cephadm

Установка пакета и первичная инициализация на первом узле:
apt install cephadm
cephadm bootstrap --mon-ip 10.0.0.11

Добавление остальных узлов и дисков:
ceph orch host add node2 10.0.0.12
ceph orch host add node3 10.0.0.13
ceph orch apply osd --all-available-devices

Проверка состояния: ceph -s, ceph orch device ls, ceph osd tree. Для продакшена закладывают минимум 3 MON и 3 MDS, если планируется CephFS. NVMe под DB и WAL для OSD снижают задержку записи заметнее, чем любой тюнинг журналов на HDD.

Создание пулов и настройка доступа

Пулы создают с автоподбором числа placement groups:
ceph osd pool create logs
ceph osd pool create backups
ceph osd pool set logs size 3
ceph osd pool application enable logs rgw

Три реплики дают полезную ёмкость в треть от сырой. Для холодных архивов можно перейти на erasure coding, но восстановление и задержки там хуже. S3-совместимый доступ включает RADOS Gateway: ceph orch apply rgw s3 --placement="3 node1 node2 node3". Для общей файловой системы из Kubernetes разворачивают CephFS с тремя MDS, а для блочных томов используют RBD.

Проверять self-heal и баланс данных нужно регулярно: ceph health detail, ceph osd df tree, ceph pg stat. Красный статус placement groups означает потерю части реплик и требует ручного вмешательства до начала восстановления.

Обеспечение отказоустойчивости и защита от потери данных

RAID и репликация защищают от отказа железа, но не от ошибки оператора, шифровальщика или повреждения файловой системы. Копии хранят по правилу 3-2-1: три копии данных, два разных носителя, одна копия вне основной площадки.

Стратегии резервного копирования и репликации

Полная копия даёт быстрый старт восстановления и высокую нагрузку на канал, инкрементальная экономит время и требует цепочки копий. Дифференциальная занимает промежуточное положение. Практические связки rsync, restic и задач TrueNAS с проверкой восстановления разобраны в статье Резервное копирование хранилища артефактов: стратегии rsync, restic и TrueNAS.

Для ZFS базовый инструмент - потоковая отправка:
zfs snapshot tank/logs@base
zfs send tank/logs@base | ssh backup zfs recv backup/logs
zfs send -i tank/logs@base tank/logs@next | ssh backup zfs recv backup/logs

В Ceph применяют снапшоты RBD и CephFS, а также зеркалирование пулов между кластерами. Снапшот RBD создаётся командой rbd snap create pool/image@snap и клонируется при необходимости без остановки сервиса.

Мониторинг и проверка восстановления

Метрики, без которых система остаётся непрозрачной: свободное место в пулах, состояние vdev, ошибки чтения и записи, температура дисков, число переназначенных секторов, загрузка сети и задержка записи. Сбор строят на node_exporter, zfs-коллекторах и модулях Ceph, визуализацию - на Grafana, алерты - в Alertmanager или Zabbix.

Проверка восстановления идёт по расписанию. Смонтируйте снапшот в отдельный каталог, восстановите несколько файлов, сверьте контрольные суммы. Для Ceph проверяют ceph health и ceph osd tree, для ZFS - zpool status после scrub. Тест на отказ диска проводят на стенде: физическое отключение накопителя показывает реальное время resilvering.

Отдельная зона контроля - СУБД, которая хранит метаданные и журналы. Если PostgreSQL используется как Visibility store в Temporal, таблица истории и её индексы растут быстрее основного объёма. Advanced Visibility доступна на PostgreSQL 12 и новее с Temporal Server 1.20 и новее, а на более старых версиях работает устаревшая схема Visibility. VACUUM возвращает место в таблице, но не убирает раздувание b-tree индексов, поэтому на нагруженных развёртываниях применяют REINDEX CONCURRENTLY: он перестраивает индекс без блокировки чтения и записи, но требует примерно одного размера индекса в свободном месте и заметного I/O. Retention Period сам индексы не уменьшает. Для таблицы с интенсивными обновлениями помогает более агрессивный autovacuum, точные оценки раздувания даёт расширение pgstattuple, а при устойчивой высокой нагрузке Visibility выносят в отдельное масштабируемое решение.

Типичные ошибки при построении системы сбора и хранения данных

• Аппаратный RAID под ZFS или Ceph. Кэш контроллера скрывает реальные ошибки записи. Решение: HBA в режиме IT.
• Недостаток RAM. При 8 ГБ и пуле на 40 ТБ ARC почти не работает, чтение деградирует. Ориентир: 1 ГБ на 1 ТБ ёмкости.
• Неверный тип vdev. RAIDZ1 из восьми дисков теряет пул при двух отказах во время resilvering. Для больших наборов берут RAIDZ2 или RAIDZ3.
• Ставка на RAID вместо резервных копий. Избыточность не защищает от удаления данных и шифровальщиков. Нужны снапшоты и внешние копии.
• Отсутствие мониторинга. Без алертов о SMART, температуре и заполнении пула отказ обнаруживают по обращению пользователей.
• Непроверенное восстановление. Копия без теста восстановления остаётся гипотезой.
• Недооценка роста данных. Логи растут быстрее планов, а снапшоты держат удалённые блоки. Помогает запас 30% и пересмотр раз в квартал.
• Один блок питания, один коммутатор, один сетевой путь. Единая точка отказа сводит на нет избыточность дисков.
• Ручные операции без регламента. Замена диска или расширение пула по памяти приводит к ошибкам. Действия описывают в документе и выполняют по шагам.
• Игнорирование раздувания индексов в PostgreSQL. Нагрузка на таблицу Visibility растёт даже при работающем Retention Period. Помогают агрессивный autovacuum, REINDEX CONCURRENTLY и контроль через pgstattuple.

Ввод системы в эксплуатацию: тестирование, документация и передача

Нагрузочное тестирование начинают до переноса реальных данных. Последовательный поток проверяют fio с параметрами bs=1M, iodepth=32, numjobs=4, случайный - bs=4k с randrw. Сеть измеряют iperf3 между узлами, а не между клиентом и сервером, чтобы увидеть реальный предел канала репликации.

Тесты отказоустойчивости включают отключение диска на работающем пуле, снятие питания с одного узла Ceph, обрыв одного сетевого пути и имитацию переполнения пула. У каждого сценария фиксируют время реакции системы, время восстановления и отметки в логах. Если тестовый стенд не совпадает по конфигурации с продуктивным, его разворачивают в облаке: например, Timeweb Cloud даёт серверы, хранилище и Kubernetes, что удобно для прогона нагрузочных сценариев и проверки репликации без покупки железа.

Документация, без которой система не передаётся в поддержку: схема размещения с адресами и ролями узлов, конфигурация пулов и датасетов, параметры Ceph и карта CRUSH, расписание снапшотов и проверок, регламент замены диска, контакты ответственных, порядок действий при красном статусе. Чек-лист готовности: мониторинг собирает метрики, алерты доходят до дежурного, восстановление проверено на копии, инструкции лежат в базе знаний, персонал прошёл обучение.

Заключение: ключевые выводы и рекомендации

Работающий план выглядит так: инвентаризация источников и замеры объёма, перевод требований в ёмкость, IOPS и RPO/RTO, выбор между одноузловым ZFS и кластером Ceph, подбор дисков, памяти и сети, создание пулов и датасетов, настройка снапшотов и репликации, мониторинг, проверка восстановления, документация и передача.

Что стоит сделать в первую неделю: посчитать суточный и пиковый объём, определить срок хранения, заложить запас 30%, выбрать тип vdev и уровень репликации, настроить алерты по SMART и заполнению пулов, провести первое тестовое восстановление. Эти шаги занимают меньше времени, чем разбор последствий потери данных.