The OpenNET Project / Index page

[ новости /+++ | форум | wiki | теги | ]

форумы  помощь  поиск  регистрация  майллист  ВХОД  слежка  RSS
"Squid, как корпоративный прокси!!!"
Вариант для распечатки  
Пред. тема | След. тема 
Форумы Настройка Squid и других прокси серверов (Public)
Изначальное сообщение [Проследить за развитием треда]

"Squid, как корпоративный прокси!!!"  
Сообщение от jekka email(??) on 31-Май-06, 14:07 
Доброго времени суток!
Хотел бы посоветоваться с умудренными опытом гуру по поводу вот какой темы!
Есть компьютер, который прочат сделать сервером интернет, комплектация такая:
AMD Athlon 3000+ (533, HT800), 512 DDR400, SATA RAID 1 80GB Seagate, 100Mb/s Fast Ethernet LAN.
Пропускная способность выдеоленного канала интернет: 5 Мбит\с
Предполагаемая ОС-FREEBSD 6.0-STABLE-AMD64
Во внутренней сети, ~70 компьютеров, причем система такая:

                              |Internet_Server|
                                      |
                                      |
                                   |Switch|--------------LAN
LAN-|Switch|________|________________________|Switch|----LAN
            |                                                      |
            |                                                      |
        |Switch|                                         |Switch|----LAN
            |                                                      |
            |                                                      |
        |Switch|                                         |Switch|
            |                                                      |
           LAN                                              LAN

Internet_Server обозначает вышеуказанный сервер, который смотрит одним интрефейсом во внутреннюю локальную сеть LAN, а вторым наружу в интернет. Причем,  там где написано LAN, там к свитчу подключены компы локалки.
Вот после такой замысловатой схемы у меня возник второстепенный вопросик: все ли компьютеры локалки увидят при такой схеме друг друга или же по правило трех hub'ов тут тоже действует и будут глюки???

Основная задумка такова:
Поставить на сервак proxy squid и проверять траффик с помощью ClamAV через icap, чтобы все в локалки брали интернет через этот прокси! Также будет настроен IPFW, и что-нить для подсчета траффика! Кстати, посоветуйте, что лучше для этого использовать: средства IPFW, или отдельные программы типа trafd???

Специалисты, подскажите, при такой скорости выделенного канала, количестве компьютеров и архитектуре самой сети эта идея способна жить и хорошо работать?
Заранее, спасибо за все советы!!!

Правка | Высказать мнение | Ответить | Cообщить модератору | Наверх

 Оглавление

Сообщения по теме [Сортировка по времени, UBB]


1. "Squid, как корпоративный прокси!!!"  
Сообщение от StSphinx (??) on 31-Май-06, 14:21 
>Доброго времени суток!
>Хотел бы посоветоваться с умудренными опытом гуру по поводу вот какой темы!
>
>Есть компьютер, который прочат сделать сервером интернет, комплектация такая:
>AMD Athlon 3000+ (533, HT800), 512 DDR400, SATA RAID 1 80GB Seagate,
>100Mb/s Fast Ethernet LAN.
>Пропускная способность выдеоленного канала интернет: 5 Мбит\с
>Предполагаемая ОС-FREEBSD 6.0-STABLE-AMD64
>Во внутренней сети, ~70 компьютеров, причем система такая:
>
>            
>          
>       |Internet_Server|
>            
>          
>          
>    |
>            
>          
>          
>    |
>            
>          
>          
> |Switch|--------------LAN
> LAN-|Switch|________|________________________|Switch|----LAN
>            
>|          
>          
>          
>          
>          |
>
>            
>|          
>          
>          
>          
>          |
>
>        |Switch|    
>          
>          
>          
>    |Switch|----LAN
>            
>|          
>          
>          
>          
>          |
>
>            
>|          
>          
>          
>          
>          |
>
>        |Switch|    
>          
>          
>          
>    |Switch|
>            
>|          
>          
>          
>          
>          |
>
>           LAN
>          
>          
>          
>          
> LAN
>
>Internet_Server обозначает вышеуказанный сервер, который смотрит одним интрефейсом во внутреннюю локальную сеть
>LAN, а вторым наружу в интернет. Причем,  там где написано
>LAN, там к свитчу подключены компы локалки.
>Вот после такой замысловатой схемы у меня возник второстепенный вопросик: все ли
>компьютеры локалки увидят при такой схеме друг друга или же по
>правило трех hub'ов тут тоже действует и будут глюки???
>
>Основная задумка такова:
>Поставить на сервак proxy squid и проверять траффик с помощью ClamAV через
>icap, чтобы все в локалки брали интернет через этот прокси! Также
>будет настроен IPFW, и что-нить для подсчета траффика! Кстати, посоветуйте, что
>лучше для этого использовать: средства IPFW, или отдельные программы типа trafd???
>
>
>Специалисты, подскажите, при такой скорости выделенного канала, количестве компьютеров и архитектуре самой
>сети эта идея способна жить и хорошо работать?
>Заранее, спасибо за все советы!!!

Правило трех хабов и работает собственно для хабов(читай ретрансляторов сигнала).
Схема работоспособная, но свичи лучше бы иметь управляемые, IMHO.

Правка | Высказать мнение | Ответить | Cообщить модератору | Наверх

2. "Squid, как корпоративный прокси!!!"  
Сообщение от jekka email(??) on 31-Май-06, 14:35 

>Правило трех хабов и работает собственно для хабов(читай ретрансляторов сигнала).
>Схема работоспособная, но свичи лучше бы иметь управляемые, IMHO.

То есть, в итоге, такая схема, как я правильно понял, если и будет работать, то компьютеры, находящиеся за более чем тремя свитчами видны не будут? А так как, нет возможности убрать некоторые из свитчей, то выход- добавить на сервер еще один интрефейс и вместо одной разбить локалку на две!
Более ли удачный это вариант или можно иначе?
И какие примерно настройки
параметров squid "cache_dir" и "cache_mem" будут наиболее работоспособные?

Правка | Высказать мнение | Ответить | Cообщить модератору | Наверх

