Как мы создали свою систему хранения видео

Для организации сервиса видеонаблюдения необходимо решить множество вопросов, и один из самых ключевых - где и как хранить видео с камер. Вариантов много, но большинство из них ставят перед неприятным выбором телеком-оператора, предоставляющего услугу видеонаблюдения. При использовании простых видеорегистраторов видео хранится только на одном диске, и при повреждении диска оно безвозвратно теряется. Можно сделать хранение более долговечным, организовать запись архива, но это дороже, и при использовании RAID, решает далеко не все проблемы резервирования.

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

Самый первый вопрос, который нужно решить перед выбором места и способа хранения видео - сколько нам требуется места для этого. Поток размером от 1 до 8 мегабит за сутки занимает от 10 до 80 Гб. памяти, а в случае наших клиентов, телеком-операторов, предлагающих услуги видеонаблюдения, речь идёт не об одном канале, а о сотнях или даже сотнях тысяч. Как же организовать хранение такого огромного объёма данных, чтобы избежать их потери и неоправданно больших расходов?

Как уменьшить объём видео?

Первый закономерный вопрос: можно ли каким-то образом уменьшить объём видеопотока, чтобы и места для хранения требовалось меньше? Варианты есть - некоторые предлагали мы сами, некоторые предлагали нам.

Вариант 1: хранение видео в jpeg

Раньше нормальной ситуацией было, когда видео хранилось на носителе в формате jpeg, в виде серии фреймов, этот формат называется mjpeg (motion jpeg). Видео, составленное из независимых jpeg-файлов примерно в 10 раз больше, чем аналогичное видео, сжатое кодеком h264. Таким типом хранения сейчас пользуются только профессиональные системы хранения оригинального цифрового контента (mxpeg и тому подобные). Их полностью устраивает занимаемый фреймами объём, так как на первом месте для них наличие максимального исходного качества видео. Но мы занимаемся массовой доставкой видео, поэтому такой тип хранения не совместим с нашими задачами и требованиями. Он остался в прошлом с теми камерами, которым не хватало процессорной мощности на сжатие H264. mjpeg использовался только для очень маленьких разрешений ( 640x480 и меньше) и маленьких fps (до 1 или даже 0,5 fps). Сегодня mjpeg продолжает использоваться в тех условиях, когда канал связи настолько узкий, что хватает 1 кадра в несколько секунд. Например, это может быть наблюдение за дачей, нефтяной вышкой или прямая трансляция с корабля.

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

Вариант 2: транскодирование

Мы можем использовать другой способ - транскодирование. Основная идея этого метода заключается в том, что на камере слабый процессор, а на сервере сильный. Значит можно потратить больше процессорных тактов на сжатие и получить более сжатое видео. На практике при хорошем изображении (если нет снега, облаков) можно получить вплоть до 5-кратного сжатия видео на CPU по сравнению с камерой.

Увы, этот метод подходит, когда можно выделить по 1 компьютеру на 10-40 камер, соотвественно, это очень дорого. Сегодня такие расходы готовы нести только на видеоаналитику, но никак не на простое хранение видео.

Вариант 3: запись по движению

Если мы не можем уменьшить то видео, которое поступает с камер, то можно хотя бы записывать его на диск не в полном объёме.

Можно настроить запись видео по движению или другим триггерам. Камеры в этом случае не ведут запись, если на видео ничего не происходит, и таким образом экономится масса места. Но сэкономив место таким образом, мы можем потерять ряд необходимых кадров - например, с лицом грабителя, если произошёл взлом на точке, где была установлена камера. В этом случае в видеонаблюдении пропадает весь смысл с точки зрения безопасности. Есть механизмы предзаписи, например, когда пишется минута до срабатывания датчика. Они помогают не только сберечь место на диске, но и сохранить то, что может быть нужно.

Мы предлагаем клиентам другую схему: оставление по движению. На диск пишется всё, а потом через несколько дней остается только то, где было движение. Таким образом снижается опасность от несрабатывания датчика тревоги (движение, открытие двери, звук) и можно хранить видео гораздо дольше, а это может быть нужно для анализа того, когда грабитель приходил в здание до момента преступления.

