Red Line Software - мы помогаем вам управлять эффективностью работы вашего офиса.

Это третья часть статьи, посвященной работам после установки ISA-сервера с настройками Unihomed Workgroup в режиме web-прокси.

Если вы хотите прочесть предыдущие части статьи, воспользуйтесь ссылками:

• Часть 1
• Часть 2

Настройки правил web-цепочки

Правила web-цепочки позволяют соединять последующий ISA-сервер с предыдущим ISA-сервером, а также и web-прокси не на основе ISA-сервера. Соединение серверов web-прокси дает возможность настроить иерархическое кэширование, в отличие от параллельного кэширования при массиве из нескольких ISA-серверов. Иерархическое и параллельное кэширование можно комбинировать для увеличения производительности и уменьшения использования общей пропускной способности интернет-соединений, WAN-соединений и даже соединений во внутренней сети.

Самое популярное использование web-цепочки – это соединение ISA-серверов филиалов и ISA-серверов головного офиса. Такая схема дает следующие преимущества:

• Содержимое, запрашиваемое всеми филиалами и головным офисом, кэшируется на массиве ISA-серверов главного офиса. Это уменьшает использование пропускной способности интернет-соединений
• Содержимое, запрашиваемое каждым филиалом, кэшируется на локальном массиве ISA-серверов. Это уменьшает использование пропускной способности WAN- или интернет-соединений филиала
• Содержимое web-серверов головного офиса может кэшироваться динамически и подгружаться в кэш филиалов. Таким образом, данное содержимое становится доступным для филиалов даже при нарушениях в работе WAN- или интернет-соединений.

С увеличением популярности схемы использования ISA-сервера в филиалах возрастет и использование правил web-цепочки.

Для создания правила web-цепочки, щелкните по узлу Networks (Сети) в левой части консоли управления ISA-сервером, а затем выберите вкладку Web Chaining Rules (Правила web-цепочки). Далее выполните следующее:

1. Выберите вкладку Tasks (Задачи) из панели задач и нажмите Create New Web Chaining Rule (Создать новое правило web-цепочки).
   
   Рисунок 1
2. На странице Welcome to the New Web Chaining Rule Wizard (Начало работы мастера правил web-цепочки) введите имя правила в поле Web chaining rule name (Имя правила web-цепочки). В нашем примере мы соединим ISA-сервер филиала с массивом в главном офисе, поэтому назовем правило Branch to Main Array. Нажмите Next (Далее).
   
   Рисунок 2
3. На странице Web Chaining Rule Destination (Назначение правила web-цепочки) нажмите кнопку Add (Добавить). В диалоговом окне Add Network Entities (Добавить сетевые элементы) выберите назначение для применения правила web-цепочки. Поскольку мы хотим, чтобы все запросы к web-содержимому (не важно, где расположенному) переадресовывались на массив главного офиса, мы выберем запись All Networks (and Local Host) (Все сети (и локальные узлы)). В диалоговом окне Add Network Entities (Добавить сетевые элементы) нажмите Close (Закрыть), а затем Next (Далее).
   
   Рисунок 3
4. На странице Request Action (Действие по запросу) вы настраиваете маршрутизацию запроса ISA-сервером до места назначения. По умолчанию запрос переадресуется непосредственно на web-сайт назначения. Однако при использовании web-цепочек вам необходимо переадресовать запрос на другой web-прокси. В этом случае вам нужно выбрать вариант Redirect requests to the specified upstream server (Переадресовать запрос на указанный сервер). При выборе этого варианта следующая страница мастера запросит у вас детали web-прокси. Выберите данную опцию и нажмите Next (Далее).
   
   Рисунок 4
5. На странице Primary Routing (Первичная маршрутизация) укажите имя предыдущего массива ISA-серверов. Можете не менять порты по умолчанию, если вы не изменяли их на массиве. В нашем примере имя разрешается в имя одного из членов домена главного офиса. Поскольку ISA-сервер филиала получает сценарий автонастройки от массива главного офиса, у него есть список имен всех серверов массива, и он переадресует запрос на нужный член массива главного офиса с помощью алгоритма CARP (CARP позволяет ISA-серверу филиала выполнять маршрутизацию web-запросов на стороне клиента на член массива web-кэширования, отвечающего за нужный URL).
   Если члену массива для предоставления web-доступа требуются учетные данные, нажмите кнопку Set Account (Настроить учетные данные) и введите необходимые учетные данные. Нажмите OK для сохранения информации об учетных данных, а затем выберите протокол аутентификации из выпадающего списка Authentication (Аутентификация). Поскольку мы всегда делаем ISA-сервер членом домена (лучший метод использования ISA-сервера), мы можем использовать встроенную аутентификацию. Это позволит нам отказаться от использования SSL для защиты соединений между ISA-сервером филиала и массивом главного офиса. На странице Primary Routing (Первичная маршрутизация) нажмите Next (Далее).
   
   Рисунок 5
