Собрание заметок об информационных технологиях
При развёртывании разнообразных вариантов высоко-доступных конфигураций Squid может возникнуть задача централизованного сбора, хранения и обработки access-логов с нескольких прокси-серверов Squid. Для решения этой задачи может использоваться система SquidARM, которую мы хотим представить в данной статье.
В очередной раз сталкиваемся с приложением работающем в среде .NET Framework и не способным в своей базовой конфигурации работать с внешними веб-ресурсами через HTTP-прокси (в нашем случае используется Squid). Ряд подобных приложений попросту не имеют среди своих настроек параметров прокси. Соответственно, если такое приложение попытается получить прямой доступ к кому-либо внешнему веб-ресурсу, возникнет ошибка. В данном случае речь идёт о приложении "Потребители продукции импортозамещения" (ptr_client.exe) от Пермского ЦНТИ
В процессе использования прокси-сервера Squid при большом количестве пользователей и относительно небольшой пропускной способности каналов предоставленных интернет-провайдерами может возникнуть потребность ограничить пропускную способность доступа в интернет разным категориям пользователей. Один из основных механизмов позволяющих реализовать такие ограничения в Squid является механизм пулов задержки - Delay pools. Пулы задержки позволяют ограничить скорость получаемого прокси-сервером интернет-трафика в зависимости от разных условий, например в зависимости от того, какой пользователь запрашивает этот трафик. В конфигурации Squid по умолчанию механизм пулов задержки выключен, и поэтому при доступе к прокси-серверу между клиентами используется простая конкуренция по принципу “кто первый встал, того и тапки”.
В общем случае для организации балансировки трафика между двумя WAN-интерфейсами на Ubuntu можно использовать способы описанные в документе Ubuntu-ru - IP-Балансировка: объединяем несколько интернет-каналов в один. В нашем случае требуется организовать немного более простую конфигурацию и поэтому способ её реализации будет несколько более прост. На уже работающих прокси-серверах Squid, собранных в конфигурацию повышенной доступности, имеется по одному WAN-интерфейсу направленному в сторону одного интернет-провайдера. Для повышения доступности Интернет для конечных пользователей мы добавим на прокси-серверы ещё по одному WAN-интерфейсу направленному в сторону другого интернет-провайдера и настроим скрипт перестроения правил маршрутизации в случае возникновения проблем с одним из провайдеров. Здесь мы рассмотрим обновлённый вариант такой настройки (без использования multipath-маршрутизации).
C помощью описанной в предыдущей заметке конфигурации UCARP можно повысить доступность не только Squid, но и других приложений, например того же веб-сервера Apache, который отвечает у нас за раздачу пользователям файла авто-конфигурации прокси wpad.dat, как это было описано ранее.
Несмотря на довольно стабильную работу прокси-сервера Squid в средах с большим количеством пользователей, может возникнуть желание повышения уровня доступности такого важного на сегодняшний день информационного ресурса, как доступ в Интернет для конечных пользователей. В этой заметке будет рассмотрен пример настройки двух прокси-серверов Squid для повышения доступности с параллельным распределением нагрузки между этими серверами.
В данном случае это непринципиальный вопрос. Утилита обновления микрокода не предъявляет претензий к версии драйвера.
А точно порядок установки именно такой - сперва драйвер, а потом firmware?
RSS - Записи
Последние комментарии