Проблема поне засега е решен, може би не толкова елегантно но резултата е повече от добър и целта е постигната.
След като прокарах всички варианти с IPMARK и разбрах, че с моята мулти нефункционална конфигурация на мрежата нещата няма да тръгнат защото ако ползвам маска /24 мога да контролирам 99 мрежи а аз имам 139 а с маска /16 само една а аз имам 9 почти се бях отказал когато ми светна една идея. Тъй като аз имам 139 частни мрежи с маска /24 в които има 700 ип адреса които пък са твърдо зад 4 публични мрежи /24 SNAT не мога ли да огранича трафика на публичните адреси. В предишен мой пост бях показал, че информацията се грепва от текствов файл със синтаксис:
GeSHi (Bash):
lan_ip:wan_ip:speed1 # платил клиент на по ниска тарифа
lan_ip:wan_ip:speed2 # платил клиент на по висока тарифа
#lan_ip:wan_ip:spee2 # неплатил клиент (скрипта го пропуска и не създава за него правила)
След като грепвам локалните ип адреси преди първото двуеточие няма да има проблем да правя същото и след второто но този път с публичните ип адреси. И ако нещата проработят щях да спестя само в едната посока в случая download от 700 правила CLASSIFY на 4 с IPMARK което хич не е малко защото общо правилата само за марка в iptables от 1400 ще станат 704. Както вече стана ясно ограничаването на скороста на публичните адреси проработи само във веригата PREROUTING и то само в посока "към" мрежата която маркирам тоест download. Пробвах всички останали вериги за да маркирам трафика посока "от" тоест upload но iptables прихващаше само някакви kb-та. И така при създалата се ситуация аз ограничавам upload на частните адреси а download на публичните. Колкото и да звучи неправилно като решение аз изчаках два дена за да наблюдавам за аномалии но такива не се получиха. Машината омекна и след дълги наблюдения мисля, че спестих някъде около 8~10 % натоварване на CPU. В скриптово положение се получи нещо такова:
Публичните адреси - download в който имаме 4 IPMARK, 700 tc class и един tc filter
GeSHi (Bash):
tc qdisc del dev $DEV1 root
tc qdisc add dev $DEV1 root handle 1: htb default 10
tc filter add dev $DEV1 parent 1:0 protocol ip prio 1 fw
NET=93.155.130.
ID=1
iptables -A PREROUTING -t mangle -d ${NET}0/24 -j IPMARK --addr=dst --and-mask=0xff --or-mask=0x10${ID}00
IP=$(grep -v \# /etc/ipclient | grep speed1 | cut -d":" -f2 | grep ${NET} | cut -d"." -f4 | sort -nu)
for IP in $IP; do
OFFSET=$(printf "%d" 0x${ID}00)
MARK=$(printf "%x" $(($OFFSET+$IP)))
tc class add dev $DEV1 parent 1:1 classid 1:0${MARK} htb rate $SPEEDIN ceil $CEIL burst $BURSTIN
tc qdisc add dev $DEV1 parent 1:0${MARK} handle 0${MARK}: sfq perturb 10
done;
Частните адреси - upload в който имаме 700 CLASSIFY, 700 tc class
GeSHi (Bash):
tc qdisc del dev $DEV2 root
tc qdisc add dev $DEV2 root handle 1: htb default 10
ADDRESS=`grep -v \# /etc/ipclient | grep speed1 | cut -d":" -f1`;
for LANIP in $ADDRESS; do
MARK=$(grep -v \# /etc/ipclient | grep -w -n $LANIP | cut -d":" -f1)
MARKUP=$(($MARK + 1000))
iptables -t mangle -A FORWARD -s $LANIP -j CLASSIFY --set-class 1:$MARKUP
tc class add dev $DEV2 parent 1:1 classid 1:$MARKUP htb rate $SPEEDOUT burst $BURSTOUT
tc qdisc add dev $DEV2 parent 1:$MARKUP handle $MARKUP: sfq perturb 10
done;
Такааа, обаче радоста ми беше кратка защото на третата вечер пак в пиков час download 250Mbit upload 350Mbit пинга подскочи. Този път беше доста по различно като на всеки 7-8 пакета стоиноста ковеше на 4-5 msec и следваха 2-3 пакета на 16-20 msec. Ситуацията не приличаше на предишния вариант защото стоиностите тогава скачаха до 40-50 msec и така си седяха постоянно, явно имаше оптимизация на машината но не съвсем. Премахваики правилата на IPMARK и получавайки същия резултат аз разбрах, че проблема ми не е само в многото правила на iptables. Провокиран от въпроса на Vladsun за прекъсванията (благодаря за което) се заех да наблюдавам процесора с програмите top, htop и sar и с изненада открих, че при определено натоварване от четирите ядра започва да работи само едно на 100% като се сменя с друго на няколко секунди. Явно при силно натоварване ядрата нямат време да се разберат кое какво ще смята. Ратърсих се из google и попаднах на една статия от 2003 година в която един пич обясняваше, че когато асоциираш една лан карта само към едно ядро времето за отговор към ланката се увеличава. Тъй като имам един сокет и 4 физически ядра (нямам Hyper Threading)
GeSHi (Bash):
core2:~# lscpu
Architecture: x86_64
CPU op-mode(s): 32-bit, 64-bit
CPU(s): 4
Thread(s) per core: 1
Core(s) per socket: 4
CPU socket(s): 1
NUMA node(s): 1
Vendor ID: GenuineIntel
CPU family: 6
Model: 15
Stepping: 11
CPU MHz: 2394.473
Virtualization: VT-x
L1d cache: 32K
L1i cache: 32K
L2 cache: 4096K
Асоциирах всяка една лан карта лъм отделно ядро:
GeSHi (Bash):
cat /proc/interrupts
CPU0 CPU1 CPU2 CPU3
76: 2771150251 1012606526 962392960 943110592 PCI-MSI-edge eth0
77: 1244924306 1301792799 2976287726 1227333165 PCI-MSI-edge eth1
78: 75135051 92587862 75365891 74809000 PCI-MSI-edge eth2
79: 401492 390144 397369 475879 PCI-MSI-edge eth3
По следния начин най натоварените портове eth0 ще се обработват от първото ядро на процесора а eth1 от третото.
GeSHi (Bash):
echo 1 > /proc/irq/76/smp_affinity #eth0
echo 4 > /proc/irq/77/smp_affinity #eth1
echo 2 > /proc/irq/78/smp_affinity #eth2
echo 8 > /proc/irq/79/smp_affinity #eth3
И за да стане още по ефективно програмите който работят на машината ги асоциирвам към второто(в случая 1) и четвъртото(в случая 3) ненатоварени ядра:
GeSHi (Bash):
taskset -cp 1,3 820350 #apache
taskset -cp 1,3 1135433 #zebra
taskset -cp 1,3 1135437 #bgpd
taskset -cp 1,3 1323014 #squid
taskset -cp 1,3 1476645 #dnsmasq
taskset -cp 1,3 1666 #snmpd
taskset -cp 1,3 1636 #ntp
taskset -cp 1,3 3835254 #cron
Така проблема с пинга окончателно е решен макар и първото и третото ядро които обработват натоварените портове да са на 60-70 % натоварване факт е, че не съм ги виждал досега на 100% но все пак до къде ли са възможностите. Не съм забравил за човъркането в BIOS и съм го планирал за края на тази седмица. По нова година трафика малко спадна но чаквам още довечера да има пик и да видим до къде сме я докарали с тия оптимизации
С най добри пожелания за новата година и благодарности на участниците в темата.
Автор
Тема: iptables - IPMARK + tc (Прочетена 7244 пъти)
Dec 10, 2002, 23:48