3. "Squid, как корпоративный прокси!!!"  
Сообщение от alex3 email(ok) on 31-Май-06, 15:00 
>>Правило трех хабов и работает собственно для хабов(читай ретрансляторов сигнала).
>>Схема работоспособная, но свичи лучше бы иметь управляемые, IMHO.
>
>То есть, в итоге, такая схема, как я правильно понял, если и
>будет работать, то компьютеры, находящиеся за более чем тремя свитчами видны
>не будут?
Объясняю. Хаб (hub) - он, получаемый на один порт сигнал, пихает его на все остальные порты. Поэтому, во избежание "сетевых штормов" и придумали "правило 3 хабов". В отличие от хабов свичи (switch) получаемый сигнал адресуют только на тот порт, куда собственно он и должен идти (согласуясь с внутренней таблицей ARP), поэтому "правило 3 хабов" к свичам неприменимо. Исходя из вышеизложенного, твоя схема вполне работоспособна. Насчет остального посоветовать не могу, сам еще в учащихся NIX-ам.
Правка | Высказать мнение | Ответить | Cообщить модератору | Наверх

5. "Squid, как корпоративный прокси!!!"  
Сообщение от jekka email(??) on 31-Май-06, 15:34 
>>>Правило трех хабов и работает собственно для хабов(читай ретрансляторов сигнала).
>>>Схема работоспособная, но свичи лучше бы иметь управляемые, IMHO.
>>
>>То есть, в итоге, такая схема, как я правильно понял, если и
>>будет работать, то компьютеры, находящиеся за более чем тремя свитчами видны
>>не будут?
>Объясняю. Хаб (hub) - он, получаемый на один порт сигнал, пихает его
>на все остальные порты. Поэтому, во избежание "сетевых штормов" и придумали
>"правило 3 хабов". В отличие от хабов свичи (switch) получаемый сигнал
>адресуют только на тот порт, куда собственно он и должен идти
>(согласуясь с внутренней таблицей ARP), поэтому "правило 3 хабов" к свичам
>неприменимо. Исходя из вышеизложенного, твоя схема вполне работоспособна. Насчет остального посоветовать
>не могу, сам еще в учащихся NIX-ам.

А на наиболее удаленных участках сети, где-нибудь на третьем, по счету, свитче тормозов вследствии частого использования одного порта не будет?

Правка | Высказать мнение | Ответить | Cообщить модератору | Наверх

6. "Squid, как корпоративный прокси!!!"  
Сообщение от alex3 email(ok) on 31-Май-06, 15:39 
>А на наиболее удаленных участках сети, где-нибудь на третьем, по счету, свитче
>тормозов вследствии частого использования одного порта не будет?
Если свичи толковые - нет, не будет, разве что иногда, редко. Хотя, если 1С-ка есть, то она может жрать сетку так, что иногда и гигабитки маловато. А вообще мы несколько отклонились от темы данного форума...
Правка | Высказать мнение | Ответить | Cообщить модератору | Наверх

7. "Squid, как корпоративный прокси!!!"  
Сообщение от StSphinx (??) on 31-Май-06, 15:47 
>>>>Правило трех хабов и работает собственно для хабов(читай ретрансляторов сигнала).
>>>>Схема работоспособная, но свичи лучше бы иметь управляемые, IMHO.
>>>
>>>То есть, в итоге, такая схема, как я правильно понял, если и
>>>будет работать, то компьютеры, находящиеся за более чем тремя свитчами видны
>>>не будут?
>>Объясняю. Хаб (hub) - он, получаемый на один порт сигнал, пихает его
>>на все остальные порты. Поэтому, во избежание "сетевых штормов" и придумали
>>"правило 3 хабов". В отличие от хабов свичи (switch) получаемый сигнал
>>адресуют только на тот порт, куда собственно он и должен идти
>>(согласуясь с внутренней таблицей ARP), поэтому "правило 3 хабов" к свичам
>>неприменимо. Исходя из вышеизложенного, твоя схема вполне работоспособна. Насчет остального посоветовать
>>не могу, сам еще в учащихся NIX-ам.

Причина не в штормах(это уже следствие), причина в особенностях работы технологии 10Base-T(любой поисковик, ключ: правило 3-4-5 для хабов). Вообще свич и хаб, если и родственники, то очень дальние. Они работают на разных уровнях модели OSI, хаб - физика, банальный усилитель, свич - канальный уровень, имеет дело с адресацией на втором уровне, умеет проверять кадры и знает в какой из своих портов кадр нужно отправить. Вообще внешнее сходство железок как правило людей запутывает.

>А на наиболее удаленных участках сети, где-нибудь на третьем, по счету, свитче
>тормозов вследствии частого использования одного порта не будет?

Все зависит от производительности свичей и х-ра информационных потоков.
Вообще есть золотое правило, проповедуется cisco:
80/20 - 80 % трафика должно быть локальным, 20 % должно выходить за пределы сегмента.
Если это не так, то стоит задуматься о перестройке сети.

Правка | Высказать мнение | Ответить | Cообщить модератору | Наверх

8. "Squid, как корпоративный прокси!!!"  
Сообщение от jekka email(??) on 31-Май-06, 16:48 
>>>>>Правило трех хабов и работает собственно для хабов(читай ретрансляторов сигнала).
>>>>>Схема работоспособная, но свичи лучше бы иметь управляемые, IMHO.
>>>>
>>>>То есть, в итоге, такая схема, как я правильно понял, если и
>>>>будет работать, то компьютеры, находящиеся за более чем тремя свитчами видны
>>>>не будут?
>>>Объясняю. Хаб (hub) - он, получаемый на один порт сигнал, пихает его
>>>на все остальные порты. Поэтому, во избежание "сетевых штормов" и придумали
>>>"правило 3 хабов". В отличие от хабов свичи (switch) получаемый сигнал
>>>адресуют только на тот порт, куда собственно он и должен идти
>>>(согласуясь с внутренней таблицей ARP), поэтому "правило 3 хабов" к свичам
>>>неприменимо. Исходя из вышеизложенного, твоя схема вполне работоспособна. Насчет остального посоветовать
>>>не могу, сам еще в учащихся NIX-ам.
>
>Причина не в штормах(это уже следствие), причина в особенностях работы технологии 10Base-T(любой
>поисковик, ключ: правило 3-4-5 для хабов). Вообще свич и хаб, если
>и родственники, то очень дальние. Они работают на разных уровнях модели
>OSI, хаб - физика, банальный усилитель, свич - канальный уровень, имеет
>дело с адресацией на втором уровне, умеет проверять кадры и знает
>в какой из своих портов кадр нужно отправить. Вообще внешнее сходство
>железок как правило людей запутывает.
>
>>А на наиболее удаленных участках сети, где-нибудь на третьем, по счету, свитче
>>тормозов вследствии частого использования одного порта не будет?
>
>Все зависит от производительности свичей и х-ра информационных потоков.
>Вообще есть золотое правило, проповедуется cisco:
>80/20 - 80 % трафика должно быть локальным, 20 % должно выходить
>за пределы сегмента.
>Если это не так, то стоит задуматься о перестройке сети.

