Comments 36
А почему вы не делали нагрузочное тестирование перед продакшеном в конфигурации продакшена? Те же камеры можно было спокойно заменить пишущими моками и получить тот же самый факап в лабораторных условиях.
Факап, по статье, появился спустя 50 дней — тупо времени не было так долго гонять СХД в правильной конфигурации.
Поздняя регрессия, это понятно. Но когда его в хвост и гриву гоняли в лаборатории, это делали на самбе или на scsi/iscsi/fc (т.е. на блоках)?
По сути было 2 нагрузочных теста. Лабораторный, где все тоже самое, но в меньших объемах, где было все ок и непосредственно опытная эксплуатация у заказчика (несколько месяцев перед продакшеном). Период в которой всплыла проблема, это как раз опытная эксплуатация у заказчика, но еще не продакшен.
Не сходится. Если это опытная эксплуатация, то накопленные данные можно дропать. А у вас в посте написано, что дропать нельзя было. Звучит так, что оптыная эксплуатация случайно была объявлена продакшеном.
(Типовое «какой стенд, мы уже клиентов туда запустили»).
(Типовое «какой стенд, мы уже клиентов туда запустили»).
Эта была одна из особенностей проекта. Уже во время опытной эксплуатации вежливые люди во всю использовали видео для своей работы. С этим ни мы, ни оператор услуг сделать ничего не могли.
Дык так оно в этой сфере не бывает. «Опытная» означает что вас пустят на площадку, дадут работать с оборудованием/софтом, ну а если данные таки потеряют то грозный дядя майор не отправит вас на этап, а просто будет очень неприятно.
Еще это означает что у вас таки есть шанс согласовать простой на несколько минут на переключение чего либо куда либо.
Еще это означает что комплекс не принят на приемосдаточных испытаниях и денег разработчик могет и не получить.
А ну и еще означает что «вежливые люди» будут знать, что к комплексу имеют доступ разработчики и никаких особо секретных работ, которые могут раскрыть оперативные мероприятия проводить не надо.
Но просто так грохнуть данные вам не разрешат…
Еще это означает что у вас таки есть шанс согласовать простой на несколько минут на переключение чего либо куда либо.
Еще это означает что комплекс не принят на приемосдаточных испытаниях и денег разработчик могет и не получить.
А ну и еще означает что «вежливые люди» будут знать, что к комплексу имеют доступ разработчики и никаких особо секретных работ, которые могут раскрыть оперативные мероприятия проводить не надо.
Но просто так грохнуть данные вам не разрешат…
Спасибо за интересную статью!
Не очень понятен опус про «посодют», особенно в разрезе опытной эксплуатации.
Вообще редко что такого масштаба получается методом «купить и включить». Интегратор, глубоко разбирающийся в особенностях системы, нужен всегда.
Что такое такой масштаб вашем понимании? Полпетабайтные схд с учётом нынешних объемом данных и масштабами их роста — не самые большие объемы. Нагрузка на них от камер ВН величина не заоблачная, никаких сотен тысяч иопс там не нужно. И величина эта линейная и легко вычисляемая.
А уж использование файлового а не блочного доступа для таких целей — полноценный факап интегратора.
Если что я в всаас работаю, мнение не из Гугла беру
А уж использование файлового а не блочного доступа для таких целей — полноценный факап интегратора.
А можно с этого места поподробней, почему? Сколько не пытался загуглить обоснование этого или сравнение производительности, ничего не нашёл.
Наш интригатор утверждал ровно обратное, и в итоге наступил на грабли в другом месте.
Кроме того, что для файлового доступа тратится оперативная память самой хранилки, больше никаких доводов не нахожу.
если вы работаете с файлами — то задача размещения этих файлов по блокам решается СХД наверняка общего назначения. А она ничего не знает ни о будущих размерах файлов ни о порядке доступа к ним. Ну и тут сразу вопрос: а какая СХД и какая там файловая система и подходит ли она для вашего профиля нагрузки. (много мелких файлов / несколько но огромных). Кроме того плюсом идет затраты на обеспечение синхронизации доступа к файлам с нескольких инициаторов.
При блочном доступе — выбор ФС и порядок доступа определяется клиентом который знает что у него там за профиль нагрузки. Плюсом в помощь кэш операционной системы или вообще директная запись в блоки. А со стороны СХД совcем не надо заботиться о синхронизации доступа к LUN.
При блочном доступе — выбор ФС и порядок доступа определяется клиентом который знает что у него там за профиль нагрузки. Плюсом в помощь кэш операционной системы или вообще директная запись в блоки. А со стороны СХД совcем не надо заботиться о синхронизации доступа к LUN.
Так то оно понятно, но в данном случае у нас явно сказано про систему видеонаблюдения. Обычно это много крупных файлов. Если запись по движению, то минимальный сегмент в среднем 10 секунд потока от 2мбит, или размером конечного файла от 2,5мб. Если постоянная запись, то обычно режут примерно по 100-200мб файлы.
Далее, если у нас куча разных серверов, то обычно все-таки делается соответственное количество LUN-ов кратное количеству серверов. Например, один сервер пишет в три LUN, долгое/среднее/короткое время жизни записей.
Если сервер видео на базе windows, то и выбора типа ФС особо и нет, только размер блока. Обычно размер блока можно указать и на самих хранилках при их настройке.
Еще что-то не припоминаю импортозамещенных программ для видео с прямой записью на устройства, обычно все пишут в файлы. Китайские видеорегистраторы для аналоговых камер раньше работали без ФС.
В чем явное преимущество блочного доступа по сравнению с файловым еще не ясно.
Далее, если у нас куча разных серверов, то обычно все-таки делается соответственное количество LUN-ов кратное количеству серверов. Например, один сервер пишет в три LUN, долгое/среднее/короткое время жизни записей.
Если сервер видео на базе windows, то и выбора типа ФС особо и нет, только размер блока. Обычно размер блока можно указать и на самих хранилках при их настройке.
Еще что-то не припоминаю импортозамещенных программ для видео с прямой записью на устройства, обычно все пишут в файлы. Китайские видеорегистраторы для аналоговых камер раньше работали без ФС.
В чем явное преимущество блочного доступа по сравнению с файловым еще не ясно.
Данные с камер надо принять… наверное по ip мелкими фрагментами этих камер много… 10 тысяч. если каждая будет писать в свой пусть большой файл… это 10 тысяч iops… пусть и последовательно. Потом удалять — это фрагментация…
Я не спорю что решить с помощью NAS это можно. Но не так с наскоку… Придется группировать данные разных камер в один огромный файл. каким то образом строить в нем систему ссылок.
Я не спорю что решить с помощью NAS это можно. Но не так с наскоку… Придется группировать данные разных камер в один огромный файл. каким то образом строить в нем систему ссылок.
Нагрузка от десятка видеокамер — конечно не заоблачная… Беда в том что этих камер «несколько тысяч» раскиданных по всему городу…
Полпетабайта в месяц это примерно 200 мегабайт в секунду… Тю… пара дисков в зеркале…
Однако несколько тысяч камер наверняка гонят данные покадрово, пакетиками, да еще надо складировать наверняка каждую камеру отдельно… Вот вам уже «несколько тысяч IOPS». Если данные прибегают по IP то пакет килобайт-полтора… В идеальном H264overRTP 65k. Ну то есть от сотни тысяч до поллумиллиона IOPS.
Так что просто получить и просто записать в файлики «в лоб» уже не получается. У нас ведь не SSD… это несколько тысяч шпинделей надо. Придется аггрегировать/копить/последовательно писать/группировать.
Поэтому кстати и не файлы ибо блочные устройства последовательны и задачу группировки запросов будет решать не СХД, а файловая система на сервере, который хотябы представляет с какими данными работает сервер и как можно оптимизировать группировку. Ну и минус разные расходы на сетевые вещи самбы.
P.S. Я не сотрудник SoftLine и отношения к этой СХД не имею
Полпетабайта в месяц это примерно 200 мегабайт в секунду… Тю… пара дисков в зеркале…
Однако несколько тысяч камер наверняка гонят данные покадрово, пакетиками, да еще надо складировать наверняка каждую камеру отдельно… Вот вам уже «несколько тысяч IOPS». Если данные прибегают по IP то пакет килобайт-полтора… В идеальном H264overRTP 65k. Ну то есть от сотни тысяч до поллумиллиона IOPS.
Так что просто получить и просто записать в файлики «в лоб» уже не получается. У нас ведь не SSD… это несколько тысяч шпинделей надо. Придется аггрегировать/копить/последовательно писать/группировать.
Поэтому кстати и не файлы ибо блочные устройства последовательны и задачу группировки запросов будет решать не СХД, а файловая система на сервере, который хотябы представляет с какими данными работает сервер и как можно оптимизировать группировку. Ну и минус разные расходы на сетевые вещи самбы.
P.S. Я не сотрудник SoftLine и отношения к этой СХД не имею
Простите, но покадрово никто не пишет, именно чтобы не было «несколько тысяч IOPS»
Совсем не факт, что сервер настроенный кое-как в наших реалиях будет это делать лучше, чем хранилище, у которого часто есть выбор оптимизации для нужного профиля нагрузки.
Опять-таки команда «записать это немедленно» с верхнего уровня ФС не уйдет мгновенно на шпиндели, а встанет как минимум в очереди в RAID или HBA-контроллере.
Можно настроить блочное подключение к хранилищу на 10 серверах ивыбрать по умолчанию NTFS неправильно настроить ФС, что на каждую команду записи данных, будет уходить две команды записи в ФС и ее журнал. Или просто отправлять данные по samba-протоколу, и ОС хранилища будет самостоятельно делать commit на уровне своей ФС
задачу группировки запросов будет решать не СХД, а файловая система на сервере, который хотябы представляет с какими данными работает сервер и как можно оптимизировать группировку.
Совсем не факт, что сервер настроенный кое-как в наших реалиях будет это делать лучше, чем хранилище, у которого часто есть выбор оптимизации для нужного профиля нагрузки.
Опять-таки команда «записать это немедленно» с верхнего уровня ФС не уйдет мгновенно на шпиндели, а встанет как минимум в очереди в RAID или HBA-контроллере.
Можно настроить блочное подключение к хранилищу на 10 серверах и
Ну как то сравнивать ситуацию «тупой клиент / умная схд» и «умный клиент /тупая схд» несколько неправильно.
И кстати не сравнивал iSCSI (SCSI over IP) и Samba (тоже over IP) какие там будут накладные расходы. Но вот если у нас будет FC то там как раз плюх много. Тот же самый Multipath для пропускной способности и резервирования линков…
И кстати не сравнивал iSCSI (SCSI over IP) и Samba (тоже over IP) какие там будут накладные расходы. Но вот если у нас будет FC то там как раз плюх много. Тот же самый Multipath для пропускной способности и резервирования линков…
Никакой покадровой записи, видеопоток это же не 24жпега/сек.
I/P/B и прочие кейфремы и дельта между ними — вот основная составляющая h264/265
Камеры не пишут прямо на схд, между ними есть «прослойка» в виде серверной части видеонаблюдательного ПО, котораязанимается аналититкой, метадатой, прочейчерноймагией, в упрощенном для интересующей нас части формирует сегменты и отправляет их на запись на схд. Играясь с параметрами этих сегментов, выбором файловой системы и ее параметрами — в итоге получается оптимальная производительность и задержки.
Naves
Имея вводную что у нас есть плохой сервер и принять на веру что вендор схд заложил идеальный профиль для записи внутри своей железки — тогда да, файловый доступ будет лучше. Если добавить еще виндовый сервак и бесплатное по, шедшее в комплекте с китайскими камерами — то SMB вообще становится единственным рабочим вариантом чтобы не уехать в солнечный Магадан.
Блочный доступ более производительный ( да, можно подобрать профиль где файловый выиграет, но профиль мы выбирать особо не можем — камеры и потоки с них никуда не денутся) и дает возможность как и самоличный выбор фс, так и ее тюнинг.
Файловый позволяет делегировать как часть своей ответственности на вендора (ну они там наверное лучше знают что и как мне писать), так и часть возникающих проблем (я не знаю почему скорость деградировала, давайте вызывать представителей вендора, пусть они отвечают)
I/P/B и прочие кейфремы и дельта между ними — вот основная составляющая h264/265
Камеры не пишут прямо на схд, между ними есть «прослойка» в виде серверной части видеонаблюдательного ПО, которая
Naves
Совсем не факт, что сервер настроенный кое-как в наших реалиях будет это делать лучше, чем хранилище, у которого часто есть выбор оптимизации для нужного профиля нагрузки.
Имея вводную что у нас есть плохой сервер и принять на веру что вендор схд заложил идеальный профиль для записи внутри своей железки — тогда да, файловый доступ будет лучше. Если добавить еще виндовый сервак и бесплатное по, шедшее в комплекте с китайскими камерами — то SMB вообще становится единственным рабочим вариантом чтобы не уехать в солнечный Магадан.
Блочный доступ более производительный ( да, можно подобрать профиль где файловый выиграет, но профиль мы выбирать особо не можем — камеры и потоки с них никуда не денутся) и дает возможность как и самоличный выбор фс, так и ее тюнинг.
Файловый позволяет делегировать как часть своей ответственности на вендора (ну они там наверное лучше знают что и как мне писать), так и часть возникающих проблем (я не знаю почему скорость деградировала, давайте вызывать представителей вендора, пусть они отвечают)
а RAIDIX не рассматривали?
RAIDIX это ПО (SDS). К нему еще нужно оборудование и поддержка этого оборудования. В рамках этого проекта SDS (ни российский, ни зарубежный) не рассматривался.
UFO just landed and posted this here
1) Ни одной технической детали
Какие диски были, какой примерно уровень RAID
Сколько в сумме было камер, средний/общий трафик с них.
2) Почему перешли с SMB на iSCSI, и какое обоснование для этого. Какая ФС была сверху.
3) экономика решения
полпетабайта это 500 Терабайт?
6Tb SAS HGST 3.5", 7200 стоит примерно 20 тыс рублей.
один диск примерно дает 5,4Tb объема, берем пусть 120 дисков, итого за диски 2,4 млн рублей без учета скидок.
Хранилка на 24 дисков с контроллером стоит меньше 2 млн рублей, но нам нужен по факту один контроллер на несколько модулей расширения, каждый на 24 диска чуть меньше пол млн рублей, итого: голова 24 диска + 4 модулей по 24 диска = 2+4*0,5=4 млн рублей на полку на 120 дисков.
В итоге хранилище на настоящие 600ТБ в прыжке стоит 6,5 млн рублей, на самом деле еще дешевле. Продал квартиру в Москве и не надо ехать в Магадан.
Если нужно супернадежное резервирование, умножаем цену на два, хотя в этом абсолютно нет необходимости.
Если что, устриц ел. habr.com/ru/post/416687/#comment_18906271
Какие диски были, какой примерно уровень RAID
Сколько в сумме было камер, средний/общий трафик с них.
2) Почему перешли с SMB на iSCSI, и какое обоснование для этого. Какая ФС была сверху.
3) экономика решения
полпетабайта это 500 Терабайт?
6Tb SAS HGST 3.5", 7200 стоит примерно 20 тыс рублей.
один диск примерно дает 5,4Tb объема, берем пусть 120 дисков, итого за диски 2,4 млн рублей без учета скидок.
Хранилка на 24 дисков с контроллером стоит меньше 2 млн рублей, но нам нужен по факту один контроллер на несколько модулей расширения, каждый на 24 диска чуть меньше пол млн рублей, итого: голова 24 диска + 4 модулей по 24 диска = 2+4*0,5=4 млн рублей на полку на 120 дисков.
например, модели
P600Q-D424 и J300Q-D224
В итоге хранилище на настоящие 600ТБ в прыжке стоит 6,5 млн рублей, на самом деле еще дешевле. Продал квартиру в Москве и не надо ехать в Магадан.
Если нужно супернадежное резервирование, умножаем цену на два, хотя в этом абсолютно нет необходимости.
Если что, устриц ел. habr.com/ru/post/416687/#comment_18906271
UFO just landed and posted this here
Точного определения нет, так как это только зарождающийся рынок у нас. 20+ лет у нас в стране почти не было системной разработки (привет Грефу: «мы все купим»).
По факту импортозамещаемость сейчас можно измерить интеллектуальной собственностью.
Если интеллект принадлежит российской компании (со всеми исходниками), то продукт российский. А если ещё и продукт работает, то совсем хорошо.
Железо в этом случае вторично, поскольку все бренды (втч американские) сейчас выпускают железо на азиатских заводах, да и в России все-равно пока нет налаженного выпуска x-86 железа.
Те же Байкалы с Эльбрусами делают по контракту в Азии.
По факту импортозамещаемость сейчас можно измерить интеллектуальной собственностью.
Если интеллект принадлежит российской компании (со всеми исходниками), то продукт российский. А если ещё и продукт работает, то совсем хорошо.
Железо в этом случае вторично, поскольку все бренды (втч американские) сейчас выпускают железо на азиатских заводах, да и в России все-равно пока нет налаженного выпуска x-86 железа.
Те же Байкалы с Эльбрусами делают по контракту в Азии.
«Мы не будем тут приводить названия организаций, которые ведут себя плохо, обманом выдавая себя за отечественных производителей»
может, не надо помогать им мошенничать? Заодно, другие интеграторы будут знать куда идти не надо.
Наверняка же есть маркетинговая табличка с перечнем продуктов и «нюансами»?
может, не надо помогать им мошенничать? Заодно, другие интеграторы будут знать куда идти не надо.
Наверняка же есть маркетинговая табличка с перечнем продуктов и «нюансами»?
Хотелось бы узнать тестирование каких российских схд провалилось и почему? Это ведь не антиреклама, а опыт которым стоит поделиться.
Есть положительным опыт работы с СХД аэродиска + видеонаблюдение порядка 200 камер с 30 дневным сроком хранения. Полгода полет нормальный, с надежностью и производительностью проблем нет. Камеры распределены по нескольким серверам, каждому выделен LUN. И все это примерно на пол петабайта.
А каким образом вы несколько тысяч камер месяц храните на 500 Тб?)
Есть положительным опыт работы с СХД аэродиска + видеонаблюдение порядка 200 камер с 30 дневным сроком хранения. Полгода полет нормальный, с надежностью и производительностью проблем нет. Камеры распределены по нескольким серверам, каждому выделен LUN. И все это примерно на пол петабайта.
А каким образом вы несколько тысяч камер месяц храните на 500 Тб?)
Хорошо что наш позитивный опыт подтверждается.
Технические детали нашего проекта мы к сожалению не имеем права раскрывать.
Что касается других СХД от российских производителей, возможно в будущем мы попробуем сделать статью о сравнении, если конечно они разрешат.
Технические детали нашего проекта мы к сожалению не имеем права раскрывать.
Что касается других СХД от российских производителей, возможно в будущем мы попробуем сделать статью о сравнении, если конечно они разрешат.
500 000 000 Мб/(200 камер * 30 дней * 24 ч * 3600с)=0,9Мб/с с одной камеры
Какое разрешение у ваших камер, что они гонят поток в 7 Мбит/с?
1) На камерах, где нужно читать мелкие детали как номера машин, поставьте поток в 4Мбит, на камерах в помещениях 2мбит, такие значения справедливы для камер 2-3Мпикс.
Или установите экспериментально значение минимального битрейта, после увеличения которого не наблюдается заметное увеличение качества картинки.
2) Переведите часть камер на запись по движению, если позволяет ПО. Для экономии процессора датчика движения, настройте датчик по второму потоку низкого разрешения с камер.
Какое разрешение у ваших камер, что они гонят поток в 7 Мбит/с?
1) На камерах, где нужно читать мелкие детали как номера машин, поставьте поток в 4Мбит, на камерах в помещениях 2мбит, такие значения справедливы для камер 2-3Мпикс.
Или установите экспериментально значение минимального битрейта, после увеличения которого не наблюдается заметное увеличение качества картинки.
2) Переведите часть камер на запись по движению, если позволяет ПО. Для экономии процессора датчика движения, настройте датчик по второму потоку низкого разрешения с камер.
Возможно в таких камерах часто нужен зум, например для точного распознавания лиц или мелких предметов в руках.
Не знаю как у брэндированных камер, но у средних китайцев на 2Мпикс камерах, что на потоке 2мбит, что на 4-7мбит, одинаково невозможно разглядеть детали меньше определенного углового размера. Крайне непривычно после опыта работы с фотографиями от 10Мпикс, что зум больше 4х ничего не даёт. Сначала мы увеличиваем участок кадра, потом всей толпой дружно отходим от монитора на два метра и начинаем угадывать цифры на номере.
Sign up to leave a comment.
Опыт реального импортозамещения с использованием российской СХД AERODISK