Доброго времени суток!
Хотел бы посоветоваться с умудренными опытом гуру по поводу вот какой темы!
Есть компьютер, который прочат сделать сервером интернет, комплектация такая:
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 LANInternet_Server обозначает вышеуказанный сервер, который смотрит одним интрефейсом во внутреннюю локальную сеть LAN, а вторым наружу в интернет. Причем, там где написано LAN, там к свитчу подключены компы локалки.
Вот после такой замысловатой схемы у меня возник второстепенный вопросик: все ли компьютеры локалки увидят при такой схеме друг друга или же по правило трех hub'ов тут тоже действует и будут глюки???Основная задумка такова:
Поставить на сервак proxy squid и проверять траффик с помощью ClamAV через icap, чтобы все в локалки брали интернет через этот прокси! Также будет настроен IPFW, и что-нить для подсчета траффика! Кстати, посоветуйте, что лучше для этого использовать: средства IPFW, или отдельные программы типа trafd???Специалисты, подскажите, при такой скорости выделенного канала, количестве компьютеров и архитектуре самой сети эта идея способна жить и хорошо работать?
Заранее, спасибо за все советы!!!
>Доброго времени суток!
>Хотел бы посоветоваться с умудренными опытом гуру по поводу вот какой темы!
>
>Есть компьютер, который прочат сделать сервером интернет, комплектация такая:
>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.
>Правило трех хабов и работает собственно для хабов(читай ретрансляторов сигнала).
>Схема работоспособная, но свичи лучше бы иметь управляемые, IMHO.То есть, в итоге, такая схема, как я правильно понял, если и будет работать, то компьютеры, находящиеся за более чем тремя свитчами видны не будут? А так как, нет возможности убрать некоторые из свитчей, то выход- добавить на сервер еще один интрефейс и вместо одной разбить локалку на две!
Более ли удачный это вариант или можно иначе?
И какие примерно настройки
параметров squid "cache_dir" и "cache_mem" будут наиболее работоспособные?
>>Правило трех хабов и работает собственно для хабов(читай ретрансляторов сигнала).
>>Схема работоспособная, но свичи лучше бы иметь управляемые, IMHO.
>
>То есть, в итоге, такая схема, как я правильно понял, если и
>будет работать, то компьютеры, находящиеся за более чем тремя свитчами видны
>не будут?
Объясняю. Хаб (hub) - он, получаемый на один порт сигнал, пихает его на все остальные порты. Поэтому, во избежание "сетевых штормов" и придумали "правило 3 хабов". В отличие от хабов свичи (switch) получаемый сигнал адресуют только на тот порт, куда собственно он и должен идти (согласуясь с внутренней таблицей ARP), поэтому "правило 3 хабов" к свичам неприменимо. Исходя из вышеизложенного, твоя схема вполне работоспособна. Насчет остального посоветовать не могу, сам еще в учащихся NIX-ам.
>>>Правило трех хабов и работает собственно для хабов(читай ретрансляторов сигнала).
>>>Схема работоспособная, но свичи лучше бы иметь управляемые, IMHO.
>>
>>То есть, в итоге, такая схема, как я правильно понял, если и
>>будет работать, то компьютеры, находящиеся за более чем тремя свитчами видны
>>не будут?
>Объясняю. Хаб (hub) - он, получаемый на один порт сигнал, пихает его
>на все остальные порты. Поэтому, во избежание "сетевых штормов" и придумали
>"правило 3 хабов". В отличие от хабов свичи (switch) получаемый сигнал
>адресуют только на тот порт, куда собственно он и должен идти
>(согласуясь с внутренней таблицей ARP), поэтому "правило 3 хабов" к свичам
>неприменимо. Исходя из вышеизложенного, твоя схема вполне работоспособна. Насчет остального посоветовать
>не могу, сам еще в учащихся NIX-ам.А на наиболее удаленных участках сети, где-нибудь на третьем, по счету, свитче тормозов вследствии частого использования одного порта не будет?
>А на наиболее удаленных участках сети, где-нибудь на третьем, по счету, свитче
>тормозов вследствии частого использования одного порта не будет?
Если свичи толковые - нет, не будет, разве что иногда, редко. Хотя, если 1С-ка есть, то она может жрать сетку так, что иногда и гигабитки маловато. А вообще мы несколько отклонились от темы данного форума...
>>>>Правило трех хабов и работает собственно для хабов(читай ретрансляторов сигнала).
>>>>Схема работоспособная, но свичи лучше бы иметь управляемые, IMHO.
>>>
>>>То есть, в итоге, такая схема, как я правильно понял, если и
>>>будет работать, то компьютеры, находящиеся за более чем тремя свитчами видны
>>>не будут?
>>Объясняю. Хаб (hub) - он, получаемый на один порт сигнал, пихает его
>>на все остальные порты. Поэтому, во избежание "сетевых штормов" и придумали
>>"правило 3 хабов". В отличие от хабов свичи (switch) получаемый сигнал
>>адресуют только на тот порт, куда собственно он и должен идти
>>(согласуясь с внутренней таблицей ARP), поэтому "правило 3 хабов" к свичам
>>неприменимо. Исходя из вышеизложенного, твоя схема вполне работоспособна. Насчет остального посоветовать
>>не могу, сам еще в учащихся NIX-ам.Причина не в штормах(это уже следствие), причина в особенностях работы технологии 10Base-T(любой поисковик, ключ: правило 3-4-5 для хабов). Вообще свич и хаб, если и родственники, то очень дальние. Они работают на разных уровнях модели OSI, хаб - физика, банальный усилитель, свич - канальный уровень, имеет дело с адресацией на втором уровне, умеет проверять кадры и знает в какой из своих портов кадр нужно отправить. Вообще внешнее сходство железок как правило людей запутывает.
>А на наиболее удаленных участках сети, где-нибудь на третьем, по счету, свитче
>тормозов вследствии частого использования одного порта не будет?Все зависит от производительности свичей и х-ра информационных потоков.
Вообще есть золотое правило, проповедуется cisco:
80/20 - 80 % трафика должно быть локальным, 20 % должно выходить за пределы сегмента.
Если это не так, то стоит задуматься о перестройке сети.
>>>>>Правило трех хабов и работает собственно для хабов(читай ретрансляторов сигнала).
>>>>>Схема работоспособная, но свичи лучше бы иметь управляемые, IMHO.
>>>>
>>>>То есть, в итоге, такая схема, как я правильно понял, если и
>>>>будет работать, то компьютеры, находящиеся за более чем тремя свитчами видны
>>>>не будут?
>>>Объясняю. Хаб (hub) - он, получаемый на один порт сигнал, пихает его
>>>на все остальные порты. Поэтому, во избежание "сетевых штормов" и придумали
>>>"правило 3 хабов". В отличие от хабов свичи (switch) получаемый сигнал
>>>адресуют только на тот порт, куда собственно он и должен идти
>>>(согласуясь с внутренней таблицей ARP), поэтому "правило 3 хабов" к свичам
>>>неприменимо. Исходя из вышеизложенного, твоя схема вполне работоспособна. Насчет остального посоветовать
>>>не могу, сам еще в учащихся NIX-ам.
>
>Причина не в штормах(это уже следствие), причина в особенностях работы технологии 10Base-T(любой
>поисковик, ключ: правило 3-4-5 для хабов). Вообще свич и хаб, если
>и родственники, то очень дальние. Они работают на разных уровнях модели
>OSI, хаб - физика, банальный усилитель, свич - канальный уровень, имеет
>дело с адресацией на втором уровне, умеет проверять кадры и знает
>в какой из своих портов кадр нужно отправить. Вообще внешнее сходство
>железок как правило людей запутывает.
>
>>А на наиболее удаленных участках сети, где-нибудь на третьем, по счету, свитче
>>тормозов вследствии частого использования одного порта не будет?
>
>Все зависит от производительности свичей и х-ра информационных потоков.
>Вообще есть золотое правило, проповедуется cisco:
>80/20 - 80 % трафика должно быть локальным, 20 % должно выходить
>за пределы сегмента.
>Если это не так, то стоит задуматься о перестройке сети.Структура сети обусловлена расположением компьютеров в здании, поэтому изменить ее очень проблематично и чревато существенными кабельными работами. Предпологается, что траффик будет на 90% к интернет-серверу!
>>>>>>Правило трех хабов и работает собственно для хабов(читай ретрансляторов сигнала).
>>>>>>Схема работоспособная, но свичи лучше бы иметь управляемые, IMHO.
>>>>>
>>>>>То есть, в итоге, такая схема, как я правильно понял, если и
>>>>>будет работать, то компьютеры, находящиеся за более чем тремя свитчами видны
>>>>>не будут?
>>>>Объясняю. Хаб (hub) - он, получаемый на один порт сигнал, пихает его
>>>>на все остальные порты. Поэтому, во избежание "сетевых штормов" и придумали
>>>>"правило 3 хабов". В отличие от хабов свичи (switch) получаемый сигнал
>>>>адресуют только на тот порт, куда собственно он и должен идти
>>>>(согласуясь с внутренней таблицей ARP), поэтому "правило 3 хабов" к свичам
>>>>неприменимо. Исходя из вышеизложенного, твоя схема вполне работоспособна. Насчет остального посоветовать
>>>>не могу, сам еще в учащихся NIX-ам.
>>
>>Причина не в штормах(это уже следствие), причина в особенностях работы технологии 10Base-T(любой
>>поисковик, ключ: правило 3-4-5 для хабов). Вообще свич и хаб, если
>>и родственники, то очень дальние. Они работают на разных уровнях модели
>>OSI, хаб - физика, банальный усилитель, свич - канальный уровень, имеет
>>дело с адресацией на втором уровне, умеет проверять кадры и знает
>>в какой из своих портов кадр нужно отправить. Вообще внешнее сходство
>>железок как правило людей запутывает.
>>
>>>А на наиболее удаленных участках сети, где-нибудь на третьем, по счету, свитче
>>>тормозов вследствии частого использования одного порта не будет?
>>
>>Все зависит от производительности свичей и х-ра информационных потоков.
>>Вообще есть золотое правило, проповедуется cisco:
>>80/20 - 80 % трафика должно быть локальным, 20 % должно выходить
>>за пределы сегмента.
>>Если это не так, то стоит задуматься о перестройке сети.
>
>Структура сети обусловлена расположением компьютеров в здании, поэтому изменить ее очень проблематично
>и чревато существенными кабельными работами. Предпологается, что траффик будет на 90%
>к интернет-серверу!Структуру можно отвязать от географии используя управляемые свичи и разбивку сети на VLAN'ы. Но это уже совсем другая тема.
>>>>>>>Правило трех хабов и работает собственно для хабов(читай ретрансляторов сигнала).
>>>>>>>Схема работоспособная, но свичи лучше бы иметь управляемые, IMHO.
>>>>>>
>>>>>>То есть, в итоге, такая схема, как я правильно понял, если и
>>>>>>будет работать, то компьютеры, находящиеся за более чем тремя свитчами видны
>>>>>>не будут?
>>>>>Объясняю. Хаб (hub) - он, получаемый на один порт сигнал, пихает его
>>>>>на все остальные порты. Поэтому, во избежание "сетевых штормов" и придумали
>>>>>"правило 3 хабов". В отличие от хабов свичи (switch) получаемый сигнал
>>>>>адресуют только на тот порт, куда собственно он и должен идти
>>>>>(согласуясь с внутренней таблицей ARP), поэтому "правило 3 хабов" к свичам
>>>>>неприменимо. Исходя из вышеизложенного, твоя схема вполне работоспособна. Насчет остального посоветовать
>>>>>не могу, сам еще в учащихся NIX-ам.
>>>
>>>Причина не в штормах(это уже следствие), причина в особенностях работы технологии 10Base-T(любой
>>>поисковик, ключ: правило 3-4-5 для хабов). Вообще свич и хаб, если
>>>и родственники, то очень дальние. Они работают на разных уровнях модели
>>>OSI, хаб - физика, банальный усилитель, свич - канальный уровень, имеет
>>>дело с адресацией на втором уровне, умеет проверять кадры и знает
>>>в какой из своих портов кадр нужно отправить. Вообще внешнее сходство
>>>железок как правило людей запутывает.
>>>
>>>>А на наиболее удаленных участках сети, где-нибудь на третьем, по счету, свитче
>>>>тормозов вследствии частого использования одного порта не будет?
>>>
>>>Все зависит от производительности свичей и х-ра информационных потоков.
>>>Вообще есть золотое правило, проповедуется cisco:
>>>80/20 - 80 % трафика должно быть локальным, 20 % должно выходить
>>>за пределы сегмента.
>>>Если это не так, то стоит задуматься о перестройке сети.
>>
>>Структура сети обусловлена расположением компьютеров в здании, поэтому изменить ее очень проблематично
>>и чревато существенными кабельными работами. Предпологается, что траффик будет на 90%
>>к интернет-серверу!
>
>Структуру можно отвязать от географии используя управляемые свичи и разбивку сети на
>VLAN'ы. Но это уже совсем другая тема.Подведя итог, можно ли надеяться что скорость доступа к интернет будет приличной? И, все-таки, какими при количестве компьютеров ~60 сделать настройки размера кэша прокси и использования опер. памяти?
>>>>>>>>Правило трех хабов и работает собственно для хабов(читай ретрансляторов сигнала).
>>>>>>>>Схема работоспособная, но свичи лучше бы иметь управляемые, IMHO.
>>>>>>>
>>>>>>>То есть, в итоге, такая схема, как я правильно понял, если и
>>>>>>>будет работать, то компьютеры, находящиеся за более чем тремя свитчами видны
>>>>>>>не будут?
>>>>>>Объясняю. Хаб (hub) - он, получаемый на один порт сигнал, пихает его
>>>>>>на все остальные порты. Поэтому, во избежание "сетевых штормов" и придумали
>>>>>>"правило 3 хабов". В отличие от хабов свичи (switch) получаемый сигнал
>>>>>>адресуют только на тот порт, куда собственно он и должен идти
>>>>>>(согласуясь с внутренней таблицей ARP), поэтому "правило 3 хабов" к свичам
>>>>>>неприменимо. Исходя из вышеизложенного, твоя схема вполне работоспособна. Насчет остального посоветовать
>>>>>>не могу, сам еще в учащихся NIX-ам.
>>>>
>>>>Причина не в штормах(это уже следствие), причина в особенностях работы технологии 10Base-T(любой
>>>>поисковик, ключ: правило 3-4-5 для хабов). Вообще свич и хаб, если
>>>>и родственники, то очень дальние. Они работают на разных уровнях модели
>>>>OSI, хаб - физика, банальный усилитель, свич - канальный уровень, имеет
>>>>дело с адресацией на втором уровне, умеет проверять кадры и знает
>>>>в какой из своих портов кадр нужно отправить. Вообще внешнее сходство
>>>>железок как правило людей запутывает.
>>>>
>>>>>А на наиболее удаленных участках сети, где-нибудь на третьем, по счету, свитче
>>>>>тормозов вследствии частого использования одного порта не будет?
>>>>
>>>>Все зависит от производительности свичей и х-ра информационных потоков.
>>>>Вообще есть золотое правило, проповедуется cisco:
>>>>80/20 - 80 % трафика должно быть локальным, 20 % должно выходить
>>>>за пределы сегмента.
>>>>Если это не так, то стоит задуматься о перестройке сети.
>>>
>>>Структура сети обусловлена расположением компьютеров в здании, поэтому изменить ее очень проблематично
>>>и чревато существенными кабельными работами. Предпологается, что траффик будет на 90%
>>>к интернет-серверу!
>>
>>Структуру можно отвязать от географии используя управляемые свичи и разбивку сети на
>>VLAN'ы. Но это уже совсем другая тема.
>
>Подведя итог, можно ли надеяться что скорость доступа к интернет будет приличной?
>И, все-таки, какими при количестве компьютеров ~60 сделать настройки размера кэша
>прокси и использования опер. памяти?Да. можно. Настройки подбираются эскпериментальным путем, под конкретную ситуацию.
Хотя что вас тут заботить, я незнаю. Squid способен обслужить и большее число клиентов и более толстый канал.
>Подведя итог, можно ли надеяться что скорость доступа к интернет будет приличной?
>И, все-таки, какими при количестве компьютеров ~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%
>>Подведя итог, можно ли надеяться что скорость доступа к интернет будет приличной?
>>И, все-таки, какими при количестве компьютеров ~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%
Большущее спасибо за такое описание, многое стало попонятней, вот только не врубился для чего размер процесса так увеличивать надо и как это скажется и что такое поллинг?
>для чего размер процесса так увеличивать надо и как это скажетсяПри работе сквид держит в памяти индекс кешей, а для большого (и эффективного кеша) индексы требуют много памяти. Если не увеличивать размер процесса в ядре, то максимальный размер процесса - и кода и данных - ограничивается 256-ю мегабайтами. Жирный кеш очень быстро съедает этот объем и появляются ошибки xmalloc: невозможно выделить 4096 байт. Это типовая проблема, хорошо описанная в факе:
http://wiki.squid-cache.org/SquidFaq/SquidMemory#head-39e12a...>и что такое поллинг?
Вот, что пишет об этом 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 долларов не стоят геморроя по борьбе с родовыми болячками железок.
Большое спасибо за подробный и понятный ответ!Дело в том что я далеко не специалист в 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, читаю документацию, но что-то не очень врубаюсь. Есть алтернативные, попроще, способы?
>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/shTanechka="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);и результат парсится и складируется, как душе угодно. Хоть на апач, хоть смсками. Как правило, только ограниченный круг лиц имеет выходы наружу через НАТ, поэтому оправдано написание своей, простенькой системы учета этого траффика.
>Все зависит от производительности свичей и х-ра информационных потоков.
>Вообще есть золотое правило, проповедуется cisco:
>80/20 - 80 % трафика должно быть локальным, 20 % должно выходить
>за пределы сегмента.
>Если это не так, то стоит задуматься о перестройке сети.Офтоп: Я тоже так думал, пока на BCMSN (Building Cisco Multilayer Switched Networks) не попал. Так вот - идеология, продвигаемая Циской сейчас, кардинально изменилась и ориентируется на маршрутизируемые коммутаторы (3-й уровень). Достаточно будет сказать, что теперь они рекомендуют при построении инфраструктуры VLAN'ы определять по географическому признаку, т.е. в идеале оставлять в пределах свичей уровня доступа. Именно потому, что сервера в наше время выносятся в отдельный сегмент и принцип 80/20 сейчас сменился на 20/80. Т.е. 80% трафика выходят за пределы сегмента.
>
>Все зависит от производительности свичей и х-ра информационных потоков.
>Вообще есть золотое правило, проповедуется cisco:
>80/20 - 80 % трафика должно быть локальным, 20 % должно выходить
>за пределы сегмента.
>Если это не так, то стоит задуматься о перестройке сети.Нет такого правила, если у тебя коммутатор, работающий на магистрали, держащий с сотню VLAN, о какой 80/20 может идти речь?
Здесь уточнять надо о каких коммутаторах идет речь. Для рабочей группы, не более.
...
Совет простой для построения сети.
Все зависит от бюджета и от поставленной задачи. Если хотим стабильность - переходим на неnoname коммутаторы, минимальный бюджет - купить коммутатор (необязательно управляемый, главное чтобы стабильно работал) и подключить к нему все существующие концентраторы... А вообще идет 2006 год, а у вас до сих пор концентраторы, может следует апгрейдить сеть в ногу с серверами и т.д.?
>
>>Правило трех хабов и работает собственно для хабов(читай ретрансляторов сигнала).
>>Схема работоспособная, но свичи лучше бы иметь управляемые, IMHO.
>
>То есть, в итоге, такая схема, как я правильно понял, если и
>будет работать, то компьютеры, находящиеся за более чем тремя свитчами видны
>не будут? А так как, нет возможности убрать некоторые из свитчей,
>то выход- добавить на сервер еще один интрефейс и вместо одной
>разбить локалку на две!
>Более ли удачный это вариант или можно иначе?
>И какие примерно настройки
>параметров squid "cache_dir" и "cache_mem" будут наиболее работоспособные?В каком месте я писал, что со свичами работать не будет?
Правило трех хабов работает только для хабов!
Разницу видите? Если нет, то man.