Локальные, облачные и гибридные системы хранения: как выбрать по TCO и задержкам

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

Производительность хранилища в каждый момент ограничивает один слой: диски вместе с контроллером и шиной PCIe, сеть или файловая система с параметрами протокола. Массив отдаёт 500 МБ/с локально, а NFS-клиент получает 80 МБ/с, и замена накопителей на более быстрые не даст ничего: предел в сети или настройках протокола. Встречается и обратная картина: канал держит 9,4 Гбит/с, но iowait стабильно выше 30%, а await растёт под нагрузкой, значит упёрлись диски.

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

Дальше логика такая. Данные с ежедневным доступом и требованием к задержке в единицы миллисекунд: локальные NVMe или гибрид с локальным кэшем. Архивы и резервные копии, которые читают раз в квартал: объектное облачное хранилище или холодный класс S3. Смешанный профиль: гибридная схема, где горячий слой локальный, холодный в облаке, а перемещение выполняют правила жизненного цикла.

Как измерить baseline и найти узкое место

1. Сбросьте кэш перед замером. Свободная оперативная память и page cache отдают данные быстрее любого накопителя, поэтому тест на прогретом кэше показывает скорость RAM. Перед запуском выполните echo 3 > /proc/sys/vm/drop_caches. Для ZFS добавляйте в fio direct=1, иначе часть чтений обслужит ARC.
2. Воспроизведите реальную нагрузку. Синхронный dd с глубиной очереди 1 показывает максимум для одной операции и ничего не говорит о базе данных с 64 одновременными запросами. В fio задавайте iodepth 32-128, смесь чтения и записи, размер блока под задачу: 4-16 КБ для СУБД, 128 КБ - 1 МБ для последовательной записи файлов.
3. Смотрите на диски. iostat -x 1 выдаёт iowait, await и загрузку устройств. Растущий await при iowait выше 30% указывает на накопители или контроллер.
4. Проверьте сеть. ethtool eth0 показывает скорость линка и duplex: гигабит на 10-гигабитном порту встречается чаще, чем ожидается. iperf3 между сервером и клиентом отделяет проблему канала от проблемы протокола.
5. Разберите протокол и файловую систему. Локально 500 МБ/с, по NFS 80 МБ/с: проверяйте rsize, wsize, nconnect и размер TCP-окна. Для ZFS смотрите recordsize, режим sync, наличие SLOG и ZIL. Синхронная запись при sync=always без быстрого SLOG упирается в HDD.
6. Отслеживайте деградацию. Скорость, которая падает со временем, требует проверки SMART, результата scrub и типов дисков в пуле. Ресурс SSD по TBW и жизненный цикл носителей разобраны в материале об обработке и хранении данных в серверных системах.

Сравнение локальных, облачных и гибридных систем хранения

Классификация по архитектуре (DAS, NAS, SAN, SDS и облачные сервисы) помогает не смешивать уровни: сначала выбирают класс системы, потом конкретную реализацию. Разбор классов с таблицами и расчётом IOPS собран в статье о СХД в 2026: классификация, архитектура и практический выбор.

Локальные СХД: когда собственное железо оправдано

Предсказуемая задержка 0,1-1 мс на NVMe и 5-10 мс на HDD, полный контроль над ZFS с его ARC, recordsize и режимом sync, отсутствие ежемесячных платежей за гигабайт. Данные не покидают периметр, что упрощает закрытие требований по хранению персональных и коммерческих сведений.

Обратная сторона: капитальные затраты, электричество и охлаждение, замена дисков, простои при отказе узла. Для непрерывности нужен второй узел или реплика, и это удваивает бюджет железа. Собственное хранение оправдано для СУБД, очередей, виртуализации, файловых шар под CAD и видео, кэша сборки контейнеров, локальных NVMe-томов в Kubernetes. Ориентир: при объёме горячих данных меньше 5-10 ТБ экономика чаще на стороне облака.

Облачные сервисы: S3, холодное хранение и их экономика

Модели тарификации в S3-совместимых сервисах: Standard около $0,023 за ГБ в месяц, то есть $23 за ТБ; Standard-IA $0,0125 за ГБ с минимумом 30 дней; Glacier Instant Retrieval $0,004 за ГБ с минимумом 90 дней; Glacier Flexible Retrieval $0,0036 за ГБ; Deep Archive $0,00099 за ГБ, это примерно $1 за ТБ в месяц, минимум 180 дней. Запросы тарифицируются отдельно: $0,005 за 1000 PUT и $0,0004 за 1000 GET, то есть миллион GET стоит $0,40. Исходящий трафик $0,09 за ГБ, значит разовая выгрузка 100 ТБ обойдётся в $9 216.

