Обычно Web-proxies для балансирования нагрузки считают одной из основных функций сервера ISA Server Enterprise Edition (корпоративная версия). Но для многих, полная стоимость корпоративной версии может быть очень высокой, несмотря на огромное желание такой организации обладать некой избыточностью и механизмом для балансирования нагрузки. В настоящее время стандартная версия не обладает возможностями по балансированию нагрузки, и если вы намереваетесь иметь два или три сервера ISA, которые должны работать совместно и делать это эффективно, то в этой статье может быть содержится ответ на вопрос, как это сделать.
Если вы хотите ознакомиться с остальными частями этой статьи, пожалуйста, прочитайте:
В сервере ISA Server 2004 (и в 2000 для данной задачи), если вы хотите иметь более одного Web-proxy сервера в вашей организации, и заставить их работать совместно и эффективно, как единая единица, то вам необходимо было приобрести корпоративную версию продукта. Корпоративная версия поддерживает протокол Cache Array Routing Protocol (CARP), благодаря чему возникает механизм для совместной работы ваших прокси. Но в действительности ли все так плохо? Если у вас всего несколько сотен пользователей и вам необходима некая избыточность в устройстве Web-proxy, неужели вам необходимо тратиться лицензии корпоративных версий?
Но в действительности некоторые аспекты CARP присутствуют в стандартной версии (Standard Edition) продукты, и ожидают, когда мы о них расскажем. Для двух или трех прокси в массиве вы можете вполне воспользоваться стандартной версией (Standard Edition) продукта, и тем самым сильно сэкономить. Но если у вас более трех прокси, то в этом случае стандартная версия вас не спасет, и вам придется использовать CARP для корпоративной версии, а также все поддерживаемые ей возможности по централизованному управлению.
Итак, предположим, что вы решили использовать два прокси для того, чтобы организовать некую избыточность. Вы хотите, чтобы они оба разделили нагрузку и тем самым хотите избежать сложности и дополнительных затрат на корпоративную версию: какие есть варианты?
Оба этих механизма могут быть использованы для обеспечения чего-то вроде отказоустойчивости (fault-tolerance) и баланса нагрузки, и я подозреваю, что некоторые из вас уже использовали их. В обоих случаях (и в случае с NLB и в случае с общим IP) вы настраиваете общее имя (common name) для указания на все ваши сервера ISA server. Помните, что более современный NLB – это не тот, который поддерживается конфигурацией Microsoft при использовании стандартной версии.
Вы можете настроить ваш браузер напрямую для вашего общего имени для прокси или же, вы можете настроить для автоматического определения “automatically detect” или для автоматического сценария настройки “automatic configuration script”. Эти автоматические настройки имеют преимущества над статическими методами в том, что вы можете указать маршрут для резервной копии на тот случай, если что-то пойдет не так, как было запланировано.
Но знайте, что если вы используете автоматические методы, то браузер (browser) будет загружать файл с конфигурацией с одного из серверов ISA Server (что решается NLB или round-robin), а этот файл затем расскажет браузеру использовать лишь этот прокси (proxy) на все время. Это может быть не то, что вы ожидали для балансирования нагрузки! Для получения быстрой отказоустойчивости при использовании автоматических методов, вы можете настроить параметры на каждом сервере ISA Server, чтобы использовать другой сервер ISA Server, в качестве маршрута отката (backup route). Сервер ISA Server будет тогда добавлять эту информацию в конфигурационный файл (configuration file), который получает браузер.
Большим недостатком этих методов является то, что каждый сервер ISA Server формирует кэш (cache), который будет содержать информацию, которая уже содержится на другом сервер ISA Server. Это неэффективное использование ресурсов.
Если вы настроите параметр для автоматического определения или автоматического сценария настройки в вашем браузере, то конфигурационный файл не должен приходить с сервера ISA – он должен указывать на другое место, в котором содержится настроенный сценарий с конфигурацией, который делаете вы, а не сервер ISA. Этот метод открывает целый набор возможностей по отказоустойчивости и балансированию нагрузки.
Так что такое эти сценарии с конфигурацией? Практически каждый браузер в наши дни поддерживает использование автоматических сценариев с конфигурацией (configuration script). Они написаны на языке JavaScript и браузер запускает их, когда вызывает особую функцию в сценарии. Функция возвращает Web-proxy то, что браузер должен вернуть на соответствующий URL запрос.
Так как же эти сценарии осуществляют балансирование нагрузки? Общий метод использует сценарий, запускающий алгоритм “hash” на запрашиваемый URL и использующий результирующий hash для определения, на какой Web-proxy посылать запрос (алгоритм преобразует строку с адресом URL в уникальный номер, под названием hash). Большое преимущество этого метода заключается в том, что каждый браузер запускает одну и ту же hash функцию, и определяет тот же самый Web-proxy для представленного URL совершенно независимо от Web-proxy сервера. Это значит, что Web-proxies формирует кэш cache, который уникален для этого Web-proxies в результате чего ресурсы используются более экономно.
Существует большое количество алгоритмов (hashing algorithms), которые можно использовать. Кампания Sharp разработала сценарий “Super Proxy Script” в 1996, на который вы можете взглянуть по следующему адресу http://naragw.sharp.co.jp/sps/. Но большинство людей ассоциируют эту технику с CARP.
В этой статье мы разработаем более тонко настроенный сценарий с конфигурацией, который использует CARP. Если это звучит немного пугающе, то не беспокойтесь, не смотря на ваши предубеждения насчет поддержки CARP в корпоративной версии и в стандартной версии (Standard Edition), помните, что мы используем ISA Server Standard Edition, в которой не все так страшно!
Как упоминалось выше, CARP используется в основном в литературе, посвященной корпоративной версии. CARP имеет две реализации — клиентская (client-side) CARP, как мы уже обсуждали, и серверная (server-side) CARP.
Она использует похожий, если не аналогичный механизм хеширования (hashing mechanism), в этот раз сервер определяет заносить ли запрашиваемый URL в свой кэш (cache), а если нет, то какой из его партнеров может иметь его в своем кэше. Это здорово, когда клиент, запрашивающий URL, не может или не хочет поддерживать клиентскую (client-side) CARP (“Secure NAT” клиенты на сервере ISA), или если на сервере есть восходящий массив прокси (upstream proxy arrays), и необходимо выбрать лучший прокси, к которому затем передать запрос.
Сервер ISA Server Enterprise Edition (корпоративная версия) поддерживает серверную реализацию (server-side) CARP, но вы должны подключить такую возможность. Standard Edition (стандартная версия) не поддерживает серверную реализацию (server-side) CARP вовсе.
Клиентскую реализацию (client-side) CARP поддерживает браузер, поэтому не важно, принадлежат ли Web прокси (proxies) корпоративной (Enterprise) или стандартной (Standard Edition) версии (или даже ISA Servers!). Однако, в корпоративной версии Enterprise Edition есть возможность по созданию автоматических файлов с конфигурацией (automatic configuration files) со всеми необходимыми возможностями для клиентской (client-side) CARP, и он делает это даже, если вы не включили CARP в конфигурацию. Но так происходит в стандартной версии (Standard Edition).
Для чего компания Microsoft поместила в стандартную версию (Standard Edition) неработающий код для клиентской реализации (client-side) CARP в сценарии с конфигурации (configuration scripts) для всех остается загадкой, но это означает, что с небольшой помощью мы можем заставить этот сценарий работать.
Поэтому давайте взглянем на сценарий, который формирует ISA Server Standard Edition (стандартная версия). Просто откройте окно браузера (browser) и наберите в поле адреса http://myISAServer:8080/wpad.dat (пожалуйста, используйте при этом ваше название сервера, а не мое!). Сохраните файл, а затем откройте его текстовом редакторе, например в Notepad (блокнот).
Ниже вы увидите, нечто похожее на то, что получилось у вас, хотя кое-что должно отличаться. Да, я добавил немного цвета, для того чтобы вы не слишком испугались и не пропустили все идущее следом. Но не пугайтесь, постепенно все станет понятно и легко.
Так, что же здесь происходит? Ваш браузер, настроенный с помощью этого сценария, загрузит и исполнит его. В результате будет запущен код, который выделен красным цветом, и который задает несколько глобальных переменных и вызывает в процессе несколько функций (выделенный фиолетовым цветом). Затем, в независимости от того необходимо ли браузеру запросить URL или нет, он вызывает функцию под названием FindProxyForURL (выделена оранжевым цветом), которая сообщит proxy серверу посылать ли URL запрос, или вернет команду “DIRECT”, которая означает не использовать Proxy для этого адреса URL.
А для чего же нужен весь код, выделенный синим цветом? Функция FindProxyForURL вызывает эти функции для того, чтобы создать хеш (hash) из адреса URL и вычислить какой из прокси знает о нем. Функция FindProxyForURL в действительности возвращает список прокси, во главе которого находится наиболее подходящий прокси, а в хвосте которого располагается настроенный маршрут отката (backup route), поэтому браузер будет использовать наиболее подходящий прокси для отправки на него запроса URL. Так работает клиентская реализация (client-side) CARP.
Подождите, но этот сценарий пришел к нам с ISA Server Standard Edition (стандартной версии), так для чего нужен весь этот код по хешированию? Совершенно ни для чего! Если вы присмотритесь по-лучше, то увидите, что есть функции, выделенная фиолетовым цветом, под названием MakeProxies, которая возвращает сервер ISA Server, который создал этот сценарий. Поэтому здесь может быть только один прокси и сценарий всегда должен возвращать этот прокси. Как все мы знаем, компания Microsoft любить использовать наши процессоры и загружать их совершенно ненужным кодом, и как превосходно видно из этого примера, наши бедные браузеры должны запускать это в основном бесполезный код каждый раз, когда он запрашивает URL, а может быть даже несколько раз за страницу Web! Конечно это немного чепуха.
Все те, для кого все это кажется сложным, находятся в шоке! Конечно, настоящая проблема заключается в получении результирующего сценария клиентским браузерами, но с ней мы разберемся позднее. Также позднее мы сделаем несколько умных изменений (во второй части), но сейчас возьмемся за основную функциональность сценария.
Взгляните на следующие строчки в сценарии, загруженного с сервера ISA Server:
cNodes=1;
function MakeProxies(){
this[0]=new Node(«10.245.10.254»,0,1.000000);
}
Очевидно, что “10.245.10.254” — это адрес моего сервера ISA Server, и что у вас будет вместо него IP адрес вашего сервера ISA Server. Вы должны указать полностью квалифицированное название домена (qualified domain name), так лучше.
Теперь измените эти строчки, чтобы добавить ваш второй сервер ISA Server:
cNodes=2;
function MakeProxies(){
this[0]=new Node(«10.245.10.254»,2032180928,1.000000);
this[1]=new Node(«10.245.10.253»,2843172549,1.000000);
}
Вот оно!
Хорошо, были добавлены некоторые мистические цифры для того, чтобы алгоритм хеширования (hashing algorithm) смог выбрать один из двух прокси, в зависимости от запрашиваемого URL. Позднее я поясню, откуда возникли эти числа, а пока я буду великолепным математиком!
Взгляните пристальней на следующую строчку:
HttpPort=»8080″;
Она сообщает браузеру, какой порт должен прослушивать ваши серверы ISA Server для запросов для proxy. Есть только одна такая запись, поэтому для этого сценария это значит, что все ваши узлы должны быть настроены на использование этого порта. Порт “8080” – это порт по умолчанию и он изменяется лишь в редких случаях.
Существует два механизма доставки этого сценария на браузеры клиентов; либо настроить браузеры для автоматического определения “automatically detect”, или указать расположение автоматического сценария с конфигурацией “automatic configuration script”. Для этого вам необходимо опубликовать ваш сценарий на соответствующем Web сайте, к которому у браузера есть доступ.
Если вы хотите использовать избыточный прокси (redundant proxies), то вы должны использовать избыточность для Web сайта, на котором вы опубликуете ваш конфигурационный файл (configuration file) или останется по-прежнему одно узкое место. Для того, чтобы проиллюстрировать необходимую конфигурацию я покажу вам создание одного IIS Web-сайта, но вы можете также использовать интранет сайт или любой другой сайт.
Показ я начну с создания нового сайта в менеджере IIS Manager:
Рисунок1
Следующим этапом в мастере Web Site Creation Wizard будет присвоение сайту понятного названия (descriptive name). Я использовал WPAD, которое, как мне кажется достаточно понятное.
Рисунок 2
На следующей странице вы должны указать IP (или оставить его без изменений), и я рекомендую оставить без изменений порт 80, т.к. так будет гораздо проще (более подробно мы обсудим это во второй части). Заголовок узла (host header), вероятно, будет необходим, т.к. порт 80 может быть открыт для использования другими виртуальными серверами (virtual servers).
Рисунок 3
Помните, что ваш DNS должен распознавать адрес, который используется в загловке узла (host-header). У вас может быть две записи, указывающие на два Web сайта (DNS round-robin).
Следуя дальше, вы должны обеспечить место для файла, и обратить внимание, что к этому сайту необходим анонимный доступ (anonymous access). На следующей странице мастера Wizard необходим задать разрешения для доступа (access permissions) – для этого сайта вам необходимо разрешение на чтение (Read permission) (не нужны разрешения на запись или исполнение).
Рисунок 4
После завершения работы мастера (Wizard) будет завершена основная конфигурация соответствующего Web-сайта. Далее дело за тем, чтобы скопировать ваш конфигурационный сценарий (configuration script) в соответствующее место (в нашем случает это C:\Inetpub\wpadroot) и разрешить анонимный доступ на чтение к этому файлу (обычно IUSR_Servername).
Рисунок 5
Проверьте, что все правильно, найдя файл в этом месте и загрузив его (в этом примере адрес URL будет таким http://wpad.company1.local/wpad.dat).
Я назвал конфигурационный сценарий (configuration script) WPAD.DAT, хотя вы можете назвать его, как захотите.
Ручная настройка Internet Explorer для использования конфигурационного файла очень проста. Начните с выбора Internet Options (параметры интернет) из меню Tools (инструменты).
Нам необходим параметр Lan Settings (параметры локальной сети), который можно найти на странице Connections (соединения).
Рисунок 6
Введите URL адрес к файлу WPAD.DAT, который вы опубликовали и нажмите на кнопку OK.
Рисунок 7
Теперь все завершено. Перейдите к Internet Web-сайту и браузер начнет использовать конфигурационный сценарий (configuration script) для выбора прокси, которому посылать запросы. Например так:
Рисунок 8
Ах… Вероятно мне необходимо было настроить мои правила на сервере ISA Server! Но ничто лучше этого не докажет, что мы проходим через ISA Server, чем эта маленькая страница.
Конечно, вручную настраивать браузеры это не то, чего бы вам хотелось, если у вас более 100 клиентов, с которыми вы имеет дело. Политика групп (Group Policy) – это отличный способ для конфигурации множества клиентов, но я хочу оставить это обсуждение на вторую часть. Также во второй части мы рассмотрим другую возможность по автоматической конфигурации Automatically detect settings (автоматически определять настройки), но учтите, что есть аргументы против такого подхода.
Но перед тем, как мы закончим …
Если вы помните, были две магические цифры, которые мы вводили в сценарий, которые должен был использовать алгоритм хеширования (hashing algorithm), чтобы гарантировать, что каждый из серверов ISA Server получает одинаковую степень нагрузки. Эти числа 2032180928 и 2843172549. Я должен быть честным и объяснить, откуда они взялись!
Я установил пробную 120-дневную версию сервера ISA Server 2004 Enterprise Edition на несколько виртуальных машин и проверил эти значения в файле WPAD.DAT, загруженном с одного из этих серверов. Да это обман, но очень эффективный!
Вы можете использовать тот же самый трюк, для вычисления других величин в сценарии, но что бы вы ни делали, не устанавливайте пакет обновлений ISA Server 2004 Service Pack 2: SP2 вносит изменения в корпоративную версию и изменяет алгоритм хеширования (hashing algorithm), который используется конфигурационном сценарии (configuration script).
Между прочим, магическое число для третьего сервера ISA Server в массиве 3804533832, а два других при этом останутся без изменений.
www.isaserver.org
Tags: cache, carp, dns, domain, ISA Server, nat, proxy, redirect