Доброго времени.
RHEL 6.0, squid 3.1.20, winbind из пакета samba 3.6.8.Количество пользователей ок. 1500, канал 60Мбит. Для аутентификации юзеров используется связка winbind+AD.
Примерно при такой нагрузке
SqStat: 1360 users and 3381 connections
netstat -ant| awk '{print $4}'|grep '.8080'|wc -l
11079top - 16:05:11 up 11 days, 17:48, 3 users, load average: 0.41, 0.45, 0.39
Tasks: 1385 total, 2 running, 1383 sleeping, 0 stopped, 0 zombie
Cpu(s): 8.1%us, 4.0%sy, 0.0%ni, 86.0%id, 0.1%wa, 0.2%hi, 1.7%si, 0.0%st
Mem: 8062044k total, 7067616k used, 994428k free, 574564k buffers
Swap: 1691640k total, 40848k used, 1650792k free, 3126468k cachedPID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
23589 squid 20 0 729m 524m 3800 R 84.6 6.7 100:21.87 squid
26741 root 20 0 242m 53m 24m S 20.7 0.7 12:43.91 winbindd
26743 root 20 0 221m 34m 28m S 9.2 0.4 5:55.48 winbindd
Смотрю squidclient -p 8080 mgr:ntlmauthenticator. Вижу, что все 1100 хелперов могут быть заняты или очень большое время аутентификации из за которого Инет работает очень медленно.На контроллер домена грешу в последнюю очередь. Т.к. другой проксик, настроенный на этот же КД работает шустро.
У кого сквид работает при таком количестве юзеров, есть ли такие тормоза. Или кто то может подсказать\посоветовать как можно улучшить работу проксика.
>[оверквотинг удален]
> 26743 root 20 0
> 221m 34m 28m S 9.2 0.4
> 5:55.48 winbindd
> Смотрю squidclient -p 8080 mgr:ntlmauthenticator. Вижу, что все 1100 хелперов могут быть
> заняты или очень большое время аутентификации из за которого Инет работает
> очень медленно.
> На контроллер домена грешу в последнюю очередь. Т.к. другой проксик, настроенный на
> этот же КД работает шустро.
> У кого сквид работает при таком количестве юзеров, есть ли такие тормоза.
> Или кто то может подсказать\посоветовать как можно улучшить работу проксика.Если вы так уверены что сквид не упирается в таймауты или еще во что-то в АД, то не зайти ли с другой стороны и сделать балансировку т.е несколько прокси серверов?
>[оверквотинг удален]
>> Смотрю squidclient -p 8080 mgr:ntlmauthenticator. Вижу, что все 1100 хелперов могут быть
>> заняты или очень большое время аутентификации из за которого Инет работает
>> очень медленно.
>> На контроллер домена грешу в последнюю очередь. Т.к. другой проксик, настроенный на
>> этот же КД работает шустро.
>> У кого сквид работает при таком количестве юзеров, есть ли такие тормоза.
>> Или кто то может подсказать\посоветовать как можно улучшить работу проксика.
> Если вы так уверены что сквид не упирается в таймауты или еще
> во что-то в АД, то не зайти ли с другой стороны
> и сделать балансировку т.е несколько прокси серверов?Очень интересно посмотреть на ваш конфиг squid-a
>[оверквотинг удален]
> 26743 root 20 0
> 221m 34m 28m S 9.2 0.4
> 5:55.48 winbindd
> Смотрю squidclient -p 8080 mgr:ntlmauthenticator. Вижу, что все 1100 хелперов могут быть
> заняты или очень большое время аутентификации из за которого Инет работает
> очень медленно.
> На контроллер домена грешу в последнюю очередь. Т.к. другой проксик, настроенный на
> этот же КД работает шустро.
> У кого сквид работает при таком количестве юзеров, есть ли такие тормоза.
> Или кто то может подсказать\посоветовать как можно улучшить работу проксика.Покажите ваш конфиг squid-a
> Покажите ваш конфиг squid-aПожалуйста:
cache_peer 10.168.62.254 parent 8080 0 no-query no-digest
cache_peer 10.9.1.11 parent 8080 0 no-query no-digestauth_param ntlm program /usr/bin/ntlm_auth -s /etc/samba/smb.conf --helper-protocol=squid-2.5-ntlmssp --domain=USB.ROOT.LC --require-membership-of="usb.root.lc+grp.all.internet"
auth_param ntlm children 1100
auth_param ntlm keep_alive on
authenticate_cache_garbage_interval 1 hour
authenticate_ttl 1 hourauth_param basic program /usr/bin/ntlm_auth -s /etc/samba/smb.conf --helper-protocol=squid-2.5-basic --domain=USB.ROOT.LC --require-membership-of="usb.root.lc+grp.all.internet"
auth_param basic children 30
auth_param basic credentialsttl 20 minute
auth_param basic casesensitive offacl manager proto cache_object
acl localhost src 127.0.0.1/32 ::1
acl to_localhost dst 127.0.0.0/8 0.0.0.0/32 ::1acl wsus_srv src 192.168.8.113/32
acl deloyt_temp src 192.168.252.0/24
acl deloyt_temp src 192.168.66.0/24
acl wsus_srv src 192.168.8.234/32
acl wsus_srv src 192.168.67.99/32acl ftp_port port 21
acl SSL_ports port 563 8443
acl Safe_ports port 80 # http
acl Safe_ports port 443 # https
acl Safe_ports port 70 # gopher
acl Safe_ports port 210 # wais
acl Safe_ports port 1025-7999
acl radio_port port 8000
acl Safe_ports port 8001-65535 # unregistered ports
acl Safe_ports port 280 # http-mgmt
acl Safe_ports port 488 # gss-http
acl Safe_ports port 591 # filemaker
acl Safe_ports port 777 # multiling http
acl CONNECT method CONNECThttp_access allow manager localhost
http_access deny manager
http_access allow localhosthttp_access allow CONNECT SSL_ports Safe_ports
acl inet_users proxy_auth REQUIRED
acl magic_usb1 url_regex -i "/etc/squid/acl/nopassword.txt"
acl deny_rep_mime_flashvideo rep_mime_type ^audio/x-scpls
acl deny_rep_mime_flashvideo rep_mime_type ^video/x-flv
acl deny_rep_mime_flashvideo rep_mime_type ^audio/mpeg
acl deny_rep_mime_flashvideo rep_mime_type ^video/x-ms-asf
acl deny_rep_mime_flashvideo rep_mime_type ^application/vnd.ms.wms-hdr.asfv1
acl deny_rep_mime_flashvideo rep_mime_type ^application/x-fcs
acl deny_rep_mime_flashvideo rep_mime_type ^audio/x-mp3
acl deny_rep_mime_flashvideo rep_mime_type ^audio/aacpacl no_acces url_regex "/etc/squid/acl/ban_site.txt"
acl denyintime url_regex "/etc/squid/acl/time.txt"acl italia url_regex "/etc/squid/acl/italia.txt"
acl italia_10.9.1.11 url_regex "/etc/squid/acl/italia_10.9.1.11.txt"acl bad_media_workers proxy_auth "/etc/squid/acl/bad_media_workers.txt"
acl good_workers proxy_auth "/etc/squid/acl/good_workers.txt"
acl deny_user proxy_auth 032-gordonov 032-semenchukav 18-huzeevdv
acl ban_from_local dst 192.168.4.1
acl ban_from_local dst 192.168.4.128
acl ban_from_local dst 10.178.34.61http_access allow magic_usb1
http_access allow wsus_srv
http_access deny radio_port
http_access deny ban_from_localhttp_access deny deny_user
http_access deny deloyt_temp denyintime
http_access allow deloyt_temphttp_access allow good_workers ftp_port
http_access deny ftp_porthttp_reply_access deny deny_rep_mime_flashvideo bad_media_workers
http_access allow good_workers denyintime
http_access deny denyintime
http_access deny no_acces
http_access allow inet_userscache_peer_access 10.168.62.254 allow italia
cache_peer_access 10.9.1.11 allow italia_10.9.1.11http_access deny all
http_port 8080
ftp_user squid@yahoo.com
ftp_passive onnever_direct allow italia
never_direct allow italia_10.9.1.11hierarchy_stoplist cgi-bin ?
cache_dir ufs /squid/cache 1024 16 256
coredump_dir /squid/cache
cache_access_log /squid/logs/access.log
cache_log /squid/logs/cache.log
cache_store_log /dev/nulllogfile_rotate 2
debug_options ALL,1 rotate=2
cache_effective_user squid
cache_effective_group squid
cache_mem 512 MB
cache_swap_low 70
cache_swap_high 90
maximum_object_size 8192 KB
minimum_object_size 8 KB
maximum_object_size_in_memory 16 KBmemory_pools off
memory_pools_limit 30 MBclient_db off
quick_abort_min 0 KB
quick_abort_max 0 KBsnmp_port 3401
acl SNMP_acl snmp_community public
snmp_access allow SNMP_acl localhost
snmp_access deny allhalf_closed_clients off
refresh_pattern ^ftp: &n... 1440 20% 10080
refresh_pattern ^gopher: 1440 0% 1440
refresh_pattern -i (/cgi-bin/|\?) 0 0% 0
refresh_pattern -i onegate.unicreditgroup.eu/. 3600 100% 3600
refresh_pattern . 0 20% 4320sleep_after_fork 10000
max_filedescriptors 16384
>[оверквотинг удален]
> 0% 1440
> refresh_pattern -i (/cgi-bin/|\?) 0 0%
> 0
> refresh_pattern -i onegate.unicreditgroup.eu/.
> 3600 100% 3600
> refresh_pattern .
> 0
> 20% 4320
> sleep_after_fork 10000
> max_filedescriptors 16384Когда-то была похожая ситуация, при подобных настройках, узким местом в этой связке выступал один из нагруженных серверов Active Directory. В вашем случае может оказаться не только сервер АД узким местом но и Samba сервер, которая может давать о себе знать. Большое количество занятых хелперов, єто признак медленной работы сервера авторизации, но вот от кого именно, Samba или AD, вам предстоит выяснить. Для начала сравните настройки Samba с двух прокси серверов, посмотрите разницу. После попробуйте посмотреть какие сервера АД используют оба сервера Прокси. Важно выяснить на каком этапе происходит задержка ответа авторизации.
В моем случае, в подобных ситуации, я отказался от такой авторизации и начал использовать Kerberos_auth. Даже 20-и хелперов более чем достаточно, как оказалось. Кроме того отпала необходимость использовать samba-сервер. Для авторизации программ и броузеров, которые не умеют использовать Kerberos, параллельно было запущено 5 хелперов LDAP_auth. В таком на устройствах где нет возможности произвести произвести Kerberos авторизацию, выскакивает окно с возможностью ввести имя пользователя и пароль.
Данная система, успешно работает долгое время на подобных нагрузках (1000-1500 клиентов).
>Важно выяснить на каком этапе происходит задержка
> ответа авторизации.В том то и дело, что оба проксика настроены на один контроллер. Проксик, который работает без нагрузки отдает страницы быстро, без задержек. =>тормозит Samba.
Насколько помнится LDAP_auth не поддерживает авторизацию по вложенным группам?
>>Важно выяснить на каком этапе происходит задержка
>> ответа авторизации.
> В том то и дело, что оба проксика настроены на один контроллер.
> Проксик, который работает без нагрузки отдает страницы быстро, без задержек. =>тормозит
> Samba.
> Насколько помнится LDAP_auth не поддерживает авторизацию по вложенным группам?Не совсем так, squid имеет достаточно хороший арсенал для авторизации.
Ниже не полный список всех возможных хелперов.FreeBSD# ls /usr/local/libexec/squid/
cachemgr.cgi ntlm_auth squid_ldap_group
digest_ldap_auth pam_auth squid_radius_auth
digest_pw_auth smb_auth squid_session
diskd smb_auth.sh squid_unix_group
ip_user_check squid_db_auth unlinkd
msnt_auth squid_kerb_auth wbinfo_group.pl
ncsa_auth squid_ldap_authsquid_ldap_group - вот то что вам нужно, если вам необходимо проверять принадлежность к группе. Насколько я помню, есть и другие подобные схемы, но для того чтобы они появились, необходимо пересобирать squid с дополнительными опциями.
С другой стороны, проверять принадлежность к группам, вы можете оставить и через samba. Таким образом вы снизите на нее нагрузку.
Из моего опыта, самая быстрая схема авторизации это squid_kerb_auth. Кроме того, одна из безопасных, в случае перехвата трафика с целью заполучить учетные данные.
Благодарю откликнувшихся.
Андрей,вопрос к вам. Точнее уточнение.Я писал:
> Насколько помнится LDAP_auth не поддерживает авторизацию по вложенным группам?Имел ввиду, что у меня Инетовские юзера лежат в группе вида grp.XX.internet, где ХХ - порядковый номер. Все эти группы входят в одну grp.all.internet, по которой и происходит авторизация. Так вот, как LDAP_auth отнесется к тому, что ему придется работать с группой, в которой есть вложенные группы?
> Благодарю откликнувшихся.
> Андрей,вопрос к вам. Точнее уточнение.
> Я писал:
>> Насколько помнится LDAP_auth не поддерживает авторизацию по вложенным группам?
> Имел ввиду, что у меня Инетовские юзера лежат в группе вида grp.XX.internet,
> где ХХ - порядковый номер. Все эти группы входят в одну
> grp.all.internet, по которой и происходит авторизация. Так вот, как LDAP_auth отнесется
> к тому, что ему придется работать с группой, в которой есть
> вложенные группы?Честно сказать, не пробовал, возможно, можно построить такой запрос. Вот пример из конфига:
external_acl_type ldap_group ttl=3600 negative_ttl=3600 children=30 %LOGIN /usr/local/libexec/squid/squid_ldap_group -P -R -b "dc=ччч,dc=ццц,dc=ттт" -f "(&(samaccountname=%v)(memberof=cn=%a,OU=Internet,OU=Access List,DC=ччч,DC=ццц,DC=ттт))" -D squid_ldap_user@ччч.ццц.ттт -W /usr/local/etc/squid/ldap.pass -K -h ldap.domain.serverсудя по всему в ключе -f можно построить нужный вам запрос, который будет проверять не только принадлежность к группе, но и к группам внутри группы.
>[оверквотинг удален]
>> вложенные группы?
> Честно сказать, не пробовал, возможно, можно построить такой запрос. Вот пример из
> конфига:
> external_acl_type ldap_group ttl=3600 negative_ttl=3600
> children=30 %LOGIN /usr/local/libexec/squid/squid_ldap_group -P -R -b "dc=ччч,dc=ццц,dc=ттт"
> -f "(&(samaccountname=%v)(memberof=cn=%a,OU=Internet,OU=Access List,DC=ччч,DC=ццц,DC=ттт))"
> -D squid_ldap_user@ччч.ццц.ттт -W /usr/local/etc/squid/ldap.pass -K -h ldap.domain.server
> судя по всему в ключе -f можно построить нужный вам запрос, который
> будет проверять не только принадлежность к группе, но и к группам
> внутри группы.Как вариант, в вашем случае, не отказываться от рабочей схемы взаимодействия сервера прокси (squid) и сервера учетных данных (samba+AD). Попробуйте задачу по проверке пользователей повесить на Squid_kerb_auth, а проверку по принадлежности к группе оставить как есть через samba. В этом случае вы снизите нагрузку на самбу, минуя ее, в части проверки пользователей. Грубо говоря, проверка пользователей будет производиться напрямую по такой схеме:
squid->squid_kerb_auth->AD_KERBEROS вместо squid->ntlm_auth->samba_server->ActiveDirectory
Если вы решитесь попробовать, сообщите результат. Ваш опыт может помочь другим пользователям ищущим решения подобных проблем.
>[оверквотинг удален]
>> внутри группы.
> Как вариант, в вашем случае, не отказываться от рабочей схемы взаимодействия сервера
> прокси (squid) и сервера учетных данных (samba+AD). Попробуйте задачу по проверке
> пользователей повесить на Squid_kerb_auth, а проверку по принадлежности к группе оставить
> как есть через samba. В этом случае вы снизите нагрузку на
> самбу, минуя ее, в части проверки пользователей. Грубо говоря, проверка пользователей
> будет производиться напрямую по такой схеме:
> squid->squid_kerb_auth->AD_KERBEROS вместо squid->ntlm_auth->samba_server->ActiveDirectory
> Если вы решитесь попробовать, сообщите результат. Ваш опыт может помочь другим пользователям
> ищущим решения подобных проблем.Только сейчас обратил внимание на "auth_param ntlm children 1100". Мне кажется такое количество хелперов излишне, попробуйте сократить количество до реально нужного количества. В моем случае, нужное количество хелперов я получал из расчета пикового использования сервера (смотрел squidclient) + 30% запас. Итого, сейчас так:
auth_param negotiate program /usr/local/libexec/squid/squid_kerb_auth -s HTTP/test@Ptest
auth_param negotiate children 15
auth_param negotiate keep_alive on# squidclient -h xx.xx.xx.xx -p 8080 cache_object://xx.xx.xx.xx/negotiateauthenticator
Negotiate Authenticator Statistics:
program: /usr/local/libexec/squid/squid_kerb_auth
number active: 15 of 15 (0 shutting down)
requests sent: 1608778
replies received: 1608778
queue length: 0
avg service time: 0 msec# FD PID # Requests Flags Time Offset Request
1 8 15119 1446396 0.002 0 (none)
2 9 15120 136314 0.004 0 (none)
3 10 15121 18645 0.004 0 (none)
4 11 15122 4780 0.008 0 (none)
5 12 15123 1485 0.006 0 (none)
6 13 15124 544 0.014 0 (none)
7 14 15125 253 0.014 0 (none)
8 15 15126 140 0.014 0 (none)
9 16 15127 74 0.009 0 (none)
10 17 15128 46 0.015 0 (none)
11 18 15129 40 0.015 0 (none)
12 19 15130 22 0.015 0 (none)
13 20 15131 19 0.015 0 (none)
14 21 15132 11 0.027 0 (none)
15 22 15133 9 0.036 0 (none)Flags key:
B = BUSY
C = CLOSING
R = RESERVED
S = SHUTDOWN PENDING
P = PLACEHOLDER
# squidclient -h xx.xx.xx.xx -p 8080 cache_object://xx.xx.xx.xx/basicauthenticator
Basic Authenticator Statistics:
program: /usr/local/libexec/squid/squid_ldap_auth
number active: 10 of 10 (0 shutting down)
requests sent: 94
replies received: 94
queue length: 0
avg service time: 1858 msec# FD PID # Requests Flags Time Offset Request
1 23 15134 94 0.048 0 (none)
2 24 15135 0 0.000 0 (none)
3 25 15136 0 0.000 0 (none)
4 26 15137 0 0.000 0 (none)
5 27 15138 0 0.000 0 (none)
6 28 15139 0 0.000 0 (none)
7 29 15140 0 0.000 0 (none)
8 30 15141 0 0.000 0 (none)
9 31 15142 0 0.000 0 (none)
10 32 15143 0 0.000 0 (none)Flags key:
B = BUSY
W = WRITING
C = CLOSING
S = SHUTDOWN PENDING
==================
External ACL Statistics: ldap_group
Cache size: 1869
program: /usr/local/libexec/squid/squid_ldap_group
number active: 30 of 30 (0 shutting down)
requests sent: 6486
replies received: 6486
queue length: 0
avg service time: 3 msec# FD PID # Requests Flags Time Offset Request
1 124 15243 6338 0.116 0 (none)
2 125 15244 147 0.006 0 (none)
3 126 15245 1 0.060 0 (none)
4 127 15246 0 0.000 0 (none)
5 128 15247 0 0.000 0 (none)
6 129 15248 0 0.000 0 (none)
7 130 15249 0 0.000 0 (none)
8 131 15250 0 0.000 0 (none)
9 132 15251 0 0.000 0 (none)
10 133 15252 0 0.000 0 (none)
11 134 15253 0 0.000 0 (none)
12 135 15254 0 0.000 0 (none)
13 136 15255 0 0.000 0 (none)
14 137 15256 0 0.000 0 (none)
15 138 15257 0 0.000 0 (none)
16 139 15258 0 0.000 0 (none)
17 140 15259 0 0.000 0 (none)
18 141 15260 0 0.000 0 (none)
19 142 15261 0 0.000 0 (none)
20 143 15262 0 0.000 0 (none)
21 144 15263 0 0.000 0 (none)
22 145 15264 0 0.000 0 (none)
23 146 15265 0 0.000 0 (none)
24 147 15266 0 0.000 0 (none)
25 148 15267 0 0.000 0 (none)
26 149 15268 0 0.000 0 (none)
27 150 15269 0 0.000 0 (none)
28 151 15270 0 0.000 0 (none)
29 152 15271 0 0.000 0 (none)
30 153 15272 0 0.000 0 (none)Flags key:
B = BUSY
W = WRITING
C = CLOSING
S = SHUTDOWN PENDING
[сообщение отредактировано модератором]
Попробуйте отключить дисковый кэш сквида. Дисковый кэш сам по себе тормоз, а при таком количестве юзеров думаю еще больший тормоз. cache_mem 512 mb. Попробуйте и его увеличить.
День добрый.
После гугления, анализа и прочего прочего остановился на negotiate схеме с хелпером kerb_auth. Для недоменных юзеров(точнее будет сказать для юзеров, чьи машины не в домене, но которые имеют учетку в АД для доступа в Инет) basic схема с хелпером ldap_auth. Проверка на принадлежность к группе через ldap_group.
Пока что данная схема проходит этап тестирования и утверждения. Как она покажет себя при нагрузке в 1500 человек сказать не могу. Остается только верить в лучшее, так как пути назад уже нет: ntlm_auth через winbind себя уже изжил. Никогда эта связка у меня не работала надежно.
Есть и пару "но".
Иногда на недоменных машинах выскакивает окно авторизации,а в cache.log ошибка:authenticateNegotiateHandleReply: Error validating user via Negotiate. Error returned 'BH gss_accept_sec_context() failed: Unspecified GSS failure. Minor code may provide more information. '
Так же периодически появляются записи в cache.log:
squid_ldap_group WARNING, LDAP search error 'Can't contact LDAP server'