ibmed Опубликовано 15 марта, 2010 (изменено) · Жалоба Да не запинайте ногами ближнего своего :) ЧТО ЕСТЬ: Сейчас BGP-роутер один (debian+quagga) и, соответственно, более-менее нормально распределяет трафик между каналами и в нормальном режиме и когда один из каналов падает. Однако в пике загрузка по процессору уже подбирается к 70-75%. Следовательно, расширяя канал, я почти наверняка упрусь в потолок производительности. Внутри сети OSPF. Из БГП внутренней карточкой смотрит в сегмент, в который смотрят 10 NAS-ов (FreeBSD+mpd). Правда, планирую пересобрать это в формате БГП - 2 Шейпера - 10 НАСов. ЧЕГО ХОЧЕТСЯ: Понять, в какую сторону правильно плясать от этой печки: а) можно отапгрейдить железо и тем отодвинуть потолок на некоторое (возможно, достаточно длительное) время; б) уже сейчас разделить каналы на разные БГП-роутеры; Так вот, начав думать над конфигурацией о двух БГП, я пришел к неутешительному выводу, что пока не очень понимаю, как красиво реализовать эту схему. Что я не очень понимаю: 1) Очевидно, придется редистрибьютить фулл-вью бгп в оспф. Иначе как они узнают, через кого отдается оптимальный маршрут и через кого ходить, если канал падает. Но это сильно забьет таблицу маршрутов на НАСах, что не айс. Альтернатива: редистрибьютить маршруты только до двух шейперов, шейперы собрать в CARP, а для НАСов уже будет один единственный default. 2) Должны ли БГП-роутеры общаться между собой? И если да, то где об этом почитать? Прогуглив ничего особенно не нашел на предмет конфигураций с несколькими БГП. 3) Стоит ли вообще городить этот огород с отдельными машинками? Если кто-то уже успешно и красиво это реализовал, или знает как - поделитесь схемой, конфигом или ссылкой на почитать.. Пожааалуйста :) Изменено 15 марта, 2010 пользователем ibmed Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
XeonVs Опубликовано 15 марта, 2010 · Жалоба О разделении мысль верная. Только зачем редистребьют? Нужно между двумя BGP поднять iBGP линк и гонять по нему фулвью. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
ibmed Опубликовано 15 марта, 2010 · Жалоба О разделении мысль верная. Только зачем редистребьют? Нужно между двумя BGP поднять iBGP линк и гонять по нему фулвью. Гм.А как исходящий трафик будет разделяться? Если не делать редистрибьют, то мы остаемся только с маршрутом по умолчанию на роутерах, смотрящих на БГП.. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
XeonVs Опубликовано 15 марта, 2010 · Жалоба О разделении мысль верная. Только зачем редистребьют? Нужно между двумя BGP поднять iBGP линк и гонять по нему фулвью. Гм.А как исходящий трафик будет разделяться? Если не делать редистрибьют, то мы остаемся только с маршрутом по умолчанию на роутерах, смотрящих на БГП.. исходящий как обычно, в некоторых случаях будет подряд два бордера.правильно конечно отдавать либо дефолт в нижележащий уровень, либо на нижележащих дефолты с разными метриками ставить. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Kristoff_Vampire Опубликовано 15 марта, 2010 · Жалоба Разделять на разные железки БГП только из-за нагрузки не есть гуд по моемому. Обычно это делают когда аплинки в разных местах подают каналы или ещё какието причины. Я бы задумался о железном варианте. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
kapa Опубликовано 15 марта, 2010 · Жалоба 2 ibmed: а не поделитесь цифрами - количество абонентов/суммарная полоса аплинков/процессор/сетевые ? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
ibmed Опубликовано 15 марта, 2010 · Жалоба 2 ibmed: а не поделитесь цифрами - количество абонентов/суммарная полоса аплинков/процессор/сетевые ? Да, с удовольствием - может кому-то будет полезно.БГП сейчас живет на дебиане, что происходит еще со времен, когда мы натили пользователей. Хотя фря мне куда милее, но на момент установки машинки, линукс НА ГОЛОВУ лучше натил, чем фря (сейчас не знаю - переехали на белые адреса). Машинка делает только bgp+ospf. Iptables выкомпилены из ядра. Суммарная емкость каналов: 1.5G Пользователей в чнн - примерно 3500-3800 Linux debian 2.6.30 #8 SMP Mon Jul 27 08:12:32 MSD 2009 i686 GNU/Linux Железо: model name : Intel® Core2 Quad CPU Q6600 @ 2.40GHz MemTotal: 3636324 kB 4х портовый Intel (e1000e: Intel® PRO/1000 Network Driver - 1.0.2.5-NAPI) Нагрузка: Time Int rKB/s wKB/s rPk/s wPk/s rAvs wAvs %Util Sat 23:24:48 bond0 5.48 519.7 275581 238518 0.02 2.23 0.00 3676.5 23:24:49 bond0 150136 136498 267778 235705 574.1 593.0 0.00 2085.1 23:24:50 bond0 145706 132029 263263 232181 566.7 582.3 0.00 0.00 23:24:51 bond0 145066 124750 261689 225558 567.7 566.3 0.00 4558.2 23:24:52 bond0 145468 129694 261564 227004 569.5 585.0 0.00 0.00 23:24:53 bond0 144394 131243 263996 230733 560.1 582.5 0.00 2571.8 23:24:54 bond0 144105 131382 263899 233221 559.2 576.9 0.00 0.00 23:24:55 bond0 148000 132686 267199 233429 567.2 582.1 0.00 0.00 при этом debian:~/nicstat-1.22# netstat -i Kernel Interface table Iface MTU Met RX-OK RX-ERR RX-DRP RX-OVR TX-OK TX-ERR TX-DRP TX-OVR Flg bond0 1500 0 1752538785 0 23199120 0 1516900495 0 0 0 BMmRU (т.е. имеются RX-DRP) TOP: Tasks: 101 total, 1 running, 100 sleeping, 0 stopped, 0 zombie Cpu0 : 0.3%us, 0.3%sy, 0.0%ni, 45.7%id, 0.0%wa, 4.1%hi, 49.5%si, 0.0%st Cpu1 : 0.7%us, 0.0%sy, 0.0%ni, 41.6%id, 0.0%wa, 4.8%hi, 52.9%si, 0.0%st Cpu2 : 0.0%us, 0.0%sy, 0.0%ni, 47.0%id, 0.0%wa, 4.2%hi, 48.8%si, 0.0%st Cpu3 : 0.7%us, 0.0%sy, 0.0%ni, 53.7%id, 0.4%wa, 4.2%hi, 41.1%si, 0.0%st Mem: 3636324k total, 600032k used, 3036292k free, 91764k buffers Swap: 0k total, 0k used, 0k free, 184016k cached PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 8 root 15 -5 0 0 0 S 4 0.0 3:33.85 ksoftirqd/2 6 root 15 -5 0 0 0 S 3 0.0 8:35.73 ksoftirqd/1 Что довольно странно: на данный момент машинка примерно на 50% в idle, однако уже второй день вижу потери пакетов порядка 1-3% по пингу на локальный интерфейс. Сие довольно странно, т.к. нагрузка бывало доходила и до 70%+ и оно жило. Возможно железо, возможно, что-то еще - пока не разобрался. В ближайшее время расширяем канал и добавляем скорости к анлимам, так что нагрузка еще возрастет. Под все это дело решил переехать на фрю. Кстати по нашим тестам в формате выкомпиленного файрвола и линк-агрегейшн фря давала большую скорость, чем линукс. Что-то еще забыл? :) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Wingman Опубликовано 15 марта, 2010 · Жалоба Опишу, как у нас: сейчас два аплинка, в сумме порядка 2gb In + 2gb Out На машинке ospf нет, ната/шейпа нет, iptables самый минимум, БГП к аплинкам и iBGP к насам (для роутинга белых ипов) Крутится генту Linux gw.ip-home.net 2.6.32.7 #5 SMP x86_64 Intel® Xeon® CPU E5504 @ 2.00GH Стоит два 4-головых интела: 10:00.1 Ethernet controller [0200]: Intel Corporation 82576 Gigabit Network Connection [8086:10e8] (rev 01) Subsystem: Intel Corporation Gigabit ET Quad Port Server Adapter [8086:a02b] Kernel driver in use: igb Но задействованы сейчас только 4 порта из них. Собраны в бонд, по которому гоняется весь трафик. Из восьми ядер, соответственно, загружены 4 -- на каждое по сетевухе. При загрузке 1.8 гбит фулдуплекс (3.6 гб по-цисковски ;) - software interrupts на загруженных ядрах составляет ~50% Сейчас тоже будем расширяться, но всё расширение в итоге сойдется в задействовании ещё 4-х портов в бонде ;) Они нагрузят простаивающие сейчас ещё 4 ядра. Такая схема теоретически потащит 4гб ин + 4 аут без проблем. Ну на крайняк - заменим процы, 2ггц уже не очень смотрится. Ни потерь ни лагов по вине машинки до сих пор не было, юзеры счастливы, жмакая спидтест и пингтест ;) Кроме того, чтобы разгрузить pc, я сейчас думаю попробовать схему: выпросить у аплинков по лишнему пиринговому IP, воткнуть интерфейсы каталиста в пиринговое пространство, и БГП-бордером отдавать аплинкам next-hop = интерфейс каталиста. Таким образом весь входящий трафик будет идти через железо, соответственно, писюк в 2 раза разгрузится. Если всё хорошо пойдёт - скоро потестирую =) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Abram Опубликовано 16 марта, 2010 · Жалоба Опишу, как у нас: сейчас два аплинка, в сумме порядка 2gb In + 2gb OutНа машинке ospf нет, ната/шейпа нет, iptables самый минимум, БГП к аплинкам и iBGP к насам (для роутинга белых ипов) А можно об этом подробнее? Как это? Квагга на NAS-е видит новые маршруты (читай: новые PPP) и отправляет их бордеру?Нет ли задержки? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Wingman Опубликовано 16 марта, 2010 · Жалоба Опишу, как у нас: сейчас два аплинка, в сумме порядка 2gb In + 2gb OutНа машинке ospf нет, ната/шейпа нет, iptables самый минимум, БГП к аплинкам и iBGP к насам (для роутинга белых ипов) А можно об этом подробнее? Как это? Квагга на NAS-е видит новые маршруты (читай: новые PPP) и отправляет их бордеру?Нет ли задержки? Задержек нет, единственное - на НАСе не квага, там микротики Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Abram Опубликовано 16 марта, 2010 · Жалоба Опишу, как у нас: сейчас два аплинка, в сумме порядка 2gb In + 2gb OutНа машинке ospf нет, ната/шейпа нет, iptables самый минимум, БГП к аплинкам и iBGP к насам (для роутинга белых ипов) А можно об этом подробнее? Как это? Квагга на NAS-е видит новые маршруты (читай: новые PPP) и отправляет их бордеру?Нет ли задержки? Задержек нет, единственное - на НАСе не квага, там микротики Спасибо, понял.А почему не OSPF? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Wingman Опубликовано 16 марта, 2010 · Жалоба Опишу, как у нас: сейчас два аплинка, в сумме порядка 2gb In + 2gb OutНа машинке ospf нет, ната/шейпа нет, iptables самый минимум, БГП к аплинкам и iBGP к насам (для роутинга белых ипов) А можно об этом подробнее? Как это? Квагга на NAS-е видит новые маршруты (читай: новые PPP) и отправляет их бордеру?Нет ли задержки? Задержек нет, единственное - на НАСе не квага, там микротики Спасибо, понял.А почему не OSPF? Исторически сложилось так, а сейчас переделывать особых причин нет =) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
[GP]Villi Опубликовано 17 марта, 2010 · Жалоба ibmed я так понимаю вы ставя два шейпера (почему не в бридже кстати?) получаете такую схему: NAS1,NAS5 - shaper1 - border и NAS6,10 - shaper 2 - border ? так что мешает в таком случае поставить 2 бордера, и с обоих сессии к аплинку/аплинкам поднять? ну и между собой докучи еще можно, чтобы часть своих адресов не через аплинка была доступна. получится типовая схема помноженная на два, которую впоследствии можно сколько угодно раз повторять. До кучи для hot_backup можно добавить внутрь iBGP и анонсить с бордеров внутрь default с разным AS-path или weight, или пользоваться localpref для распределения. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
ibmed Опубликовано 17 марта, 2010 (изменено) · Жалоба [GP]Villi Не совсем так. На данный момент наиболее правильной схемой в сценарии с двумя БГП мне кажется что-то вроде: БГП1 =\_/= Шейпер1 БГП2 =/ \= Шейпер2 Оба БГП при этом будут отдавать по ОСПФ свой фулл-вью, а Шейперы на сетевых, смотрящих в сторону НАСов будут собраны в CARP, чтобы у насов оставался один единственный дефолт, и фулл-вью дальше шейперов не выходил. Таким образом лучше обеспечивается отказоустойчивость (БГП упал, анонсы в оспф перестали, маршруты прозрачно построились через живой бгп). Почему не бриджом? Ну во-первых, наверное, я просто не знал, насколько хорошо бридж справляется с нагрузкой против роутера (хорошо?). Во-вторых, в приведенной схеме при использовании Шейпов как бриджей придется-таки рассказывать НАСам про фулл-вью, либо изобретать что-то другое (С iBGP, честно, никогда не игрался и пока не умею - возможно, оно там получается красивей, чем мне кажется? Поищу на почитать.). P.S> В данный момент я больше склоняюсь-таки к железячному сценарию развития. :) Изменено 17 марта, 2010 пользователем ibmed Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
ibmed Опубликовано 19 марта, 2010 (изменено) · Жалоба Сегодня переехали на новое железо и фрю. Однако.. CPU: Intel® Xeon® CPU E5420 @ 2.50GHz (2506.23-MHz K8-class CPU) Origin = "GenuineIntel" Id = 0x1067a Stepping = 10 Features=0xbfebfbff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLU SH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE> Features2=0x40ce3bd<SSE3,RSVD2,MON,DS_CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,DCA,<b19>,XSAVE> AMD Features=0x20100800<SYSCALL,NX,LM> AMD Features2=0x1<LAHF> Cores per package: 4 usable memory = 8576208896 (8178 MB) avail memory = 8250183680 (7867 MB) ACPI APIC Table: <INTEL S5000PSL> FreeBSD/SMP: Multiprocessor System Detected: 8 CPUs 7.2-RELEASE-p7 amd64 Ядро - практически GENERIC, только убрано ненужное. 2 четырехголовых Интела (em) с последним драйвером от Яндекса (<Intel® PRO/1000 Network Connection 6.9.6.Yandex[$Revision: 1.36.2.17 $]>). По одному порту на два канала. 3 порта в lacp lagg в сторону локалки. bgp# cat /boot/loader.conf vm.kmem_size=3G hw.em.rxd=4096 hw.em.txd=4096 cat /etc/sysctl.conf: net.inet.ip.fastforwarding=1 sysctl -w dev.em.2.rx_int_delay=750 sysctl -w dev.em.2.tx_int_delay=750 sysctl -w dev.em.2.rx_abs_int_delay=1000 sysctl -w dev.em.2.tx_abs_int_delay=1000 sysctl -w dev.em.3.rx_int_delay=750 sysctl -w dev.em.3.tx_int_delay=750 sysctl -w dev.em.3.rx_abs_int_delay=1000 sysctl -w dev.em.3.tx_abs_int_delay=1000 sysctl -w dev.em.7.tx_int_delay=750 sysctl -w dev.em.7.rx_int_delay=750 sysctl -w dev.em.7.rx_abs_int_delay=1000 sysctl -w dev.em.7.tx_abs_int_delay=1000 sysctl -w dev.em.8.tx_int_delay=750 sysctl -w dev.em.8.rx_int_delay=750 sysctl -w dev.em.8.rx_abs_int_delay=1000 sysctl -w dev.em.8.tx_abs_int_delay=1000 sysctl -w dev.em.9.tx_int_delay=750 sysctl -w dev.em.9.rx_int_delay=750 sysctl -w dev.em.9.rx_abs_int_delay=1000 sysctl -w dev.em.9.tx_abs_int_delay=1000 (Пробовал играться с этими показателями. Поначалу выставил все значения в 250 - нагрузка процов уже при 500kpps была порядка 50%. Поменял все значения на 500 - нагрузка мгновенно упала вдвое, без каких-либо дропов. Увеличение до 750 совсем чуть-чуть снизило нагрузку. Дальнейшее увеличение результатов не принесло и было оставлено в том виде, в котором приведено). bgp# netstat -w1 input (Total) output packets errs bytes packets errs bytes colls 850599 0 550159804 834747 0 521952924 0 850871 0 546076120 832834 0 518072008 0 861307 0 550636679 842033 0 522021955 0 860054 0 551806145 839254 0 522651924 0 858529 0 548114024 838182 0 519862948 0 864952 0 554527751 846750 0 525230852 0 855247 0 546161607 840761 0 519676813 0 (перемалывал и больше - под 1Mpp/s, почти совсем без дропов (200-500 пакетов на 950Кппс)) Но. Нагрузка по процам такая же как была на 4-ядерном железе под линуксом еще вчера. И это странно. last pid: 13429; load averages: 5.03, 4.97, 5.36 up 0+11:50:21 23:08:12 141 processes: 12 running, 115 sleeping, 14 waiting CPU 0: 0.0% user, 0.0% nice, 65.2% system, 0.0% interrupt, 34.8% idle CPU 1: 0.4% user, 0.0% nice, 65.0% system, 0.0% interrupt, 34.6% idle CPU 2: 0.0% user, 0.0% nice, 55.3% system, 0.0% interrupt, 44.7% idle CPU 3: 0.0% user, 0.0% nice, 57.1% system, 0.0% interrupt, 42.9% idle CPU 4: 0.0% user, 0.0% nice, 53.2% system, 0.0% interrupt, 46.8% idle CPU 5: 0.0% user, 0.0% nice, 50.6% system, 0.0% interrupt, 49.4% idle CPU 6: 0.0% user, 0.0% nice, 49.1% system, 0.0% interrupt, 50.9% idle CPU 7: 0.0% user, 0.0% nice, 46.8% system, 0.0% interrupt, 53.2% idle Mem: 259M Active, 58M Inact, 302M Wired, 92K Cache, 21M Buf, 7273M Free Swap: 8192M Total, 8192M Free PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMMAND 44 root 1 43 - 0K 16K CPU6 6 309:57 67.09% em3_rx_kthread_1 43 root 1 43 - 0K 16K CPU5 5 310:32 64.60% em3_rx_kthread_0 11 root 1 171 ki31 0K 16K CPU7 7 476:43 55.18% idle: cpu7 12 root 1 171 ki31 0K 16K RUN 6 472:29 51.86% idle: cpu6 13 root 1 171 ki31 0K 16K RUN 5 457:13 49.07% idle: cpu5 14 root 1 171 ki31 0K 16K CPU4 4 438:51 47.75% idle: cpu4 15 root 1 171 ki31 0K 16K CPU3 3 421:27 44.29% idle: cpu3 16 root 1 171 ki31 0K 16K CPU2 2 398:34 40.38% idle: cpu2 17 root 1 171 ki31 0K 16K CPU1 1 372:24 37.99% idle: cpu1 64 root 1 43 - 0K 16K WAIT 3 192:05 36.87% em8_rx_kthread_1 18 root 1 171 ki31 0K 16K RUN 0 356:56 36.67% idle: cpu0 63 root 1 43 - 0K 16K WAIT 3 192:23 34.08% em8_rx_kthread_0 60 root 1 43 - 0K 16K WAIT 4 192:10 33.50% em7_rx_kthread_1 42 root 1 -68 - 0K 16K CPU7 7 73:10 33.15% em3_txcleaner 59 root 1 43 - 0K 16K WAIT 4 192:23 32.18% em7_rx_kthread_0 39 root 1 43 - 0K 16K WAIT 1 197:14 31.79% em2_rx_kthread_0 40 root 1 43 - 0K 16K WAIT 2 196:49 29.98% em2_rx_kthread_1 68 root 1 43 - 0K 16K WAIT 2 128:59 22.46% em9_rx_kthread_1 67 root 1 43 - 0K 16K WAIT 0 129:15 22.17% em9_rx_kthread_0 38 root 1 -68 - 0K 16K WAIT 6 51:37 18.36% em2_txcleaner 58 root 1 -68 - 0K 16K WAIT 0 27:35 11.96% em7_txcleaner 62 root 1 -68 - 0K 16K WAIT 0 27:40 11.08% em8_txcleaner 66 root 1 -68 - 0K 16K WAIT 3 27:07 10.50% em9_txcleaner 4753 root 1 44 0 179M 172M select 1 3:46 0.00% bgpd Я ожидал увидеть как минимум 25% снижение нагрузки по графикам. В ближайшее время, возможно, попробую собрать конфигурацию на том же железе, что сейчас с фрей, но под линуксом. Если кто-то может поделиться советами по тюнингу линукса в контекст высокопроизводительного роутера - буду признателен. Изменено 19 марта, 2010 пользователем ibmed Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
ibmed Опубликовано 22 марта, 2010 · Жалоба Wingman А не покажете суммарное количество pps по интерфейсам в ЧНН? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Wingman Опубликовано 23 марта, 2010 · Жалоба Wingman А не покажете суммарное количество pps по интерфейсам в ЧНН? 1434835 Packets/s сейчас при чуть более гбит/с в обе стороны. Вообще надо было в субботу смотреть ;) в след. выходные гляну, отпишу Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
ibmed Опубликовано 23 марта, 2010 · Жалоба Wingman О как.. Получается, линукс и здесь фрю делает.. "Обидно, Вань" (с) :) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Abram Опубликовано 23 марта, 2010 · Жалоба Получается, линукс и здесь фрю делает.. "Обидно, Вань" (с) :) Кому обидно, а кто пойдет троллить BSDельников. ;) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
t0ly Опубликовано 23 марта, 2010 · Жалоба какой смысл в дровах от яндекса если у вас и так сетевух больше чем ядер? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
ibmed Опубликовано 23 марта, 2010 · Жалоба Тех, что задействовано, меньше. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Wingman Опубликовано 24 марта, 2010 (изменено) · Жалоба Wingman О как.. Получается, линукс и здесь фрю делает.. "Обидно, Вань" (с) :) 1953016 Packets/s :P И это где-то 60-70% от пиков по выходным, так что да, конкретно в этом случае - делает =)) По одному порту на два канала. 3 порта в lacp lagg в сторону локалки.Почему бы не попробовать собрать все линки (и в локалку, и от аплинков) на коммутатор, и гонять трафик на бордер в едином бонде? Так по идее нагрузка должна более равномерно распределяться. Ну и оставшиеся сетевушки задействуйте, пусть простаивающие ядра вкалываютНу и да, линух поставьте %) (ядро ванильное без левых патчей; отрубите socket security hooks - лишняя нагрузка, ну и почитайте тут на наге ветку про linux softrouter и за последние месяцы пара подобных тем была про оптимизацию, много полезного почерпнул) (P.s. при работе с линухом, conntrack, надеюсь, отрубали? 0_о) Изменено 24 марта, 2010 пользователем Wingman Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
ibmed Опубликовано 25 марта, 2010 · Жалоба Wingman Спасибо за наводки. Топики уже читаю. Не затруднит ли Вас поделиться конфигом ядра и прочими тюнингами от вашей success-story? :) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Wingman Опубликовано 25 марта, 2010 · Жалоба Wingman Спасибо за наводки. Топики уже читаю. Не затруднит ли Вас поделиться конфигом ядра и прочими тюнингами от вашей success-story? :) В личку скину Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
kapa Опубликовано 25 марта, 2010 · Жалоба Wingman Спасибо за наводки. Топики уже читаю. Не затруднит ли Вас поделиться конфигом ядра и прочими тюнингами от вашей success-story? :) В личку скину ну вот...с таким интересом следил за темой :) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...