Как организовать хранение больших объёмов данных без потери производительности
Хранение больших объёмов данных начинают проектировать не с покупки дисков, а с описания нагрузки: какие данные, как быстро растут, кто и как часто к ним обращается. Горячие данные размещают на быстрых SSD, холодные — на ёмких HDD или в объектном хранилище. Закладывают разницу между физической и полезной ёмкостью, проверяют сеть и отдельно проектируют резервное копирование. Производительность чаще всего теряется не на дисках, а на сети, контроллерах или неправильно выбранном типе хранилища.
Большой объём данных — понятие относительное. Для одной компании это 5 ТБ сканов договоров, для другой — сотни терабайт видеоархива, логов и данных для аналитики. Порог в терабайтах здесь ничего не решает. Сложности начинаются, когда одновременно растут объём, количество файлов, число пользователей и интенсивность операций, а привычный сервер перестаёт справляться.
Разберём, как устроено хранение больших массивов данных, где обычно возникает узкое место и как посчитать ёмкость, скорость и стоимость.
Разберём, как устроено хранение больших массивов данных, где обычно возникает узкое место и как посчитать ёмкость, скорость и стоимость.
Когда объём данных становится «большим»
Признаки того, что хранилище пора проектировать как отдельную систему:
- резервная копия перестаёт укладываться в ночное окно;
- поиск и открытие файлов заметно замедлились, хотя свободное место ещё есть;
- количество файлов исчисляется миллионами, и файловая система тратит время на метаданные;
- с данными одновременно работают десятки пользователей, серверов или аналитических задач;
- объём прибавляет больше 30–50% в год;
- перенос данных на новое оборудование растягивается на дни.
Особенно заметно это там, где хранение совмещено с обработкой: обработка больших объёмов данных и анализ больших объёмов данных создают постоянную нагрузку на чтение, и медленное хранилище тормозит всю цепочку. Работа с большим объёмом данных требует смотреть на весь путь данных — от приложения до диска и обратно — а не только на ёмкость.
Шаг 1. Разделите данные по температуре
Данные используются неравномерно. Свежие проекты, текущие базы и логи последних дней нужны постоянно, архив прошлых лет открывают редко. Хранить всё на одинаково дорогих носителях невыгодно, а на одинаково медленных — неудобно.
Разделение по уровням — самый простой способ сохранить производительность и не переплатить. Быстрые диски получают только те данные, которым скорость действительно нужна.
Шаг 2. Посчитайте объём с учётом роста
Расчёт объёма хранилища включает текущие данные, прогноз роста на срок службы оборудования (обычно 3–5 лет) и запас. Прогноз лучше строить по фактической динамике за последние месяцы, а не по ощущениям.
Пример: 50 серверов пишут логи, каждый — около 2 ГБ в сутки. Это 100 ГБ в день и около 36,5 ТБ в год. Если активно логи нужны 30 дней, на быстром хранилище держат около 3 ТБ, а остальное переносят в архив. Без разделения пришлось бы покупать 36,5 ТБ быстрых дисков в год.
Пример: 50 серверов пишут логи, каждый — около 2 ГБ в сутки. Это 100 ГБ в день и около 36,5 ТБ в год. Если активно логи нужны 30 дней, на быстром хранилище держат около 3 ТБ, а остальное переносят в архив. Без разделения пришлось бы покупать 36,5 ТБ быстрых дисков в год.
Шаг 3. Учтите разницу между физической и полезной ёмкостью
Защита данных требует избыточности. Поэтому купленные терабайты и терабайты, доступные для данных, — разные величины.
Сверху закладывают свободное место. Многие системы хранения начинают терять производительность при заполнении выше 80–85%. Итог: чтобы хранить 100 ТБ данных в схеме с тройной репликацией, потребуется около 360 ТБ физической ёмкости, а с erasure coding 8+3 — около 165 ТБ.
Репликация данных проще и быстрее восстанавливается, но расходует больше дисков. Erasure coding экономит ёмкость, но нагружает процессоры и медленнее работает на запись мелких файлов. Для архивов и объектного хранения чаще выбирают erasure coding, для баз данных и виртуальных машин — зеркалирование или репликацию.
Репликация данных проще и быстрее восстанавливается, но расходует больше дисков. Erasure coding экономит ёмкость, но нагружает процессоры и медленнее работает на запись мелких файлов. Для архивов и объектного хранения чаще выбирают erasure coding, для баз данных и виртуальных машин — зеркалирование или репликацию.
Шаг 4. Разберитесь, чего требует нагрузка: IOPS, пропускная способность, задержка
Производительность хранилища описывается тремя разными параметрами, и их часто путают.
Разница хорошо видна на цифрах. База данных выполняет 1 000 операций в секунду блоками по 4 КБ — это всего 4 МБ/с, но жёсткий диск с этим не справится, ему нужны SSD. Видеоархив пишет 1 ГБ/с крупными блоками — IOPS тут почти не важны, зато нужны быстрая сеть и много дисков в массиве.
- IOPS — сколько операций ввода-вывода выполняется в секунду. Критично для баз данных, 1С, виртуальных машин, где много мелких случайных операций.
- Пропускная способность хранилища (throughput) — сколько мегабайт в секунду проходит через систему. Важна для видео, резервных копий, больших файлов.
- Задержка (latency) — сколько длится одна операция. От неё зависит отзывчивость приложений.
Разница хорошо видна на цифрах. База данных выполняет 1 000 операций в секунду блоками по 4 КБ — это всего 4 МБ/с, но жёсткий диск с этим не справится, ему нужны SSD. Видеоархив пишет 1 ГБ/с крупными блоками — IOPS тут почти не важны, зато нужны быстрая сеть и много дисков в массиве.
Шаг 5. Проверьте сеть
При больших объёмах сеть часто становится главным ограничением. Хранилище может выдавать несколько гигабайт в секунду, но пользователи получат не больше, чем пропускает канал.
Расчёт теоретический, реальная скорость ниже на 10–30%. Но порядок цифр показывает главное: передача больших объёмов данных по каналу 1 Гбит/с занимает часы и даже дни. Это касается переезда на новое хранилище, первой полной резервной копии и восстановления после сбоя. Если на восстановление 50 ТБ нужно почти пять суток, бизнес столько простоит.
Какую архитектуру выбрать: СХД, файловое, блочное или объектное хранилище
СХД для больших объёмов данных оправдана, когда общий быстрый ресурс нужен нескольким серверам — например, кластеру виртуализации. Объектное хранилище больших данных подходит для неструктурированной информации: файлов, которые записывают один раз и потом читают. S3 — это протокол доступа, который поддерживают многие системы, а не название конкретного продукта. Но приложение, которому нужен файловый доступ или низкая задержка, на объектном хранилище работать не будет.
Как масштабировать хранилище
Масштабирование хранилища бывает двух видов.
Вертикальное — добавляем диски и полки в существующую систему. Просто и быстро, но есть предел: производительность контроллера не растёт вместе с ёмкостью. Со временем система становится большой, но медленной в пересчёте на терабайт.
Вертикальное — добавляем диски и полки в существующую систему. Просто и быстро, но есть предел: производительность контроллера не растёт вместе с ёмкостью. Со временем система становится большой, но медленной в пересчёте на терабайт.
Горизонтальное — добавляем новые узлы, и каждый приносит и ёмкость, и производительность. Так устроены распределённые и объектные хранилища. Масштабируемое хранилище данных такого типа сложнее в настройке, но растёт без замены всей системы.
При выборе способа спросите себя, что будет через три года: хватит ли одного контроллера на весь объём и сколько будет стоить переезд, если не хватит.
При выборе способа спросите себя, что будет через три года: хватит ли одного контроллера на весь объём и сколько будет стоить переезд, если не хватит.
Дедупликация и сжатие: сколько реально можно сэкономить
Дедупликация данных убирает повторяющиеся блоки, сжатие уменьшает объём каждого блока. Эффект сильно зависит от типа данных.
Обещать универсальный коэффициент экономии без анализа реальных данных некорректно. Лучше проверить на выборке своих данных до покупки оборудования. И учесть, что дедупликация требует памяти и процессора и может замедлять запись.
- Резервные копии и образы виртуальных машин содержат много повторов — здесь экономия бывает значительной.
- Документы и базы данных сжимаются умеренно.
- Видео, фотографии, архивы ZIP и уже сжатые форматы почти не уменьшаются.
Обещать универсальный коэффициент экономии без анализа реальных данных некорректно. Лучше проверить на выборке своих данных до покупки оборудования. И учесть, что дедупликация требует памяти и процессора и может замедлять запись.
Защита данных и резервное копирование
Ни RAID, ни репликация, ни erasure coding не заменяют резервную копию. Они защищают от отказа оборудования, но не от удаления, ошибки программы или шифровальщика — такие изменения мгновенно расходятся по всем копиям.
Для больших объёмов у резервного копирования свои сложности:
Для больших объёмов у резервного копирования свои сложности:
- первая полная копия 50 ТБ по каналу 1 Гбит/с займёт почти пять суток, поэтому канал до хранилища копий должен быть быстрым;
- после первой копии переходят на инкрементные, когда передаются только изменения;
- хотя бы одна копия должна быть изолирована от основной сети и находиться на другой площадке;
- восстановление нужно проверять на практике: важно знать не только что копия есть, но и сколько часов займёт возврат данных.
Как организовать хранение больших объёмов данных: порядок действий
- Проведите инвентаризацию: какие данные есть, сколько их и как быстро растут.
- Разделите данные на горячие, тёплые и холодные.
- Для каждой группы определите тип доступа: файловый, блочный или объектный.
- Зафиксируйте требования к IOPS, пропускной способности и задержке.
- Выберите схему защиты и пересчитайте физическую ёмкость.
- Определите способ масштабирования на 3–5 лет.
- Проверьте сеть: между хранилищем и серверами, между офисом и ЦОДом.
- Отдельно спроектируйте резервное копирование и проверьте восстановление.
- Посчитайте полную стоимость владения: оборудование, размещение, электричество, обслуживание.
Типичные ошибки
- Проектировать по текущей ёмкости. Через год хранилище заполнено и начинает тормозить.
- Путать IOPS и пропускную способность. Покупают быстрые большие HDD под базу данных, которой нужны SSD.
- Забывать про служебную ёмкость. Купили 100 ТБ, а для данных доступно 60.
- Игнорировать сеть. Быстрое хранилище упирается в канал 1 Гбит/с.
- Хранить всё на одном уровне. Архив занимает дорогие SSD, а база ютится на медленных дисках.
- Считать репликацию резервной копией. Шифровальщик реплицируется так же исправно, как полезные данные.
- Использовать объектное хранилище не по назначению. Приложению нужен файловый доступ, а его пытаются перевести на S3.
Хранение больших объёмов данных в Иркутске: чем поможет Интерфоника
Интерфоника — технологический провайдер из Иркутска, у которого есть собственная оптическая сеть, узлы связи и два ЦОДа в городе. Для компаний с большими объёмами данных это решает главную проблему — скорость передачи.
- Канал до 100 Гбит/с без доплаты за подключение. Интерфоника бесплатно подключает клиентов к своему ЦОДу напрямую по оптике со скоростью до 100 Гбит/с, без ограничений по трафику. За счёт этого большие объёмы данных переносятся за часы, а не за недели.
- Проектирование хранения. Инженеры проектируют архитектуру хранения, настраивают регулярное резервное копирование, быстрый доступ и контроль прав.
- Гибридная схема. Критичные данные остаются у компании, а резервные копии размещаются на ресурсах Интерфоники. Данные предварительно шифруются, поэтому провайдер не может их прочитать.
- Изолированные копии. Резервные копии недоступны из основной сети, хранятся географически разнесённо и регулярно проверяются восстановлением.
- Собственные ЦОДы. Резервирование питания, охлаждения и каналов связи. Можно разместить собственную СХД или серверы — размещение сервера (colocation) стоит от 5 000 ₽ за юнит.
- Хранение по 152-ФЗ. Хранилище для рабочих данных, архивов, логов и бэкапов в соответствии с 152-ФЗ.
Как это работает при сбое, показывает случай одного из клиентов Интерфоники. Вирус-шифровальщик полностью остановил работу компании, но изолированное хранилище было развёрнуто заранее. Через 15 минут после звонка в Интерфонику компания продолжила работать.
Подробнее о решениях для хранения — на странице IT-услуги для крупного бизнеса.
Частые вопросы
Что считать большим объёмом данных?
Универсального порога нет. Объём становится «большим», когда привычная инфраструктура перестаёт справляться: резервная копия не укладывается в ночь, файлы открываются медленно, перенос данных занимает дни. Для одной компании это 10 ТБ, для другой — сотни терабайт.
Как организовать хранение больших объёмов данных без потери производительности?
Разделить данные на горячие и холодные и хранить их на разных носителях, выбрать тип хранилища под характер нагрузки, заложить запас ёмкости и свободного места, обеспечить быструю сеть и отдельно спроектировать резервное копирование.
Что лучше: СХД или объектное хранилище?
Это решения для разных задач. СХД даёт быстрый блочный доступ для баз данных и виртуализации. Объектное хранилище масштабируется практически без ограничений и подходит для архивов, резервных копий, медиа и данных для аналитики.
Сколько дисков нужно, чтобы хранить 100 ТБ данных?
Зависит от схемы защиты. В RAID 6 на 10 дисках для данных доступно около 80% ёмкости, при тройной репликации — треть. С учётом запаса свободного места физическая ёмкость составит примерно от 150 до 360 ТБ.
Нужно ли резервное копирование, если данные реплицируются?
Да. Репликация защищает от отказа оборудования, но удаление файла или заражение шифровальщиком мгновенно попадает во все реплики. Резервная копия, изолированная от основной сети, позволяет вернуться к состоянию до инцидента.
Сколько времени займёт перенос большого объёма данных?
По каналу 1 Гбит/с 10 ТБ передаются около суток, по каналу 100 Гбит/с — примерно за 13 минут без учёта накладных расходов. В Иркутске Интерфоника бесплатно подключает клиентов к своему ЦОДу по оптике со скоростью до 100 Гбит/с.
Универсального порога нет. Объём становится «большим», когда привычная инфраструктура перестаёт справляться: резервная копия не укладывается в ночь, файлы открываются медленно, перенос данных занимает дни. Для одной компании это 10 ТБ, для другой — сотни терабайт.
Как организовать хранение больших объёмов данных без потери производительности?
Разделить данные на горячие и холодные и хранить их на разных носителях, выбрать тип хранилища под характер нагрузки, заложить запас ёмкости и свободного места, обеспечить быструю сеть и отдельно спроектировать резервное копирование.
Что лучше: СХД или объектное хранилище?
Это решения для разных задач. СХД даёт быстрый блочный доступ для баз данных и виртуализации. Объектное хранилище масштабируется практически без ограничений и подходит для архивов, резервных копий, медиа и данных для аналитики.
Сколько дисков нужно, чтобы хранить 100 ТБ данных?
Зависит от схемы защиты. В RAID 6 на 10 дисках для данных доступно около 80% ёмкости, при тройной репликации — треть. С учётом запаса свободного места физическая ёмкость составит примерно от 150 до 360 ТБ.
Нужно ли резервное копирование, если данные реплицируются?
Да. Репликация защищает от отказа оборудования, но удаление файла или заражение шифровальщиком мгновенно попадает во все реплики. Резервная копия, изолированная от основной сети, позволяет вернуться к состоянию до инцидента.
Сколько времени займёт перенос большого объёма данных?
По каналу 1 Гбит/с 10 ТБ передаются около суток, по каналу 100 Гбит/с — примерно за 13 минут без учёта накладных расходов. В Иркутске Интерфоника бесплатно подключает клиентов к своему ЦОДу по оптике со скоростью до 100 Гбит/с.
15.10.2026