[dignity]

В общем, решил поделиться с раздумывающими операторами на тему фильтрации.

 

У нашей организации есть некоторое количество абонентов, для которых требуется делать эту замечательную фильтрацию. Пиковый трафик HTTP по вечерам ~ 160 Mbit/s, абонентов в сети в час пик ~ 900 человек. Мы уже достаточно давно смотрим на системы кэширования, а в последнее время нашли возможность их практического использования. Итак, что хотим:

 

1) фильтровать роскомнадзоровский список

2) кэшировать контент для снижения нагрузки на аплинк + уменьшения времени отклика

 

Делаем с помощью: Squid3 + tproxy

 

Надо сказать, что эксперимент этот не первый, мы и раньше пытались внедрять это решение. Упирались в производительность HDD по IOPS.

 

Платформа: Xeon E3-1230, 16GB RAM, 2 x SSD Intel 520 MLC 240GB, сетевушка Intel обыкновенная встроенная =), есть необыкновенная, но мы не заморачиваемся, так как трафика мало. Живет система на 1й сетевой в одном VLAN, поднято 2 /30 сети.

 

Примечание по Squid: используем версию 3, которая однопоточная, можно заюзать многопоточный 3.2 что позволит поднять производительность кратно количеству ядер. Нам не требуется.

 

TPROXY - сравнительно новый механизм, который позволяет работать Squid полностью прозрачно от IP проходящего трафика. Поддерживается ядром Linux версий 2.6.37+, в результате у пользователя не возникает возможности понять что он за прокси, например, 2ip показывает ip пользователя и т.п.

 

Настройка Squid:

- 2 дисковых кэша, каждый на своем SSD, размером 170 GB каждый.

- маленький RAM-кэш, поскольку для Squid лучше, чтобы буферный кэш был побольше, что по сути эквивалентно большому RAM кэшу.

- учет клиентов выключен

 

Трафик: трафик на этот узел заворачивается через PBR с чего хотите, мы делали и с коммутатора С6509/Sup2, сейчас просто заворачиваем с шейпера входящий, с NAS исходящий на 80 порт. Мы решили, что хотим, чтобы наши пользователи получали данные из кэша мимо шейпера на максимальной скорости, поэтому такая топология.

 

Результаты:

кэш - SSD отлично вывозят высокие IOPS, что и требуется для данного решения.

CPU - загрузка около 50% одного ядра Xeon в пике.

 

После первичной настройки нас в первый же день завалили участники ботнета, наши же =) абоненты. Пришлось докрутить следующие настройки:

 

iptables -A INPUT -i eth1.3 -p tcp -m tcp --dport 80 -m state --state NEW -m recent --update --seconds 5 --hitcount 200 --name httpdos --rsource -j LOG --log-prefix "FILTERTRAP "

iptables -A INPUT -i eth1.3 -p tcp -m tcp --dport 80 -m state --state NEW -m recent --update --seconds 5 --hitcount 200 --name httpdos --rsource -j DROP

iptables -A INPUT -i eth1.3 -p tcp -m tcp --dport 80 -m state --state NEW -m recent --set --name httpdos --rsource

 

Что получили:

1) защитили Squid от перегруза.

2) удалили из сети нескольких перепродаванов, которые передают трафик на целые подсети.

3) нейтрализовали часть своих DoS-еров по HTTP.

 

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

 

Вот картинка по трафику:

 

 

Вот картинка по cachemgr.cgi

 

 

Надеюсь, что кому-то будет полезно. По моим оценкам, потенциал вышеуказанной платформы ~ 800 Мбит трафика (при многоядерном Squid).

 

Для фильтрации контента сделаны два ACL по IP и по URL regex.

Edited December 19, 2012 by dignity

[orlik]

Спасибо , довольно интересно и познавательно, а не поделитесь ли конфигом от squid ?

Также инетресует вопрос , а кешируется ли youtube,windowsupdate и прочая гадость которая по умолчанию не кешируется ?

[dignity]

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

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

 

Забыл написать, что на этом же узле стоит кэширующий DNS pdns-recursor. Кстати, возник еще один сайд-эффект, на аплинке трафик стал более "гладким", уменьшились скачки.

 

В качестве развития платформы можно рассмотреть перехват торрентов и локальный кэш торрента.

