[AKim]

Стоят базушки, да в чистом полюшке да на высотинушке ветрами обдуваемые. Очень нестабильная платформа. :)

 

И что по ним гуляет?

 

шейпер, RIP, DHCP, VPN, 300+ мбит туда обратно?

[saaremaa]

И что по ним гуляет?

DHCP, PPPOE, VLAN, немного firewall 1 база ~ 20-30 Мбит/с (20-25 клиентов)

где-то после 28 приезжают еще CCR1016-12G - 4 шт на апгрейд MPLS/VPLS ядра. Сейчас живет на части CCR1016-12G , часть RB1100AHx2. Будем тестировать. CCR1016-12G живет не плохо на 6.4, но есть глюкии аптайм не более недели при нагрузке 300-500 Мбит/с в реальном трафике. В синтетике пропускал 1.1 Гбит/с общей производительности ядра(ограничение по производительности РРЛ - кольца). Опять же если заменить оставшиеся RB1100AHx2 - будет пошустрее.

Изменено 19 октября, 2013 пользователем saaremaa

[myst]

Стоят базушки, да в чистом полюшке да на высотинушке ветрами обдуваемые. Очень нестабильная платформа. :)

Чиста ради интереса? Отройте тайну... Зачем замазывать адреса из серой сети?

[saaremaa]

Чиста ради интереса? Отройте тайну... Зачем замазывать адреса из серой сети?

Дело привычки. :)

[Gaspar]

Как же засрана тема... Всякий оффтоп про х86, вайфай, болванки какие-то... и лишь иногда проскакивают сообщения о реальной производительности MikroTik CCR :)

 

Мы давно смотрим в сторону этой железки как на вариант резерва аппаратных маршрутизаторов.

О постоянном использовании в продакшене речи не идет, исключительно резерв на время, необходимое для замены.

 

Интересует, сможет ли она держать порядка 10-ти бгп сессий (пиры, аиксы, несколько фуллвью) с общим количеством маршрутов около 1.6 млн при использовании только в качестве бордера.

Количество трафика интересует хотябы 1-2 ГБит/с в одну сторону. Соответственно суммарная нагрузка трафиком будет 2-4 ГБит/с.

 

Есть ли у кого-нибудь _реальный_ опыт эксплуатации такого решения в качестве бордера? Как быстро в этом случае обсчитываются таблицы, какова загрузка CPU? Сколько пролезает трафика?

[xxxupg]

поддерживаю работу такого бордера на x86

суммарно вход ~2,5Г выход примерно ~1Г

BGP:

- 2 фуллвью

- 3 IX

- 10 на локальные машины

 

Отдаём в зависимости от направлений разно нарубленные 4 сетки три /20 и одну /23

 

максимальная загрузка на intel x2 8 ядерном (модель не помню но уточню) 28% (если смотреть нагрузку по ядрам отдельно то самая большая мб 40-45%)

сетевуха 10G

 

 

При падении пира, всё обновляется довольно шустро, никто ничего не замечает. в ЧНН меняли руками приотеризацию каналов и вообще "роняли" основной и поднимали доп. всё Ок

Аптайм 400+дней, собственно с момента включения.

 

p.s. хотел попробовать поставить у себя CCR, раньше у него была проблема которая заключалась в том что обсчёт маршрутов bgp почему-то выполняло только 1 ядро, и это было медленно, но сейчас говорят что исправили, вот пытаюсь добиться ответа, исправили или нет, если поправили (как говорят) то новая модель с sfp+ будет очень кстати.

 

P.S.2. как то давно, как только CCR вышел, делали тест его как НАТ, получалось такое:

 

 

один из тестов, правил файрволла - 40, НАТ правил - 60.

+ ospf примерно 5000 маршрутов

+ bgp null 2 шт.

Изменено 23 октября, 2013 пользователем xxxupg

[Gaspar]

А какая ОС на х86? Не микротик случаем?

 

