On Fri, Jan 28, 2011 at 11:48:12PM +0200, Vladimir Litovka wrote:
привет,
два вопроса -
1) что нынче с прокси-серверами? понятно, squid. А какие есть ему реальные (с точки зрения производительности и featureset) альтернативы?
Нету. Ибо, по большому счету, незачем - на кэшировании как таковом ты выиграешь не более 10% траффика, и это вряд-ли окупит стоимость построения и поддержки мощной прокси.
2) можно-ли на рекомендуемом (в смысле - на том, который кто рекомендует) прокси-сервере делать выборочное проксирование контента? Что я имею в виду - пришел запрос и если это не то, что интересно, то отправлять запрос дальше, но подспуфив оригинальный адрес (чтобы ответ от Web-сервера даже не попадал на прокси).
Так, чтобы ответ вообще не шел через proxy - нельзя в любом случае. Так, чтобы ответ не кешировался или чтобы запрос приходил на сервер "с оригинального ip-адреса" - первое делается вообще элементарно, второе в зависимости от задачи.
3) можно-ли собирать в кластер рекомендуемый прокси? ну типа - внешний диспетчер запросов, пачка сквидов которые работают с общим стораджем и общим индексом. На сайте сквида есть словесные описания викимедиа и фликра, но дизайнов нетути.
Просто поставить в параллель N+1 squid'ов, настроить между ними icp-peering и обеспечить нормальный failover "любым методом" (их более чем один, например, freebsd'шники предпочитают carp, linux'оиды - heartbeat или keepalived, а некоторые Стесины так и вообще на обычной quagga'е это еще в девяностых годах делали) ? PS: У викимедии/flickr'а решение скорее другого класса - у них не обычный proxy, стоящий "рядом с клиентом" и управляемый клиентским ISP, а, так называемый reverse-proxy, стоящий рядом с их же server farm. Для такой задачи нужно смотреть уже не столько на squid, сколько на nginx и varnish. Или на haproxy, он, хоть и не кэширующий, но в некоторых случаях дает nginx'у прикурить. -- In theory, there is no difference between theory and practice. But, in practice, there is.