форумы  помощь  поиск  регистрация  майллист  ВХОД  слежка

Вариант для распечатки		Пред. тема | След. тема
Форумы Настройка Squid и других прокси серверов (Public)
Изначальное сообщение		[Проследить за развитием треда]

"Squid, как корпоративный прокси!!!"

Сообщение от jekka (??) 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 (??) on 31-Май-06, 14:35
	>Правило трех хабов и работает собственно для хабов(читай ретрансляторов сигнала). >Схема работоспособная, но свичи лучше бы иметь управляемые, IMHO. То есть, в итоге, такая схема, как я правильно понял, если и будет работать, то компьютеры, находящиеся за более чем тремя свитчами видны не будут? А так как, нет возможности убрать некоторые из свитчей, то выход- добавить на сервер еще один интрефейс и вместо одной разбить локалку на две! Более ли удачный это вариант или можно иначе? И какие примерно настройки параметров squid "cache_dir" и "cache_mem" будут наиболее работоспособные?
	Правка | Высказать мнение | Ответить | Cообщить модератору | Наверх

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

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

	6. "Squid, как корпоративный прокси!!!"
	Сообщение от alex3 (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 (??) 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 (??) 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 (??) 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 (??) 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 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]