Какой поток потянет такая конфигурация?

[KaYot 3 685]

Но ведь

1) используется всего 2 ядра

2) процессор/система давно устарели, i5-2500 с ddr3 будет давать еще в 1.5-2 раза больше

3) на них 400мбит создают <10% загрузки

Это не совсем ">4 ядер, при оптимизации до гига"

 

По счетчикам в корне не согласен. Все-таки любое правило в фаерволе добавляет лишнюю работу работу на прохождение КАЖДОГО пакета. В вашем случае 4 правила на клиента заставляют при прохождении пакета выполнить в среднем лишние 1500 операций, что весьма и весьма много.

 

В моей структуре учета всего 6 правил фаервола, отправляющих трафик во временную таблицу, из которой биллинг время от времени достает данные. Накладные расходы на обработку в сотни раз меньше. Tак же как и с правилами доступа, если их написать в тупую 750 строк с акцептами, будут тормоза т.к. на каждый пакет лишние 300 операций. Если же запихать все в set(или как там в BSD, table?) - всегда будет до десятка операций поиска нужной записи и все..

 

Старая версия нашего биллинга работает у конкурентов в нашем же городе, там как раз таки по 2 правила на разрешение работы для клиента и еще 2 для учета трафика. И жрет оно 100% ресурсов начиная со 100мбит на любом железе)))

 

Да, поминутная ПЕРСОНАЛЬНАЯ статистика по трафика у нас ведется, клиент всегда может просмотреть свой трафик за любой период времени хоть в табличном виде, хоть в виде графиков в личном кабинете.

[pavlabor 1 937]

Шо там стоит за операционка?

top - 14:35:01 up 76 days, 1:32, 1 user, load average: 0.00, 0.02, 0.00

это мистика, такого не может быть в приципе!

[KaYot 3 685]

Не может быть 76 дней аптайма или load average? Linux, среднюю нагрузку он всегда считал как-то странно.

[pavlabor 1 937]

load average.

Это случайно не вята?

load average - это параметр загрузки очереди обработки, и для 0, система должна стоять, нет нечего в очереди.

при таких нагрузках , такого не может быть.

 

Чуствую KaYot, подкинул ты мне работы...

[KaYot 3 685]

Обычный linux, у меня на всех серверах этот average или 0.0 или какое-то маленькое число, честно и не знаю что оно значит.

[pavlabor 1 937]

Обычный linux, у меня на всех серверах этот average или 0.0 или какое-то маленькое число, честно и не знаю что оно значит.

 

С многоядерностю, разработчики сами не знают что это значит

Идея там следующая, 1 это 100% загрузки процессора.

Если average 1.2, то это означает что в очереди на обработку находится столько задачь, что необходимо 120% процесорных ресурсов.

И это сигнал прикупать еще один проц, или повышать частоту проца.

Если в системе стоит 2 проца, то как бы 1.2 это нормально, свободно 80%, и т.д.

Для квадро, 4 это нормально.

Но 0, этого не может быть, потому как проц то работает, и если система загружена на 10%, то там по любому должно быть хоть 0.1

[KaYot 3 685]

Значит глючит этот параметр в топе линукса.

Вот с iptv-сервера, который всегда загружен на 20% независимо от времени суток.

top - 16:29:05 up 1 day,  4:24,  1 user,  load average: 0.00, 0.00, 0.00
Tasks: 144 total,   2 running, 142 sleeping,   0 stopped,   0 zombie
Cpu0  : 22.5%us,  3.9%sy,  0.0%ni, 71.6%id,  0.0%wa,  1.0%hi,  1.0%si,  0.0%st
Cpu1  : 13.8%us,  1.8%sy,  0.0%ni, 82.6%id,  0.0%wa,  0.9%hi,  0.9%si,  0.0%st
Cpu2  : 21.7%us,  3.8%sy,  0.0%ni, 72.6%id,  0.0%wa,  0.9%hi,  0.9%si,  0.0%st
Cpu3  : 12.8%us,  2.8%sy,  0.0%ni, 82.6%id,  0.0%wa,  0.9%hi,  0.9%si,  0.0%st
Mem:   2060044k total,  1997920k used,    62124k free,    82064k buffers
Swap:  2048248k total,      528k used,  2047720k free,  1243936k cached