6. На странице Backup Action (Резервное действие) вы выбираете маршруты web-запросов при недоступности предыдущего ISA-сервера (web-прокси). В нашем примере предположим, что у филиала есть собственное интернет-соединение. Поэтому выберем вариант Retrieve requests directly from the specified destination (Получать запросы непосредственно из указанного места назначения), и все соединения будут переадресовываться от ISA-сервера филиала прямо на интернет-серверы, а не на массив web-кэширования главного офиса. Нажмите Next (Далее).
   
   Рисунок 6
7. На странице Completing the New Web Chaining Rule Wizard (Завершение работы мастера правил web-цепочки) нажмите Finish (Завершить).
   
   Рисунок 7

Должен отметить, что правила web-цепочки дают вам гибкость управления ISA-сервером web-запросами от клиентов web-прокси. Данный пример показывает лишь один из множества возможных сценариев. В нашей книге по ISA Server 2006 мы посвятим достаточное количество времени обсуждению сценариев цепочек web-прокси, и больше узнаете обо всем этом. Естественное, в книге будет гораздо больше вариантов настройки правил web-цепочки, чем я могу описать в данном примере.

Включение и настройка web-кэширования

Даже при использовании ISA-сервера с настройками Unihomed Workgroup в режиме web-прокси по умолчанию функция web-кэширования не включена. Вы должны понимать разницу между web-прокси и web-кэшированием. К сожалению, большинство людей путают данные термины и воспринимают их как синонимы. Это огромнейшая ошибка, ведущая ко многим недоразумениям, которых следует избегать.

Сервер Web-прокси – это компьютер, который обрабатывает web-запросы от клиентов web-прокси. Компоненты прокси могут аутентифицировать пользователей, выполнять перезапись URL, выполнять нормализацию web-запросов и протоколов сопряжения и т.д. А сервер Web-кэширования выполняет только одну функцию: он кэширует web-содержимое. В большинстве случаев, сервера web-прокси тоже выполняют действия по кэшированию, хотя это и не требуется от них. По умолчанию ISA-сервер настроен как сервер web-прокси через фильтр web-прокси, расположенный в службах брандмауэра ISA-сервера. Однако, ISA-сервер не является сервером web-кэширования по умолчанию. Если вы хотите использовать web-кэширование, вам нужно включить эту функцию.

Для включения функции web-кэширования на ISA-сервере выполните следующее:

1. В консоли управления ISA-сервером выберите узел Cache (Кэширование), который находится под узлом Configuration (Настройки) в левой части консоли. Выберите вкладку Cache Drives (Диски для кэширования) и нажмите Properties (Свойства).
   
   Рисунок 8
2. В диалоговом окне Properties (Свойства) выберите диск, на котором вы хотите сохранять кэш. В идеале это должен быть диск, отличный от тех, на которых расположена операционная система и файлы журналов. При оптимальной конфигурации ISA-сервер имеет как минимум три диска: для операционной системы и установки программного обеспечения ISA-сервера; для хранения журналов в текстовом формате и формате MSDE; и для хранения кэша. Дополнительные диски требуются для внедрения RAID для устойчивости к отказам, но для кэша RAID не нужен, поскольку содержимое кэша не используется для долгого хранения. В нашей книге о ISA Server 2006 вы найдете рекомендации по оптимальным конфигурациям дисков и RAID.

После выбора диска введите объем дискового пространства, который вы хотите использовать для кэширования. Оценки необходимого дискового пространства для кэша различны. Я считаю, что 5-10 МБ на пользователя достаточно, но оценивать оптимальный размер кэша следует, исходя из вашей схемы развертывания сети.

Например, если вы используете ISA-сервер только для публикации web-сайтов, вам требуется достаточно большой объем для кэширования всего содержимого ваших опубликованных сайтов. При использовании ISA-сервера в качестве прокси лучше всего ограничить размер кэша в зависимости от скорости дисков. Следует также пользоваться информацией счетчиков производительности web-кэша ISA-сервера. Для добавления значения нажмите Set (Установить), а затем OK.

Рисунок 9

Детальную информацию об оптимизации Web-кэширования ISA-сервера можно получить на сайте Microsoft в статье http://www.microsoft.com/technet/prodtechnol/isa/2004/plan/bestpractices.mspx

Отключение ненужных приложений и web-фильтров

Приложения и web-фильтры расширяют возможности ISA-сервера. Они безопасно управляют сложными протоколами, производят обычную проверку на уровне приложений протоколов приложений, защищают службы от переполнения буфера, добавляют поддержку улучшенной аутентификации и т.д. Однако приложения и web-фильтры могут занимать ресурсы памяти и процессора, которые могли бы использоваться для другого.

Поэтому следует отключить неиспользуемые фильтры. При использовании Unihomed ISA-сервера многие фильтры не нужны, поскольку Unihomed ISA-сервер в режиме web-прокси поддерживает только HTTP, HTTPS (SSL) и TFTP. Вы можете отключить фильтры, которые обслуживают и защищают другие протоколы, поскольку ISA-сервер не будет получать запросы по ним.

