[myth]

dpdk

[Ivan_83]

9 часов назад, default_vlan сказал:

Ок. Есть ли тул для сохранения трафика?

В таких пром масштабах я не видел.

Здесь же не только сохранение, здесь и распараллеливание записи и ротация дисков и поиск через какое то АПИ по каким то критериям.

Попробуйте спросить в АНБ.

[default_vlan]

https://www.carbonsoft.ru/products/carbon-ecms-2/ - можете завалить меня тряпками смоченными в урине. Для тех, кто не знал и будет говорить, что уже видел 100 раз.

 

Меня больше спокойствие радует. Придет время, коммерческой реализации нет, ФСБ заваливает провайдеров заявками на выдачу. Вся первая страница ответов сидит на пятой точке ровно и пишет отписки - не можем выдать, т.к. платная версия софта не вышла. Вот будет, накопим и выдадим.

 

Ор шире штор.

 

15 часов назад, Ivan_83 сказал:

Здесь же не только сохранение, здесь и распараллеливание записи и ротация дисков и поиск через какое то АПИ по каким то критериям.

есть конкретно регламент, что должно быть апи и т.п.? Шутка шуткой, а я трафик всех пользователей на 50 дисках по  2Тб каждый выдам (если носитель принесут) и пусть развлекаются с декодировкой TLS трафика. И еще. регламента нет на то что я должен выдать трафик только этого пользователя. Или всё, или ничего.

 

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

[alexwin]

Насчет tcpdump итд. В Linux,вспомнил,есть такая тема как kernel bypass,используемая на высоконагруженных серверах. Ознакомиться можно,н-р,тут :https://blog.cloudflare.com/how-to-receive-a-million-packets/

Смысл ее в том,чтобы принимать трафик минуя медленный сетевой стэк ядра.

 

P.S. Вижу DPDK его тоже использует.

 

P.P.S. https://habrahabr.ru/company/intel/blog/302126/

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

[Ivan_83]

Получить весь трафик с сетевухи давно не проблема.

Вопрос в том, как и куда это лить, в каком виде писать, как потом искать, как ротировать диски.

Всё сильно усугубляется тем что обычный хдд вещь с весьма не линейными показателями даже при однотопоточной записи/чтении, а уж когда нужно будет и читать и писать то вообще весело.

Формула один гиг - один диск не канает, и даже если там ставить страйп для типа балансировки то всё сдохнет на первом же сбойном секторе.

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

И вот там нюансов ещё 100500 вылезет при реализации и эксплуатации.

А вы щас пытаетесь придти на перестрелку даже не с ножом а зубочисткой, нипроканает - это наколенные решения уровня конторы на 10 человек, где 2 мегабита канал и 2тб диска хватит на год. И в опенорсе ничего и близко нет, потому что нахер никому такое не впёрлось.

 

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

Сейчас ничего нет, кроме бреда и фантазий.

И ничего не будет. Не будет ещё года 2 самый минимум, пока прикормленные конторы не смогут чего то родить.

Что толку это обсуждать?

Вы что, думаете щас возьмёте DPDK/PF_RING/NetMap, хуяк-хуяк и заработет чтоли? Или что у вас потом это кто то примет?

[alexwin]

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

И в опенорсе ничего и близко нет, потому что нахер никому такое не впёрлось.

Соглашусь с данным оратором.

 

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

Вы что, думаете щас возьмёте DPDK/PF_RING/NetMap, хуяк-хуяк и заработет чтоли? Или что у вас потом это кто то примет?

Опять же соглашусь с данным оратором. Никто вам не даст помешать распилить бабло.

[ayf]

9 часов назад, Ivan_83 сказал:

Сейчас ничего нет, кроме бреда и фантазий.

И ничего не будет. Не будет ещё года 2 самый минимум, пока прикормленные конторы не смогут чего то родить.

Что толку это обсуждать?

И пока не появится НПА, с описанием, что и как конкретно хотят, даже прикормленные конторы ничего не родят.

[YuryD]

В 03.02.2018 в 06:39, Ivan_83 сказал:

Получить весь трафик с сетевухи давно не проблема.

 

 Операторы вообще-то с миррорпорта ох-каких коммутаторов берут зеркало трафика. Или с оптосьемников. И никакие самописьные дпи тут не помогут никому и никогда. И знаете - почему ? У самописек в разработке никогда не будет нормальных сетевых карт и нормального сервера для хотя-бы тестирования-декодирования пакетов под гиг скорости. А продающиеся дпи - вполне существуют, и обобрены ркном.

[Ivan_83]

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

И знаете - почему ? У самописек в разработке никогда не будет нормальных сетевых карт и нормального сервера для хотя-бы тестирования-декодирования пакетов под гиг скорости. А продающиеся дпи - вполне существуют, и обобрены ркном.

Я вот не очень понял о самописных у которых денег нет на сетевухи.

Если говорить о гиге то i210 вполне доступны и неплохи.

ДПИ тут пишут в основном всякие инженеры програмеров, у них оно тоже на работе валяется.

 

А вообще топик про хранение, а не ДПИ.

ДПИ тема сильно проще, как по мне.

[alexwin]

21 час назад, YuryD сказал:

У самописек в разработке никогда не будет нормальных сетевых карт и нормального сервера для хотя-бы тестирования

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

 

Цитата

Для сборки и тестирования OpenBSD на всех платформах требуется целый "зоопарк" железа, в том числе старого и весьма прожорливого. Всё это железо находится в доме Тео де Раадта в Канаде и не может быть заменено стандартными серверами в местах с более дешёвым электричеством. Счёт за электроэнергию составляет 20 000 канадских долларов в год.

 

[YuryD]

 Про хранение - отдельная тема.  Сначала бы в память успеть захватить всё, дефрагментировать пакеты, а это карта и цпу, вместе с внутренними шинами материнки + тсп-стек. А уж затем суметь это перепихнуть в анализатор (цпу), и итоги  слить в дисковую подсистему. Это для дпи. Если для яровой - да хавать всё без анализа, и писать в raw - диски такое уже позволяют по скорости, хоть прямо через dma. Идея для дешевой китайской железки типа архив видеонаблюдения. Добавить робота для смены дисков в массиве осталось :)

 

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

ДПИ тут пишут в основном всякие инженеры програмеров, у них оно тоже на работе валяется.

 

 

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

[Ivan_83]

18 часов назад, YuryD сказал:

Если для яровой - да хавать всё без анализа, и писать в raw - диски такое уже позволяют по скорости, хоть прямо через dma. Идея для дешевой китайской железки типа архив видеонаблюдения. Добавить робота для смены дисков в массиве осталось :)

Я тут выше для кого распинался описывая примерные самые крупные затыки?

Или ты из офисных админов, у которых аплинк 10 мегабит и у них это реально решается одним подержанным диском в 1тб и компом с помойки?

 

Хз как ты, а лично я успел получить опыт в нечте близком ещё в 2004-2005 годах.

Я тогда накодил себе сверх быстрый многопоточный копировальщик файлов по сетке (с шар) под венду.

На одном стенде я получил график скорости чтения с диска откуда тянул данные, благо куда тянул был мощнее.

На другом стенде у меня ситуация была обратная - на диск не успевало записывать и система делала ещё хуже - уходила в своп.

Поэтому писанина на диски механические нихера не простая затея, даже в ссд можно что то словить со скоростью записи.

И это многократно усугубляется тем, что писать нужно сразу на пачку дисков, потому что один точно не осилит с запасом даже гиг. Ротации, поиск отдельная песня.

 

Что касается дпи и дефрагментации трафика, то ИМХО многие этого не делают или стараются не включать. Но в целом задача не сильно сложнее NAT (и даже легче - трекать только тцп), который на х86 уже года 4 как могут делать в 110 гигабит.

[Tosha]

Хранилище с гарантированной записью 15Г при условии что 1) размер тысяча дисков 2) параллельно идет гарантированное чтение хотя бы на скорости 15Г 3) параллельно идет перестройка массива в связи с выходом 1 узла из строя на скорости эдак 20Г. 4) поиск сведений по главным критериям не должен превышать, скажем, 1 часа при анализе всей информации массива.

И вот такое хранилище - очень непростое дело. Например, текущие облачные бесплатные реализации хранилища очень сильно проседают когда выходит из строя один из серверов.

И сеть между серверами облака получается надо строить чуть ли не на 100Г интерфейсах...

И это все строить надо сравнительно небольшому провайдеру, у которого доход совсем ни в какое сравнение с доходами Гугла (которому такие хранилища по карману) не идет...

Может быть энтузиасты специфичное п/о напишут (или модернизируют готовое) года через два как будут полностью ясны требования к системе...

 

[MATPOC]

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

И это все строить надо сравнительно небольшому провайдеру, у которого доход совсем ни в какое сравнение с доходами Гугла (которому такие хранилища по карману) не идет...

 

Самый реальный сценарий на данный момент:

 

1. Небольшим операторам связи разрешено использовать СХД (ЦОДы), принадлежащие другому оператору связи

2. Оборудование Яровой устанавливает Б4, ТТК, Эр, ещё кто-нибудь. Ну как устанавливают - подписывают соответствующие бумаги (Акты о приёмке. Протоколы и пр.).

3. Остальные операторы наверняка используют кого-то из предыдущего пункта в качестве аплинка. Поэтому получают право использовать их оборудование Яровой для записи своих абонентов.

 

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

 

Вот так мы не умрём первого июля 2018 года. Можно временно выдохнуть.

 

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

[zhenya`]

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

[rm_]

2 hours ago, zhenya` said:

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

Про IPv4 NAT забыть. Единственным не обязательно.

[YuryD]

8 часов назад, Ivan_83 сказал:

Я тут выше для кого распинался описывая примерные самые крупные затыки?

Или ты из офисных админов, у которых аплинк 10 мегабит и у них это реально решается одним подержанным диском в 1тб и компом с помойки?

 

 

 Если уж мы на ты, то ты вроде не описал сложность хернии для выборки из этого обязаннохранимого бреда. Написать софт для "сделай мне красиво" из таких бигдата - это совсем не копейки. Ну я и предложил, чтобы им задачу усугубить :) Пишем в raw - дешево и сердито. Как они это будут читать и анализировать - не мои траблемы. Мой КБ пока устраивает все стороны вопроса. Тем более, что теперешние сормы так и делают. Капчурят всё, кладут в кб, и из него уже и онализируют вроде. 3 юнита в стойке, и жрут электро - как не в себя. Один их этих серверов требует, чтобы питалово было на оба БП, иначе противно орёт и не запущается.

[Ivan_83]

7 часов назад, YuryD сказал:

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

Полагаю задача стоит в том, чтобы отдать все пакеты от/к указанного IP в заданный период.

Сам софт для разбора потоков уже есть, я видел на хаха как вакансии так и резюме тех кто писал всякие разборщики всяких протоколов из абстрактных мимо пролетающих потоков.

 

7 часов назад, YuryD сказал:

Пишем в raw - дешево и сердито. Как они это будут читать и анализировать - не мои траблемы.

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

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

[alexwin]

19 часов назад, MATPOC сказал:

придётся повышать цены

Никто вам не даст повышать цены,вы думаете вам позволят создавать социальную напряженость? Будете поглощаться мелкие в средние,средние в крупные и образуете чебурнет.

[myth]

А продуктовым сетям кто-то запрещает повышать цены?

[alexwin]

5 минут назад, myth сказал:

А продуктовым сетям кто-то запрещает повышать цены?

А продуктовые сети такие же расходы должны заложить в абонплату?

[myth]

они вообще непонятно что туда закладывают. Цена чуть ли не каждый день растет

[alexwin]

4 минуты назад, myth сказал:

они вообще непонятно что туда закладывают. Цена чуть ли не каждый день растет

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

[Tosha]

7 часов назад, Ivan_83 сказал:

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

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

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

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

[alexwin]

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

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

Эти проблемы давно уже решила бигдата,RDBS нервно курят в сторонке (хотя MySQL 8 еще там что-то дергается).Hadoop наше все. Хотя уже наверное не Hadoop,а Spark,который его давно обогнал (MapReduce vs Spark). Индексировать в реал-тайм у вас нет необходимости,это пакетная операция (batch operation).

 

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

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

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

 

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