Сильные стороны: нет CAPEX, масштабирование за минуты, геораспределение, версионирование, Object Lock и готовые правила жизненного цикла. Слабые: задержка в десятки миллисекунд, привязка к каналу и тарифам, необходимость следить за расходом запросов. Облако выгодно для архивов, резервных копий, логов, медиаконтента и аналитических датасетов, к которым обращаются редко.

Если нужен S3-совместимый слой, виртуальные машины под шлюз и кэш или managed Kubernetes рядом с хранилищем, подойдёт облачная инфраструктура от Timeweb Cloud: серверы, базы данных и объектное хранилище с оплатой за фактические ресурсы.

Гибридные схемы: баланс между производительностью и стоимостью

Гибрид соединяет локальный кэш и облачный бэкенд. Технически это выглядит как ZFS с ARC в оперативной памяти и L2ARC на NVMe для чтения, SLOG на NVMe для синхронной записи, плюс S3-совместимый шлюз (MinIO, Ceph RGW) с локальным кэшем и бэкендом в облаке. Правила жизненного цикла переводят объекты в холодные классы по возрасту.

Выгода: горячие данные получают задержку локального массива, холодные хранятся по цене архива, зависимость от одного провайдера падает за счёт прослойки с общим API. Цена решения: две инфраструктуры в мониторинге, тестирование правил перехода и риск ошибки в lifecycle, которая унесёт нужные данные в холодный класс раньше срока. Какой слой подходит конкретной задаче, разобрано в сравнении объектного, блочного и файлового хранилищ.

Как рассчитать TCO для локального и облачного хранения

Для локального варианта: TCO = CAPEX / срок службы + (электричество + охлаждение + ЗИП + обслуживание + часы администратора + амортизация стойки) + потери от простоя. Для облака: TCO = сумма (объём x цена за ТБ x число месяцев) + запросы + исходящий трафик + плата за раннее удаление + стоимость миграции. Методика расчёта IOPS и ёмкости с уровнями hot, warm, cold и archive описана в материале о проектировании СХД предприятия.

Пример на 100 ТБ и горизонте 5 лет. Локально: 12 дисков по 16 ТБ в RAIDZ2, сервер с 256 ГБ RAM, двумя NVMe под SLOG и L2ARC, сеть 25 GbE. CAPEX около $13 000. Питание 350 Вт круглосуточно даёт около $460 в год, охлаждение добавляет 30-50%. Замена дисков при AFR 2% - примерно 1,2 диска за 5 лет, это ещё около $550 с запасом на полке. Обслуживание 4 часа в месяц по $60 даёт $14 400 за 5 лет. Итого около $31 000, то есть $5,2 за ТБ в месяц с учётом работы администратора и $2,8 за ТБ без неё.

Те же 100 ТБ в облаке: S3 Standard $2 355 в месяц и $141 300 за 5 лет, Glacier Flexible Retrieval $369 в месяц и $22 140 за 5 лет, Deep Archive $101 в месяц и $6 060 за 5 лет. Запросы, извлечение и трафик считаются сверх этого.

Точка безубыточности по 100 ТБ горячих данных: $2,8-5,2 за ТБ локально против $23,5 за ТБ в S3 Standard, собственное железо окупается за 1-2 года. Для 5 ТБ архива расклад обратный: мини-сервер за $2 000 с электричеством даёт около $46 в месяц за 5 лет, а Deep Archive хранит те же 5 ТБ примерно за $5 в месяц. Итог зависит от доли горячих данных: если в облако уходит только холод, гибрид обходится дешевле чистых вариантов.

Скрытые расходы, которые часто упускают

• Исходящий трафик по $0,09 за ГБ: разовая выгрузка 100 ТБ дороже года хранения в Deep Archive.
• Плата за запросы: массовый листинг миллионов объектов и перебор метаданных накапливают заметную сумму.
• Минимальный срок хранения: удаление объекта из Glacier раньше 90 дней и из Deep Archive раньше 180 дней оплачивается как полный срок.
• Минимальный размер объекта 128 КБ в IA и холодных классах. Миллион файлов по 10 КБ тарифицируется как 128 ГБ вместо 10 ГБ.
• Версионирование: удалённые версии продолжают занимать место и тарифицироваться.
• Репликация между регионами и запросы к сервису ключей: около $0,03 за 10 000 операций.
• Локально: ЗИП на полке, второй узел для непрерывности, стойка, обучение персонала, стоимость часа простоя.