p.s. хотел попробовать поставить у себя CCR, раньше у него была проблема которая заключалась в том что обсчёт маршрутов bgp почему-то выполняло только 1 ядро, и это было медленно, но сейчас говорят что исправили, вот пытаюсь добиться ответа, исправили или нет, если поправили (как говорят) то новая модель с sfp+ будет очень кстати.

 

Вот и я слышал, что вроде как баг с бгп пофиксили. Но покупать железку за 40к чтобы в этом убедиться - не хочется. Мы тоже смотрим с портами сфп+.

Даже если баг пофиксили, вопрос с пакетной производительностью и вносимой задержкой остается.

[s.lobanov]

Даже если баг пофиксили, вопрос с пакетной производительностью и вносимой задержкой остается.

 

Как и на любом софтроутере

[Gaspar]

Как и на любом софтроутере

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

Вопрос в том - на сколько? В абсолютных величинах и применительно к CCR1036-8G-2S+EM.

Аналогично и с ппс - у разных софтроутеров разная производительность, интересует опять же конкретно 1036 в конкретной задаче (бордер).

 

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

[xxxupg]

Gaspar, да описывал бордер именно на mikrotik x86

раньше нам давали "на тест" CCR1036, может быть с новой моделью тоже получится :)

Изменено 23 октября, 2013 пользователем xxxupg

[s.lobanov]

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

 

Ну да, на CCR есть fastpath. Чтобы он работал необходимо выполнить условия: http://wiki.mikrotik.com/wiki/Manual:Fast_Path , иначе это будет такой же софтроутер как обычный PC. На задаче asbr-only в принципе эти условия выполнимы, однако всё равно при роутинге будут обращения в обычную RAM, просто в обход ядра linux.

 

А вообще, для вас лишние 1-2мс задержки это критично? Вы предоставляете услуги для финансовых бирж? (если да, тогда вряд ли бы речь вообще шла про микротик, сразу бы вкатили нормальное решение с tcam-ом на 512K-1M маршрутов)

[Gaspar]

А вообще, для вас лишние 1-2мс задержки это критично? Вы предоставляете услуги для финансовых бирж?

Если 1-2мс - не критично, учитывая то, каким именно образом мы хотим использовать этот микротик.

 

Мы давно смотрим в сторону этой железки как на вариант резерва аппаратных маршрутизаторов.

О постоянном использовании в продакшене речи не идет, исключительно резерв на время, необходимое для замены.

 

Интересует, сможет ли она держать порядка 10-ти бгп сессий (пиры, аиксы, несколько фуллвью) с общим количеством маршрутов около 1.6 млн при использовании только в качестве бордера.

 

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

Но если она даст +10 мс (что я видел в некоторых тестах, правда не в качестве asbr), то так дело не пойдет.

 

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

[DVM-Avgoor]

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

 

 

Я бы не стал столь категорично заявлять :) Насколько я понял Tile-GX не имеет какой-либо акселерации TCP/Ethernet/NAT... Это тупо большая коробка с ядрами. В таких системах кроме плюса в виде огромного суммарного кэша (а на ядро там всего 32+32+256) имеют гигантскую проблему с синхронизацией работы всего этого добра с памятью. Т.е. в плохом случае (а фулвью это вполне такой плохой случай) затраты на выборку из памяти перевешивают любое преимущество всяких там mPIPE и 36-ти ядер. Это увы факт. По-сути эта штука мало чем отличается от обычного 2х процессорного писюка с кучей дешевых ядер. И вся акселерация там выполнена программно (насколько я вижу из блоксхемы, могу ошибаться).

 

Специализированный процессор для трафика это скорее Cavium Octeon 5020, два мипс-ядра, блок железной акселерации CP или SCP. Вот это как раз специализированное решение. На нем кстати EdgeRouterLite by Ubiquiti выдал в пустой конфигурации 1МППС насколько я помню :)

Изменено 23 октября, 2013 пользователем DVM-Avgoor

[Gaspar]

Я бы не стал столь категорично заявлять :)

Да это не я придумал, это так позиционируются данные процессоры.

The TILE-Gx™ processor family is optimized for networking ...

 