Структура сети обусловлена расположением компьютеров в здании, поэтому изменить ее очень проблематично и чревато существенными кабельными работами. Предпологается, что траффик будет на 90% к интернет-серверу!

Правка | Высказать мнение | Ответить | Cообщить модератору | Наверх

9. "Squid, как корпоративный прокси!!!"  
Сообщение от StSphinx (??) on 31-Май-06, 17:52 
>>>>>>Правило трех хабов и работает собственно для хабов(читай ретрансляторов сигнала).
>>>>>>Схема работоспособная, но свичи лучше бы иметь управляемые, IMHO.
>>>>>
>>>>>То есть, в итоге, такая схема, как я правильно понял, если и
>>>>>будет работать, то компьютеры, находящиеся за более чем тремя свитчами видны
>>>>>не будут?
>>>>Объясняю. Хаб (hub) - он, получаемый на один порт сигнал, пихает его
>>>>на все остальные порты. Поэтому, во избежание "сетевых штормов" и придумали
>>>>"правило 3 хабов". В отличие от хабов свичи (switch) получаемый сигнал
>>>>адресуют только на тот порт, куда собственно он и должен идти
>>>>(согласуясь с внутренней таблицей ARP), поэтому "правило 3 хабов" к свичам
>>>>неприменимо. Исходя из вышеизложенного, твоя схема вполне работоспособна. Насчет остального посоветовать
>>>>не могу, сам еще в учащихся NIX-ам.
>>
>>Причина не в штормах(это уже следствие), причина в особенностях работы технологии 10Base-T(любой
>>поисковик, ключ: правило 3-4-5 для хабов). Вообще свич и хаб, если
>>и родственники, то очень дальние. Они работают на разных уровнях модели
>>OSI, хаб - физика, банальный усилитель, свич - канальный уровень, имеет
>>дело с адресацией на втором уровне, умеет проверять кадры и знает
>>в какой из своих портов кадр нужно отправить. Вообще внешнее сходство
>>железок как правило людей запутывает.
>>
>>>А на наиболее удаленных участках сети, где-нибудь на третьем, по счету, свитче
>>>тормозов вследствии частого использования одного порта не будет?
>>
>>Все зависит от производительности свичей и х-ра информационных потоков.
>>Вообще есть золотое правило, проповедуется cisco:
>>80/20 - 80 % трафика должно быть локальным, 20 % должно выходить
>>за пределы сегмента.
>>Если это не так, то стоит задуматься о перестройке сети.
>
>Структура сети обусловлена расположением компьютеров в здании, поэтому изменить ее очень проблематично
>и чревато существенными кабельными работами. Предпологается, что траффик будет на 90%
>к интернет-серверу!

Структуру можно отвязать от географии используя управляемые свичи и разбивку сети на VLAN'ы. Но это уже совсем другая тема.

Правка | Высказать мнение | Ответить | Cообщить модератору | Наверх

10. "Squid, как корпоративный прокси!!!"  
Сообщение от jekka email(??) on 31-Май-06, 18:24 
>>>>>>>Правило трех хабов и работает собственно для хабов(читай ретрансляторов сигнала).
>>>>>>>Схема работоспособная, но свичи лучше бы иметь управляемые, IMHO.
>>>>>>
>>>>>>То есть, в итоге, такая схема, как я правильно понял, если и
>>>>>>будет работать, то компьютеры, находящиеся за более чем тремя свитчами видны
>>>>>>не будут?
>>>>>Объясняю. Хаб (hub) - он, получаемый на один порт сигнал, пихает его
>>>>>на все остальные порты. Поэтому, во избежание "сетевых штормов" и придумали
>>>>>"правило 3 хабов". В отличие от хабов свичи (switch) получаемый сигнал
>>>>>адресуют только на тот порт, куда собственно он и должен идти
>>>>>(согласуясь с внутренней таблицей ARP), поэтому "правило 3 хабов" к свичам
>>>>>неприменимо. Исходя из вышеизложенного, твоя схема вполне работоспособна. Насчет остального посоветовать
>>>>>не могу, сам еще в учащихся NIX-ам.
>>>
>>>Причина не в штормах(это уже следствие), причина в особенностях работы технологии 10Base-T(любой
>>>поисковик, ключ: правило 3-4-5 для хабов). Вообще свич и хаб, если
>>>и родственники, то очень дальние. Они работают на разных уровнях модели
>>>OSI, хаб - физика, банальный усилитель, свич - канальный уровень, имеет
>>>дело с адресацией на втором уровне, умеет проверять кадры и знает
>>>в какой из своих портов кадр нужно отправить. Вообще внешнее сходство
>>>железок как правило людей запутывает.
>>>
>>>>А на наиболее удаленных участках сети, где-нибудь на третьем, по счету, свитче
>>>>тормозов вследствии частого использования одного порта не будет?
>>>
>>>Все зависит от производительности свичей и х-ра информационных потоков.
>>>Вообще есть золотое правило, проповедуется cisco:
>>>80/20 - 80 % трафика должно быть локальным, 20 % должно выходить
>>>за пределы сегмента.
>>>Если это не так, то стоит задуматься о перестройке сети.
>>
>>Структура сети обусловлена расположением компьютеров в здании, поэтому изменить ее очень проблематично
>>и чревато существенными кабельными работами. Предпологается, что траффик будет на 90%
>>к интернет-серверу!
>
>Структуру можно отвязать от географии используя управляемые свичи и разбивку сети на
>VLAN'ы. Но это уже совсем другая тема.

Подведя итог, можно ли надеяться что скорость доступа к интернет будет приличной? И, все-таки, какими при количестве компьютеров ~60 сделать настройки размера кэша прокси и использования опер. памяти?

Правка | Высказать мнение | Ответить | Cообщить модератору | Наверх