Видеорегистраторы

Один из исторически первых способов хранения видео - это видеорегистраторы, и телеком-операторы часто начинают с ним. На данный момент хранение видео шагнуло насколько далеко вперёд, что видеорегистраторы выбирать невыгодно и не всегда удобно. Установка и обслуживание видеорегистратора составляют приличную статью расходов. Отдельный пункт - это защита видеорегистратора. В случае воровства он исчезает вместе со всеми хранящимися на нём записями, если не организовано их хранение на отдельном сервере в облаке. И мы говорим сейчас только об одном видеорегистраторе, где запись одного диска рассчитана на от 12 до 32 камер. Чем больше камер обслуживается телеком-оператором, тем больше видеорегистраторов будет необходимо устанавливать, и тем больше будет расходов на их обслуживание.

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

Сервера и RAID

Куда надёжнее в таком случае записывать видео на жёсткий диск сервера, но здесь возникает вопрос: будем ли мы раздавать записанное видео? Чтение со шпинделя HDD невозможно - это быстро выведет диск из строя, а значит, нам нужен кэш, в котором будет хранится видео. Записать кэш возможно, если речь идёт о небольшом архиве на ограниченное число каналов. В таком случае можно попробовать дублировать данные.

Какие диски можно для этого использовать? Казалось бы, чем больше диск, тем лучше, но те же 12-терабайтные диски не очень хорошо подходят для небольшого видео: диск большой, и чтобы полностью его использовать с небольшой глубиной хранения, на него надо одновременно отправить очень много потоков записи, с которыми он не справится. Они используют магнитную черепичную запись, и программное обеспечение должно очень специфически с ними работать: стараться не перезаписывать, а дописывать, и затем стирать весь жесткий диск. Места на жёстком диске может хватить на 1000 камер, но при стандартной скорости записи в 150-200 мегабит в секунду мы можем одновременно охватывать только 100 камер. Соответственно, чем больше жёсткий диск, тем меньше он будет использоваться и тем больше за него будет переплата.

Для дублирования данных многие наши клиенты хотят использовать RAID на своих серверах. RAID дублирует данные между жёсткими дисками таким образом, чтобы система могла безболезненно пережить выход из строя одного из них. Звучит хорошо, но мы очень не рекомендуем его использовать. По нашему опыту, многие пользователи никогда не проводили учений по его восстановлению под нагрузкой. Эти учения заключаются в том, что нужно взять и на ходу выключить диск из сервера. И тут мы сталкиваемся со спецификой видео: все нагрузки очень ровные, что позволяет очень легко подобраться к пределу возможностей системы. Когда RAID загружен на 90%, происходит поломка диска, и тогда нагрузка поднимается выше 100%. При попытках перезалить видео всё становится ещё хуже. Если мы по какой-то причине не успеваем записать кадр, скапливается очередь из них, скорость записи снижается, а малейшее промедление приводит к потере целых фрагментов видео.

Бывают ситуации ещё страшнее: из-за роста нагрузки может отказать не только первый, но и второй жёсткий диск, и это довольно частая проблема для RAID (особенно если приобретались жёсткие диски из одной партии).

Хранилища корпоративного класса

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

У полноценного хранилища корпоративного класса есть несомненные плюсы: масштабируемость (правда, обычно, опускается, что именно под этим подразумевается, просто так любят писать), определённая отказоустойчивость (за очень большие деньги). Однако, мы столкнулись с очевидными минусами: дисковая полка - это, фактически, отдельный компьютер, притом достаточно недешевый.

SAN (Storage Area Network) – это сеть хранения данных, представляющая собой решение для подключения устройств хранения данных к серверам таким образом, чтобы операционная система определила все подключённые внешние ресурсы как локальные.

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

Amazon S3

Наши клиенты не хотят усложнять себе задачу, ввязываясь в расчет и прогнозирование закупки дорогостоящего железа, и их можно понять: неприятно недокупить оборудования на 10% со временем поставки в 4 месяца. Как вариант, на горизонте возникает объектное хранилище Amazon S3, который обычно используется только для OTT-сервисов. Из плюсов: простой и понятный интерфейс, крайне редкие потери данных, отличная отказоустойчивость. Но главный минус перевешивает все плюсы сразу: это невероятно дорого.

