Перейти к содержимому
Калькуляторы

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

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

 

У нашей организации есть некоторое количество абонентов, для которых требуется делать эту замечательную фильтрацию. Пиковый трафик 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.

 

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

 

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

 

14all.cgi.png

 

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

 

Снимок экрана от 2012-12-19 14:48:26.png

 

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

 

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

Изменено пользователем dignity

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

 

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

 

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

Изменено пользователем dignity

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

 

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

Изменено пользователем dignity

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

dignity

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Изменено пользователем ichthyandr

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Трафик HTTP 2.5G?

 

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

Изменено пользователем dignity

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Трафик HTTP 2.5G?

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

 

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

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

 

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

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

Изменено пользователем [anp/hsw]

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

не, суммарный, думаю процентов 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 в сутки.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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, хотя соотношение запись/чтение близко к стандартному).

Изменено пользователем [anp/hsw]

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

 

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

 

' timestamp='1355990168' post=788468]

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

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

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

 

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

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

 

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

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

Изменено пользователем [anp/hsw]

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

 

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

Изменено пользователем dignity

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

/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 играться, или ставить более оптимизированую ФС.

Изменено пользователем [anp/hsw]

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Гость
Ответить в тему...

×   Вставлено в виде отформатированного текста.   Вставить в виде обычного текста

  Разрешено не более 75 смайлов.

×   Ваша ссылка была автоматически встроена.   Отобразить как ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставить изображения напрямую. Загрузите или вставьте изображения по ссылке.