11. "Squid, как корпоративный прокси!!!"  
Сообщение от StSphinx (??) on 31-Май-06, 23:00 
>>>>>>>>Правило трех хабов и работает собственно для хабов(читай ретрансляторов сигнала).
>>>>>>>>Схема работоспособная, но свичи лучше бы иметь управляемые, IMHO.
>>>>>>>
>>>>>>>То есть, в итоге, такая схема, как я правильно понял, если и
>>>>>>>будет работать, то компьютеры, находящиеся за более чем тремя свитчами видны
>>>>>>>не будут?
>>>>>>Объясняю. Хаб (hub) - он, получаемый на один порт сигнал, пихает его
>>>>>>на все остальные порты. Поэтому, во избежание "сетевых штормов" и придумали
>>>>>>"правило 3 хабов". В отличие от хабов свичи (switch) получаемый сигнал
>>>>>>адресуют только на тот порт, куда собственно он и должен идти
>>>>>>(согласуясь с внутренней таблицей ARP), поэтому "правило 3 хабов" к свичам
>>>>>>неприменимо. Исходя из вышеизложенного, твоя схема вполне работоспособна. Насчет остального посоветовать
>>>>>>не могу, сам еще в учащихся NIX-ам.
>>>>
>>>>Причина не в штормах(это уже следствие), причина в особенностях работы технологии 10Base-T(любой
>>>>поисковик, ключ: правило 3-4-5 для хабов). Вообще свич и хаб, если
>>>>и родственники, то очень дальние. Они работают на разных уровнях модели
>>>>OSI, хаб - физика, банальный усилитель, свич - канальный уровень, имеет
>>>>дело с адресацией на втором уровне, умеет проверять кадры и знает
>>>>в какой из своих портов кадр нужно отправить. Вообще внешнее сходство
>>>>железок как правило людей запутывает.
>>>>
>>>>>А на наиболее удаленных участках сети, где-нибудь на третьем, по счету, свитче
>>>>>тормозов вследствии частого использования одного порта не будет?
>>>>
>>>>Все зависит от производительности свичей и х-ра информационных потоков.
>>>>Вообще есть золотое правило, проповедуется cisco:
>>>>80/20 - 80 % трафика должно быть локальным, 20 % должно выходить
>>>>за пределы сегмента.
>>>>Если это не так, то стоит задуматься о перестройке сети.
>>>
>>>Структура сети обусловлена расположением компьютеров в здании, поэтому изменить ее очень проблематично
>>>и чревато существенными кабельными работами. Предпологается, что траффик будет на 90%
>>>к интернет-серверу!
>>
>>Структуру можно отвязать от географии используя управляемые свичи и разбивку сети на
>>VLAN'ы. Но это уже совсем другая тема.
>
>Подведя итог, можно ли надеяться что скорость доступа к интернет будет приличной?
>И, все-таки, какими при количестве компьютеров ~60 сделать настройки размера кэша
>прокси и использования опер. памяти?

Да. можно. Настройки подбираются эскпериментальным путем, под конкретную ситуацию.
Хотя что вас тут заботить, я незнаю. Squid способен обслужить и большее число клиентов и более толстый канал.

Правка | Высказать мнение | Ответить | Cообщить модератору | Наверх

12. "Squid, как корпоративный прокси!!!"  
Сообщение от DeadLoco (??) on 06-Июн-06, 13:55 
>Подведя итог, можно ли надеяться что скорость доступа к интернет будет приличной?
>И, все-таки, какими при количестве компьютеров ~60 сделать настройки размера кэша
>прокси и использования опер. памяти?

Я пять лет назад начал строить университетскую сеть на бекбоне из дешевых неуправляемых офисных свитчей в надежде позднее переделать все "по уму" в оптику. В силу ряда обстоятельств этого не произошло. В настоящее время используется топология "сороконожка" со стомегабитной средой. Длиннейшая цепочка состоит из 16 устройств, всего в сети почти две сотни свитчей. Более тысячи компов. Все работает, и работает довольно неплохо, что очень неожиданно с теоретической т.зр. Впрочем, я этот парадокс наблюдал и при денормализации баз :)

Наружный канал - 6 Мбит. Сервер - Р4-2.4/1гиг/4х120гиг.
Фря откомпилена с увеличением размера процесса (см. фак по сквиду) до 1Гб, с включенным поллингом, и с 1000Гц таймера. Кэш в 192Гб разбросан по 4 партициям на четырех винтах (2хПАТА+2хСАТА). Каждое устройство на отдельном АТА-канале - довольно шустро. Максимальный размер объекта, хранимого в кэше, установлен в 64Мб, что накрывает почти 90% скачиваний и делает ненужной организацию репозитория всякого софта и драйверов (80% массивных файлов). Схема каталогов - 24х256 (против дефолтных 16х256).

Сквид в памяти разрастается до 400-500 Мб, нагрузка на систему не превышает 0.4-0.5

По многолетней статистике, процент хитов по количеству держится на уровне 40-43%, по объему - от 10 до 17%, в периоды массовых психозов (ака Йети-геймс/Loituma) - до 30%

Правка | Высказать мнение | Ответить | Cообщить модератору | Наверх

13. "Squid, как корпоративный прокси!!!"  
Сообщение от jekka email(??) on 06-Июн-06, 18:22 
>>Подведя итог, можно ли надеяться что скорость доступа к интернет будет приличной?
>>И, все-таки, какими при количестве компьютеров ~60 сделать настройки размера кэша
>>прокси и использования опер. памяти?
>
>Я пять лет назад начал строить университетскую сеть на бекбоне из дешевых
>неуправляемых офисных свитчей в надежде позднее переделать все "по уму" в
>оптику. В силу ряда обстоятельств этого не произошло. В настоящее время
>используется топология "сороконожка" со стомегабитной средой. Длиннейшая цепочка состоит из 16
>устройств, всего в сети почти две сотни свитчей. Более тысячи компов.
>Все работает, и работает довольно неплохо, что очень неожиданно с теоретической
>т.зр. Впрочем, я этот парадокс наблюдал и при денормализации баз :)
>
>
>Наружный канал - 6 Мбит. Сервер - Р4-2.4/1гиг/4х120гиг.
>Фря откомпилена с увеличением размера процесса (см. фак по сквиду) до 1Гб,
>с включенным поллингом, и с 1000Гц таймера. Кэш в 192Гб разбросан
>по 4 партициям на четырех винтах (2хПАТА+2хСАТА). Каждое устройство на отдельном
>АТА-канале - довольно шустро. Максимальный размер объекта, хранимого в кэше, установлен
>в 64Мб, что накрывает почти 90% скачиваний и делает ненужной организацию
>репозитория всякого софта и драйверов (80% массивных файлов). Схема каталогов -
>24х256 (против дефолтных 16х256).
>
>Сквид в памяти разрастается до 400-500 Мб, нагрузка на систему не превышает
>0.4-0.5
>
>По многолетней статистике, процент хитов по количеству держится на уровне 40-43%, по
>объему - от 10 до 17%, в периоды массовых психозов (ака
>Йети-геймс/Loituma) - до 30%