Казалось бы, Amazon S3 берёт смехотворно маленькие деньги за одну операцию записи. Но если мы записываем видео в формате индексированного архива, у нас получается больше одной операции записи на каждый сегмент. Скажем, у нас есть 20 сегментов видео (по 3 секунды каждый) для записи в минуту. Они формируют 1200 сегментов в час и, соответственно, 28 800 сегментов в сутки при постоянной записи видео. Если мы записываем в хранилище 1000 камер 3-х секундными сегментами, мы получаем порядка 28 миллионов сегментов в сутки или 850 млн в месяц.

Крохотная стоимость в $0.005 за 1000 запросов (на момент написания статьи) превращается в $4300 в месяц только за одну лишь запись, то есть порядка $4,5 долларов на одну камеру. Такой ценник делает услугу абонентского видеонаблюдения нерентабельной, поскольку есть ещё и стоимость хранения, стоимость каналов и серверов.

Ceph

Аналогом Amazon S3 может послужить объектное хранилище Ceph. Из плюсов: возможность резервного хранения и посегментной записи, и скрытая стоимость владения. Кто-то может сказать, что Ceph бесплатен, однако нельзя сказать, что как грибы после дождя, плодятся конкуренты Amazon. Значит, предлагаемый ими ценник не запредельно огромный, и услуга облачного файлового хранилища сама по себе не такая дешевая. Для эксплуатации Ceph нужен хороший администратор с экспертизой по его ремонту. Мы поощряем у клиентов желание работать с Ceph, только если они готовы проводить тесты системы, которые заключаются в резком отсоединении жёсткого диска от сервера или отключении целого сервера. Если тесты не проводятся, то экспертизы о том, что делать в ситуации, когда жёсткий диск отказывает, у команды попросту не будет.

Наш выход

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

В итоге мы пришли к разработке нашей собственной системы под рабочим названием Flussonic RAID. Администратор сервера монтирует все жёсткие диски отдельно, зависимостей между ними нет, а метаданные размещаются на отдельном SSD. Видео равномерно распределяется по этим дисками отдельными, никак не связанными, фрагментами, и, соответственно, в случае сбоя максимум, что мы теряем - это данные на одном конкретном диске и отдельные фрагменты одного видео. Для нас самое главное, что даже если 9 из 10 дисков выйдет из строя, 10 всё равно будет работать, и данные с него никуда не пропадут. Система масштабируется: можно купить сервер с 20 слотами для жёстких дисков и гибко расширяться, докупая их по мере необходимости.

По сути, мы перенесли на уровень приложения задачу управления пачкой жестких дисков. Мы сделали более специализированное, простое и эффективное для нашей конкретной задачи решение, чем обобщенный RAID5, который хорош для всех, но не идеален ни для кого. Основная причина по которой это стало возможным — видео не перезаписывается! После того, как оно попало на диск, его можно только стереть. Соответственно, это очень удобный в работе паттерн append only данных.

Мы решили отказаться от дублирования данных внутри одного сервера:

1. во-первых это привносит все те проблемы, которые есть у обычного RAID5 (деградированное состояние при восстановлении диска),
2. во-вторых это никак не защищает от выхода из строя сервера. Для резервирования данных на сегодняшний день дешевле и проще дублировать данные между серверами.

Даже в таком простом механизме оказалась масса сложностей, и одна из самых тонких деталей — выбор диска для записи следующей порции данных. С одной стороны, диски необходимо грузить равномерно, с другой стороны, хочется, чтобы в системе из 70 дисков основная масса простаивала, а писались только активные единицы (из целей энергосбережения).

Мы планируем совершенствовать систему и дальше: из ближайших планов - добавить хороший, интуитивный интерфейс для отслеживания статуса миграции, плавное отключение диска, на котором произошёл сбой, событийное API, SMART monitoring, а также возможность следить за всеми жёсткими дисками одного кластера одновременно.

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