Когда спутниковому оборудованию нужен сервер: путь данных от ресивера до архива
Один спутниковый ресивер с локальным накопителем справляется с записью отдельного видеопотока, но эта схема быстро упирается в ограничения при росте числа каналов и срока хранения. Когда записи нужно собирать централизованно, передавать по IP-сети, открывать для других систем или дополнительно обрабатывать, в инфраструктуре появляется сервер. Разберем, где проходит эта граница, как данные движутся от ресивера до архива и что в действительности определяет конфигурацию сервера: процессор, сеть, дисковая подсистема или требуемая емкость.
Когда одного ресивера уже недостаточно
Один спутниковый ресивер с локальным накопителем подходит для простой схемы: принять сигнал, декодировать выбранный канал и сохранить запись рядом с устройством. Пока поток один, срок хранения невелик, а доступ к файлам нужен только локально, выделять отдельный сервер обычно нет смысла. Проблемы начинаются, когда каждый ресивер ведёт собственный архив: записи оказываются разбросаны по разным накопителям, свободное место приходится контролировать вручную, а поиск нужного фрагмента занимает всё больше времени. Именно в таких случаях стоит рассмотреть сервер бу корпоративного класса — когда локальной записи на отдельных ресиверах уже просто недостаточно.
Понять, что система переросла локальную запись, можно по нескольким признакам:
- Одновременно принимаются и записываются несколько видеопотоков.
- Архив должен храниться централизованно в течение недель или месяцев.
- Доступ к записям получают рабочие станции, системы мониторинга или другие приложения.
- Потоки необходимо обрабатывать, копировать либо передавать дальше по инфраструктуре.
В такой конфигурации сервер становится общей точкой приема и хранения данных. Если потоки нужно собирать в одном месте, долго хранить и предоставлять к ним сетевой доступ, практичной основой может стать и бу сервер enterprise версии, но только при соответствии его дисковой подсистемы, сетевых интерфейсов и производительности фактической нагрузке.
Подбор конфигурации начинается не с названия модели и не с условной «мощности» процессора. Сначала определяют количество потоков, их средний битрейт, продолжительность хранения и характер дополнительной обработки. Эти параметры показывают, какая пропускная способность сети, скорость записи и полезная ёмкость массива действительно потребуются.
Как данные проходят от ресивера в IP-сеть
До ресивера сигнал существует в спутниковой части системы: антенна принимает его, конвертер переносит нужный частотный диапазон, а ресивер выполняет настройку на транспондер и демодуляцию. После этого начинается уже знакомая ИТ-инфраструктура. Сформированный цифровой поток передается через Ethernet на сервер записи или в систему хранения.
Упрощенно путь данных выглядит так: спутниковый сигнал → приём и демодуляция → ресивер → IP-сеть → сервер → дисковый массив → архив. На границе спутниковой и сетевой частей выполняются три основные операции:
- Ресивер принимает и демодулирует выбранный сигнал.
- Полученный транспортный поток передается в IP-сеть, например в формате MPEG-TS по UDP или RTP.
- Сервер принимает поток, записывает его на дисковый массив и добавляет в централизованный архив.
Сам сервер не работает непосредственно с радиосигналом. Для него входящие данные являются обычным сетевым трафиком, который необходимо принять без потерь, правильно сохранить и связать с нужным каналом и временем трансляции.
На этом участке важна не номинальная скорость одного порта, а суммарная нагрузка. Если десять потоков имеют средний битрейт 15 Мбит/с, только полезные видеоданные создадут трафик около 150 Мбит/с. К нему добавляются накладные расходы протоколов, служебный обмен и обращения к архиву. Поэтому пропускную способность рассчитывают для всей цепочки: портов ресиверов, коммутаторов, интерфейсов сервера и соединения с системой хранения.
Какие задачи выполняет сервер
Серверный слой не появляется в системе автоматически вместе со спутниковым оборудованием. Его добавляют под конкретные операции, которые неудобно или невозможно распределять между отдельными ресиверами. В простом сценарии сервер принимает уже сформированные видеопотоки и сохраняет их без изменения, поэтому основная нагрузка приходится на сеть и дисковую подсистему.
Набор функций зависит от назначения комплекса, но чаще всего сервер решает несколько связанных задач:
- Централизованно записывает потоки от нескольких спутниковых ресиверов;
- Формирует единый видеоархив с привязкой записей к каналам, датам и времени;
- Предоставляет доступ к материалам рабочим станциям, системам мониторинга и другим приложениям;
- Передает записи на отдельное хранилище или в резервный контур;
- Выполняет дополнительную обработку, если она предусмотрена проектом.
К дополнительной обработке относится, например, транскодирование — преобразование видео в другой кодек, разрешение или битрейт. Оно может потребоваться для трансляции на устройства с разными возможностями или для сокращения объема передаваемых данных. Такая операция заметно нагружает процессор, а в некоторых конфигурациях выполняется с аппаратным ускорением на GPU.
Если сервер лишь принимает и сохраняет исходный поток, устанавливать мощную вычислительную платформу «с запасом» необязательно. Спутниковое оборудование само по себе не требует высокой производительности сервера. Ресурсы определяются количеством данных, глубиной архива, числом одновременных обращений и перечнем операций, выполняемых над видео.
Что ограничивает производительность: CPU, сеть или диски
Узкое место зависит от того, что сервер делает с видеопотоком. При простой записи уже закодированных данных процессор обычно не является главным ограничением. Гораздо важнее, успевает ли сеть принимать весь трафик, а дисковый массив — непрерывно его сохранять.
При расчёте конфигурации последовательно проверяют три компонента:
- Сеть. Пропускная способность должна покрывать суммарный битрейт всех входящих потоков, обращения к архиву и служебный трафик.
- Диски. Массив оценивают по скорости длительной последовательной записи, полезной ёмкости и поведению при отказе или восстановлении накопителя.
- CPU и GPU. Их роль возрастает при транскодировании, видеоаналитике, распознавании объектов и другой обработке кадров.
Например, увеличение числа записываемых каналов прежде всего повышает сетевой трафик, скорость записи и требуемый объем хранения. Но если те же потоки одновременно преобразуются в несколько форматов, нагрузка на вычислительные ресурсы может стать определяющей. Поэтому выбирать конфигурацию нужно по профилю работы, а не по количеству каналов без учета их битрейта и выполняемых операций.
Как рассчитать объем видеоархива
Базовый расчет строится по формуле: объем архива ≈ средний битрейт × количество потоков × время хранения. При этом битрейт указывается в битах в секунду, а емкость накопителей — в байтах, поэтому значение нужно разделить на восемь.
Рассмотрим условный пример: сервер записывает восемь потоков со средним битрейтом 12 Мбит/с и хранит их 30 суток. Расчет выглядит так:
- Один поток создает 12 ÷ 8 = 1,5 МБ/с данных;
- Восемь потоков формируют 12 МБ/с;
- За 30 суток получится около 31,1 ТБ исходных данных.
Это сырой объем без запаса. Если используется переменный битрейт VBR, расчет выполняют по среднему фактическому значению за репрезентативный период, а кратковременные пики учитывают при проверке сети и скорости записи.
К полученному объему добавляют пространство для служебных данных, индексов, файловой системы, роста архива и нормальной работы массива без заполнения до предела. Также нельзя считать полезную емкость простым сложением объемов всех HDD: часть пространства займет избыточность RAID, а итог дополнительно зависит от выбранного уровня массива и наличия резервных дисков.
Почему RAID не заменяет резервное копирование
RAID повышает отказоустойчивость дисковой подсистемы: при выходе одного или нескольких накопителей массив может продолжить работу в пределах возможностей выбранного уровня. Это особенно важно для круглосуточной записи, где остановка сервера приводит к появлению пробелов в архиве.
Однако RAID не защищает данные от других сценариев. Отдельная резервная копия нужна на случай:
- Ошибочного удаления записей или повреждения файлов.
- Сбоя программного обеспечения, контроллера либо файловой системы.
- Вредоносного воздействия и серьезной аппаратной аварии.
Резервные данные должны храниться отдельно от основного массива, а возможность восстановления необходимо периодически проверять. Для критичного видеоархива надежная схема включает и отказоустойчивый RAID, и независимую копию наиболее важных записей. Первый поддерживает доступность системы при отказе диска, вторая позволяет вернуть данные после их утраты или повреждения.
