[IT-инфраструктура, SAN, Виртуализация, Хранение данных] СХД Qsan в системах видеонаблюдения
Автор
Сообщение
news_bot ®
Стаж: 6 лет 9 месяцев
Сообщений: 27286
Окружающий мир определенно не такой, каким он был десяток лет назад. В то время никто бы не поверил, что за нами будет пристально следить 24 часа в сутки огромное количество видеокамер. Если раньше видеонаблюдение было развернуто лишь в наиболее уязвимых, с точки зрения безопасности, местах, то сейчас редко можно встретить даже мелкий магазинчик без собственных видеокамер. В крупных мегаполисах применяется масштабное наблюдение за улицами, дворами домов и прочими общественными местами. Можно по-разному относиться к постоянному наблюдению за людьми и объектами (кто-то видит в этом безопасность, а кто-то – признаки тотального контроля), но решать технические вопросы в данной сфере все равно необходимо.
Типичная система видеонаблюдения представляет собой сегодня набор камер, программное обеспечение, осуществляющее запись, обработку и воспроизведение с них, а также пространство хранения для всего этого «богатства». Разнообразие камер сейчас способно удовлетворить любой вкус и кошелек. Софта для работы с ними несколько меньше видов, но тоже достаточное количество. В данной же статье мы хотим затронуть вопросы в отношении пространства хранения, в том числе и практические аспекты в его планировании.
От использования DVR (такие маленькие коробочки, совмещающие в себе софт видеонаблюдения и один или несколько HDD для хранения результатов) сейчас уже почти отказались из-за проблем с масштабированием по производительности, количеству камер и емкости. Поэтому в качестве хранилища выступает либо набор дисков, расположенных внутри сервера, либо внешняя СХД с файловым или блочным доступом.
Собственно, от хранилища, каким бы оно не было, требуются весьма простые на первый взгляд параметры:
- Объем
- Производительность
- Надежность
Объем определяется из количества камер и их типа (считай, разрешения и применяемым ими кодеком), а также глубиной хранения. Любые вменяемые производители камер, а уж тем более вендоры ПО по работе с ними, имеют в открытом доступе калькуляторы для расчета необходимой емкости в зависимости от ваших потребностей. Но в любом случае даже скромный десяток камер с временем хранения в две недели затребует нескольких ТБ дискового пространства. С ростом количества камер и глубины архива потребность в хранилище легко может идти на сотни ТБ и даже ПБ.
С производительностью несколько сложнее. Более 95% времени на хранилище осуществляется запись данных в последовательном режиме (т.е. в максимально комфортном для накопителей). Вместе с тем, периодически происходит поиск по индексной базе и воспроизведение материала. Конечно же на показатель производительности напрямую влияет количество и тип камер. Но современный софт давно научился кэшировать входящие потоки на стороне сервера прежде всего с целью индексации событий и объектов, попавших в объективы камер. Поэтому непосредственная запись на устройство хранения осуществляется крупными порциями по несколько ГБ. Отсюда и требования к хранилищу по части скорости записи относительно невелики: лишь бы успеть записать подготовленный материал за то время, пока набирается следующий. Однако итоговая производительность должна учитывать конкурентные запросы на поиск и воспроизведение, из-за чего массив должен содержать в себе достаточное количество HDD для этого.
О массиве было упомянуто неспроста. Ведь обеспечить первичную надежность (а вместе с тем и требуемую производительность) разумнее всего при помощи RAID. Дальнейшее увеличение надежности возможно уже только лишь за счет дублирования: контроллеров, путей, массива данных.
Внутренние диски сервера могут обеспечить все указанные выше требования лишь отчасти. Так емкость можно нарастить при помощи внешних полок расширения, если требуется обеспечить бОльшую глубину архива. Да и с производительностью дисковой подсистемы едва ли возникнут проблемы при той нагрузке, которую сможет обеспечить сам сервер (точнее ПО видеонаблюдения). А вот с надежностью могут возникнуть вопросы. Ведь будет единая точка отказа в виде самого сервера.
Нивелировать этот недостаток может внешняя система хранения. Если произойдет отказ сервера, потоки с камер можно перенаправить на другие серверы, которые, в свою очередь, могут без проблем получить доступ к пространству хранения временно выбывшего из строя «собрата». Также возможно применение двухконтроллерных СХД для исключения самой СХД как точки отказа. Консолидация же множества серверов позволит сэкономить на дисках, не теряя при этом в производительности и той же надежности.
Если сравнивать между собой файловые и блочные протоколы доступа к СХД в контексте систем видеонаблюдения, то SAN системы будут иметь ряд преимуществ из-за более простой и потому более дешевой реализации системы хранения. Ведь чисто блочным СХД не требуются сверхмощное «железо» и продвинутые возможности встроенной ОС. Функционал типа дедупликации или тирингабудет бессилен перед сжатым видео, которое перезаписывается по кругу. Все это в конечном итоге положительно скажется на стоимости решения, разумеется, в пользу SAN.
Практические советы по построению систем видеонаблюдения
Дальнейшие рассуждения справедливы в общем случае для СХД любого вендора. Но мы будем базироваться на продукции Qsan, рассматривая особенности реализации и применения их решений.
Если масштаб системы видеонаблюдения таков, что достаточно 1-2 серверов по обработке потоков, то абсолютно нерентабельно использовать в данной конфигурации внешние СХД (кроме случаев с требованиями к повышенной отказоустойчивости). Достаточно использовать внутренние RAID контроллеры и диски. При большем количестве серверов наличие СХД как раз, наоборот, позволит снизить стоимость решения за счет консолидации дисковых ресурсов.
При планировании построения дискового пространства в СХД стоит отказаться от желания сделать один большой массив на все случаи жизни из-за потенциальных проблем с производительностью и надежностью:
- Производительность в RAID массивах хоть и масштабируется с увеличением количества HDD в группе, но постоянная конкурентная запись видеопотоков от множества серверов не всегда позволит получать требуемые скоростные показатели для каждого из них. Разумным решением будет создание отдельных RAID массивов для групп из 2-4 серверов.
- С точки зрения надежности, при использовании HDD большой емкости необходимо использовать как минимум RAID6 с количеством дисков в группе не более 12-14. В случае использования большего числа дисков необходимо объединять такие группы в RAID60. Также следует учитывать, что, при постоянной записи на массив, ребилд для диска емкостью 10-14ТБ легко может занять 2 и более недели. И различные технологии ускорения вроде Fast Rebuild здесь, увы, не помогут. Если позволяют бюджеты, то для повышения надежности все же стоит рассматривать RAID10.
Интерфейс подключения СХД к серверам не играет большой роли с точки зрения производительности. Поэтому чаще всего используется максимально бюджетный вариант с iSCSI. Более того, в случае прямого подключения сервера к СХД вполне достаточно даже скорости 1GbE, благо дополнительные карты расширения с таким интерфейсом для СХД Qsan стоят дешевле портов 10GbE на коммутаторах. Но если подключение происходит все же с использованием коммутатора(ов), то 10GbE, конечно же, является предпочтительным.
В случае использования двухконтроллерных моделей СХД следует учитывать, что на стороне серверов должна быть поддержка MPIO. Акцент на этом моменте сделан не случайно: достаточно часто с целью удешевления на стороне видеосерверов используются клиентские версии ОС (Windows 7-10 и т.п.), которые не могут работать с MPIO.
Также не следует забывать, что блочный доступ подразумевает монопольное использование дискового ресурса конкретным сервером (кроме случаев кластеризации видеосерверов в виртуальных средах). Поэтому необходимо обязательно со стороны СХД настроить контроль доступа к публикуемым томам при помощи LUN Masking. В случае плановой или аварийной замены видеосервера будет достаточно изменить параметры LUN Masking для продолжения работы.
Если рассматривать выбор конкретной СХД для целей видеонаблюдения, то на эту роль вполне подойдут младшие модели (например, серию XCubeSAN XS12xx), поскольку предполагается работа с обычными HDD, latency которых просто несоизмеримы с производительностью контроллеров. При большом количестве дисков особенно выигрышно будут смотреться конфигурации с использованием полок высокой плотности сторонних производителей, благо Qsan официально поддерживает подобное. Переход на старшие линейки СХД оправдан лишь в тех случаях, когда суммарная потоковая запись на СХД предполагается выше, чем 3 ГБ/с, что характерно для очень больших инсталляций с несколькими десятками видеосерверов.
Номенклатура и возможности СХД Qsan позволяют использовать их в решениях по видеонаблюдению любого масштаба и любой сложности, а возможность установки в них совместимых накопителей делает итоговую стоимость оборудования максимально финансово привлекательной.
===========
Источник:
habr.com
===========
Похожие новости:
- [Виртуализация, Настройка Linux] Сравниваем лучшее программное обеспечение для виртуализации в 2020 году: Hyper-V, KVM, vSphere и XenServer (перевод)
- [DevOps, Облачные сервисы, Хранение данных, Хранилища данных] Пример event-driven приложения на основе вебхуков в объектном S3-хранилище Mail.ru Cloud Solutions
- [IT-инфраструктура, Распределённые системы, Сетевое оборудование, Системное администрирование] Добавление ноды в Skydive топологию вручную через Skydive client
- [IT-инфраструктура, Open source, Разработка под Linux, Учебный процесс в IT] Мастер-курсы по Istio и Kafka, книга про Python и немного про навыки веб-разработки
- [Компьютерное железо, Накопители, Хранение данных, Хранилища данных] Western Digital начинает поставки корпоративных HDD объемом до 20 ТБ
- [Big Data, PostgreSQL, Администрирование баз данных, Хранение данных] Видео @Databases Meetup: Percona, Postgres Pro, Tarantool и MCS
- [IPv6, IT-инфраструктура, Разработка систем связи, Сетевое оборудование, Стандарты связи] Азиатский интернет-регистратор APNIC обнаружил около 50 млн неиспользуемых IPv4-адресов
- [Распределённые системы, Хранение данных, Хранилища данных] Коды избыточности: простыми словами о том, как надёжно и дёшево хранить данные
- [IT-инфраструктура, Сетевые технологии, Сетевое оборудование] Huawei DCN: пять сценариев построения сети ЦОД
- [IT-компании, Физика, Хранение данных, Хранилища данных] В Samsung изолировали «белый графен». Решение могут использовать при создании новейшей памяти
Теги для поиска: #_itinfrastruktura (IT-инфраструктура), #_san, #_virtualizatsija (Виртуализация), #_hranenie_dannyh (Хранение данных), #_qsan, #_shd (СХД), #_sistemy_hranenija_dannyh (системы хранения данных), #_san, #_itinfrastruktura (IT-инфраструктура), #_hranilischa_dannyh (хранилища данных), #_blog_kompanii_skilline (
Блог компании Skilline
), #_itinfrastruktura (
IT-инфраструктура
), #_san, #_virtualizatsija (
Виртуализация
), #_hranenie_dannyh (
Хранение данных
)
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 22-Ноя 19:06
Часовой пояс: UTC + 5
| Автор | Сообщение |
|---|---|
|
news_bot ®
Стаж: 6 лет 9 месяцев |
|
|
Окружающий мир определенно не такой, каким он был десяток лет назад. В то время никто бы не поверил, что за нами будет пристально следить 24 часа в сутки огромное количество видеокамер. Если раньше видеонаблюдение было развернуто лишь в наиболее уязвимых, с точки зрения безопасности, местах, то сейчас редко можно встретить даже мелкий магазинчик без собственных видеокамер. В крупных мегаполисах применяется масштабное наблюдение за улицами, дворами домов и прочими общественными местами. Можно по-разному относиться к постоянному наблюдению за людьми и объектами (кто-то видит в этом безопасность, а кто-то – признаки тотального контроля), но решать технические вопросы в данной сфере все равно необходимо.  Типичная система видеонаблюдения представляет собой сегодня набор камер, программное обеспечение, осуществляющее запись, обработку и воспроизведение с них, а также пространство хранения для всего этого «богатства». Разнообразие камер сейчас способно удовлетворить любой вкус и кошелек. Софта для работы с ними несколько меньше видов, но тоже достаточное количество. В данной же статье мы хотим затронуть вопросы в отношении пространства хранения, в том числе и практические аспекты в его планировании. От использования DVR (такие маленькие коробочки, совмещающие в себе софт видеонаблюдения и один или несколько HDD для хранения результатов) сейчас уже почти отказались из-за проблем с масштабированием по производительности, количеству камер и емкости. Поэтому в качестве хранилища выступает либо набор дисков, расположенных внутри сервера, либо внешняя СХД с файловым или блочным доступом. Собственно, от хранилища, каким бы оно не было, требуются весьма простые на первый взгляд параметры:
Объем определяется из количества камер и их типа (считай, разрешения и применяемым ими кодеком), а также глубиной хранения. Любые вменяемые производители камер, а уж тем более вендоры ПО по работе с ними, имеют в открытом доступе калькуляторы для расчета необходимой емкости в зависимости от ваших потребностей. Но в любом случае даже скромный десяток камер с временем хранения в две недели затребует нескольких ТБ дискового пространства. С ростом количества камер и глубины архива потребность в хранилище легко может идти на сотни ТБ и даже ПБ. С производительностью несколько сложнее. Более 95% времени на хранилище осуществляется запись данных в последовательном режиме (т.е. в максимально комфортном для накопителей). Вместе с тем, периодически происходит поиск по индексной базе и воспроизведение материала. Конечно же на показатель производительности напрямую влияет количество и тип камер. Но современный софт давно научился кэшировать входящие потоки на стороне сервера прежде всего с целью индексации событий и объектов, попавших в объективы камер. Поэтому непосредственная запись на устройство хранения осуществляется крупными порциями по несколько ГБ. Отсюда и требования к хранилищу по части скорости записи относительно невелики: лишь бы успеть записать подготовленный материал за то время, пока набирается следующий. Однако итоговая производительность должна учитывать конкурентные запросы на поиск и воспроизведение, из-за чего массив должен содержать в себе достаточное количество HDD для этого. О массиве было упомянуто неспроста. Ведь обеспечить первичную надежность (а вместе с тем и требуемую производительность) разумнее всего при помощи RAID. Дальнейшее увеличение надежности возможно уже только лишь за счет дублирования: контроллеров, путей, массива данных. Внутренние диски сервера могут обеспечить все указанные выше требования лишь отчасти. Так емкость можно нарастить при помощи внешних полок расширения, если требуется обеспечить бОльшую глубину архива. Да и с производительностью дисковой подсистемы едва ли возникнут проблемы при той нагрузке, которую сможет обеспечить сам сервер (точнее ПО видеонаблюдения). А вот с надежностью могут возникнуть вопросы. Ведь будет единая точка отказа в виде самого сервера. Нивелировать этот недостаток может внешняя система хранения. Если произойдет отказ сервера, потоки с камер можно перенаправить на другие серверы, которые, в свою очередь, могут без проблем получить доступ к пространству хранения временно выбывшего из строя «собрата». Также возможно применение двухконтроллерных СХД для исключения самой СХД как точки отказа. Консолидация же множества серверов позволит сэкономить на дисках, не теряя при этом в производительности и той же надежности. Если сравнивать между собой файловые и блочные протоколы доступа к СХД в контексте систем видеонаблюдения, то SAN системы будут иметь ряд преимуществ из-за более простой и потому более дешевой реализации системы хранения. Ведь чисто блочным СХД не требуются сверхмощное «железо» и продвинутые возможности встроенной ОС. Функционал типа дедупликации или тирингабудет бессилен перед сжатым видео, которое перезаписывается по кругу. Все это в конечном итоге положительно скажется на стоимости решения, разумеется, в пользу SAN. Практические советы по построению систем видеонаблюдения Дальнейшие рассуждения справедливы в общем случае для СХД любого вендора. Но мы будем базироваться на продукции Qsan, рассматривая особенности реализации и применения их решений. Если масштаб системы видеонаблюдения таков, что достаточно 1-2 серверов по обработке потоков, то абсолютно нерентабельно использовать в данной конфигурации внешние СХД (кроме случаев с требованиями к повышенной отказоустойчивости). Достаточно использовать внутренние RAID контроллеры и диски. При большем количестве серверов наличие СХД как раз, наоборот, позволит снизить стоимость решения за счет консолидации дисковых ресурсов. При планировании построения дискового пространства в СХД стоит отказаться от желания сделать один большой массив на все случаи жизни из-за потенциальных проблем с производительностью и надежностью:
Интерфейс подключения СХД к серверам не играет большой роли с точки зрения производительности. Поэтому чаще всего используется максимально бюджетный вариант с iSCSI. Более того, в случае прямого подключения сервера к СХД вполне достаточно даже скорости 1GbE, благо дополнительные карты расширения с таким интерфейсом для СХД Qsan стоят дешевле портов 10GbE на коммутаторах. Но если подключение происходит все же с использованием коммутатора(ов), то 10GbE, конечно же, является предпочтительным. В случае использования двухконтроллерных моделей СХД следует учитывать, что на стороне серверов должна быть поддержка MPIO. Акцент на этом моменте сделан не случайно: достаточно часто с целью удешевления на стороне видеосерверов используются клиентские версии ОС (Windows 7-10 и т.п.), которые не могут работать с MPIO. Также не следует забывать, что блочный доступ подразумевает монопольное использование дискового ресурса конкретным сервером (кроме случаев кластеризации видеосерверов в виртуальных средах). Поэтому необходимо обязательно со стороны СХД настроить контроль доступа к публикуемым томам при помощи LUN Masking. В случае плановой или аварийной замены видеосервера будет достаточно изменить параметры LUN Masking для продолжения работы. Если рассматривать выбор конкретной СХД для целей видеонаблюдения, то на эту роль вполне подойдут младшие модели (например, серию XCubeSAN XS12xx), поскольку предполагается работа с обычными HDD, latency которых просто несоизмеримы с производительностью контроллеров. При большом количестве дисков особенно выигрышно будут смотреться конфигурации с использованием полок высокой плотности сторонних производителей, благо Qsan официально поддерживает подобное. Переход на старшие линейки СХД оправдан лишь в тех случаях, когда суммарная потоковая запись на СХД предполагается выше, чем 3 ГБ/с, что характерно для очень больших инсталляций с несколькими десятками видеосерверов. Номенклатура и возможности СХД Qsan позволяют использовать их в решениях по видеонаблюдению любого масштаба и любой сложности, а возможность установки в них совместимых накопителей делает итоговую стоимость оборудования максимально финансово привлекательной.
=========== Источник: habr.com =========== Похожие новости:
Блог компании Skilline ), #_itinfrastruktura ( IT-инфраструктура ), #_san, #_virtualizatsija ( Виртуализация ), #_hranenie_dannyh ( Хранение данных ) |
|
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 22-Ноя 19:06
Часовой пояс: UTC + 5