[Ivan_83]

2 часа назад, Tosha сказал:

База данных то есть получается. Но вот тут тоже большая проблема - индексировать поток 10Г это сложно само по себе и это потребует в разы больше вычислительных способностей и места хранения. Да и сервер базы данных на миллионы вставок за секунду - очень непросто.

Ничего сложного тут нет, и даже бд как таковая не нужна.

Пишем в файл время и оффсет на диске.

А уж ложить пакеты в БД это вообще маразматичная идея.

 

2 часа назад, Tosha сказал:

Но в данном случае если придет запрос на основании внешнего IP - то анализ трафика может затянуться на неделю...

Такой задачи не стояло.

Но есть нетфлоу и метки времени.

[alexwin]

36 минут назад, Ivan_83 сказал:

А уж ложить пакеты в БД это вообще маразматичная идея.

Не надо их ложить в бд,их надо писать в распределенную фс типа HDFS в формате raw/pcap,а потом уже когда надо обрабатывать.

https://labs.ripe.net/Members/wnagele/large-scale-pcap-data-analysis-using-apache-hadoop

[YuryD]

В 08.02.2018 в 05:03, Ivan_83 сказал:

Проблема в том, что как минимум ещё нужны метки времени.

И хорошо бы иметь некий индекс, чтобы быстро прыгать к нужному времени.

 С ленточными накопителями дело не имели ? FS и индекса там в начале ленты понятно нету, но есть всякие приблуды-маркеры для быстрых перемоток. Привод в смке мотал до маркера. Маркером может быть хоть и время. В автовидеорегистраторах дешевых на флэшке USB  вроде и есть фс, по факту её нету.

[MATPOC]

В 09.02.2018 в 21:24, YuryD сказал:

С ленточными накопителями дело не имели ?

Да что вы себе мозги парите с возможными вариантами технической реализации??? Выкатят вам список из одного производителя и скажут у него брать.

[pavel.odintsov]

On 08/02/2018 at 10:43 AM, alexwin said:

Не надо их ложить в бд,их надо писать в распределенную фс типа HDFS в формате raw/pcap,а потом уже когда надо обрабатывать.

https://labs.ripe.net/Members/wnagele/large-scale-pcap-data-analysis-using-apache-hadoop

Еще главное не забыть, так это нанять data engineer где-нить за $130k USD (если повезет), чтобы это поддерживать в хорошем рабочем состоянии :(

[alexwin]

1 минуту назад, pavel.odintsov сказал:

Еще главное не забыть, так это нанять data engineer где-нить за $130k USD (если повезет), чтобы это поддерживать в хорошем рабочем состоянии :(

Наймите меня,я вам встану в $100K,если не осилите hadoop the definitive guide длиной в 900стр :)))

[zhenya`]

После гайда хорошее рабочее состояние не выйдет )

[alexwin]

2 часа назад, zhenya` сказал:

После гайда хорошее рабочее состояние не выйдет )

У вас есть опыт работы с Hadoop,чтобы делать такие заключения?

[Ivan_83]

В 09.02.2018 в 17:24, YuryD сказал:

С ленточными накопителями дело не имели ? FS и индекса там в начале ленты понятно нету, но есть всякие приблуды-маркеры для быстрых перемоток.

Там это обязательный костыль, здесь есть пространство для манёвра и не использовать его просто глупо.

 

В 08.02.2018 в 13:43, alexwin сказал:

Не надо их ложить в бд,их надо писать в распределенную фс типа HDFS в формате raw/pcap,а потом уже когда надо обрабатывать.

Ты вот только что предложил внести дополнительный элемент с не предсказуемым поведением.

Что такое хадуп я ваще не знаю, подозреваю что это некий абстрактный пул обработчиков - так он нахер не нужен.

[alexwin]

1 час назад, Ivan_83 сказал:

Ты вот только что предложил внести дополнительный элемент с не предсказуемым поведением.

Что такое хадуп я ваще не знаю, подозреваю что это некий абстрактный пул обработчиков - так он нахер не нужен.