Edited December 19, 2012 by dignity

[Merridius]

Почему вы не воспользовались WCCPv2?

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

[dignity]

Cisco не рекомендует WCCPv2 на больших потоках трафика, по крайней мере для платформы 6500 - это раз. Во вторых, по краям стоят linux, а не WCCPv2-enabled железки. В третьих, зачем?

 

Про продаванов: Ну покупает абонент тариф и раздает его на друзей/продает (в общагах, например или для офиса).

Edited December 19, 2012 by dignity

[Nag]

Может это, напишешь статью для сайта? :-)

[dignity]

Могу попробовать.

[biox]

dignity

Респект тебе и уважуха.

Сами сейчас то же на squid+tproxy запускаем, подзастряли на этапе связки с Mikrotik.

[[anp/hsw]]

SSD бы всетаки я не советовал - протрет в нем дыры меньше, чем за 3 месяца.

Более живучими оказались 4шт SAS винтов 147Gx15K. Уже третий год работают.

 

Хотя, покажите iostat, может и правда, SSD там только и место.

[dignity]

250 GB записывается в день суммарно на оба, то есть по 125GB на 1 штуку, соответственно,

если брать даже 1000 циклов перезаписи ячейки, хотя на MLC 5000, если мне не изменяет склероз (пусть так), то получим не меньше 1000 дней срока эксплуатации на текущем трафике.

[ichthyandr]

познавательно, вот только что делать, если абонентов в пике >4000 и трафик 2.5G ...

Edited December 20, 2012 by ichthyandr

[dignity]

Трафик HTTP 2.5G?

 

2-3 платформы как у меня с разбросом по SRC-DST IP или другой политике, как вам нравится + Squid 3.2 (многопоточный)?

Edited December 20, 2012 by dignity

[ichthyandr]

Трафик HTTP 2.5G?

не, суммарный, думаю процентов 25% http (не замерял)

[[anp/hsw]]

250 GB записывается в день суммарно на оба, то есть по 125GB на 1 штуку, соответственно,

 

Вы не шутите? Или имеется ввиду запись "с нуля", а не работа на заполненом хранилище?

Просто не соотносится размер хранилища с интенсивностью записи на ваших скриншотах.

 

Сколько со сквидом работаю, не видел еще такого.

Это вызывает больший интерес посмотреть вывод вашей команды iostat :)

Edited December 20, 2012 by [anp/hsw]

[dignity]

не, суммарный, думаю процентов 25% http (не замерял)

все выше я писал только про http.

------------

root@http-filter-1:~# uptime

14:27:55 up 6 days, 23:24, 2 users, load average: 0.56, 0.88, 0.89

 

------------

root@http-filter-1:~# iostat -zm /dev/sd{c,d}

Linux 2.6.32-5-amd64 (http-filter-1) 20.12.2012 _x86_64_ (8 CPU)

 

avg-cpu: %user %nice %system %iowait %steal %idle

1,43 0,00 2,32 0,41 0,00 95,85

 

Device: tps MB_read/s MB_wrtn/s MB_read MB_wrtn

sdc 108,15 0,44 1,25 266096 752884

sdd 108,11 0,45 1,25 268504 751456

 

------------

root@http-filter-1:~# iostat -zm 60 /dev/sd{c,d}

Linux 2.6.32-5-amd64 (http-filter-1) 20.12.2012 _x86_64_ (8 CPU)

 

avg-cpu: %user %nice %system %iowait %steal %idle

1,43 0,00 2,32 0,41 0,00 95,85

 

Device: tps MB_read/s MB_wrtn/s MB_read MB_wrtn

sdc 108,16 0,44 1,25 266153 753103

sdd 108,11 0,45 1,25 268554 751510

 

avg-cpu: %user %nice %system %iowait %steal %idle

1,59 0,00 3,17 0,51 0,00 94,74

 

Device: tps MB_read/s MB_wrtn/s MB_read MB_wrtn

sdc 146,42 0,39 1,87 23 112

sdd 137,35 0,81 1,68 48 100

------------

100MB x 60 x 24 = 144000MB в сутки.

[Ivan_83]

После первичной настройки нас в первый же день завалили участники ботнета, наши же =) абоненты. Пришлось докрутить следующие настройки