Судя по описанию, у них есть и общий кэш. Сталкивались когда-нибудь с индексацией баз данных? или с написанием шейпера с использованием хэшей? Можно, например, группировать все маршруты (FV+IX etc), и хранить в общем кэше индексы, ссылающиеся на блоки памяти, где уже будут части таблицы маршрутов покрупней. А если еще эти части раскидать в кэш каждого ядра, то может быть оно и будет быстрей. Это лишь один из вариантов, который сразу приходит на ум, и конечно не факт что рабочий :)

 

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

[DVM-Avgoor]

Да это не я придумал, это так позиционируются данные процессоры.

 

На самом деле на заборе тоже ведь написано :) А там...

Архитектурно в этом плане x86 стабильно сосет.

 

 

 

Судя по описанию, у них есть и общий кэш. Сталкивались когда-нибудь с индексацией баз данных? или с написанием шейпера с использованием хэшей? Можно, например, группировать все маршруты (FV+IX etc), и хранить в общем кэше индексы, ссылающиеся на блоки памяти, где уже будут части таблицы маршрутов покрупней. А если еще эти части раскидать в кэш каждого ядра, то может быть оно и будет быстрей. Это лишь один из вариантов, который сразу приходит на ум, и конечно не факт что рабочий :)

 

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

 

ПС. Вы же понимаете что lookup маршрута хоть в линуксе хоть в бсд и так нелинеен? Там все уже придумано до нас (С)

[NiTr0]

Да это не я придумал, это так позиционируются данные процессоры.

Может, потому что Tile-Gx больше никуда попросту невозможно засунуть?

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

 

Даже если допустить что в треде прерывания выполняется и лукап и НАТ по пакету

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

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

[DVM-Avgoor]

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

 

 

Я не знаю как в линуксе, глубоко в него не лез. Но что-то мне подсказывает, что "передать другому ядру" это бессмысленно. Зачем?

Плюс как обычно, ИМХО, там глобально все равно все в локах, когда передается ядру, когда оно принимает, когда обращается к памяти, когда отдает результат в память или уже на выход. Мне просто кажется, что с 36 ядрами это страшное месиво из столлов и прерываний. Можно провести эксперимент, скажем просто: дать Х трафика получив допустим 50% всех ядер на IRQ-загрузке. Довести загрузку до 100% и убедиться что трафика не стало 2*Х :)

[Ivan_83]

Т.е. в плохом случае (а фулвью это вполне такой плохой случай) затраты на выборку из памяти перевешивают любое преимущество всяких там mPIPE и 36-ти ядер.

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

 

Можно, например, группировать все маршруты (FV+IX etc), и хранить в общем кэше индексы, ссылающиеся на блоки памяти, где уже будут части таблицы маршрутов покрупней. А если еще эти части раскидать в кэш каждого ядра, то может быть оно и будет быстрей. Это лишь один из вариантов, который сразу приходит на ум, и конечно не факт что рабочий :)

Вам бы теории немного подучить.

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

Можно принудительно загрузить и принудительно очистить кеш, но узнать что там есть нельзя.

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

 

Неприятность многоядерности случается когда все ядра работают с одной и той же инфой, в этом случае все кеши должны быть когерентны (общая информация должна быть везде одинакова). Соответственно как только одно ядро что то захочет там поменять то оно должно моментально приехать в кеши всех других ядер. Есть разные возможности реализации этого, но в любом случае это затратно. Даже если все остальные ядра не лочатся чтобы обновились их кеши, то как минимум эта инфа объявляется устаревшей (менее но тоже затратно) и они в след раз будут ждать когда она обновится из общего кеша.

 

 

Я не знаю как в линуксе, глубоко в него не лез. Но что-то мне подсказывает, что "передать другому ядру" это бессмысленно. Зачем?

А вот нифига.

В линуксе RPS (вроде) а во фре NetISR (есть ещё аналогичный функционал в нетграфе, но это сильно отдельная и специфичная тема).

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

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

А другие потоки с очереди себе забирают на обработку и тоже могут не сильно торопится.

Постановка и удаление из очереди:

лок()

поставить/взять()

анлок()

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

[Painter]