Для отключения фильтров щелкните по узлу Add ins (Дополнения), расположенному под узлом Configuration (Настройки) в левой части консоли. Выберите вкладку Application Filters (Фильтры приложений) (Рисунок 10). Правой кнопкой щелкните по ненужному вам фильтру и выберите Disable (Отключить). На Рисунке 10 отключены все фильтры, которые не относятся к Unihomed ISA-серверу в режиме web-прокси. Отключите эти же фильтры и в своей конфигурации Unihomed ISA-сервера.

Рисунок 10

Щелкните по вкладке Web Filters (Web-фильтры). Web-фильтры – это дополнительные модули ISAPI для фильтра web-прокси ISA-сервера. Это «фильтры, привязанные к фильтру». Обратите внимание, что по умолчанию включены все фильтры, кроме DiffServ. Следует проверить каждый фильтр на целесообразность использования его в вашей организации. Если один или несколько фильтров вы точно не будете использовать (например, фильтр аутентификации RADIUS), отключите их.

Рисунок 11

Настройка предпочтений сжатия

ISA-сервер можно настроить на поддержку запросов к сжатому содержимому. Данная функция впервые была реализована в ISA 2004 SP2. Следует аккуратно использовать эту возможность, поскольку ISA-сервер поддерживает не все методы сжатия, и к тому же данная функция имеет тенденцию к созданию большого количества ошибок, связанных с альтернативными методами сжатия. Однако, есть сценарий, при котором компрессия очень даже полезна: при использовании филиалов, если ISA-серверы филиалов связаны в цепочку web-прокси с предыдущими ISA-серверами из массива web-кэширования.

Для доступа к предпочтениям сжатия HTTP щелкните по узлу General (Общие), который находится под узлом Configuration (Настройки) консоли ISA-сервера. В средней части консоли щелкните по ссылке Define HTTP Compression Preferences (Определить предпочтения HTTP-компрессии). Откроется вкладка General (Общие) (Рисунок 12).

По умолчанию опция Enable HTTP compression (Включить HTTP-компрессию) включена. Для отключения поддержки HTTP-компрессии удалите отметку с этого параметра.

Рисунок 12

В диалоговом окне HTTP Compression (HTTP-компрессия) выберите вкладку Return Compressed Data (Возвращать данные в сжатом виде). Здесь вы можете настроить ISA-сервер на использование сжатия при ответе, если клиент запрашивает данные с указанных вами сетевых ресурсов. Например, если вы хотите, чтобы клиенты могли запрашивать сжатое содержимое у интернет-узлов, вы можете указать здесь внутреннюю сеть ISA-сервера. Обратите внимание, что у вас есть возможность устанавливать исключения и определять типы содержимого для сжатия.

Важно отметить, что когда компания Microsoft разрабатывала поддержку сжатого содержимого, имелся в виду сценарий с использованием главного офиса и филиалов, при котором ISA-сервер запрашивает сжатое содержимое у массива главного офиса.

Рисунок 13

В диалоговом окне HTTP Compression (HTTP-компрессия) выберите вкладку Request Compressed Data (Запрашивать данные в сжатом виде). Здесь вы можете указать, какие сетевые элементы запрашивают сжатое HTTP-содержимое, если запросы посылаются к этим сетевым элементам. Например, если вы хотите, чтобы ISA-сервер запрашивал данные от web-серверов Интернета в сжатом виде, добавьте в список внешнюю сеть ISA-сервера по умолчанию. Еще раз повторю, что все не так просто, как кажется, поскольку данная функция разработана для конфигурации с использованием цепочки web-прокси между филиалами и главным офисом.

Рисунок 14

Я понимаю, что выгляжу глупым при объяснении настройки поддержки сжатия на ISA-сервере. Данный вопрос достаточно сложный, есть несколько возможных сценариев, и каждый требует своих настроек. Дополнительную информацию о поддержки HTTP-компрессии ISA-сервером можно получить на сайте http://www.microsoft.com/technet/prodtechnol/isa/2004/plan/sp2.mspx

Резюме

В данной статье мы продолжили обсуждение пост-установочных работ для ISA-сервера с настройками Unihomed Workgroup в режиме web-прокси, единственном члене массива серверов. Почти все закончено! В следующей части мы закончим рассматривать работы после установки сервера и перейдем к более интересным темам, таким как публикация группы внешних серверов Exchange!

Автор: Томас Шиндер (Thomas Shinder)

Доктор Томас Шиндер (Thomas W. Shinder) является MCSE, MCP+I и MCT. Он работает в качестве инструктора и консультанта по технологиям в Dallas-Ft. Worth муниципальном районе, помогая в разработке и внедрении коммуникационных стратегий, основанных на IP, для таких больших фирм, как Xerox, Lucent и FINA.