Как снизить зависимость от облачного провайдера

Риски привязки измеримы: рост тарифов на 20-30% при пересмотре прайса, изменение условий по минимальным срокам, недоступность региона, лимиты на число запросов, блокировка аккаунта при инциденте с платежом. Часть событий приводит к простоям, часть к незапланированным расходам.

• S3-совместимый API как обязательное требование. MinIO, Ceph RGW и большинство провайдеров говорят на одном протоколе, поэтому переезд меняет endpoint и ключи, а не код приложения.
• Endpoint и регион в конфигурации, а не в исходниках: смена провайдера ограничивается правкой переменных окружения.
• Шифрование на клиенте (restic, borg, age). Ключи живут вне облака, провайдер не читает содержимое и не мешает миграции.
• Отказ от проприетарных функций в критичных сценариях: специфичные очереди, триггеры и форматы метаданных усложняют вынос данных.
• Вторая копия у другого поставщика или на своём железе для самых важных наборов.
• Регулярная проверка выгрузки: раз в квартал переносите небольшой набор в тестовый бакет другого провайдера и сверяйте контрольные суммы.

Миграция данных между облаками: практические аспекты

1. Оцените объём и число объектов. Миллион мелких объектов переносится дольше, чем один архив на 10 ТБ.
2. Посчитайте канал: 100 ТБ по 1 Гбит/с занимают около 9,3 суток идеального времени, по 10 Гбит/с меньше суток. На практике добавляйте 30-50% на накладные и повторные попытки.
3. Проверьте стоимость исходящего трафика до старта: 100 ТБ по $0,09 за ГБ дают $9 216. Для больших объёмов физическая доставка дисков (AWS Snowball, Azure Data Box) часто дешевле.
4. Выберите инструмент: rclone с проверкой контрольных сумм, aws cli sync, AWS DataSync для регулярных переносов.
5. Переносите версии и метаданные: правила жизненного цикла, теги и Object Lock настраиваются заново, автоматически они не переезжают.
6. Сверьте результат: число объектов, суммарный объём, выборочная проверка контрольных сумм, тестовое чтение.

Практические сценарии: резервное копирование, архивирование и активные данные

Три типовые задачи решаются разными комбинациями слоёв и классов хранения.

Резервное копирование в облако: пошаговый план

1. Зафиксируйте RPO и RTO. RPO 15 минут требует репликации, ночной инкремент закрывает RPO в сутки. RTO определяет, держите ли вы горячий стенд или восстанавливаетесь с нуля.
2. Отдельный аккаунт или проект под бэкапы: компромисс прод-аккаунта не должен уносить копии.
3. Включите версионирование бакета и Object Lock в режиме compliance, если копии защищают от шифровальщиков.
4. Шифруйте на клиенте: restic, borg, gpg или age. Ключи храните вне облака и вне прод-контура.
5. Настройте расписание: restic или borg для файлов и виртуальных машин, rclone для снапшотов, pg_basebackup с архивом WAL для PostgreSQL.
6. Добавьте правила жизненного цикла: 30 дней в Standard, дальше Standard-IA, с 90 дней Glacier IR.
7. Ограничьте бюджет: метрики на объём и число запросов, алерт при отклонении от прогноза.
8. Проверяйте восстановление раз в квартал: тестовый restore, замер времени, сверка контрольных сумм.

Схема 3-2-1 работает и с облаком: три копии, два типа носителей, одна вне основной площадки. Облачный бакет закрывает третье требование.

Архивирование: как сэкономить на холодном хранении

Стратегия по возрасту данных: 0-30 дней S3 Standard, 30-90 дней Standard-IA по $0,0125 за ГБ, старше 90 дней Glacier Instant Retrieval по $0,004 за ГБ или Flexible по $0,0036 за ГБ, старше 180 дней Deep Archive по $0,00099 за ГБ, около $1 за ТБ в месяц.

Экономика на 100 ТБ за 3 года: Standard стоит $84 780, Glacier Flexible $13 284, Deep Archive $3 636. Разница между стандартным и холодным классом превышает $70 000.

Условия, о которых забывают: минимальный срок хранения 30 дней для IA, 90 дней для Glacier, 180 дней для Deep Archive, плата за извлечение ($0,01 за ГБ в Standard-режиме и $0,0025 за ГБ в Bulk) и минимум 128 КБ на объект. Архив из миллиона мелких файлов упаковывайте в tar с zstd: это уменьшает и тарифицируемый объём, и число запросов.

