Зачем нужна организация хранения данных и с чего начать
Инфраструктура на 40 ТБ может деградировать без единого отказа диска. Достаточно положить резервные копии, логи и горячую базу данных в один пул на одинаковых носителях: NVMe-массив окажется занят архивом на 70%, а транзакции получат 8 мс задержки вместо 0,5. Организация хранения данных снимает эту проблему: данные раскладываются по уровням, переезды между ними описывают политики, доступ обеспечивает выбранная архитектура.
Как организовать хранение данных на практике. Уровни (тиры) делят носители по скорости и цене: NVMe под горячие данные, SSD под активные сервисы, SATA HDD под файлы и бэкапы, лента и облако под архив. Политики жизненного цикла описывают судьбу каждого объекта: где он лежит, когда переезжает на медленный тир, когда удаляется. Архитектура задаёт способ доступа и протоколы: DAS, NAS, SAN, hyperconverged или объектное хранилище. Эти три слоя связаны, и выбор одного ограничивает остальные.
Цена ошибки считается в деньгах и простоях. Раскладка по тирам снижает стоимость гигабайта в 3-6 раз, если архив не лежит на NVMe. Отсутствие политик приводит к переполнению пула: ZFS при 100% заполнения переходит в режим только для чтения, и приложения теряют запись. Неверная архитектура упирается в сеть: канал 1 Гбит/с отдаёт максимум около 110 МБ/с, и массив NVMe за ним не поможет. Разбор классов СХД, расчёт IOPS и схемы резервирования собраны в статье про системы хранения данных 2026.
Три столпа организации хранения: уровни, политики, архитектуры
Уровни отвечают на вопрос, где лежат данные. Политики отвечают, когда и куда они переезжают. Архитектуры отвечают, как приложения к ним обращаются. Связка выглядит так: PostgreSQL требует 5000 IOPS и задержку ниже 1 мс, поэтому его файлы живут на NVMe в Tier 0 и доступны по блочному протоколу. Ежедневные бэкапы уходят в объектное хранилище по S3 API, а правило жизненного цикла удаляет их через 30 дней.
Порядок работы над хранилищем: сначала инвентаризация данных и требований, затем тиры и политики, и только потом архитектура. Обратный порядок приводит к покупке SAN под задачи, которым достаточно одного NAS, или к NAS там, где нужна блочная задержка ниже миллисекунды.
Уровни (тиры) хранения данных: как распределить данные по скорости и стоимости
Тирирование начинается с вопроса, как часто данные читают и насколько быстро к ним обращаются. Практика даёт четыре уровня. Tier 0 - NVMe, кэш и метаданные, время отклика 80-150 микросекунд. Tier 1 - SSD на SAS или SATA, виртуальные машины и рабочие наборы данных. Tier 2 - жёсткие диски SATA и SAS, файлы, бэкапы, медиа. Tier 3 - лента LTO и облачные архивы, где важна цена гигабайта, а не скорость. Для третьего тира без собственного кластера подойдёт Timeweb Cloud: серверы, объектное хранилище и Kubernetes в одной панели.
Критерии выбора тира: IOPS, латентность, стоимость
| Носитель | IOPS (случайные) | Латентность | Стоимость за ТБ | Типовые задачи |
|---|---|---|---|---|
| NVMe U.2/E3.S | 500 000-1 000 000 | 80-150 мкс | максимальная | OLTP-базы, etcd, кэш, метаданные |
| SAS или SATA SSD | 50 000-150 000 | 0,1-0,3 мс | в 3-5 раз ниже NVMe | виртуальные машины, индексы, файловые сервисы |
| SAS HDD 10-15k rpm | 150-250 | 4-8 мс | средняя | смешанные нагрузки, редко используемые базы |
| SATA HDD 7200 rpm | 80-150 | 8-15 мс | низкая | архив, бэкапы, медиатека, OSD-пулы |
| Лента LTO-9/LTO-10 | 1-3 потоковых | секунды и минуты | минимальная | долгосрочный архив, air-gap копии |
| Облачный архив | зависит от сервиса | десятки-сотни мс | оплата за объём и запросы | третий тир, реплика за пределы площадки |
Диапазоны меняются каждые 12-18 месяцев, поэтому при выборе опирайтесь на актуальные спецификации вендора. Пропускная способность различается сильнее, чем IOPS: NVMe отдаёт 3-7 ГБ/с последовательно, SATA HDD - 150-250 МБ/с, одна полка LTO-9 пишет около 400 МБ/с без сжатия.
Частая ошибка - покупать по принципу «чем быстрее, тем лучше». Горячих данных в типовой инфраструктуре 5-15% от общего объёма. Раскладка 10 ТБ NVMe, 30 ТБ SSD и 200 ТБ HDD закрывает задачи, на которые потребовалось бы 240 ТБ NVMe.
Автоматическое перемещение данных между тирами
Ни один массив не переносит данные между носителями «сам по себе». ZFS использует L2ARC как кэш чтения на SSD, а special vdev хранит метаданные и мелкие блоки на быстрых дисках. Перенос блоков между пулами ZFS не делает: его настраивают отдельными задачами, например репликацией датасета на медленный пул или выгрузкой в облако. Ceph распределяет данные по классам устройств через CRUSH-правила: пул с правилом hdd получает только жёсткие диски, пул с правилом nvme - только NVMe. S3 предлагает Intelligent-Tiering, который отслеживает обращения к объекту и переносит его между уровнями сам.
Рабочий пример политики тирирования. Файлы, к которым не обращались 30 дней, переезжают с SSD на SATA HDD. Объекты без обращений за 365 дней уходят в облачный архив. Снапшоты хранятся 14 дней с интервалом в один час, дальше удаляются. Такая схема снижает стоимость хранения на 40-60% без изменения кода приложений. Внутреннее устройство пулов, кэшей и репликации разобрано в статье про архитектуру программного хранилища.
Политики жизненного цикла данных: от создания до удаления
Управление жизненным циклом информации (ILM, Information Lifecycle Management) описывает путь данных от создания до удаления правилами, а не ручными решениями администратора. Этапы одинаковы для любого хранилища: создание, активное использование, редкое обращение, архив, удаление. Правила фиксируют, где данные находятся на каждом этапе, кто к ним имеет доступ и по какому событию они уходят.
Политика нужна по двум причинам. Первая - стоимость: 90% объектов в бэкапах и логах не читают повторно, и держать их на SSD бессмысленно. Вторая - требования регуляторов и внутреннего аудита: финансовые документы хранят 5-7 лет, медицинские данные могут требовать иных сроков, а логи безопасности - не менее года. Политика превращает эти требования в автоматические переходы и удаления.
Примеры политик для типовых данных
| Тип данных | Тир | Срок хранения | Действие по истечении |
|---|---|---|---|
| Ежедневные бэкапы | объектное хранилище или SATA HDD | 30 дней | удаление по правилу |
| Снапшоты виртуальных машин | SSD | 7-14 дней | удаление |
| Логи приложений | SATA HDD, затем объектное | 90 дней | сжатие, потом удаление |
| Медиафайлы и записи | SATA HDD или лента | 3-5 лет | перенос в холодный тир |
| Документы с регуляторным сроком | объектное с Object Lock | 5-7 лет | удаление только по истечении срока |
| Метрики и логи Kubernetes | NVMe, затем объектное | 7-30 дней | удаление |
Сроки в таблице - отправная точка. Для каждого набора проверьте, есть ли у бизнеса или регулятора требование к минимальному сроку хранения. Ошибка в сторону меньшего срока обходится дороже, чем лишний терабайт на ленте.
Реализация политик в S3, ZFS и TrueNAS
S3 задаёт правила в конфигурации бакета через Lifecycle. Типовое правило: перевод объектов из STANDARD в STANDARD_IA через 30 дней, в GLACIER через 90 дней и удаление через 365 дней. Object Lock в режиме compliance делает объекты неизменяемыми: ни пользователь, ни администратор не удалит их раньше срока. Версионирование защищает от случайной перезаписи, но требует правила NoncurrentVersionExpiration, иначе старые версии копятся годами.
ZFS управляет сроками через снапшоты. Инструменты sanoid или zfs-auto-snapshot создают снимки по расписанию и удаляют их по retention-политике: hourly за 24 часа, daily за 30 дней, monthly за 12 месяцев. Удержание zfs hold защищает датасет от удаления до снятия блокировки, что полезно для расследований и аудита.
В TrueNAS политики настраиваются в разделе Data Protection. Periodic Snapshot Tasks создают рекурсивные снапшоты с параметром Keep for, Replication Tasks копируют их на второй узел, Cloud Sync Tasks выгружают данные в S3-совместимое хранилище. Проверяйте политику на тестовом датасете: удаление снапшотов и датасетов не имеет корзины, и ошибка в шаблоне имени стирает данные сразу.
Оптимизация хранения: дедупликация и компрессия
Компрессия сжимает содержимое блока и уменьшает объём записи. Дедупликация ищет блоки с одинаковым хешем и хранит их в одном экземпляре, подставляя ссылки. Обе технологии экономят место, но по-разному влияют на CPU, память и задержку.
Компрессия работает inline, то есть на пути записи, либо post-process, когда сжатие выполняется в фоне. Алгоритмы различаются по скорости и степени сжатия: LZ4 даёт около 2-3x на текстовых данных почти без нагрузки, ZSTD с уровнем 3 сжимает на 10-20% сильнее при небольшом росте нагрузки на CPU, высокие уровни ZSTD дают лучшее сжатие, но заметно тормозят запись. Дедупликация выполняется только inline и требует таблицы DDT (deduplication table), которая живёт в оперативной памяти.
Память под DDT - главный ограничитель. В ZFS на каждый терабайт дедуплицированных данных нужно ориентировочно 1-5 ГБ RAM, точное значение зависит от размера блока и числа уникальных блоков. Если памяти не хватает, система читает DDT с диска, и задержка вырастает в десятки раз. Дедупликация включается для всего датасета, а не для отдельных файлов, поэтому включение «на всякий случай» на пуле со смешанными данными почти всегда ухудшает производительность.
Когда дедупликация и компрессия дают выигрыш, а когда вредят
| Сценарий | Дедупликация | Компрессия |
|---|---|---|
| VDI, 100 ВМ из одного шаблона | 5-10x | 1,5-2x |
| Файловые бэкапы с повторяющейся структурой | 2-4x | 1,3-1,8x |
| Логи и текстовые выгрузки | 1,1-1,3x | 3-10x |
| База с уникальными записями | около 1x | 1,2-1,5x |
| Медиатека JPEG и H.264 | около 1x | около 1x |
| Зашифрованный массив или зашифрованные бэкапы | около 1x | около 1x |
Зашифрованные и уже сжатые данные не сжимаются повторно: энтропия максимальна, дедупликация по хешу тоже не находит совпадений. Обратный случай - контейнерные образы и клоны виртуальных машин, где одни и те же страницы повторяются тысячами. Здесь дедупликация оправдана, хотя клоны ZFS уже используют общие блоки без таблицы DDT.
Настройка в ZFS и TrueNAS
Компрессия включается на датасет командой zfs set compression=lz4 pool/dataset или zfs set compression=zstd pool/dataset. В TrueNAS Scale компрессия LZ4 включена по умолчанию для новых датасетов. Эффект проверяется командой zfs get compressratio pool/dataset, фактическое потребление - через zpool list -v.
Дедупликация включается командой zfs set dedup=on pool/dataset. Перед этим посчитайте потенциальный выигрыш на копии данных: если уникальных блоков больше 70%, экономия не оправдает расход памяти. Режим dedup=verify включён по умолчанию и проверяет совпадения контрольной суммой, отключать его нельзя. Статистику DDT даёт zpool status -D pool, долю сэкономленного места - zfs get dedupratio.
Размер блока влияет на обе технологии. Для баз данных recordsize 16K уменьшает усиление записи, для файловых серверов и медиа подходит 1M. Для томов zvol размер блока фиксируется при создании, изменить его позже нельзя, поэтому параметр проверяют до переноса данных.
Типовые архитектуры хранения: DAS, NAS, SAN, hyperconverged, объектные
Архитектура определяет, как серверы получают доступ к данным и какие протоколы при этом используются. Различия видны в трёх параметрах: тип доступа (блочный, файловый, объектный), задержка и способ масштабирования.
| Архитектура | Доступ | Протоколы | Латентность | Масштабирование | Типовые задачи |
|---|---|---|---|---|---|
| DAS | блочный | SAS, SATA, NVMe | от 0,08 мс | вертикальное | базы данных, диски OSD |
| NAS | файловый | NFS, SMB | 0,2-2 мс | вертикальное, реже кластер | общие папки, бэкапы, медиа |
| SAN | блочный | iSCSI, Fibre Channel, NVMe-oF | 0,1-1 мс | вертикальное | VMware VMFS, Hyper-V CSV, Oracle |
| Hyperconverged | блочный, файловый, объектный | зависит от платформы | 0,5-3 мс | горизонтальное | виртуализация, VDI, частное облако |
| Объектное | объектный | S3, Swift | 10-100+ мс | горизонтальное | бэкапы, PV для Kubernetes, ML-датасеты |
Подробное сравнение DAS, NAS, SAN и HCI с расчётом RPO/RTO и стоимости владения приведено в отдельной статье про выбор системы хранения.
DAS: когда прямое подключение оправдано
DAS (Direct-Attached Storage) - диски, подключённые к серверу напрямую: NVMe в слотах материнской платы, SAS-полка на HBA-контроллере, внешний JBOD. Задержка минимальна, потому что между приложением и носителем нет сети: 0,08-0,15 мс на NVMe. Стоимость гигабайта ниже, чем у SAN, на 30-50%, так как не нужны контроллеры хранения и фабрика.
Ограничения тоже прямые. Данные видит только этот сервер, совместный доступ невозможен, а отказ узла делает хранилище недоступным до восстановления. Масштабирование упирается в число слотов и портов HBA. Типичные сценарии: PostgreSQL и MySQL на локальных NVMe, ZFS-пул в одном сервере TrueNAS, диски OSD в узлах Ceph.
NAS: файловое хранилище для совместной работы
NAS (Network-Attached Storage) отдаёт данные по сети через NFS или SMB. NFS 4.2 выбирают для Linux и Kubernetes, SMB 3.1.1 - для Windows и macOS. Практические реализации: TrueNAS, Synology, NetApp, а также ZFS или XFS на сервере с экспортом по NFS.
Сценарии: общие папки с правами Active Directory, бэкапы рабочих станций, медиатека, PersistentVolume с режимом RWX для Kubernetes. Узкое место - сеть: 1 Гбит/с даёт около 110 МБ/с, 10 Гбит/с - 1,1 ГБ/с, 25 Гбит/с - 2,8 ГБ/с. Задержка NFS поверх 10 GbE составляет 0,3-1 мс, чего достаточно для виртуальных машин и файловых сервисов, но мало для чувствительных к задержке баз данных.
SAN: блочное хранилище для виртуализации и баз данных
SAN (Storage Area Network) предоставляет блочные LUN по iSCSI поверх 10/25/100 GbE, по Fibre Channel 16/32 Гбит/с или через NVMe-oF с RoCEv2. Серверы видят LUN как локальный диск и строят на нём VMFS, CSV или ASM.
Сильные стороны: стабильная задержка 0,1-1 мс, многопутевой доступ MPIO или DM-Multipath, синхронная репликация между площадками, снапшоты на уровне массива. Сценарии: VMFS для VMware, CSV для Hyper-V, Oracle. Цена - отдельная фабрика коммутаторов, лицензии и специалист по массивам. SAN выбирают, когда нужна предсказуемая задержка p99 и защита от отказа узла виртуализации.
Hyperconverged: объединение вычислений и хранения
HCI объединяет вычислительные узлы и хранение в одном кластере: каждый узел отдаёт диски в общий пул SDS. Примеры: VMware vSAN, Nutanix, Proxmox VE с Ceph, Azure Stack HCI. Данные реплицируются между узлами (обычно 2-3 копии) либо кодируются схемой EC.
Плюсы: масштабирование добавлением узла, единое управление, отсутствие отдельной СХД. Минусы: вычисления и хранение растут вместе, поэтому при нехватке CPU приходится покупать и диски; задержка на 1-2 мс выше, чем у SAN; нужна сеть 10/25 GbE, а для нагрузки с высокой записью - выделенный интерфейс репликации. HCI удобен для виртуализации, VDI и частного облака среднего размера.
Объектные хранилища: масштабируемость и S3
Объектное хранилище хранит данные как объекты с метаданными и доступом по HTTP через S3 API или Swift. Иерархии каталогов нет, а масштабирование выполняется добавлением узлов: MinIO, Ceph RGW, Swift. Задержка на порядок выше блочной, 10-100+ мс, зато кластер растёт до петабайтов без остановки.
Функции, которые важны на практике: версионирование, Object Lock для неизменяемых копий, теги и метаданные для выборок, правила жизненного цикла для перевода в холодные классы. Сценарии: бэкапы Veeam и Restic, артефакты CI, логи, ML-датасеты, PV для Kubernetes через CSI. Сравнение объектного, блочного и файлового доступа с критериями выбора собрано в статье про типы хранилищ.
Как сопоставить требования приложений с возможностями СХД
Требования переводятся в параметры массива в шесть шагов. Сначала измерьте текущую нагрузку и оцените рост. Потом посчитайте IOPS с учётом штрафа RAID. Дальше проверьте пропускную способность сети. Затем заложите запас по производительности и объёму. После этого подтвердите задержку p99 и только потом выбирайте конкретные модели.
- Снимите метрики: iostat, sar, fio, pgbench, ioping показывают IOPS, задержку и профиль доступа.
- Оцените рост данных: 10-30% в год для файловых сервисов, до 50% для логов и метрик.
- Посчитайте IOPS: суммарно по дискам минус потери на RAID.
- Проверьте сеть: 1 Гбит/с, 10 Гбит/с и 25 Гбит/с дают 110 МБ/с, 1,1 ГБ/с и 2,8 ГБ/с.
- Заложите запас: 30% по IOPS, 30-40% по объёму, иначе пул упрётся в порог заполнения.
- Зафиксируйте SLA по задержке p99 и проверьте его бенчмарком до переноса продакшена.
Определение требований: IOPS, пропускная способность, латентность
| Приложение | IOPS | Латентность | Профиль доступа |
|---|---|---|---|
| PostgreSQL OLTP | 3000-10 000 | p99 ниже 1 мс | случайные 8 КБ, чтение и запись |
| MySQL с InnoDB | 2000-8000 | p99 1-2 мс | случайные 16 КБ |
| Kubernetes etcd | 500-1000 | p99 ниже 10 мс | синхронная запись с fsync |
| Файловый сервер, 100 пользователей | 100-300 | 5-20 мс | смешанный |
| Медиасервер, 40 потоков 4K | 200-500 | 10-30 мс | последовательное чтение, 200-500 Мбит/с |
| Витрина аналитики | 500-2000 | не критична | последовательные чтения |
Профиль нагрузки важнее средних значений. Для случайной записи считайте по формуле: суммарные IOPS равны числу дисков, умноженному на IOPS одного диска, минус потери на RAID. Восемь SATA HDD по 100 IOPS дают 800 операций в секунду на чтение, RAID 5 со штрафом записи 4 оставляет около 200 операций записи, RAID 10 - около 400. Синтетику снимайте через fio, задержку проверяйте ioping, для PostgreSQL используйте pgbench на копии данных.
Выбор RAID и его влияние на производительность
| Уровень | Минимум дисков | Потеря ёмкости | Штраф записи | Отказоустойчивость |
|---|---|---|---|---|
| RAID 0 | 2 | 0% | 1 | нет |
| RAID 1 | 2 | 50% | 2 | один диск в зеркале |
| RAID 5 | 3 | один диск | 4 | один диск |
| RAID 6 | 4 | два диска | 6 | два диска |
| RAID 10 | 4 | 50% | 2 | до одного диска в каждой паре |
RAID 5 на дисках 8-16 ТБ опасен: перестройка массива занимает 12-36 часов, а второй отказ за это время уничтожает пул. К этому добавляется write hole при потере питания. Для баз данных берите RAID 10, для больших архивных массивов - RAID 6 или erasure coding. RAID не заменяет бэкап: массив защищает от отказа диска, но не от ошибочного удаления или шифровальщика.
Проектирование хранилища, которое масштабируется без переделок
Масштабируемость закладывается решениями на этапе проектирования, а не покупкой дополнительных полок. Пять правил покрывают большинство случаев. Разделяйте вычислительные узлы и хранение там, где они растут с разной скоростью. Оставляйте свободные слоты и порты. Считайте сеть на три года вперёд. Не допускайте единой точки отказа в пути данных. Настраивайте мониторинг и проверяйте восстановление бэкапа, а не только факт его создания.
Горизонтальное vs вертикальное масштабирование
Вертикальное масштабирование означает добавить диски или полку к существующей системе. Оно проще, не меняет схему администрирования, но ограничено контроллером: обычно 24-60 дисков на полку и 2-4 полки на контроллер. Ребилд после замены диска идёт часами, а расширение часто требует окна обслуживания.
Горизонтальное масштабирование добавляет узлы. Ceph запускают минимум на трёх узлах, для продакшена лучше пять, MinIO требует не менее четырёх. Кластер растёт без остановки, но требует сети 10/25 GbE и даёт overhead репликации: три копии оставляют 33% сырой ёмкости, схема EC 4+2 - около 67%. Выбор между подходами определяет бюджет на сеть и квалификацию команды.
Примеры масштабируемых решений: Ceph, MinIO, TrueNAS Scale
Ceph состоит из mon-узлов (3 или 5 для кворума), OSD (по одному на диск), MDS для CephFS и RGW для S3. CRUSH распределяет данные по узлам, кластер самовосстанавливается после отказа. Пример: 5 узлов по 12 дисков 16 ТБ дают 960 ТБ сырой ёмкости, при репликации 3x полезно около 320 ТБ. Минимум для продакшена - 3 узла, 10 GbE и отдельная сеть репликации.
MinIO в distributed mode разворачивают на четырёх и более узлах, данные хранятся с erasure coding, доступ идёт по S3 API. Решение подходит под бэкапы, артефакты CI и ML-датасеты. TrueNAS Scale закрывает другой сценарий: один узел с ZFS, приложениями и S3-совместимым доступом, репликация на второй узел. Горизонтального масштабирования у него нет, поэтому рост закрывают репликами. Оценка решений для быстро растущих объёмов и переноса данных без потерь дана в статье про хранение больших данных.
Практические примеры и типичные ошибки
Три типовые задачи показывают, как требования превращаются в конфигурацию. Для виртуализации на 100 ВМ со средним профилем 100 IOPS на машину нужно около 10 000 IOPS при p99 в 1 мс, снапшоты и репликация: это массив с NVMe-кэшем и SSD-тиром, LUN на VMFS, multipath и синхронная репликация на вторую площадку для RPO 0. Для бэкапов подходит объектное хранилище с Object Lock, retention 30 дней и недельной копией на ленту с air-gap.
Пример: хранилище для Kubernetes
| Вариант | Доступ | Плюсы | Минусы | Когда выбирать |
|---|---|---|---|---|
| NFS + CSI | RWX | простой, много подов одновременно | единая точка отказа, сетевая задержка | общие данные, артефакты |
| Ceph RBD + CSI | RWO | блочный доступ, реплики, снапшоты | нужен кластер 3+ узлов, сложнее | базы данных, stateful-сервисы |
| MinIO + CSI | S3 | подходит для бэкапов и артефактов | задержка выше, не для баз | объектные данные, логи |
| local-path | локальный | максимальная скорость | данные привязаны к узлу | тесты и кэш |
etcd требует fsync и p99 ниже 10 мс, поэтому его данные держат на локальном NVMe. PVC с базой размещают на блочном томе Ceph RBD или на LUN из SAN, а не на NFS. Для RWX-томов с медиа и артефактами NFS остаётся самым простым вариантом, если узел NAS не стал единой точкой отказа: используйте два узла с репликацией или CephFS.
Чек-лист проектирования хранилища
- Инвентаризация данных: объём, профиль доступа, требования к задержке для каждого приложения.
- Расчёт: IOPS со штрафом RAID, пропускная способность сети, запас 30%.
- Тиры: распределение по NVMe, SSD, HDD, ленте и облаку с обоснованием.
- Политики: сроки хранения, переходы между тирами, удаление, Object Lock для аудита.
- Архитектура: DAS, NAS, SAN, HCI или объектное хранилище под протоколы приложений.
- Сжатие на всех датасетах, дедупликация только после расчёта DDT и запаса RAM.
- Отказоустойчивость: RAID 10 или RAID 6/EC, репликация, отсутствие единой точки отказа.
- Сеть: 10/25 GbE для продакшена, отдельный интерфейс репликации.
- Мониторинг: SMART, заполнение пулов (тревога 80%, критично 90%), задержка p99.
- Бэкапы: схема 3-2-1, регулярная проверка восстановления, копия за пределами площадки.
Частые ошибки стоят дороже любого оборудования. Меньше 1 ГБ RAM на терабайт пула ZFS, а для дедупликации до 5 ГБ на терабайт, приводит к просадкам при чтении. RAID 5 на дисках от 8 ТБ увеличивает риск потери пула при перестройке. Один массив под продакшен, бэкапы и логи лишает возможности быстро восстановиться. Заполнение пула выше 90% ломает работу ZFS. Смешивание трафика репликации с клиентским перегружает каналы.
Начните с таблицы: приложение, объём, IOPS, задержка p99, срок хранения. Эти пять колонок определяют тиры, политики и архитектуру, а расчёт на их основе даёт конфигурацию, которую можно расширять узлами или полками без миграции продакшена.