Сейчас рассматриваем, на самом деле. Следующим шагом для этого проекта я как раз вижу возможность ухода от внешнего устройства с FPGA. Думаю, что для некоторых условий, где камер не так много, этого будет вполне достаточно.
На самой заре проекта нужно было быстро-быстро показать макет. И мы сделали его за 2 недели! Через две недели после получения первых спеков мы уже были в тестовой зоне у заказчика с компом и MX'ом.
И за эти 2 недели сложилась определённая архитектура софта, ориентированная на быстрый результат, который можно показать. Так родилось решение: вывод демона (в текстовом виде), анализирущего трафик от MX'а пропускать через svlogd, а svlogd уже брал на себя задачу архивирования и проставление меток времени.
У этой простой схемы есть свои преимущества и недостатки. Но с задачей она всегда справлялась, поэтому поменять впоследствии её уже не удалось, т.к. была куча других насущных проблем вроде поддержки TCP-шных камер. Так до конечного продукта эта база в виде архивированных логов и самописного select'а с фильтрами на awk/grep/sed и дошла.
Зато теперь я знаю, что с базой лучше заранее определяться :)
Драйвер ixgbe.ko в базе решил все необходимые задачи, там параметром interrupt coalescing был настроен и включён rss. Трафиком от MX'а мы полностью управляем, поэтому у нас фиксированное количество unicast'овых потоков + Jumbo Frames. Да и поток на сервер небольшой по современным меркам.
Поэтому до pf_ring дело не дошло.
Например, видео-стриминговый сервер может перестать справляться с нагрузкой. Что в этом случае произойдёт? Пользователь видео его не увидит. А кто в этом виноват? Оператор, который исправно обеспечивает транспорт видео до сервера?
И как нам в этом вопросе помогут метрики со стриминговых серверов, которые будут «рассказывать», что половину пакетов они просто не получили?
На сервере мы использовали обычный (если можно так сказать) linux, debian, развернули пару контейнеров, через cgroup выдали каждому контейнеру по несколько ядер. Один контейнер занимается перелопачиванием трафика от MX'ов, а другой выполняет по cron'у генерацию отчётов. Для того, чтобы процессор не умирал на обработке прерываний, настроен interrupt coalescing и по ядрам раскидана обработка очередей (rss).
База у нас получилась самописная и она базируется на логах, которые ведёт svlogd. Я лично не считаю это большим достижением и немного остерегаюсь писать про ещё одну grepdb…
А репортинг построен на шелл-скриптах, которые парсят логи, проводят необходимую агрегацию результатов (считают количество всяких событий, означающих превышение порогов). При помощи gnuplot'а строят графики, а при помощи markdown'а генерируют html-странички.
Спасибо, на самом деле я про подобный подход знаю довольно давно, но больше теоретически. В Matlab'е давно была возможность генерировать VHDL-код для модели, думаю, никуда она не делась.
Но как-то всегда не доверял системам, которые генерируют С/VHDL код. Да и стоит этот Matlab очень недёшево.
А ещё меня реально интересует, кто в жизни использует подобный подход, особенно в реальных продуктах…
весь монтаж был сделан вручную, все 200 штук, с сотней я ошибся, соответственно был непропай, криво поставленные компоненты. И еще, в схеме были разъемы rj45 со встроенными трансформаторами. И мы заказывали конкретные разъемы, а эти ребята без согласования с нами ставили свой нонейм, характеристики у которого плавали. В итоге переделывали. А вот к текстолиту никаких претензий нет. Мы сделали вывод, что если там ( в китае) не находишься, то сделают плохо.
Очень надеюсь, что вы сделали правильный выбор и у вас все будет ок. Желаю удачи!
мы несколько лет назад тоже обратились к китайцам, нужно было сделать 100 штук дивайсов. Там проц, ПЛИС, 4 слоя, трансиверы гигабит ethernet. К сожалению, опыт получился крайне неудачный — больше 90 процентов брака. Все платы пришлось перепаивать. С тех делаем на своем производстве.
а как ваш договор составлен? устройства проходят какие-то тесты прямо в китае? и какие ваши действия, если пришлют брак?
Получается (с учётом рейтинга комментов, по ниспадающей) следующее:
(21) Ты пока делай, а макеты и ТЗ я тебе потом дам
(14) Так сложилось исторически
(4) нам ТЗ некогда было внимательно читать (выбрал из четырёх предложенных именно этот)
(4) С бэкендом всё отлично — остался фронтенд
(3) Это не моя задача
(3) Ничего не исправилось (звучит от имени пользователей)
(2) Сделай пока хоть как-нибудь
(1) Этого не может быть — у меня всё работает
(1) Это не мой код
Итого 9 штук, то есть с января по сентябрь включительно! Осталось ещё три месяца и картинки соответствующие придумать, и можно будет запустить в печать календарь с анти-паттернами от Хабра-пользователей на 2015 год.
PS: это что же получается… большинство начинает работу до того, как известны макеты и ТЗ?
И за эти 2 недели сложилась определённая архитектура софта, ориентированная на быстрый результат, который можно показать. Так родилось решение: вывод демона (в текстовом виде), анализирущего трафик от MX'а пропускать через svlogd, а svlogd уже брал на себя задачу архивирования и проставление меток времени.
У этой простой схемы есть свои преимущества и недостатки. Но с задачей она всегда справлялась, поэтому поменять впоследствии её уже не удалось, т.к. была куча других насущных проблем вроде поддержки TCP-шных камер. Так до конечного продукта эта база в виде архивированных логов и самописного select'а с фильтрами на awk/grep/sed и дошла.
Зато теперь я знаю, что с базой лучше заранее определяться :)
Драйвер ixgbe.ko в базе решил все необходимые задачи, там параметром interrupt coalescing был настроен и включён rss. Трафиком от MX'а мы полностью управляем, поэтому у нас фиксированное количество unicast'овых потоков + Jumbo Frames. Да и поток на сервер небольшой по современным меркам.
Поэтому до pf_ring дело не дошло.
Система отчётов на bash + много awk'а.
И как нам в этом вопросе помогут метрики со стриминговых серверов, которые будут «рассказывать», что половину пакетов они просто не получили?
И получается, что нужен объективный инструмент, способный, как арбитр в футболе, решить спорные ситуации.
На сервере мы использовали обычный (если можно так сказать) linux, debian, развернули пару контейнеров, через cgroup выдали каждому контейнеру по несколько ядер. Один контейнер занимается перелопачиванием трафика от MX'ов, а другой выполняет по cron'у генерацию отчётов. Для того, чтобы процессор не умирал на обработке прерываний, настроен interrupt coalescing и по ядрам раскидана обработка очередей (rss).
База у нас получилась самописная и она базируется на логах, которые ведёт svlogd. Я лично не считаю это большим достижением и немного остерегаюсь писать про ещё одну grepdb…
А репортинг построен на шелл-скриптах, которые парсят логи, проводят необходимую агрегацию результатов (считают количество всяких событий, означающих превышение порогов). При помощи gnuplot'а строят графики, а при помощи markdown'а генерируют html-странички.
На чём лучше сделать акцент? :)
Но как-то всегда не доверял системам, которые генерируют С/VHDL код. Да и стоит этот Matlab очень недёшево.
А ещё меня реально интересует, кто в жизни использует подобный подход, особенно в реальных продуктах…
Очень надеюсь, что вы сделали правильный выбор и у вас все будет ок. Желаю удачи!
а как ваш договор составлен? устройства проходят какие-то тесты прямо в китае? и какие ваши действия, если пришлют брак?
Получается (с учётом рейтинга комментов, по ниспадающей) следующее:
(21) Ты пока делай, а макеты и ТЗ я тебе потом дам
(14) Так сложилось исторически
(4) нам ТЗ некогда было внимательно читать (выбрал из четырёх предложенных именно этот)
(4) С бэкендом всё отлично — остался фронтенд
(3) Это не моя задача
(3) Ничего не исправилось (звучит от имени пользователей)
(2) Сделай пока хоть как-нибудь
(1) Этого не может быть — у меня всё работает
(1) Это не мой код
Итого 9 штук, то есть с января по сентябрь включительно! Осталось ещё три месяца и картинки соответствующие придумать, и можно будет запустить в печать календарь с анти-паттернами от Хабра-пользователей на 2015 год.
PS: это что же получается… большинство начинает работу до того, как известны макеты и ТЗ?