Те же нули..

[alex_o 1 194]

Павлабор, боюсь Вас шокировать, но рискну рассказать следующее. Есть такой вендор - juniper, у него есть маршрутизаторы серии М (М7i, М10i). Это обычные софт-роутеры класса циски 7200, их потолок - роутинг потока 2Гбит/сек. Так вот там целероны стоят. Старые, добрые интеловские целероны, которых теперь даже на барахолке не сыскать - ОДНОЯДЕРНЫЕ. А их JunOS - всего лишь оптимизированный клон FreeBSD. Не поверите, но эти железяки роутят аж гай шумит.

[pavlabor 1 937]

Есть роутеры софтовые, аппаратные и аппаратно софтовые.

И за 286 процы на цысках, тоже знаю.

Нет тут нечего удивительного.

 

Если есть желание узнать как оно работает, в двух словах раскажу.

 

Для начала что такое роут, начнем с хаба.

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

Чем интересен свичь.

В свиче придумали таблицу мак адресов.

Когда пакет с одного порта заходит, то свичь пробрасывает брадкастовый мак опрос на все порты,

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

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

Дальше, когда маршрут построен, пакеты просто отправляются на указанный порт.

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

Примечательно то что таблица реализована на уровне регистров, сама фабрика коммутации логический автомат,

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

это позволяет работать на больших скоростях, при практически очень низких енергозатратах.

Шина 800мегабит, для компа это приличный радиатор, в коммутаторах практически радиаторов нет.

 

Вырезка маков на полной скорости это круто

Цыска, посмотрела на такой финт и подумала, а чо если резонуть больше.

И появился коммутатор 3 уровня.

Здесь IP, вырезалось автоматом и помещалось в таблицу маршрутизации,

это были регистры самой фабрики коммутации, поетому пакет обрабатывется на на полной скорости.

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

Потом пошли дальще, кроме мака, и IP, начали вырезать часть приамбулы пакета

и на его основе построили асл правила.

 

После такого усовершенствования, коммутатор, не намного подорожав,

превратился в роутер и мог роутить потоки на скорости коммутации.

Это круто.

 

Возникает вопрос,

Павлабор, боюсь Вас шокировать...

...роутинг потока 2Гбит/сек. Так вот там целероны стоят...

чем там занимаются целероны?

А нечем...!

Они там и на не на...!

Все роутится на уровне центрального чипа коммутатора, ему не нужен даже целерон!

А, ну да, коммутатор то управляемый... и как бы нужно чем то управлять,

и собственно, там с головой достаточно ПИК-а.

Зачем?

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

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

Все!

Но визуально прет, на скорости 20ркс в секунду, и под 20 гиг производительности...

Вот и вся цыска, равно как и juniper, да причие производители.

 

Теперь, если стало понятно с коммутатром, можно расмотреть как работает рс.

А рс, если ы него воткнуть две сетевые, не получает единого моста между портами,

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

Отсюда PCI шина просто физически не может выдержать нагрузки, а на ней висит еще куча обвязки.

 

На этом уровне должно стать понятно что,

- для цыски абсолютно побарабану какой там стоит проц, главное фабрика коммутации,

- комп, в часности пень, не может обойти цыску в принципе, из за архитектурных особенностей.

 

Но не все так кучерявенько.

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

и задачи когда нужно много регистров.

Отсюда, практически все лер3 могут сделать рип, оспф, но не могут сделать бжп!

Чо за фигня?

В чом проблема?

Как писал один админ - "сделал запрос, может обновлю прошиву, чтобы бжп разрулило..."

Ну, ну...

 

А вся проблема в том, что рип, это статические маршруты, и их всего лиш 32 штуки,

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

и молотить будет поток на полной скорости.

А бжп, это проблема, 700-800 тыс. анонсов это серьезные объемы,