Большущее спасибо за такое описание, многое стало попонятней, вот только не врубился для чего размер процесса так увеличивать надо и как это скажется и что такое поллинг?

Правка | Высказать мнение | Ответить | Cообщить модератору | Наверх

14. "Squid, как корпоративный прокси!!!"  
Сообщение от DeadLoco (??) on 07-Июн-06, 14:00 
>для чего размер процесса так увеличивать надо и как это скажется

При работе сквид держит в памяти индекс кешей, а для большого (и эффективного кеша) индексы требуют много памяти. Если не увеличивать размер процесса в ядре, то максимальный размер процесса - и кода и данных - ограничивается 256-ю мегабайтами. Жирный кеш очень быстро съедает этот объем и появляются ошибки xmalloc: невозможно выделить 4096 байт. Это типовая проблема, хорошо описанная в факе:
http://wiki.squid-cache.org/SquidFaq/SquidMemory#head-39e12a96f79151b3749822fa25b5d935979a3dfb

>и что такое поллинг?

Вот, что пишет об этом LINT:

# DEVICE_POLLING adds support for mixed interrupt-polling handling
# of network device drivers, which has significant benefits in terms
# of robustness to overloads and responsivity, as well as permitting
# accurate scheduling of the CPU time between kernel network processing
# and other activities. The drawback is a moderate (up to 1/HZ seconds)
# potential increase in response times.
# It is strongly recommended to use HZ=1000 or 2000 with DEVICE_POLLING
# to achieve smoother behaviour.
# Additionally, you can enable/disable polling at runtime with the
# sysctl variable kern.polling.enable (defaults off), and select
# the CPU fraction reserved to userland with the sysctl variable
# kern.polling.user_frac (default 50, range 0..100).
#
# Not all device drivers support this mode of operation at the time of
# this writing.  See polling(4) for more details.
options         DEVICE_POLLING


Вот, что пишет man 4 polling:

     Device polling requires explicit modifications to the device drivers.  As
     of this writing, the dc(4), em(4), fwe(4), fxp(4), nge(4), rl(4), sis(4),
     ste(4), and vr(4) devices are supported.

Я на нагруженных машинах держу fxp - дешево и со вкусом. Realtek rl тоже поддерживают поллинг, и даже прозрачное бриджевание, но надежность их работы ниже критики. 10-15 долларов не стоят геморроя по борьбе с родовыми болячками железок.

Правка | Высказать мнение | Ответить | Cообщить модератору | Наверх

15. "Squid, как корпоративный прокси!!!"  
Сообщение от jekka email(??) on 08-Июн-06, 14:12 
Большое спасибо за подробный и понятный ответ!

Дело в том что я далеко не специалист в FreeBSD, а когда сталкиваешься с подобными задачами, пытаясь их решить по своему разумению, во время поиска много информации пропускается (сам бы я не нашел), поэтому я подобным советам несказанно рад.

Хотел бы посоветоваться еще по поводу методов борьбы с "рушением" кэша в squid и по поводу систем подсчета траффика. Сейчас работает squid с почти "умолчальными" настройками, вот конфигурационный файл:
http_port 192.168.1.1:3128
icp_port 0
acl QUERY urlpath_regex cgi-bin \?
no_cache deny QUERY
cache_mem 15 MB
cache_dir ufs /usr/local/squid/cache 500 16 256
cache_store_log none
refresh_pattern ^ftp:        1440    20%    10080
refresh_pattern ^gopher:    1440    0%    1440
refresh_pattern .        0    20%    4320
acl all src 0.0.0.0/0.0.0.0
acl manager proto cache_object
acl localhost src 127.0.0.1/255.255.255.255
acl to_localhost dst 127.0.0.0/8
acl SSL_PORTS port 443 563
acl SAFE_PORTS port 80 23 21 20 70 210 280 591 777 9090
acl UNREG port 1025-65535
acl CONNECT method CONNECT
acl LAN src 192.168.1.0/25
acl porno url_regex "/usr/local/etc/squid/porno"
http_access deny LAN porno
http_access allow manager localhost
http_access deny manager
http_access allow SAFE_PORTS
http_access allow SSL_PORTS
http_access allow UNREG
http_access deny CONNECT !SSL_PORTS
http_access allow LAN
http_access deny all
visible_hostname ProxySquid
coredump_dir /usr/local/squid/cache
refresh_pattern -i \.png$ 4320 100% 4320 override-lastmod override-expire
refresh_pattern -i \.jpg$ 4320 100% 4320 override-lastmod override-expire
refresh_pattern -i \.jpeg$ 4320 100% 4320 override-lastmod override-expire
refresh_pattern -i \.gif$ 2500 100% 2500 override-lastmod override-expire
refresh_pattern -i \.pdf$ 14400 100% 14400 override-lastmod override-expire
refresh_pattern -i \.zip$ 14400 100% 14400 override-lastmod override-expire
refresh_pattern -i \.exe$ 14400 100% 14400 override-lastmod override-expire
refresh_pattern -i \.rar$ 15000 100% 15000 override-lastmod override-expire
refresh_pattern -i \.swf$ 2500 100% 2500 override-lastmod override-expire
refresh_pattern -i \.mid 25000 100% 25000 override-lastmod override-expire
refresh_pattern -i \.mp3 25000 100% 25000 override-lastmod override-expire


Кэш время от времени падает, вот вырезка из cache.log:


2006/06/06 09:23:18| Starting Squid Cache version 2.5.STABLE6 for i386-portbld-freebsd5.3...
2006/06/06 09:23:18| Process ID 492
2006/06/06 09:23:18| With 1792 file descriptors available
2006/06/06 09:23:18| DNS Socket created at 0.0.0.0, port 52597, FD 4
2006/06/06 09:23:18| Adding nameserver 192.168.1.1 from /etc/resolv.conf
2006/06/06 09:23:18| Unlinkd pipe opened on FD 9
2006/06/06 09:23:18| Swap maxSize 512000 KB, estimated 39384 objects
2006/06/06 09:23:18| Target number of buckets: 1969
2006/06/06 09:23:18| Using 8192 Store buckets
2006/06/06 09:23:18| Max Mem  size: 15360 KB
2006/06/06 09:23:18| Max Swap size: 512000 KB
2006/06/06 09:23:18| Store logging disabled
2006/06/06 09:23:18| Rebuilding storage in /usr/local/squid/cache (DIRTY)
2006/06/06 09:23:18| Using Least Load store dir selection
2006/06/06 09:23:18| Set Current Directory to /usr/local/squid/cache
2006/06/06 09:23:18| Loaded Icons.
2006/06/06 09:23:18| Accepting HTTP connections at 192.168.1.1, port 3128, FD 10.
2006/06/06 09:23:18| WCCP Disabled.
2006/06/06 09:23:18| Ready to serve requests.
2006/06/06 09:23:19| Store rebuilding is  8.4% complete
2006/06/06 09:23:21| Done reading /usr/local/squid/cache swaplog (48912 entries)
2006/06/06 09:23:21| Finished rebuilding storage from disk.
2006/06/06 09:23:21|     45955 Entries scanned
2006/06/06 09:23:21|         0 Invalid entries.
2006/06/06 09:23:21|         0 With invalid flags.
2006/06/06 09:23:21|     45641 Objects loaded.
2006/06/06 09:23:21|         0 Objects expired.
2006/06/06 09:23:21|       305 Objects cancelled.
2006/06/06 09:23:21|       952 Duplicate URLs purged.
2006/06/06 09:23:21|         4 Swapfile clashes avoided.
2006/06/06 09:23:21|   Took 2.2 seconds (20570.4 objects/sec).
2006/06/06 09:23:21| Beginning Validation Procedure
2006/06/06 09:23:21|   Completed Validation Procedure
2006/06/06 09:23:21|   Validated 44692 Entries
2006/06/06 09:23:21|   store_swap_size = 482630k
2006/06/06 09:23:21| storeLateRelease: released 0 objects
2006/06/06 09:32:58| WARNING: 1 swapin MD5 mismatches
2006/06/06 16:14:34| WARNING: 10 swapin MD5 mismatches
2006/06/07 08:40:08| Starting Squid Cache version 2.5.STABLE6 for i386-portbld-freebsd5.3...
2006/06/07 08:40:08| Process ID 462
2006/06/07 08:40:08| With 1792 file descriptors available
2006/06/07 08:40:08| DNS Socket created at 0.0.0.0, port 52597, FD 4
2006/06/07 08:40:08| Adding nameserver 192.168.1.1 from /etc/resolv.conf
2006/06/07 08:40:08| Unlinkd pipe opened on FD 9
2006/06/07 08:40:08| Swap maxSize 512000 KB, estimated 39384 objects
2006/06/07 08:40:08| Target number of buckets: 1969
2006/06/07 08:40:08| Using 8192 Store buckets
2006/06/07 08:40:08| Max Mem  size: 15360 KB
2006/06/07 08:40:08| Max Swap size: 512000 KB
2006/06/07 08:40:08| Store logging disabled
2006/06/07 08:40:08| Rebuilding storage in /usr/local/squid/cache (DIRTY)
2006/06/07 08:40:08| Using Least Load store dir selection
2006/06/07 08:40:08| Set Current Directory to /usr/local/squid/cache
2006/06/07 08:40:08| Loaded Icons.
2006/06/07 08:40:08| Accepting HTTP connections at 192.168.1.1, port 3128, FD 10.
2006/06/07 08:40:08| WCCP Disabled.
2006/06/07 08:40:08| Ready to serve requests.
2006/06/07 08:40:09| Store rebuilding is  7.0% complete
2006/06/07 08:40:10| WARNING: newer swaplog entry for dirno 0, fileno 00001520
2006/06/07 08:40:10| WARNING: newer swaplog entry for dirno 0, fileno 00001DDE
2006/06/07 08:40:10| WARNING: newer swaplog entry for dirno 0, fileno 00001DDF
2006/06/07 08:40:10| WARNING: newer swaplog entry for dirno 0, fileno 00001DE3
2006/06/07 08:40:10| WARNING: newer swaplog entry for dirno 0, fileno 00001DF4
2006/06/07 08:40:10| WARNING: newer swaplog entry for dirno 0, fileno 00001DF7
2006/06/07 08:40:10| WARNING: newer swaplog entry for dirno 0, fileno 00001DF9
2006/06/07 08:40:10| WARNING: newer swaplog entry for dirno 0, fileno 00001E02
2006/06/07 08:40:10| WARNING: newer swaplog entry for dirno 0, fileno 00001E03
2006/06/07 08:40:10| WARNING: newer swaplog entry for dirno 0, fileno 00001E06
2006/06/07 08:40:10| WARNING: newer swaplog entry for dirno 0, fileno 00001E08
2006/06/07 08:40:10| WARNING: newer swaplog entry for dirno 0, fileno 000043CD
2006/06/07 08:40:10| WARNING: newer swaplog entry for dirno 0, fileno 000043CE
2006/06/07 08:40:10| WARNING: newer swaplog entry for dirno 0, fileno 000043CF
2006/06/07 08:40:10| WARNING: newer swaplog entry for dirno 0, fileno 000043D0
2006/06/07 08:40:10| WARNING: newer swaplog entry for dirno 0, fileno 00009953
2006/06/07 08:40:10| WARNING: newer swaplog entry for dirno 0, fileno 00009B79
2006/06/07 08:40:10| WARNING: newer swaplog entry for dirno 0, fileno 00009D41
2006/06/07 08:40:10| WARNING: newer swaplog entry for dirno 0, fileno 00009D42
2006/06/07 08:40:10| WARNING: newer swaplog entry for dirno 0, fileno 00009D43
2006/06/07 08:40:10| WARNING: newer swaplog entry for dirno 0, fileno 00009D44
2006/06/07 08:40:10| WARNING: newer swaplog entry for dirno 0, fileno 00009D45
2006/06/07 08:40:10| Done reading /usr/local/squid/cache swaplog (58737 entries)
2006/06/07 08:40:10| Finished rebuilding storage from disk.
2006/06/07 08:40:10|     50431 Entries scanned
2006/06/07 08:40:10|         0 Invalid entries.
2006/06/07 08:40:10|         0 With invalid flags.
2006/06/07 08:40:10|     49049 Objects loaded.
2006/06/07 08:40:10|         0 Objects expired.
2006/06/07 08:40:10|       240 Objects cancelled.
2006/06/07 08:40:10|      1559 Duplicate URLs purged.
2006/06/07 08:40:10|      1140 Swapfile clashes avoided.
2006/06/07 08:40:10|   Took 2.2 seconds (22074.7 objects/sec).
2006/06/07 08:40:10| Beginning Validation Procedure
2006/06/07 08:40:10|   Completed Validation Procedure
2006/06/07 08:40:10|   Validated 47492 Entries
2006/06/07 08:40:10|   store_swap_size = 512310k
2006/06/07 08:40:11| storeLateRelease: released 0 objects
2006/06/07 08:50:04| WARNING: 1 swapin MD5 mismatches
2006/06/07 10:23:57| sslReadServer: FD 14: read failure: (54) Connection reset by peer
2006/06/07 10:23:57| sslReadServer: FD 32: read failure: (54) Connection reset by peer
2006/06/07 10:23:57| sslReadServer: FD 30: read failure: (54) Connection reset by peer
2006/06/07 10:24:37| sslReadServer: FD 17: read failure: (54) Connection reset by peer
2006/06/07 10:24:42| sslReadServer: FD 14: read failure: (54) Connection reset by peer
2006/06/07 12:02:56| sslReadServer: FD 17: read failure: (54) Connection reset by peer
2006/06/07 13:07:22| WARNING: 10 swapin MD5 mismatches
2006/06/07 19:12:34| urlParse: Illegal character in hostname 'hest.ru]'
2006/06/07 19:12:34| urlParse: Illegal character in hostname 'hest.ru]'
2006/06/08 09:10:30| Starting Squid Cache version 2.5.STABLE6 for i386-portbld-freebsd5.3...
2006/06/08 09:10:30| Process ID 519
2006/06/08 09:10:30| With 1792 file descriptors available
2006/06/08 09:10:30| DNS Socket created at 0.0.0.0, port 52597, FD 4
2006/06/08 09:10:30| Adding nameserver 192.168.1.1 from /etc/resolv.conf
2006/06/08 09:10:30| Unlinkd pipe opened on FD 9
2006/06/08 09:10:30| Swap maxSize 512000 KB, estimated 39384 objects
2006/06/08 09:10:30| Target number of buckets: 1969
2006/06/08 09:10:30| Using 8192 Store buckets
2006/06/08 09:10:30| Max Mem  size: 15360 KB
2006/06/08 09:10:30| Max Swap size: 512000 KB
2006/06/08 09:10:30| Store logging disabled
2006/06/08 09:10:30| Rebuilding storage in /usr/local/squid/cache (DIRTY)
2006/06/08 09:10:30| Using Least Load store dir selection
2006/06/08 09:10:30| Set Current Directory to /usr/local/squid/cache
2006/06/08 09:10:30| Loaded Icons.
2006/06/08 09:10:30| Accepting HTTP connections at 192.168.1.1, port 3128, FD 10.
2006/06/08 09:10:30| WCCP Disabled.
2006/06/08 09:10:30| Ready to serve requests.
2006/06/08 09:10:31| Store rebuilding is  6.4% complete
2006/06/08 09:10:32| WARNING: newer swaplog entry for dirno 0, fileno 000014C7
2006/06/08 09:10:32| WARNING: newer swaplog entry for dirno 0, fileno 0000001B
2006/06/08 09:10:32| WARNING: newer swaplog entry for dirno 0, fileno 00001DDF
2006/06/08 09:10:32| WARNING: newer swaplog entry for dirno 0, fileno 00001DE7
(И еще много подобных строк подобного рода)
2006/06/08 09:10:32| Done reading /usr/local/squid/cache swaplog (64022 entries)
2006/06/08 09:10:32| Finished rebuilding storage from disk.
2006/06/08 09:10:32|     53945 Entries scanned
2006/06/08 09:10:32|         0 Invalid entries.
2006/06/08 09:10:32|         0 With invalid flags.
2006/06/08 09:10:32|     51939 Objects loaded.
2006/06/08 09:10:32|         0 Objects expired.
2006/06/08 09:10:32|       422 Objects cancelled.
2006/06/08 09:10:32|      2774 Duplicate URLs purged.
2006/06/08 09:10:32|      1575 Swapfile clashes avoided.
2006/06/08 09:10:32|   Took 2.3 seconds (22544.2 objects/sec).
2006/06/08 09:10:32| Beginning Validation Procedure
2006/06/08 09:10:32|   Completed Validation Procedure
2006/06/08 09:10:32|   Validated 49164 Entries
2006/06/08 09:10:32|   store_swap_size = 523000k
2006/06/08 09:10:33| storeLateRelease: released 0 objects
2006/06/08 09:10:34| WARNING: Disk space over limit: 513234 KB > 512000 KB
2006/06/08 09:35:02| WARNING: 1 swapin MD5 mismatches
2006/06/08 11:39:56| sslReadServer: FD 15: read failure: (54) Connection reset by peer
2006/06/08 12:02:57| WARNING: 10 swapin MD5 mismatches