CCR1036-12G-4S

 

Купили для теста, поставили в качестве BRAS, PPPoE+шейпер (некоторые подключаются с MPPE). Параллельно еще 3 x86 микротика.

 

Проблема CCR в том, что он медленнее чем x86 отвечает на PPPoE discovery и к нему цепляется мало клиентов, возможно это связано со скоростью единичного ядра.

 

Ради интереса переключили на него 600 пользователей (тарифы 4-80 мбит), отлично справился, для одного ядра видел в пике 70% нагрузки. В работе 7 месяцев. было одно зависание (можно списать на тогда еще rc версию 6 router os). Специфичных для этой модели проблем не было.

 

Конфиг простой, nat, пара bridge правил, ospf (1500 маршрутов) и ibgp (пара десятков маршрутов).

 

Прикрепил графики его текущей загрузки. Как видно нагрузка довольно хорошо размазывается по ядрам (на графике 100% всех CPU будет 3600%).

 

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

[kayot]

Читаю и аж дух захватывает..

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

С подобными задачами у меня 'сервера' стоимостью 200$ справляются на ура, ребутил я их в последний раз даже не помню когда, с этим примерно раз в год энергетики помогают))

[saaremaa]

Производитель железку заявляет почти как аналог MX серии от джунипера

пруф, если не сложно.

[DVM-Avgoor]

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

А другие потоки с очереди себе забирают на обработку и тоже могут не сильно торопится.

 

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

[Ivan_83]

Не нужно боятся локов :)

Этот "определённый уровень нагрузки" как раз и есть тот потолок который может обрабатывать одно ядро. Когда одного ядра мало - проще через очередь раскидать на все.

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

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

Сейчас в индустрии повторяется ситуация начала 200х, когда появились 100 мегабит, но чтобы их заюзать на полную нужны были сетевухи с аппаратными оффлоадингами ибо процы не вывозили, только теперь 10Г, и уже 40 и 100 на подходе, а у кремния застой. И многоядерность не теперь требует ещё и многоканальности от контролёров памяти, а по частоте расти уже некуда...

[DVM-Avgoor]

Не нужно боятся локов :)

Этот "определённый уровень нагрузки" как раз и есть тот потолок который может обрабатывать одно ядро. Когда одного ядра мало - проще через очередь раскидать на все.

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

 

Ладно, что на ночь мутить воду. Одно ядро то может и примет поток прерываний, но в системе кроме них еще ведь задачи есть. А как вы можете наблюдать в картинках с CCR прерывания от души приходят на все ядра.

 

Есть труды достойных товарищей процедевелоперов, в которых ясно сказано: реализовать неблокируемую архитектуру из 8+ ядер настолько трудо- и деньгозатратно, что это просто не имеет никакого смысла.

 

Это я и пытался донести, что в ситуации когда IRQ достается всем ядрам и память одна на всех - гибель от обжорства неминуема. Настанет такой момент когда память будет залочена только прерываниями, и никакой реальной работы происходить не будет, и не только на ядре которое принимает прерывания. Все остальные в хальте будут висеть ожидая данных с замученной нарзаном памяти :) Такие монструозные решения увы не жизнеспособны. Косвенно мы видим этот показатель в "популярности" Тилеры, о которой до CCR большая часть народонаселения и не слышала-то :)

[NiTr0]

Но что-то мне подсказывает, что "передать другому ядру" это бессмысленно. Зачем?

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

А вот поиск сессии по нат-таблице - может выполняться хоть всеми 36-ю ядрами одновременно. Пока не упрется в ПСП памяти. Как и энкапсуляция/декапсуляция пакетов для туннелей. Как и шифровка ipsec/mppe. При обработке пакетов сравнительно мало данных глобальных таблиц модифицируются, в основном модифицируются данные пакета.

 

Мне просто кажется, что с 36 ядрами это страшное месиво из столлов и прерываний. Можно провести эксперимент, скажем просто: дать Х трафика получив допустим 50% всех ядер на IRQ-загрузке. Довести загрузку до 100% и убедиться что трафика не стало 2*Х :)

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