Переход на более производительное оборудование или оптимизация?
Здравствуйте уважаемые. Настало время, переходить на более производительное оборудование. Есть:
софтовый роутер - Linux router 2.6.30-gentoo-r4 #2 SMP Sat Aug 15 12:56:37 MSD 2009 i686 Intel(R) Core(TM)2 Quad CPU Q9550 @ 2.83GHz GenuineIntel GNU/Linux
биллинг - net-misc/utm5-2.1.007
машина выполняет так же функцию основного маршрутизатора в сети. В пиках на внешнем интерфейсе загрузка свыше 250 mbit/sec, на внутреннем свыше 350 mbit/sec.
В результате в пиках появляет ошибки на интерфейсах, теряются пакеты и проч. Загрузка ЦП ~ 40-60%
Собираемся переложить функции маршрутизации на cisco 3550, может кто имел опыт перехода и поведает на какие грабли не надо наступать, плюсы и минусы и тд и тп.
Есть вариант с оптимизацией: в данный момент авторизованные юзеры (более 1500) получают нужный маршрут тем самым поучают доступ к сети, то есть для каждого пользователя создаётся правило вида ip rule add from $IP table $table, из-за изначальной кривой топологии сразу не сделали iptables -A FORWARD -s $IP -j ACCEPT. Уменьшит ли нагрузку на сервер данный вид топологии?
Значения sysctl:
echo 1024000 > /proc/sys/net/ipv4/netfilter/ip_conntrack_max
echo 4096 87380 16777216 > /proc/sys/net/ipv4/tcp_rmem
echo 4096 65536 16777216 > /proc/sys/net/ipv4/tcp_wmem
echo 98304 131072 196608 > /proc/sys/net/ipv4/tcp_mem
echo 3500 > /proc/sys/net/core/netdev_max_backlog
Может кто-нибудь посоветует более производительный вариант? Спасибо!
- Для комментирования войдите или зарегистрируйтесь
Не знаю как с циско. Я
Не знаю как с циско.
Я когда-то видел сеть, где свитчи были циско и там запускали vmps и людей просто в нужные vlanы кидали.
По поводу производительности.
Как можне сильнее порезать файрвол на таблички чтоб каждый пакиет проходил как можно меньше правил. Это отгрузит процессор.
Рутинг порезаный на таблички к сожалению не является хорошей идеей лучше резать людей на iptables. Ну или еще лучше по возможности на свитчах.
Такие рутера как 3550 это немного старовато и не удевитесь, если он будет терять пакетов больше чем линукс. Если решитесь, на него, то так и так надо думать над минимальной табличкой рутинга. И каким-нибудь порт монитором, чтоб все пакеты так и так на какой-нибудь линукс бросать и там в них смотреть.
Если есть возможность, дописать рутеру статическую табличку арпов с маками клиентов, то это тоже поможет.
И последнее (то с чего я хотел начать) обновите ядро. Я видел чудеса с уменьшениями потерь пакетов na 90%.
Порезать сеть на меньшие сегменты, чтоб не добивать рутера броадкастами.
П.С. Сама по себе загрузка процессора при такой нагрузке это нормально. Страшны потери.
свыше 250 mbit/sec, на
это ни о чем не говорит. pps и модели сетевых озвучьте.
ой ли :), толко маршрутизация и ничего больше ?
Compute:
Bosch M2.8.1 -> custom Bosch M2.8.3 clone from Russia.
Speed about 260 km,Ram 2 pers.,HDD - 70 kg,210 FLOPS ;)
1. Ethernet controller: Intel
1. Ethernet controller: Intel Corporation 82573L Gigabit Ethernet Controller
2. Маршрутизация и сбор данных о трафике(сейчас используется ядро биллинга + ipcad).
Вообщем ситуация нерадостная, после очередного повышения тарифов сеть почти "лежит", надо принимать решение. Посоветуйте модель cisco для реализации данной задачи.
Я просил и pps то же
Я просил и pps то же показать. До кучи - ethtool -S для внутренней сетевой
Compute:
Bosch M2.8.1 -> custom Bosch M2.8.3 clone from Russia.
Speed about 260 km,Ram 2 pers.,HDD - 70 kg,210 FLOPS ;)
slepnoga написал(а): Я просил
ethtool -S eth1
NIC statistics:
rx_packets: 13047509621
tx_packets: 13615039000
rx_bytes: 9518295177475
tx_bytes: 12009092955332
rx_broadcast: 10165432
tx_broadcast: 5426877
rx_multicast: 231
tx_multicast: 0
rx_errors: 0
tx_errors: 0
tx_dropped: 0
multicast: 231
collisions: 0
rx_length_errors: 0
rx_over_errors: 0
rx_crc_errors: 0
rx_frame_errors: 0
rx_no_buffer_count: 89160360
rx_missed_errors: 30673032
tx_aborted_errors: 0
tx_carrier_errors: 0
tx_fifo_errors: 0
tx_heartbeat_errors: 0
tx_window_errors: 0
tx_abort_late_coll: 0
tx_deferred_ok: 0
tx_single_coll_ok: 0
tx_multi_coll_ok: 0
tx_timeout_count: 0
tx_restart_queue: 3
rx_long_length_errors: 0
rx_short_length_errors: 0
rx_align_errors: 0
tx_tcp_seg_good: 97182
tx_tcp_seg_failed: 0
rx_flow_control_xon: 0
rx_flow_control_xoff: 0
tx_flow_control_xon: 0
tx_flow_control_xoff: 0
rx_long_byte_count: 9518295177475
rx_csum_offload_good: 12495761565
rx_csum_offload_errors: 262794
rx_header_split: 0
alloc_rx_buff_failed: 0
tx_smbus: 0
rx_smbus: 0
dropped_smbus: 0
rx_dma_failed: 0
tx_dma_failed: 0
1. 64 бит 2. поменять
1. 64 бит
2. поменять сетевухи на что-нибудь более достойное (например, Intel Gigabit, хотя бы десктопные которые)
P.S.: Linux - это красная таблетка :-) Windows - синяя...
Aladdin написал(а): 1. 64
1. нельзя. utm5 бывает 32 битный, на 64 битной архитектуре будет работать с глюками
2.
Уже говорили - выкинь биллинг
Уже говорили - выкинь биллинг совсем с этой машины
Compute:
Bosch M2.8.1 -> custom Bosch M2.8.3 clone from Russia.
Speed about 260 km,Ram 2 pers.,HDD - 70 kg,210 FLOPS ;)
Правильно подобранная циска
Правильно подобранная циска это хорошо. Граблей же в сетевом деле много. Ну во первых есть случаи от которых циска не спасет, потому что не в ней дело.
К примеру у вас наружу точно гигабит? Неплохо былоб проверить, iperf вам в помощь. Может кто что еще посоветует. В том что вам плохо может быть виноват и провайдер (потери на внешнем). Задержечки посмотреть трейспасом, соединения проверить, свичи опять жеж косячить могут (потери на внутреннем).
Есть еще одно нескромное предположение. А поделим ка гигабит тупо по более 1500 юзерам. Получается в районе менее 700 килобит на брата. Это ежели они вежливые и любят поровну делиться :). Ежели хотя бы у 10 юзеров совести нет (что не исключено), то какой нить торрент легко заберет канал, оставив остальных участников процесса с песочными часами вместо нета (что впринципе верно, ибо нефиг вендузятникам в сети делать :)). Судя по поверхностному описанию проблемы, полоса у Вас не нарезана. В принципе ежели при таком положении вещей с циской так же поступить, то есть вариант потратить пару тройку килобаксов на тот же результат. А начальство этого не очень любит.
Карточки мегабитные, нагружены на треть. Подозрительно как то. Мой любимый файловик 900 отдает легко, при более скромном железе. Что с памятью? Как диски нагружены? Что top говорит по поводу iowait ? Неплохо былоб некий мониторинг организовать местными средствами, потому как по сети на рутер в пике не пролезешь.
Ну и еще с цисками засада. Потому как доткнуть нечто внутрь, или навесить непредусмотренный функционал будет проблематично, а при неправильном выборе и невозможно. ИМХО Лучше поискать в нете сборище цискарей.
ЗЫ
Пусть меня щаз забросают старыми цисками, ну не верю я, что "жалкая" поделка в 60 килобаксов со сравниммым по потреблению с атомом процом при должном подходе уложит полноценный квад. Для этого надо как минимум килобаксов под сто.
Циски берут не из за
Циски берут не из за производительности, а из за фичь - КО.
По каким параметрам ? :)
Для топикстратера - если у вас в конторе нету певца по имени Цискаридзе :), то эта железка не для вас.Вам наверно некто с красно-голубыми глазами спел песню - "я фанат, циско - магический девайс, решает все вопрпы сам " ?
Алсо, пока у нас тут безпредметный разговор с попыткой телепатии. Давай по порядку:
список демонов на серваке, схему сети ( как, откуда, сколько приходит на сервак, какой свитч и где, что на доступе, пров или нет,), наличи шейпинга/полисинга,
разкидку софтирков по ядрам, топ в моменты дропа. Если есть ( что врядле, как я понимаю) профиль траффика по приложениям.
Выдай хотя бы это - там бум посмотреть
Compute:
Bosch M2.8.1 -> custom Bosch M2.8.3 clone from Russia.
Speed about 260 km,Ram 2 pers.,HDD - 70 kg,210 FLOPS ;)
gebs написал(а):echo 1024000
Где-то читал, что это значение должно быть степенью двойки. Менять значение только если в этом есть необходимость.
По существу, не имея никаких существенных данных - менять сетеывые на базе Intel 82576. И разность нагрузку на разные машины. Уберите для начала с этого сервера биллинг и его базу. Сбор трафика перенесите на ipt_netflow - он грузит систему гораздо меньше ipcad.
Нащяльника, мая сервира паставиль, фрибизьдя инсталя сделаль, апачи сабраль, пыхапе патключиль, сапускаю, а ано - ажамбех пашамбе эшельбе шайтанама!
у меня была проблема с
у меня была проблема с "Большой нагрузкой" ограничение скоростей пользователям делали? если да то как?
Спасибо откликнувшимся, пошёл
Спасибо откликнувшимся, пошёл разгребать предложения.
_passer написал(а): gebs
По опыту IPCAD более менее честно считает, а предложенный Вами вариант?
Сравнивайте. Я после подбора
Сравнивайте. Я после подбора размера буфера и хэша - никаких проблем не имел и сильно порадовался уменьшению загрузки процессора.
Нащяльника, мая сервира паставиль, фрибизьдя инсталя сделаль, апачи сабраль, пыхапе патключиль, сапускаю, а ано - ажамбех пашамбе эшельбе шайтанама!
gebs написал(а): По опыту
ipt_netflow тоже считает честно - юзаю и то и другое, но у него есть существенный минус: собирается и стабильно работает только на ядрах =< 2.6.29 (на 2.6.30 собирается, но при выпадает в segfault при попытке выгрузить модуль да и при работе периодически, причем повторно модуль после этого уже не загрузишь - виснет). ipcad при правильной настройке систему грузит не более чем ipt_netflow, нужно просто повесить его на ulog а в iptables добавить соответствующие правила (если интересно - могу рассказать подробнее)
сори, из за глюка ngnix
сори, из за глюка ngnix мессага запостилась дважды. просьба это сообщение удалить
_Andrey написал(а): сори, из
И ты тоже считаешь это глюком nginx - ну-ну... стыдно должно быть писать такое, разберись в том что такое nginx.
Agressor написал(а): И ты
Ну хорошо, хорошо, не ngnix это глюк а php... Сори, просто лень было разбираться :) но ngnix тоже мог бы и по понятней проблему описать :-P
P.S. Сори за оффтоп, умолкаю...