тут аппаратно сделать уже нужно попотеть.

То есть, легко заметить, что это задача совершенно другого уровня!

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

 

И таких задачь не мало,

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

И само управление, требует все больше и больше сервисов.

И постепенно, в коммутаторе появляется два ядра,

первое это непосредственно фабрика коммутации,

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

 

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

Коммутатор может также решать примитивные задачи, днсп, днс, пинг, трейс и прочую ерунду.

Но если необходимо, БЖП, собрать статистику по нетфлоу, прокси, шейперы, цыска превращается в девайс, не чем не отличающияся от класического сервака.

И на таких задачах, ефективней использовать комп,

тем более, после появления pci-e, и кучи наворотов на его базе, комп начинает составлять серьезную конкуренцию цыске.

А появление карточек дуо и квадро, вообще говорит что в недалеком будущем, квадро карточка будет выступать фабрикой коммутации,

а комп станет ядром управления.

И тогда цыска, свабодна!

Или сделают божеские цены.

 

Думаю данный пост позволит по другому взглянуть на некоторые, крутые, вещи.

[KaYot 3 685]

Отсюда, практически все лер3 могут сделать рип, оспф, но не могут сделать бжп!

..

А вся проблема в том, что рип, это статические маршруты, и их всего лиш 32 штуки,

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

и молотить будет поток на полной скорости.

А бжп, это проблема, 700-800 тыс. анонсов это серьезные объемы,

тут аппаратно сделать уже нужно попотеть.

То есть, легко заметить, что это задача совершенно другого уровня!

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

Как хорошо что наш бордер на C3750G не знает что RIP это статические маршруты и что их всего 32! Глядишь икнул бы от удивления и перестал принимать ~4к динамических маршрутов как сейчас происходит

Понятие регистры скорее применимо к процессорам, свичу важна только CAM-память под MACи/маршруты, в объемы которой все и упирается. Ну еще стандартная DRAM для firmware, в ее объем упирается поддержка тяжелых 'фич'. Кстати, технически bgp ничем не сложнее того же ospf'a, который поддерживают практически все, все же это просто маркетинг или ненужность фичи(вот нафига на свиче доступа, пусть даже самом крутом, нужен bgp??)

[pavlabor 1 937]

Исправлять не стану, голова болит, главое чтобы была понятна идея.

 

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

то есть это не память.

И регистры на самом деле для свича, самое важное, потому что в самой фабрике коммутации нет такого понятия как частота,

это логические ключи, если там 0 переход закрыт, если 1 переход открыт,

При получении пакета в аккумулятор, мак, ип, приамбула, паралельно раскладываются по соответствующим регистрам,

если получаем логический 0, пакет дропается, если 1 , он выгружается в соответствующий порт.

Потому и скорость, потому и не блокируемая матрица.

Эти регистры находятся внутри чипа, и правильно

> MACи/маршруты, в объемы которой все и упирается.

Это класический коммутатор,

лер 3, так же организовывает и другие маски управления, это ип, асл правила.

 

DRAM для коммутатора не важна, у фабрики коммутации нет такого понятия как прошивка,

прошивка это уровень управляющего процесора, и firmware нужна для него.

Собственно и то что после заливки firmware, мы получаем цыску, залей туда juniper, получиш juniper.

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

Но образно, так.

 

Мы переписывали прошивки, заливали в существующее железо и оно работает.

только прошиву написать довольно сложно.

 

bgp от ospf отличается кардинально.

Если ты оптимизоровал комп под http://gara.opennet.ru/ipacc/ то думаю что быстро поймеш что я написал.

 

Промышленый шпионаж,

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

Потому что мне достаточно намека, не разочаровывай меня.

 

По ipacc, почему не ng_ipacct?

Дело в том что у нас стояли коллекторы на ng_ipacct,

мы их похоронили лет пять назад (поднял архивы, последние правки - июн 22 2006).

Потому как по мне, там нет правила

from_IP to_ANY pkg byte

перетачивали ли под себя, под 64 битность?

 

Подожду реакцию на DRAM...