Согласен,вы точно не знаете что такое hadoop. Это касается утверждения и про непредсказуемое поведение,ну и про все остальное. Ознакомьтесь хотя бы по ссылке вверху - там написано,что RIPE NCC используется его для анализа дампов трафика в формате pcap.

 

Единственно,можно в определенной мере согласиться с утверждением,что он нахер не нужон. Действительно,мелкие и средние провайдеры вряд ли потянут финасово кластер из сотен или тысяч  нод. Проще пилить,что-то "на коленке",вполне вероятно,что получиться сэкономить на железе. Правда до определенной степени: рано или поздно вы упретесь в потолок вертикального маштабирования. А Hadoop искаробки заточен под горизонтальное и может маштабироваться как в том анекдоте про иноплянетян и докуя.

[Ivan_83]

37 минут назад, alexwin сказал:

там написано,что RIPE NCC используется его для анализа дампов трафика в формате pcap.

1. У меня нет таких проблем.

2. Почему то ты решил что контора авторитет, хотя скорее всего у них нет своих профильных спецов и они решают задачу не эффективно просто используя то что есть.

Их коллеги из ISC говнокодили не одно десятилетие свои бинд и дхцп и честно писали что софт больше как PoC с соблюдением всех RFC, а всякие производительности и стабильности это дело десятое, им не за это платят.

 

37 минут назад, alexwin сказал:

Единственно,можно в определенной мере согласиться с утверждением,что он нахер не нужон. Действительно,мелкие и средние провайдеры вряд ли потянут финасово кластер из сотен или тысяч  нод. Проще пилить,что-то "на коленке",вполне вероятно,что получиться сэкономить на железе.

Нахера эти ноды нужны?

Ты каждому хомяку по ноде хочешь?)

Задача стоит в сборе, хранении и выдаче. Обработки тут нет.

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

[alexwin]

1 час назад, Ivan_83 сказал:

2. Почему то ты решил что контора авторитет, хотя скорее всего у них нет своих профильных спецов и они решают задачу не эффективно просто используя то что есть

А где я написал,что это авторитет и пример для подражания,не понял? Я написал,вот пример как можно анализировать петабайты дампов. И да,они просто решают тем,что есть не изобретая велосипед,так там в комментах и видно. Там кстати в комментах отметился свой индусский Ivan_83 с аналогичными "претензиями" ;))

 

1 час назад, Ivan_83 сказал:

Нахера эти ноды нужны?

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

 

1 час назад, Ivan_83 сказал:

Ты каждому хомяку по ноде хочешь?)

Ну прочти же ты уже что-нибудь хотя бы обзорное-то по hadoop ). Ладно,проехали.

 

1 час назад, Ivan_83 сказал:

Задача стоит в сборе, хранении и выдаче. Обработки тут нет.

Тогда тебе точно не нужно это решение,вполне хватит и дисковых полок.

 

1 час назад, Ivan_83 сказал:

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

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

 

[big-town]

В общем как я понял у народа ни какой конкретики. Все ждут волшебника на голубом вертолете который подарит решение, ну конечно не за бесплатно. Купим и будем счастливы или нет... Сейчас я вижу что чиновники топают ногами и кричат хочу-хочу. И закон на той стадии "Мы вот тут как то придумали, а вы должны сделать но что бы работало". Понятно что ни о какой безопасности здесь не может идти и речи - это тупое выжимание бабла из оператора, и поверьте от такого вкусного куска ни кто не откажется, это моё ИМХО. По идее такое оборудование должно быть сертифицировано и бла-бла-бла.  Но что если после даты Ч чиновник из РКН придет и спросит "а кде?" вот вам предписание и что бы через 10 дней все было и не ипет. Возможно такое развитие событий? Конечно да, ибо это Россия. Поэтому предлагаю делится конкретными наработками и искать решение самостоятельно.

 

Вот как развлекался я:

В качестве эксперимента собрал raid 5 из 6-ти дисков обычных sata 1G. Скорость записи отвратная от 150-300Мбс в зависимости от теста. Явно не хватает. У нас пиковая 3Г. Писать пробовал  нативной тулзой dumpcap  -B4096 -i eth2 -b duration:60 -w /tmp/pcapfile. Файлы получаются вида pcapfile_00001_20180212132214  pcapfile_00002_20180212132314, можно так же писать по размеру файла dumpcap  -B4096 -i eth2 -b filesize:60 -w /tmp/pcapfile. Пробовал писать в RAM. Для анализа использовал скрипт вида:

#!/bin/bash

RX0=`grep eth2 /proc/net/dev | sed -r 's/ +/ /g' | cut -d' ' -f4`
TX0=`grep eth2 /proc/net/dev | sed -r 's/ +/ /g' | cut -d' ' -f12`

dumpcap  -B4096 -i eth2 -a duration:60 -w /tmp/pcapfile ;

RX1=`grep eth2 /proc/net/dev | sed -r 's/ +/ /g' | cut -d' ' -f4` ;
TX1=`grep eth2 /proc/net/dev | sed -r 's/ +/ /g' | cut -d' ' -f12` ;


let SUM_RX=$RX1-$RX0
let SUM_TX=$TX1-$TX0

echo $((SUM_RX+SUM_TX))

Результат работы для трафика  1.6Gps:

root@nat220:~# ./pcap.sh
File: /tmp/pcapfile
Packets captured: 7525466
Packets received/dropped on interface eth2: 15864744/8338503
15876241 

Размер файла 6223М

Манипуляции с размером буфера эффекта не дали.

Половина пакетов отбрасывается.

Вывод - утилиты на основе libpcap не годятся для подобных задач, как собственно и raid5.

 

Единственным правильным вариантом считаю использовать интеловский фрэймворк  DPDK, на основе которого Макс написал свой замечательный exfilter. Писать только на raid10. Логику записи можно оформить в ini-файле. Куда писать сколько писать и по сколько писать.

 

Изменено 12 февраля, 2018 пользователем big-town

[alexwin]

30 минут назад, big-town сказал:

Писать только на raid10

Зачем вам резервирование? Оно в требованиях есть?

 

30 минут назад, big-town сказал:

Скорость записи отвратная от 150-300Мбс в зависимости от теста

Модели дисков уточните?

 

30 минут назад, big-town сказал:

Конечно да, ибо это Россия

Пора уже наверное Черноземову карманный огнетушитель покупать )))

 

30 минут назад, big-town сказал:

Логику записи можно оформить в ini-файле. Куда писать сколько писать и по сколько писать.

Звучит как заказ ))

 

30 минут назад, big-town сказал:

Вывод - утилиты на основе libpcap не годятся для подобных задач

 

Тест dd можете сделать и выложить? Пример.

Изменено 12 февраля, 2018 пользователем alexwin

[Ivan_83]

45 минут назад, big-town сказал:

Единственным правильным вариантом считаю использовать интеловский фрэймворк  DPDK

Есть же PF-RING, netmap.

И в данном случае ИМХО не принципиально.

Рейда мало, нужен ещё оперативный кеш на ссд, на случай если рейд затупил.

И много ещё всяких нюансов.

Здесь такое никто не осилит, если только контора которая пилит скат.

Так что можете сворачивать обсуждение и искать деньги :)

[big-town]

Диски дешманские ST1000DM010 и ST1000DM003. Машинку уже разобрал. Но если мне не изменяет память то 150 если запретить кэширование в dd те с опцией dsync. 300 показывал если размер файла превышал минимум вдвое размер оперативки. В остальных тестах конечно цифры выглядели лучше. Все тесты были типа dd if=/dev/zero of=/test.img count=X bs=Y.

 

Насчет резервного копирования, тут все зависит от закона, если по попе давать не будут то конечно можно и руками развести,  мол мы старались но сломался блин. Тут конечно и выгода весомая будет.

 

 

Изменено 12 февраля, 2018 пользователем big-town

[pavel.odintsov]

да, на базе pcap не годятся https://habrahabr.ru/post/261161/ =)