Активные данные: когда локальное или гибридное хранение выигрывает

База данных с 50 000 IOPS и требованием к задержке 1 мс не размещается в объектном хранилище с задержкой 20-100 мс: ей нужны локальные NVMe. Рабочая конфигурация гибрида выглядит так:

• ARC в оперативной памяти: 50-70% RAM под кэш чтения. На 256 ГБ это 128-180 ГБ горячих блоков.
• L2ARC на NVMe, когда рабочий набор больше памяти: кэш второго уровня держит то, что не влезло в ARC.
• SLOG на NVMe при sync=always: снижает задержку синхронных операций, ZIL остаётся на дисках как журнал.
• recordsize под данные: 8-16 КБ для СУБД, 128 КБ для файловых шар, 1 МБ для потокового видео и крупных архивов.
• Уровни: NVMe под горячее, SSD под тёплое, HDD под тёплое-холодное, объектное хранилище под архив и бэкапы.
• NFS: rsize и wsize 1 МБ, nconnect=4-8 для нескольких TCP-соединений, версия 4.2 с серверным копированием файлов.

Для контейнеров нагрузку разделяют по классам: локальные NVMe через local PV для сервисов, чувствительных к задержке, объектное хранилище для логов и артефактов, CSI-драйвер с блочным томом для СУБД.

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

• Бенчмарк на прогретом кэше: цифры завышены в разы, а реальная нагрузка упирается в диски.
• Тест одним потоком или через dd с глубиной очереди 1: результат не имеет отношения к базе данных с конкурентными запросами.
• Планирование под текущий объём. В ZFS расширение пула идёт добавлением vdev, а не отдельного диска, и запас на 2-3 года дешевле, чем пересборка пула.
• Забытые скрытые расходы: трафик, запросы, минимальные сроки, удалённые версии объектов.
• Отсутствие мониторинга ёмкости, задержки, iowait, ошибок SMART и остатка ресурса SSD по TBW. Деградация становится заметной, когда её уже нельзя списать на пиковую нагрузку.
• Проприетарные API и форматы, которые превращают миграцию в отдельный проект.
• Резервные копии без проверки восстановления.
• Синхронная репликация между площадками по WAN: задержка канала добавляет время к каждой записи.
• Путаница в единицах: 100 ТБ против 100 ТиБ дают расхождение около 10%, а RAIDZ2 на 12 дисках отдаёт полезную ёмкость 10 дисков.

Как не ошибиться с выбором формата данных

Формат определяет четыре измеримых параметра: объём на носителе, скорость сравнения и индексации, стоимость конвертации при отдаче данных и сложность миграции. JSON удобен в отладке, но занимает в 3-5 раз больше места, чем колоночный Parquet со сжатием. Сжатие zstd или lz4 в потоке снижает объём записи и цену холодного хранения. Многогигабайтные объекты требуют multipart-загрузки, а миллионы мелких файлов упираются в минимальные 128 КБ тарификации и накладные расходы на метаданные. Ошибка проявляется на масштабе, когда в бакете уже сотни миллионов объектов, а схему и миграции приходится переделывать.

Для медиафайлов формат и хранилище выбирают вместе: от разрешения и частоты кадров зависит объём, от сценария доступа зависит класс хранения. Как это устроено, разобрано в материале о системе хранения изображений: назначение, типы и критерии выбора.

Заключение: как выработать стратегию хранения без привязки к вендору

Стратегия строится в четыре шага: измерить baseline и найти узкое место, разделить данные по уровням доступа, посчитать TCO на 3-5 лет вместе с трафиком и часами администратора, заложить возможность миграции до подписания контракта. Мониторинг и пересмотр схемы раз в год закрывают рост объёмов и изменение тарифов.

Чек-лист перед решением:

• IOPS, пропускная способность, задержка и объём замерены на нагрузке, похожей на рабочую.
• Узкое место локализовано: диски, сеть или файловая система.
• Для каждого класса данных заданы RPO и RTO.
• Данные разделены на горячие, тёплые, холодные и архивные с правилами перехода.
• TCO посчитан на 3-5 лет, включая исходящий трафик, запросы, электричество, ЗИП и часы администратора.
• API S3-совместимый, endpoint в конфигурации, шифрование на клиенте.
• Мониторинг ёмкости, задержки, SMART и ресурса SSD настроен.
• Тестовое восстановление из резервной копии пройдено, время восстановления измерено.

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