Некоторые художники не выносят вида своих творений когда они закончены. А я свой самый большой поклонник. O.W. Grant (Interstate 60)
Команда Ivideon больше года работала над сервисом удаленного хранения архивных видео записей в собственном облаке (как мне не нравится это слово). Почему так долго, технические подробности и как бесплатно получить к нему доступ для читателей Хабра — вы узнаете под катом.
Существует несколько известных платформ для создания облачного хранения данных. Например, тот же OpenStack, который, к слову, мы также поддержали. И тем не менее для себя реализовали полностью свое решение. Почему мы так поступили? Чтобы ответить на этот вопрос нужно понять специфику хранения удаленного архива видеонаблюдения. Дело в том, что почти все облачные платформы рассчитаны преимущественно на преобладание операций чтения над записью. Отчасти поэтому входящий трафик в облака бесплатный, а исходящий стоит денег. Для такой платформы в большинстве случаев не так уж и важно, в каком порядке на дисках хранятся записанные файлы. Хотя работа над оптимизацией безусловно ведется.
По-другому обстоят дела с хранением видео системы наблюдения. Прежде всего, здесь есть очевидное существенное преобладание операций записи над операциями чтения. Люди просматривают не более 1 — 2 % всех архивных записей. А иногда и того меньше.
Не смотря на то, что запись производится по детектору движения, при большом количестве клиентов поток данных идет постоянно. И все бы было хорошо, если бы не ограниченность объема жестких дисков. В какой-то момент самые старые записи пользователя необходимо удалить, чтобы освободить место для новых. И здесь уже начинаются проблемы с обычными облаками.
Представьте, средний пользователь по нашей статистике за сутки может сформировать около 1200 записей видео наблюдения разной длительности с одной камеры. Чтобы видео было доступно пользователю не после окончания всей записи, а, например, через минуту, требуется каждую запись разбивать на на небольшие порции, которые должны сохраняться в облаке. То есть файлов может быть не 1200, а существенно больше. Предположим, что их 2500.
А теперь представьте, что на одном физическом жестком диске, находятся файлы за неделю от 200 пользователей. И в какой-то момент, запускается процедура ротации архива — удаления самых старых файлов, записанных за три дня. Необходимо разом удалить порядка 1,5 млн. файлов! Безусловно — облако это отработает. Медленно, но отработает. Только жесткие диски долго такую нагрузку не выдержат, а как известно, в облачном хранении это один из самых дорогих элементов. И мы получим, что облачное хранение будет очень дорогой услугой для обычного пользователя. А мы всегда стремились дать людям не только самый качественный, но и доступный сервис из всего того, что есть на рынке.
Облако Ivideon обладает иерархической структурой и создано как независимый элемент всей платформы Ivideon. То есть может разрабатываться и тестироваться отдельно от всего сервиса в целом. Мы стремимся обеспечить такой подход во всей нашей разработке, чтобы над отдельными модулями могли работать относительно независимые группы разработчиков. В результате мы получаем возможность повышать скорость разработки элементов нашей платформы, привлекая новых разработчиков в проект.
В качестве frontend’ов мы используем группу серверов с большим объемом оперативной памяти. На текущий момент каждый из таких серверов содержит порядка 96 Гбайт памяти.
Задача данного сервера — аккумуляция готовых фрагментов от камер по несколько минут. Все эти фрагменты пишутся исключительно в оперативную память.
На каждую камеру выделяется около 80 — 100 Мбайт. На сервер поступает множество видео кадров от разных камер. Как только фрагмент завершается — он тут же ставится в очередь на отправку в backend хранения. Памяти специально выделяется больше, чем размер одного фрагмента, чтобы во время отправки завершенного фрагмента было место для записи нового.
Что же представляют из себя backend’ы? Это группа серверов с 36 дисками каждый, которая может находиться как в одном датацентре, так и в нескольких, в зависимости от требуемой степени надежности хранения. Назовем такие сервера нодами. Каждый фрагмент может быть продублирован на заданном количестве нод в зависимости от настройки тарифного плана пользователя. А для распределения нагрузки на ноды используются механизмы шардинга. Рассчитывается максимальная скорость физической записи в ноду и контролируется, чтобы количество передаваемых данных за единицу времени не превышало этого параметра.
С программной точки зрения мы поддерживаем ноды OpenStack, web-dav, nfs и т.д. Но для хранения архива в наших датацентрах мы используем собственную реализацию программного обеспечения ноды. В этом случае связь с ней осуществляется по внутреннему HTTP-base протоколу. Фактически производится почти мгновенная передача уже готового фрагмента и его запись в ноду. А также внесение данных о фрагменте во внутреннюю базу. Базой является mongoDB, установленая на отдельных серверах.
Но это еще не все. Для решения проблемы удаления большого объема старых записей и снижения фрагментации диска в результате этого удаления в нашей реализации ноды мы разработали собственную файловую систему. Конечно, это звучит довольно громко, но сложного в этом на самом деле ничего нет. Каждый фрагмент пишется на диск уже не как отдельный файл, а объединяется последовательно с предыдущими, образуя один большой файл с записями в течении часа. В следующих статьях мы постараемся об этом рассказать подробнее.
В момент, когда необходимо произвести ротацию архива и удалить данные за несколько дней, нода временно помечается как не готовая к записи и новые фрагменты распределяются между другими нодами. Делается это для того, чтобы во время удаления на ноду не производилась запись для предотвращения фрагментации.
Затем запускается сам процесс удаления. В котором нужно удалить не 7500 маленьких файлов от каждого пользователя, а всего лишь 72, так как каждый файл это записи за один час.
Здесь я не рассказал о многих тонкостях работы нашей платформы, связанных, например, с разными тарифными планами. Кто-то хранит неделю архива, а кто-то месяц. Также я не стал заострять внимания на конкретных деталях работы с широко известными элементами, используемыми в нашей платформе. Например, MongoDB. И это уже тема для следующей статьи.
Надеюсь, благодаря этому, изложение получилось понятным и в то же время полезным.
Хочу лишь добавить, что как и всегда, в своих датацентрах мы используем исключительно Linux и наше серверное ПО оптимизируем для него.
И напоследок. Мы очень постарались провести комплексное и нагрузочное тестирование нашей платформы удаленного хранения. И тем не менее запускаем её в режиме Beta и устанавливаем “сдерживающий” тариф, чтобы рост нагрузки был контролируемым с нашей стороны. Но если кто-то из читателй Хабра хочет помочь нам, приняв участие в тестировании, пишите в личку, указывайте e-mail вашего личного кабинета и мы положим на ваш счет требуемую сумму денег, чтобы использование облачного хранения Ivideon было для вас бесплатным.
Команда Ivideon больше года работала над сервисом удаленного хранения архивных видео записей в собственном облаке (как мне не нравится это слово). Почему так долго, технические подробности и как бесплатно получить к нему доступ для читателей Хабра — вы узнаете под катом.
Почему нельзя использовать существующее облачное хранение?
Существует несколько известных платформ для создания облачного хранения данных. Например, тот же OpenStack, который, к слову, мы также поддержали. И тем не менее для себя реализовали полностью свое решение. Почему мы так поступили? Чтобы ответить на этот вопрос нужно понять специфику хранения удаленного архива видеонаблюдения. Дело в том, что почти все облачные платформы рассчитаны преимущественно на преобладание операций чтения над записью. Отчасти поэтому входящий трафик в облака бесплатный, а исходящий стоит денег. Для такой платформы в большинстве случаев не так уж и важно, в каком порядке на дисках хранятся записанные файлы. Хотя работа над оптимизацией безусловно ведется.
По-другому обстоят дела с хранением видео системы наблюдения. Прежде всего, здесь есть очевидное существенное преобладание операций записи над операциями чтения. Люди просматривают не более 1 — 2 % всех архивных записей. А иногда и того меньше.
Не смотря на то, что запись производится по детектору движения, при большом количестве клиентов поток данных идет постоянно. И все бы было хорошо, если бы не ограниченность объема жестких дисков. В какой-то момент самые старые записи пользователя необходимо удалить, чтобы освободить место для новых. И здесь уже начинаются проблемы с обычными облаками.
Представьте, средний пользователь по нашей статистике за сутки может сформировать около 1200 записей видео наблюдения разной длительности с одной камеры. Чтобы видео было доступно пользователю не после окончания всей записи, а, например, через минуту, требуется каждую запись разбивать на на небольшие порции, которые должны сохраняться в облаке. То есть файлов может быть не 1200, а существенно больше. Предположим, что их 2500.
А теперь представьте, что на одном физическом жестком диске, находятся файлы за неделю от 200 пользователей. И в какой-то момент, запускается процедура ротации архива — удаления самых старых файлов, записанных за три дня. Необходимо разом удалить порядка 1,5 млн. файлов! Безусловно — облако это отработает. Медленно, но отработает. Только жесткие диски долго такую нагрузку не выдержат, а как известно, в облачном хранении это один из самых дорогих элементов. И мы получим, что облачное хранение будет очень дорогой услугой для обычного пользователя. А мы всегда стремились дать людям не только самый качественный, но и доступный сервис из всего того, что есть на рынке.
Как мы реализовали наше хранение
Облако Ivideon обладает иерархической структурой и создано как независимый элемент всей платформы Ivideon. То есть может разрабатываться и тестироваться отдельно от всего сервиса в целом. Мы стремимся обеспечить такой подход во всей нашей разработке, чтобы над отдельными модулями могли работать относительно независимые группы разработчиков. В результате мы получаем возможность повышать скорость разработки элементов нашей платформы, привлекая новых разработчиков в проект.
В качестве frontend’ов мы используем группу серверов с большим объемом оперативной памяти. На текущий момент каждый из таких серверов содержит порядка 96 Гбайт памяти.
Задача данного сервера — аккумуляция готовых фрагментов от камер по несколько минут. Все эти фрагменты пишутся исключительно в оперативную память.
На каждую камеру выделяется около 80 — 100 Мбайт. На сервер поступает множество видео кадров от разных камер. Как только фрагмент завершается — он тут же ставится в очередь на отправку в backend хранения. Памяти специально выделяется больше, чем размер одного фрагмента, чтобы во время отправки завершенного фрагмента было место для записи нового.
Что же представляют из себя backend’ы? Это группа серверов с 36 дисками каждый, которая может находиться как в одном датацентре, так и в нескольких, в зависимости от требуемой степени надежности хранения. Назовем такие сервера нодами. Каждый фрагмент может быть продублирован на заданном количестве нод в зависимости от настройки тарифного плана пользователя. А для распределения нагрузки на ноды используются механизмы шардинга. Рассчитывается максимальная скорость физической записи в ноду и контролируется, чтобы количество передаваемых данных за единицу времени не превышало этого параметра.
С программной точки зрения мы поддерживаем ноды OpenStack, web-dav, nfs и т.д. Но для хранения архива в наших датацентрах мы используем собственную реализацию программного обеспечения ноды. В этом случае связь с ней осуществляется по внутреннему HTTP-base протоколу. Фактически производится почти мгновенная передача уже готового фрагмента и его запись в ноду. А также внесение данных о фрагменте во внутреннюю базу. Базой является mongoDB, установленая на отдельных серверах.
Но это еще не все. Для решения проблемы удаления большого объема старых записей и снижения фрагментации диска в результате этого удаления в нашей реализации ноды мы разработали собственную файловую систему. Конечно, это звучит довольно громко, но сложного в этом на самом деле ничего нет. Каждый фрагмент пишется на диск уже не как отдельный файл, а объединяется последовательно с предыдущими, образуя один большой файл с записями в течении часа. В следующих статьях мы постараемся об этом рассказать подробнее.
В момент, когда необходимо произвести ротацию архива и удалить данные за несколько дней, нода временно помечается как не готовая к записи и новые фрагменты распределяются между другими нодами. Делается это для того, чтобы во время удаления на ноду не производилась запись для предотвращения фрагментации.
Затем запускается сам процесс удаления. В котором нужно удалить не 7500 маленьких файлов от каждого пользователя, а всего лишь 72, так как каждый файл это записи за один час.
Резюме
Здесь я не рассказал о многих тонкостях работы нашей платформы, связанных, например, с разными тарифными планами. Кто-то хранит неделю архива, а кто-то месяц. Также я не стал заострять внимания на конкретных деталях работы с широко известными элементами, используемыми в нашей платформе. Например, MongoDB. И это уже тема для следующей статьи.
Надеюсь, благодаря этому, изложение получилось понятным и в то же время полезным.
Хочу лишь добавить, что как и всегда, в своих датацентрах мы используем исключительно Linux и наше серверное ПО оптимизируем для него.
И напоследок. Мы очень постарались провести комплексное и нагрузочное тестирование нашей платформы удаленного хранения. И тем не менее запускаем её в режиме Beta и устанавливаем “сдерживающий” тариф, чтобы рост нагрузки был контролируемым с нашей стороны. Но если кто-то из читателй Хабра хочет помочь нам, приняв участие в тестировании, пишите в личку, указывайте e-mail вашего личного кабинета и мы положим на ваш счет требуемую сумму денег, чтобы использование облачного хранения Ivideon было для вас бесплатным.