Из данных сообщений я понимаю, что слетает кэш, squid его восстанавливает, а он опять слетает! Что с этим можно сделать и с чем это связано?

И второе: нужно считать траффик, делать отчеты.
Я поступил вот каким образом:
Так как во внутренней сети домен и почти все в домене, на windows машине поставил squid-NT и настроил его так, чтобы он обращался к данному прокси (NT-шный прокси поставил, чтобы было удобнее пользователей из домена регистрировать в access.log), потом некоторые сервисы работают не через прокси, а через НАТ (клиент-банки, почта), потому решил еще воспользоваться связкой ipfw+ipa, читаю документацию, но что-то не очень врубаюсь. Есть алтернативные, попроще, способы?

Правка | Высказать мнение | Ответить | Cообщить модератору | Наверх

16. "Squid, как корпоративный прокси!!!"  
Сообщение от DeadLoco (??) on 08-Июн-06, 23:38 
>2006/06/08 09:10:32| WARNING: newer swaplog entry for dirno 0, fileno 00001DE7
>(И еще много подобных строк подобного рода)

Причиной является, скорее всего, поврежденный индекс кеша. В корневом каталоге дерева кеша лежит файл swap.state - это индекс, выгружаемый сквидом из памяти во время остановки. Если остановить сквид и этот файл удалить, то сквид начнет строить кеш заново, как при первом запуске. Учитывая, что кеш у вас маленький (500МБ) особой беды не будет, если имеющийся грохнуть.

