Иногда возникает необходимость «подружить» несколько кэширующих прокси-серверов таким образом, чтобы изменить стандартную последовательность обработки запросов с «локальный кэш, интернет» на «локальный кэш, кэш соседнего прокси-сервера, интернет».

Это может быть полезно, если каждый отдел организации имеет свой отдельный прокси-сервер, однако «наружу» все отделы выходят через один общий канал, в этом случае такое объединение кэшей соседних прокси-серверов позволит ускорить загрузку страниц и приведёт к дополнительнй экономии трафика. Также возможна ситуация, когда несколько офисов одной организации подключены к одному провайдеру, и используемый тариф предусматривает более низкую стоимость и/или более высокую скорость внутрисетевого трафика по отношению к внешнему.

Далее будет показано, как можно организовать взаимодействие двух прокси-серверов для взаимного обмена данными из их кэшей.

Начальные условия:

• Два офиса, соединённые с помощью OpenVPN;
• Прокси-сервера обоих офисов работают под управлением Ubuntu Jaunty;
• На обоих прокси-серверах установлен пакет squid (или squid3), который слушает на порту 3128.

Задача:

Настроить оба кэширующих прокси-сервера таким образом, чтобы поиск объекта производился сначала в локальном кэше, потом в кэше соседнего прокси-сервера, и только потом (если раньше объект не был найден) происходил запрос объекта из интернета.

Решение:

Будем считать, что прокси-сервера уже настроены и связаны с помощью OpenVPN, прокси-сервер A имеет адрес 192.168.10.1, а прокси-сервер B - 192.168.10.107. На обоих адресах разрешён весь трафик с «соседнего» адреса. На прокси-сервере A установлен пакет squid3, а на прокси-сервере B - squid.

Сначала рассмотрим, как же именно будут взаимодействовать прокси-сервера. Допустим, что прокси-сервер A получил запрос от клиента, первым делом он будет искать ответ на запрос у себя в кэше. Если ответ найден в кэше - он будет передан клиенту, если же нет - прокси-сервер шлёт ICP (Internet Cache Protocol)-запрос прокси-серверу B. Если ответ есть в кэше прокси-сервера B, то оригинальный HTTP-запрос пересылается на сервер B, там из кэша «достаётся» ответ, возвращается серверу A и оттуда клиенту. Если же кэш прокси-сервера B также не содержит ответа - прокси-сервер A делает запрос в интернет и возвращает клиенту отклик уже оттуда.

Принципиальной разницы между настройками squid3 и squid нет, фактически в пакете squid содержится версия squid 2.7, а в пакете squid3 - версия 3.0, являющаяся продолжением версии 2.7.

Приступаем к настройке. Для начала надо на обоих серверах разрешить ICP-запросы друг от друга. На сервере A для этого нужно в файле /etc/squid3/squid.conf найти строку:

icp_access deny all

и добавить перед ней следующие строки:

acl peer_allow src 192.168.10.107
icp_access allow peer_allow

Затем на сервере B в файле /etc/squid/squid,conf также нужно найти строку:

icp_access deny all

и добавить перед ней строки:

acl peer_allow src 192.168.10.1
icp_access allow peer_allow

Здесь в обоих случаях создаются списки доступа (ACL) с именем peer_allow, в которые входят адреса «соседних» прокси, и разрешается доступ с них на текущий сервер по ICP. По умолчанию для обработки ICP-запросов используется UDP-порт 3130, и мы не будем это менять.

Разрешив прокси-серверам доступ к друг другу по ICP (то есть фактически разрешив прокси-серверам получать информацию о наличии объектов в кэше друг у друга), перейдём, собственно, к настройке использования этой возможности.

Для этого первым делом разрешим использование прокси-серверов друг другому с помощью директивы http_access (например, добавив адреса соседних прокси в ACL localnet).

Затем используем директиву файла конфигурации cache_peer, с помощью которой настраивается взаимодействие с другими прокси-серверами.

На прокси-сервере B нужно добавить в конец файла /etc/squid/squid.conf строку:

cache_peer	192.168.10.1		sibling		3128	3130	no-digest

После чего применить новую конфигурацию squid командой:

squid -k reconfigure

На прокси-сервере A в файл /etc/squid3/squid.conf нужно добавить строку:

cache_peer	192.168.10.107		sibling		3128	3130	background-ping no-digest

и применить новую конфигурацию командой:

squid3 -k reconfigure

Отличие добавляемых строк заключено в опции background-ping, которая появилась в версии squid 3.0, и позволяет периодически в фоновом режиме проверять доступность соседнего прокси-сервера и в случае его недоступности — отключать поиск объектов в его кэше.

На этом в общем-то всё. Система уже работает, однако как быть, если один из прокси-серверов отправляет запросы не напрямую в интернет, а через «родительский» прокси-сервер? Понятно, что у нас будет две директивы cache_peer, однако как указать правильный порядок их перебора? Тут на помощь приходит опция weight директивы cache_peer, с помощью которой задаются приоритеты соседних кэшей (чем больше значение weight, тем приоритетнее кэш).

Допустим, что squid на сервере A пересылает запросы на HAVP, раотающий на localhost:8080, тогда конфигурация этого сервера примет вид:

cache_peer	192.168.10.107		sibling		3128	3130	background-ping no-digest weight=2
cache_peer	127.0.0.1		parent		8080	0	no-query no-digest weight=1

В этом случае при отсутствии файла в локальном кэше, поиск будет произведён в соседнем, и в случае отсутствия файла там - запрос будет переслан на «родительский» прокси.

На этом всё. Приятной работы!

Корректор: Регина Васильева (reggi86@mail.ru)