В браузере сотни две-три вкладок, браузер рестар... и?

[[anp/hsw]]

Device: tps MB_read/s MB_wrtn/s MB_read MB_wrtn

sdc 146,42 0,39 1,87 23 112

sdd 137,35 0,81 1,68 48 100

 

Действительно, похоже на нормальную работу.

Но советую вам поиграться с cache_replacement_policy и minimum_object_size, дабы все-таки снизить нагрузку на диски (по идее она должна быть в 3-4 раза меньше на таком request rate, хотя соотношение запись/чтение близко к стандартному).

Edited December 20, 2012 by [anp/hsw]

[dignity]

После первичной настройки нас в первый же день завалили участники ботнета, наши же =) абоненты. Пришлось докрутить следующие настройки

В браузере сотни две-три вкладок, браузер рестар... и?

 

Потенциально - да, по факту, ни одного обращения не было.

 

' timestamp='1355990168' post=788468]

Действительно, похоже на нормальную работу.

Но советую вам поиграться с cache_replacement_policy и minimum_object_size, дабы все-таки снизить нагрузку на диски (по идее она должна быть в 3-4 раза меньше на таком request rate, хотя соотношение запись/чтение близко к стандартному).

 

Я вот специально игрался чтобы именно эти параметры кэширования настроить)

[[anp/hsw]]

Я вот специально игрался чтобы именно эти параметры кэширования настроить)

 

И все равно мне не дают покоя ваши объемы IO, но не думаю, что трафик у вас какой-то особенный.

Даже делая поправку на mean object size в 60кб (обычно он близок к 30-40) - это, допустим, 1.5-2 увеличение объемов IO.

 

Но куда делась еще двухкратная разница?

На ум приходит оверхед от журналирования фс, но я надеюсь, у вас хотя бы data=writeback, а то и вообще reiserfs/xfs затюненая?

Edited December 20, 2012 by [anp/hsw]

[dignity]

Честно, мне не шибко интересно это выяснять...

 

cache_mem 256 MB

maximum_object_size_in_memory 128 KB

cache_replacement_policy heap LFUDA

cache_dir aufs /mnt/ssd1/cache 170000 128 128

cache_dir aufs /mnt/ssd2/cache 170000 128 128

minimum_object_size 0 KB

maximum_object_size 65536 KB

cache_swap_low 98

cache_swap_high 99

 

 

/dev/sdc1 /mnt/ssd1 ext4 defaults,relatime,discard 0 2

/dev/sdd1 /mnt/ssd2 ext4 defaults,relatime,discard 0 2

Edited December 20, 2012 by dignity

[[anp/hsw]]

/dev/sdc1 /mnt/ssd1 ext4 defaults,relatime,discard 0 2

/dev/sdd1 /mnt/ssd2 ext4 defaults,relatime,discard 0 2

 

Да. Вот тут все собака зарыта. Хотя я в нюансах работы ext4 на ssd не искушен, может там и правда reatime (а это ведь практически sync) ничуть не хуже чем data=writeback по скорости.

Но независимо от ФС будут полезны сквиду эти опции - noatime,nodiratime

 

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

 

//

Спутал realtime и relatime - новая опция, собственно и содержит noatime/nodiratime. Тогда только с data=writeback играться, или ставить более оптимизированую ФС.

Edited December 20, 2012 by [anp/hsw]

[optimous]

2) кэшировать контент для снижения нагрузки на аплинк

А есть ли какие-то конкретные цифры по снижению ?

[dignity]

на картинках все нарисовано.

[KPOXA.NET]

Стоят SSD на кешах Squid в 12 серверах, работают больше года, сомневаюсь, что в ближайшее время будут выходить из строя. Использую Intel 320 серии, в последнее время перешел на 520. SSD на 300 Гб используется полностью под кэш, в среднем используется 90% места.

[catalist]

Мы тоже недавно запустили подобную систему как у ТС, тока по WCCP. В целом довольны.

В ходе тестирования выяснилось что многокотоковая версия сквида глючит.

Трафик у нас примерно такой же.

Сделали немного хитрей, на SAS диск поставили систему, для логов и прочего, а на ссд своп, и кеш. Диски по 300 гигов.