>И второе: нужно считать траффик, делать отчеты.

SARG. У него можно делать привязку к IP клиентов и к их именам. Дает развернутую статистику по активности клиентов (кто, куда и сколько), по сайтам (популярность), по скачиваниям файла (по расширениям)


>потом некоторые сервисы работают не через прокси,
>а через НАТ (клиент-банки, почта), потому решил еще воспользоваться связкой ipfw+ipa,
>читаю документацию, но что-то не очень врубаюсь. Есть алтернативные, попроще, способы?

Самый простой - пачка правил COUNT в IPFW. Например:

-------------------------------------------------------------------
#!/bin/sh

Tanechka="192.168.1.12"
Lenochka="192.168.1.13"
LANcard="fxp1"
fwcmd="ipfw -q "
MFBank="1.2.3.4 2000"

${fwcmd} add 10000 count tcp from any 25,110 to ${Tanechka} in via ${LANcard}
${fwcmd} add 10001 count tcp from ${Tanechka} to any 25,110 out via ${LANcard}
${fwcmd} add 10002 count tcp from ${MFBank} to ${Tanechka} in via ${LANcard}
${fwcmd} add 10003 count tcp from ${Tanechka} to ${MFBank} out via ${LANcard}
....
${fwcmd} add 10090 count tcp from any 25,110 to ${Lenochka} in via ${LANcard}
${fwcmd} add 10091 count tcp from ${Lenochka} to any 25,110 out via ${LANcard}
....
-------------------------------------------------------------------

Разумеется, все счетчики должны стоять ДО разрешительных и ПОСЛЕ запретительных правил.

Затем по крону из перла запускается нечто, вроде

    open(FWSHOW, "ipfw show | grep count |");
    @fwlog = <FWSHOW>;
    close(FWSHOW);

и результат парсится и складируется, как душе угодно. Хоть на апач, хоть смсками. Как правило, только ограниченный круг лиц имеет выходы наружу через НАТ, поэтому оправдано написание своей, простенькой системы учета этого траффика.

Правка | Высказать мнение | Ответить | Cообщить модератору | Наверх

17. "Squid, как корпоративный прокси!!!"  
Сообщение от Denter on 13-Сен-06, 12:32 
>Все зависит от производительности свичей и х-ра информационных потоков.
>Вообще есть золотое правило, проповедуется cisco:
>80/20 - 80 % трафика должно быть локальным, 20 % должно выходить
>за пределы сегмента.
>Если это не так, то стоит задуматься о перестройке сети.

Офтоп: Я тоже так думал, пока на BCMSN (Building Cisco Multilayer Switched Networks) не попал. Так вот - идеология, продвигаемая Циской сейчас, кардинально изменилась и ориентируется на маршрутизируемые коммутаторы (3-й уровень). Достаточно будет сказать, что теперь они рекомендуют при построении инфраструктуры VLAN'ы определять по географическому признаку, т.е. в идеале оставлять в пределах свичей уровня доступа. Именно потому, что сервера в наше время выносятся в отдельный сегмент и принцип 80/20 сейчас сменился на 20/80. Т.е. 80% трафика выходят за пределы сегмента.

Правка | Высказать мнение | Ответить | Cообщить модератору | Наверх

18. "Squid, как корпоративный прокси!!!"  
Сообщение от Alexander Yakimenko raider email on 18-Сен-06, 09:58 

>
>Все зависит от производительности свичей и х-ра информационных потоков.
>Вообще есть золотое правило, проповедуется cisco:
>80/20 - 80 % трафика должно быть локальным, 20 % должно выходить
>за пределы сегмента.
>Если это не так, то стоит задуматься о перестройке сети.

Нет такого правила, если у тебя коммутатор, работающий на магистрали, держащий с сотню VLAN, о какой 80/20 может идти речь?

Здесь уточнять надо о каких коммутаторах идет речь. Для рабочей группы, не более.

...
Совет простой для построения сети.
Все зависит от бюджета и от поставленной задачи. Если хотим стабильность - переходим на неnoname коммутаторы, минимальный бюджет - купить коммутатор (необязательно управляемый, главное чтобы стабильно работал) и подключить к нему все существующие концентраторы... А вообще идет 2006 год, а у вас до сих пор концентраторы, может следует апгрейдить сеть в ногу с серверами и т.д.?

Правка | Высказать мнение | Ответить | Cообщить модератору | Наверх

4. "Squid, как корпоративный прокси!!!"  
Сообщение от StSphinx (??) on 31-Май-06, 15:03 
>
>>Правило трех хабов и работает собственно для хабов(читай ретрансляторов сигнала).
>>Схема работоспособная, но свичи лучше бы иметь управляемые, IMHO.
>
>То есть, в итоге, такая схема, как я правильно понял, если и
>будет работать, то компьютеры, находящиеся за более чем тремя свитчами видны
>не будут? А так как, нет возможности убрать некоторые из свитчей,
>то выход- добавить на сервер еще один интрефейс и вместо одной
>разбить локалку на две!
>Более ли удачный это вариант или можно иначе?
>И какие примерно настройки
>параметров squid "cache_dir" и "cache_mem" будут наиболее работоспособные?

В каком месте я писал, что со свичами работать не будет?
Правило трех хабов работает только для хабов!
Разницу видите? Если нет, то man.

Правка | Высказать мнение | Ответить | Cообщить модератору | Наверх

Архив | Удалить

Индекс форумов | Темы | Пред. тема | След. тема
Оцените тред (1=ужас, 5=супер)? [ 1 | 2 | 3 | 4 | 5 ] [Рекомендовать для помещения в FAQ]




Спонсоры:
Слёрм
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2020 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру