Поищи такую взрослую штуку, как сайты для онлайн дрочеров

не напишут

Они напишут. Правда, работать это будет как говно (то есть, как весь вконтакте), но когда у тебя бесконечное количество железа -- это неважно.

Типа бонгокамс, чатурбейт и прочие рунетки

их в рушке по пальцам пересчитать

Они напишут. Правда, работать это будет как говно (то есть, как весь вконтакте), но когда у тебя бесконечное количество железа -- это неважно.

Варт, а в чём проблема, если серьёзно?

С чем?

Типа бонгокамс, чатурбейт и прочие рунетки

если они вообще в рушке есть.

балансер/dpi сейчас легко сделать на 40Гбит и больше.

У этих сайтов пиковая нагрузка столь высока, что просто ващпе

Да нет, понятно, что можно сделать. Но чтобы он хорошо работал -- это непросто.

у упоминавшегося сегодня Леонида Юрьева есть хорошие слайды по topgun.

там есть очень красивое решение: на входе мы очень-очень быстро считаем хеш от payload и используем его как некий ключ на какую ноду должен попасть трафик. и сам этот ключ мы кладем в кусочек dst mac.

А дальше?

Это один пакетик

Тебе же туда надо всю сессию отправить.

ну так вся сессия и пойдёт :)

У этих сайтов пиковая нагрузка столь высока, что просто ващпе

Это понятно. только им не проджать)

Так хэшики от пэйлоада будут всегда разные

это как RSS в сетевых карточках, только тут оно раскладывается на ноды.

Так хэшики от пэйлоада будут всегда разные

я не совсем корректно выразился. для начала можно хешик от src ip + dst ip

Это понятно. только им не проджать)

А под кого вы его сделали?

и тогда весь flow будет попадать на конкретную ноду.

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

И все такое.

Вот и получится продукт :)

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

а тут стек не нужен )) тут нужен dpdk и прочий kernel bypass. правда, много магии надо будет с реассемблингом

Это rocket science... Крик души) первые в РФ.. и все такое...

Это понятно. только им не проджать)

Я к вопросу поиска клиентов подхожу с очень систематическим подходом. ;)

тут самое сложное - это как раз вот на входет быстро раскидать flows. и для этого на сотке нужны уже fpga.

а тут стек не нужен )) тут нужен dpdk и прочий kernel bypass. правда, много магии надо будет с реассемблингом

Воот. Выкидываешь стек -- сам ебешься со сборкой

Воот. Выкидываешь стек -- сам ебешься со сборкой

правда, в dpdk есть и реассемблинг.

http://metrotek.spb.ru/files/doc/b100/b100-balancer-booklet_ru.pdf

Ну и да. Я так понимаю, на современных пицюках можно до 40 гигабит процессить

С карточками умными

циклическая, равномерная, на основе хешей, динамическая, на основе энтро- пийного анализа

Это то, почему все производители говнодипиачиков и сормов продают решения сороковками :)

Почитаю буклет дома

Поля для фильтрации MAC адреса, Ethertype, VLAN (до 3-х тегов), MPLS(до 3-х меток), IPv4/IPv6 ад- реса, IP proto, ToS/DSCP, UDP/TCP порты, флаги TCP Фильтрация по произволь- ным полям до 128 байт, автоматическое и ручное задание смещения

Ну и да. Я так понимаю, на современных пицюках можно до 40 гигабит процессить

http://www.netdevconf.org/1.1/proceedings/slides/dangaard-network-performance.pdf

сейчас в linux сетевой стек на tx может 42mpps.

но пока всё упирается в rx

b100 идеальный сорм, по-идее.

b100 может железно закрыть какой-нить скайп на РФ)

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

Если смотреть другой буклет)))

http://metrotek.spb.ru/files/doc/b100/b100-booklet_ru.pdf

Сорм требует анализа содержимого, включая, например, заголовки e-mail

Справочная информация Брошюра (анализ трафика) Брошюра (балансировка трафика)

)))

http://www.netdevconf.org/1.1/proceedings/slides/dangaard-network-performance.pdf

Отличная преза

http://metrotek.spb.ru/files/doc/b100/b100-booklet_ru.pdf

скок стоит?

это смотря какую брошюру скачать)))

скок стоит?

Недорого, кстати. 4 ляма вроде.

ну около того. это без оптических модулей

Справочная информация Брошюра (анализ трафика) Брошюра (балансировка трафика)

Там нет ничего про анализ payload и разбор протоколов

Там только про замеры характеристик

задержка, джиттер, пропадание пакетов, порядок прихода пакетов, гистограм- ма задержки и джиттера, битовые ошибки, нагрузка Статистика по ошибкам, по адресации (broadcast/unicast/multicast), по размерам

Про фильтрацию там неясно из брошур

l2, короче.

Отличная преза

да там многое с netdev достойно. кстати, ты был прав насчёт 40Gbps: >40Gb rate, with TSO=on or TSO=off, it does not matter anymore.

А про замену телеграмму, я думаю про wire

Он жопл

И труъ-скайповый

Гуй не открыт, только либа

да там многое с netdev достойно. кстати, ты был прав насчёт 40Gbps: >40Gb rate, with TSO=on or TSO=off, it does not matter anymore.

Ну это при нормальном размере пакетов, понятно. Если поднять pps путем уменьшения размеров, throughput у таких говнодипиаев падает радикально :))

Всему своё время

ERROR: S client not available

Именно по описанным в презентации причинам.

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

Ну это при нормальном размере пакетов, понятно. Если поднять pps путем уменьшения размеров, throughput у таких говнодипиаев падает радикально :))

ну, сейчас линукс может 14mpps одним ядром утилизировать.

а бенчить прикольно moongen'ом

я тут случайно в офисе сделал петлю, тестируя софт-бридж на dpdk.

причём, всё было ок, пока случайно не прилетел броадкаст и я увидел 1.44Mpps

14 миллинов ппс по 70, например, байт -- это сколько получится? :)

Гиг :)

у нас гдето всего 1.5 летает покачто

14 это на каком железе?

14 миллинов ппс по 70, например, байт -- это сколько получится? :)

~ 800-860 Мбайт/с

14 это на каком железе?

это wirespeed для 10GbE

некстати. perkele оказался на удивление ок и юзабелен скрипитово и всё такое

yflj j vextybz[ c ДУ yf [f.ht yfgbcfnm xnj kb

~ 800-860 Мбайт/с

То есть че-то типа 7 гигабит?

надо про свои хождения по LE на хабре что ли написать

Детальный анализ данных (DPI) в реальном времени на уровнях L2–L7 модели OSI при любой нагрузке (до 100%) Анализ и фильтрация по критериям, определяемым оператором: VLAN метки, MPLS, IP-адреса, подсети, протоколы различной степени вложенности, диапазоны сетей и протоколов, строки символов. Анализ данных с одновременной фильтрацией и мультиплексированием в интерфейсы с меньшей скоростью передачи (10 Гбит/c). Обработка 100% трафика без потерь на каждом из интерфейсов даже при минимальном размере кадра (64 байта). Суммарная пропускная способность прибора составляет 480 Гбит/c. Анализатор может быть перенастроен под любые пользовательские цели и задачи.

это с сайта.

в брошюре кажется имелся ввиду тестер на сотке.

напомните, сейчас какой год?

Вчера был 2016

сегодня еще не проверял

впринципе "может быть перенастроен под любые пользовательские цели и задачи"

Странно, тогда в теории половина чатика не родилась ещё когда "можель ОСИ" уже была булшитом

То есть че-то типа 7 гигабит?

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

откуда это словосочетание с цифрой 7 всплывает в 2016 году, если мы не в чатике археологов?

вкратце - меня стошнило и хочу это развидеть

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

Воот. И все без исключения DPI страдают от того, что при понижении размера пакетов у них радикально падает трупут.

а у нас не падает

Воот. И все без исключения DPI страдают от того, что при понижении размера пакетов у них радикально падает трупут.

что логично

а у нас не падает

Да вы не тестили наверное ;))

что логично

почеу?