Современные
информационные технологии/3.Программное обеспечение
Мясіщев А.А., Федишин Д.Я.
Хмельницький Національний університет,
м.Хмельницький
Аналіз
доцільності використання Squid для
доступу в Інтернет
При підключенні комп'ютерних мереж організацій, фірм,
учбових закладів часто необхідно виконувати наступні дії:
1. Придбання в найближчого провайдера
Інтернет мережі реальних IP-адрес для кожного комп'ютера компанії. Чим більше
комп'ютерів у локальній мережі, тим більше адрес необхідно купити. Так у цей
час вартість однієї IP-адреси становить ~3 у.о. на місяць. При установці в
локальній мережі близько 500 комп'ютерів потрібно платити провайдеру ~1500
у.о./міс.
2.
Адміністрування мережі, тобто надання кожному локальному комп'ютеру заданих
повноважень доступу до мережі. Наприклад, обмеження доступу за часом роботи з
Інтернет, обмеження швидкості доступу, надання можливості роботи з конкретними
сайтами й заборона доступу до інших серверів і т.д.
3.
Проведення заходів щодо економії засобів по оплаті дорогого каналу Інтернет.
Наприклад, установка сервера, кешуючого попередні запити для того, щоб при
повторному звертанні до зовнішніх серверів інформація частково зчитувалася з
кеша(жорсткого диска) з накопиченої за заданий проміжок часу інформацією. Чим більше буде йти звертань до
раніше накопиченої інформації, тим менше буде завантажений зовнішній канал.
Рішення перших двох завдань можливо з
використанням проксі-серверу squid. При рішенні першого завдання необхідно, щоб
інтерфейс проксі-серверу мав одну реальний ip-адресу а другий локальний,
наприклад із мережі класу B - 172.20.0.0/255.255.0.0. Тоді всі комп'ютери з
локальними ip-адресами організації повинні бути прописані в конфігураційному
файлі squid.conf, що дасть можливість проксі-серверу задовольняти їхні запити
до зовнішніх серверів підмінюючи їхні локальні адреси своєю реальною
ip-адресою. Нижче наведений фрагмент squid.conf для шести локальних
комп'ютерів.
acl net172_011 src 172.20.0.11/255.255.255.255
acl net172_012 src 172.20.0.12/255.255.255.255
acl net172_013 src 172.20.0.13/255.255.255.255
acl net172_014 src 172.20.0.14/255.255.255.255
acl net172_015 src 172.20.0.15/255.255.255.255
acl net172_016 src 172.20.0.16/255.255.255.255
http_access allow net172_011
http_access allow net172_012
http_access allow net172_013
http_access allow net172_014
http_access allow net172_015
http_access allow net172_016
У такий спосіб використання squid для мережі ~500 комп'ютерів
приводить до економії ~1500 у.о. на місяць. Для забезпечення роботи мережі з
500 комп'ютерів досить одного сервера із процесором intel Core2 Duo E4600 з частотою 2,40Ghz, оперативною пам'яттю ~1024Mbyte і дискової ~10Gbyte вартістю не
більше 600 у.о. Отже такий сервер для організації окупиться менш ніж за 1 місяць.
Рішення другого завдання також можливо
шляхом внесення змін у файл squid.conf. Дозвіл доступу для конкретних ip-адрес
до проксі розглянуто вище. Обмеження швидкості до 6000байт/с
із загального потоку 32000байт/с для наведених вище адрес може бути
виконано додаванням наступних рядків в squid.conf:
delay_pools 1
delay_class 1 2
delay_access 1 allow
net172_011
delay_access 1 allow net172_012
delay_access 1 allow
net172_013
delay_access 1 allow
net172_014
delay_access 1 allow
net172_015
delay_access 1 allow
net172_016
delay_access 1 deny all
delay_parameters 1 32000/32000 6000/6000
Для
організації авторизованого доступу з кожного локального комп'ютера до
проксі-сервера squid, а отже й до Інтернет - додаванням таких рядків:
authenticate_program
/usr/local/squid/bin/ncsa_auth
/usr/local/squid/etc/passwd
authenticate_children 5
acl net172_011_p proxy_auth
h011
acl net172_012_p proxy_auth
h012
acl net172_013_p proxy_auth
h013
acl net172_014_p proxy_auth
h014
acl net172_015_p proxy_auth
h015
acl net172_016_p proxy_auth
h016
http_access allow net172_011 net172_011_p
http_access allow net172_012 net172_012_p
http_access allow net172_013 net172_013_p
http_access allow net172_014 net172_014_p
http_access allow net172_015 net172_015_p
http_access allow net172_016 net172_016_p
Тут /usr/local/squid/bin/ncsa_auth -
програма аутентифікації, що поставляє з squid, а /usr/local/squid/etc/passwd -
файл паролів, що може створюватися програмою
htpasswd. Вона поставляється разом з web-сервером apache.
Для рішення третього завдання, тобто перевірки дійсної ефективності роботи
sqiud - а із зовнішнім каналом спочатку зробимо наступний експеримент.
Відключимо можливість squid-а скидати отриману із сайтів інформацію в кеш на
магнітному диску. Для цього в конфігураційний файл додамо рядок:
no_cache deny all
А
потім включимо кеш на диску розміром 150Mbyte. Далі за допомогою програми MRTG
згенеруємо графіки, скільки інформації було передано squid-м комп'ютерам
локальної мережі, скільки інформації squid-м було отримано від зовнішніх
серверів, скільки інформації пройшло через зовнішній канал, підключений тільки
до цього проксі-серверу . Додатково за допомогою MRTG згенеруємо графік кривих
середньої кількості запитів у хвилину за кожні п'ять хвилин, що було витягнуто
з кеша для локальних клієнтів і середнього числа запитів, які були повернуті
клієнтам від проксі. Очевидно, що взявши відношення цих запитів одержимо
ефективність роботи проксі squid. Так якщо відношення дорівнює в середньому 30%
наприклад за добу, тобто зовнішній канал повинен бути завантажений на 30%
менше, ніж якби не було проксі й вихід в Інтернет був організований з
комп'ютерів організації з реальними ip-адресами без використання проксі. Як
експериментальний канал використався канал на Lucky Link EU зі швидкістю
256Kbit/c. Проксі squid версії 2.4 під Unix FreeBSD версії 4.5.
Для зняття даних із проксі
використовувався протокол SNMP. Для цього squid збирався із ключем
-enable-snmp, а в конфігураційному файлі squid.conf були додані рядки:
acl snmppublic snmp_community public
snmp_access allow all
Для
перевірки працездатності snmp squid скористаємося утилітою snmpwalk. Об'єкти
squid зберігаються в MIB файлі /usr/local/squid/etc/mib.txt:
тут треба забрати фігурні дужки з усім змістом з опису модуля й покласти його в
/usr/local/share/snmp/mibs. Для
добування повного дерева об'єктів для squid необхідно виконати команду:
snmpwalk -p 3401 -m SQUID-MIB ім’я-хоста
імені-співтовариства squid
Конкретно для вузла
195.230.134.97 і співтовариства public команда прийме вид:
smpwalk
-m SQUID-MIB -p 3401 195.230.134.97 public squid
Далі буде
випливати роздрукування всіх об'єктів, що лежать в піддереві iso.org.dod.internet.private.enterprises.nlanr.squid
(1.3.6.1.4.1.3495.1). Найбільш важливі для нас наступні:
cacheSystem
cacheSysVMsize (обсяг кеша в оперативній пам'яті, в KB)
cacheSysStorage (обсяг кеша на диску, в
KB)
cacheUptime (час роботи проксі після
останнього перевантаження в 1/100 секунди)
cachePerf
cacheProtoStats
cacheProtoAggregateStats
cacheProtoClientHttpRequests ( Повне число HTTP запитів повернуте від
кеша(squid-а) клієнтам)
cacheHttpHits (Повне число HTTP запитів, які потрапили в кеш, що
створений squid-ом) cacheHttpInKb (кілобайт інформації,
отримані від клієнтів)
cacheHttpOutKb (кілобайт інформації, віддані клієнтам)
cacheServerInKb (кілобайт інформації отримані squid від серверів)
cacheServerOutKb (кілобайт інформації віддані squid серверам)
cacheClients
(число IP адрес клієнтів, які
звернулися до кеш)
cacheMedianSvcTable (середні дані за інтервал часу, зазначений в cacheMedianTime)
cacheMedianSvcEntry (індекс доступу до екземпляра: cacheMedianTime)
cacheHttpAllSvcTime.5 (середній час обслуговування всіх запитів,
мілісекунд)
cacheHttpMissSvcTime.5(середній час обслуговування запитів, відсутніх
у кеш або
застарілих, мілісекунд)
Для формування графіків за допомогою
MRTG створимо конфігураційний файл mrtg.cfg [1]:
WorkDir: /usr/local/apache/htdocs/mrtg6
LoadMIBs:/usr/local/mrtg-2/cfg6/mib.txt,
/usr/local/share/snmp/mibs/IF-MIB.txt
RunAsDaemon: Yes
Interval: 5
Language: russian
kilo[_]:1024
# Http Hits/Requests
Target[cacheHits]:
cacheHttpHits&cacheProtoClientHttpRequests:public@172.20.0.153
Title[cacheHits]: HTTP Hits
PageTop[cacheHits]: <h1>HTTP Hits / Requests</h1>
MaxBytes[cacheHits]: 400
Supress[cacheHits]: y
YLegend[cacheHits]: perminute
ShortLegend[cacheHits]: req/min
Legend[cacheHits]: HTTP hits
Legend[cacheHits]: HTTP requests
Legend1[cacheHits]: hits
Legend2[cacheHits]: requests
Options[cacheHits]: nopercent, perminute, dorelpercent
# Скільки байт отримані по протоколі HTTP клієнтами від
squid - а
Target[OutKb]:
cacheHttpOutKb&cacheHttpOutKb:public@172.20.0.153:3401 * 1024
MaxBytes[OutKb]: 4000000000
Title[OutKb]: HTTP Out Traffic
Options[OutKb]: nopercent,gauge
PageTop[OutKb]: <h1>HTTP Out Traffic </h1>
YLegend[OutKb]: Bytes
ShortLegend[OutKb]: Bytes
Legend[OutKb]: HTTP Out
Legend[OutKb]: HTTP Out
Legend1[OutKb]: Out
Legend2[OutKb]: Out
# Скільки байт
одержав squid від зовнішніх серверів
Target[InKb]: cacheServerInKb&cacheServerInKb:public@172.20.0.153:3401
* 1024
MaxBytes[InKb]: 4000000000
Title[InKb]: Server In Traffic
Options[InKb]: nopercent,gauge
PageTop[InKb]: <h1>Server In Traffic </h1>
YLegend[InKb]: Bytes
ShortLegend[InKb]: Bytes
Legend[InKb]: Server In
Legend[InKb]: Server In
Legend1[InKb]: In
Legend2[InKb]: In
# Скільки байт було
переслано squid - у із зовнішнього супутникового каналу
Target[16]:
ifInOctets.16&ifInOctets.16:public@172.20.0.160:
MaxBytes[16]: 4000000000
Title[16]: Traffic Analysis
for switch libr.
PageTop[16]: <H1>Lucky
Link</H1>
Options[16]: nopercent,gauge
YLegend[16]: Bytes
ShortLegend[16]: Bytes
Legend[16]: HTTP In
Legend[16]: HTTP In
Legend1[16]: Out
Legend2[16]: Out
Результат
роботи представлений наступними графіками в послідовності конфігураційного
файлу.
Рис.1
Рис.2
Рис.3
Рис.4
Права
частина графіків відповідає випадку виключеного кеша на диску, ліва - з
організацією кеша на диску в розмірі 150Mbyte. У випадку відключеного кеша
віддане squid-м локальним комп'ютерам 421Мбайт (рис.2), прийняте squid-м від
зовнішніх серверів 414Мбайт (рис.3), переслане squid-у із супутника 476Мбайт
(рис.4). У такий спосіб squid із зовнішнього супутникового каналу взяв ~ на 13%
більше інформації чим віддав клієнтам локальної мережі. Отже squid без
дискового кеша працює вкрай не ефективно. Для увімкненого кеша віддано squid-м
локальним комп'ютерам 533Мбайт (рис.2), прийняте squid -м від зовнішніх
серверів 466Мбайт (рис.3), переслане
squid - у із супутника 528Мбайт (рис.4). У такий спосіб зі створенням
невеликого дискового кеша ефективність роботи squid збільшується й приблизно
відповідає кількості отриманої інформації із зовнішнього каналу. Збільшимо
розмір кеша до 1500Мбайт і проаналізуємо ефективність squid-а знову. За кілька
днів роботи віддано squid-ом локальної мережі 2005Мбайт (рис.6), прийняте
squid-м від зовнішніх серверів 1619Мбайт
(рис.7), передане squid-у із супутника 1757Мбайт (рис.8). У такий спосіб
реальна ефективність роботи проксі-сервера для великого кеша згодом його
відновлення 7 днів склала приблизно ((2005-1757)/1757)х100%=14%(рис.6,8). Хоча
середнє влучення в кеш перебуває в межах 30-35% (див. рис.5), очевидно те,
що й теоретична ефективність роботи
squid-а повинна бути близько 30-35%. Однак, якщо взяти до уваги дані з мал. 6 і
мал. 7, то з них видно що ефективність роботи проксі приблизно дорівнює
((2005-1619)/1619)х100%=24%. Таке розходження (14% й 24%) зв'язано, очевидно з
тим, що squid посилає зовнішнім серверам пакети запитів і приймає пакети
відповідей розміром приблизно на 10% більше, ніж вони формуються локальними
комп'ютерами. У цих 10% проксі формує необхідну йому службову інформацію,
зокрема, ip-адресу локальних комп'ютерів, яким необхідно повернути запитані
ними дані із зовнішніх серверів.
Рис.5
Рис.6
Рис.7
Рис.8
Література.
1.Мясіщев
А.А. Полозова В.М. Використання MRTG для обліку завантаженості інтерфейсів.
Збiрник наукових праць N24, ч.II - Хмельницький, Видавництво НАПВУ, 2003. -
с.173-177
2.http://www.squid-cache.org